TlbImp, the .Net tool to create Interop assemblies from COM type libraries, contains an optimization that presumably aims at making the consumption of the Interop assembly easier, but ultimately is a nuisance. Consider the following IDL code:
import "oaidl.idl"; import "ocidl.idl"; [ uuid( a657ef35-fea1-40ad-86d8-bb7b6085a0a3 ), version( 1.0 ) ] library Test { [ object, uuid( 84b2f017-b8fe-4c2c-87b8-0587b4bf5507 ), version( 1.0 ), oleautomation ] interface IFoo : IUnknown { HRESULT Foo(); } [ object, uuid( 13d950d6-beb3-4dd3-957b-88b0e5eb5e3f ), version( 1.
Continue »
The cfix 1.2 package as released last week contained a rather stupid bug that the new build, 1.2.0.3244, now fixes: the amd64 binaries cfix64.exe and cfixkr64.sys were wrongly installed as cfix32.exe and cfixkr32.sys, respectively. Not only did this stand in contrast to what the documenation stated, it also resulted in cfix being unable to load the cfixkr driver on AMD64 platforms.
The new MSI package is now available for download on Sourceforge.
Continue »
cfix 1.2, which has been released today, introduces a number of new features, the most prominent being improved support for C++ and additional execution options.
New C++ API To date, cfix has primarily focussed on C as the programming language to write unit tests in. Although C++ has always been supported, cfix has not made use of the additional capabilities C++ provides. With version 1.2, cfix makes C++ a first class citizen and introduces an additional API that leverages the benefits of C++ and allows writing test cases in a more convenient manner.
Continue »
The Windows kernel maintains two types of threads – Non-GUI threads, and GUI threads. Non-GUI threads threads use the default stack size of 12KB (on i386, which this this discussion applies to) and the default System Service Descriptor table (SSDT), KeServiceDescriptorTable. GUI threads, in contrast, are expected to have much larger stack requirements and thus use an extended stack size of 60 KB (Note: these are the numbers for Svr03 and may vary among releases).
Continue »
Tomorrow, Stack Overflow is scheduled to go public. Being a long time reader of Jeff Atwood’s and Joel Spolsky’s blogs and essays, I was sceptical, yet interested in how this project would turn out. After all, although I have a strong tendency of favoring the usenet over Q&A web sites and forums, there was the possibility that given their audience, Stack Overflow could become a Q&A site that does not suck like just about all the other forums on the web.
Continue »
Programming memory leaks in C or C++ is easy. Even careful programming often cannot avoid the little mistakes that finally end up in your program having a memory leak. Thankfully, however, there are plenty of helpful tools that assist in finding leaks as early as possible.
One especially helpful tool for leak detection is the debug CRT. Although the leak detection facilities provided by the debug CRT are not as far-reaching as those of, say, UMDH, using the debug CRT is probably the most friction-less way of identifying leaks.
Continue »
As discussed last week, cfix 1.1.0 has suffered from a potential deadlocking issue when run in the VisualStudio 2008 debugger. cfix 1.1.1 mitigates this problem and should now work equally well with Visual Studio 2005 and 2008.
When run in a debugger, cfix now will not try to capture a stack trace for a failed assertion any more. These stack traces usually have been redundant to what the debugger provides, yet the logic to implement this has been the reason for the interference with the VS 2008 debugger.
Continue »
While I still use VisualStudio 2005 Team System for most of my development, I want to make sure that cfix works properly with VisualStudio 2008 as well.
To test that, I recently started a Windows 2003 Server VM, installed VCExpress 2008 and cfix and attempted to run an example project in the VC debugger. As long as no assertions fired, everything seemed fine. I then altered the example’s source code so that one of the assertion would fail, ran it in the debugger – and waited.
Continue »
When used in conjunction with the VisualStudio 2008 debugger, cfix may hang indefinitely as soon as an assertion fails. The reason for this behavior is a Symbol Server-caused deadlock between the debugger and cfix. I am going to discuss the details of this deadlock in a separate post.
Until a new version of cfix is available, you can work around this problem as follows: Go to the cfix installation directory and rename or delete symsrv.
Continue »
Thread IDs uniquely identify a thread – this certainly holds for user mode threads and should also hold for kernel mode threads. But there is one kind of thread where the ID does not uniquely identify a KTHREAD – the Idle thread.
On a uniprocessor system, there is only one Idle thread and this idle thread will have the thread ID 0 (in process 0). On a multiprocessor system, however, Windows creates one Idle thread per CPU.
Continue »
cfix 1.0 had been licensed under the GNU General Public License. One of the characteristics of the GPL is that it disallows proprietary binaries to be linked against GPL-licensed binaries.
In the context of cfix, linking is quite a concern – after all, every test-DLL has to be linked against cfix.dll. As cfix.dll is GPL-licensed, this means that it would be illegal to redistribute the test-DLL, along with the cfix test runner, commercially.
Continue »
cfix 1.1 introduces a number of new features. The most important among these is the additional ability to write kernel mode unit tests, i.e. unit tests that are run in kernel mode. Needless to say, cfix 1.1 still supports user mode unit tests.
All contemporary unit testing frameworks focus on unit testing in user mode. Certainly, the vast majority of testing code can be assumed to be targeting user mode, so this does not come at a surprise.
Continue »
The stack pointer, esp on i386, denotes the top of the stack. All memory below the stack pointer (i.e. higher addresses) is occupied by parameters, variables and return addresses; memory above the stack pointer must be assumed to contain garbage.
When programming in assembly, it is equally easy to use memory below and above the stack pointer. Reading from or writing to addresses beyond the top of the stack is unusual and under normal circumstances, there is little reason to do so.
Continue »
When working with symbols, the default case is that you either analyze the current process, a concurrently running process or maybe even the kernel. dbghelp provides special support for these use cases and getting the right symbols to load is usually easy – having access to the process being analyzed, dbghelp can obtain the necessary module information by itself and will come up with the matching symbols.
Things are not quite as easy when analyzing symbols for a process (or kernel) that is not running any more or executes on a different machine.
Continue »
Despite the fact that mainstream support for Windows 2000 has ended in 2005 and the system is well on its way to retirement, Windows 2000 is still in wide use today. As such, it remains being an important target platform for many software packages.
The fact that cfix has not provided support for Windows 2000 was thus unfortunate – after all, if Windows 2000 is among the target platforms of your software, you should be able to run your tests on this platform.
Continue »
Most code that uses Structured Exception Handling does this with the help of the compiler, e.g. by using try/except/__finally. Still, it is possible to do everything by hand, i.e. to provide your own exception handlers and set up the exception registration records manually. However, as this entire topic is not documented very well, doing so opens room for all kind of surprises…
Although more than 10 years old, the best article on this topic still seems to be Matt Pirtrek’s A Crash Course on the Depths of Win32™ Structured Exception Handling, which I assume you have read.
Continue »
To date, I did all my Java development uding 32 bit JVMs. After all, as long as you do not have extreme memory requirements, the 64 bit JVM should not buy you much. Today I installed the Java 6 Update 6 x64 JDK on my Vista x64 machine and tried to run some of my JUnit tests on this VM.
With little success:
# # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000772b219b, pid=4188, tid=2272 # # Java VM: Java HotSpot™ 64-Bit Server VM (10.
Continue »
One of the builtin WinDBG commands is wt (Trace and Watch Data), which can be used to trace the execution flow of a function. Given source code like the following:
void foo() { } void bar() { } int main() { // Some random code… int a = 1, b = 2; // Call a child function. foo(); // More useless code… a+=b; if ( a == b) a = b; // Call another child function.
Continue »
Last week, Ksplice, an automatic system for rebootless Linux kernel security updates gained some attention. The idea of using hotpatching techniques for applying sucurity fixes to the kernel in order to save reboots is not quite new. Not only does Windows support hotpatching as of Windows Server 2003 SP1, there also have have been attempts to introduce a hot updating infrastructure to the Linux kernel before. Anyway, the paper is an instresting read.
Continue »
Quite obviously, Google does not always get it right either. Ever when I try to see my Google Calendar (using Opera), I am requested to login. So I enter my credentials, am redirected a couple of times and – are broght to the login page again. Logging in again does not help, I have by then entered an infinite loop. Thankfully, I can escape this loop by jumping to the original calendar URL again – now Google recognizes that I have already logged in and shows me my calendar.
Continue »
Working Around TlbImp's Cleverness
