On the Visual C++ .NET DLLs…

One would notice that many applications compiled with Visual C++ 2002 or later would have the Visual C runtime DLLs in their private folders. As mentioned in KK’s blog, this approach doesn’t allow for central servicing.

Examine the code of one differential CRT DLL (say, msvcr90.dll), and that of the Windows CRT DLL (msvcrt.dll) – many of the functions haven’t changed through the years. This results in duplicated code in two different binary images, which wastes space. Exception handling can change, yes, but many of them still reference C Library functions (which hasn’t changed).

In that light, I decided to write a “proxy” DLL to make them use the Windows OS CRT.

There is one more common issue when using “legacy” DLLs (those compiled with VC6) with images produced by the VC7+ compilers: Heap corruption. Each CRT instance has its own heap, and even passing pointers between two different instances of the same identical CRT DLL is very likely going to result in a runtime failure. Examine again a differential CRT DLL with the Windows CRT DLL, and you will find that memory allocation functions (such as operator new[] and operator delete[]) are duplicated. To eliminate this problem, I also decided to use the Windows CRT’s memory heap instead and provide code-wraps and forwards required by the new VC7+ code.

By the way, I would greatly appreciate contributions in finding the functions that have been added after VC6.