Changes in this version

Here I will talk a little about what will change and what will not.

Modularity

In version 0.3, the source code of the main executable contained about three big categories of code:

1. User interface code: This is the code that manages the windows, switchbar, pane, all the settings dialogs, etc. Everything you can see or interact with is here.
2. IRC code: This is what manages the actual connections, parses the protocol and notifies the user interface. Also, all CTCP, DCC and Identity management is here.
3. Helper and “glue” code:This is all the code that does common tasks. Initialization, custom memory management, string parsing, threads, etc. This part was very big.

Of course, all of it was compiled into a giant monolithic executable that has everything embedded in it. Therefore, the goal for this version is to try and make KoroIRC 0.4 more modular.

In order to achieve this goal, the main executable code has been split into many parts. First, all the common code has been made into a new library, kirccore.dll. This also allows the other executables and DLLs to reuse that code too, reducing them in code size. Most of the extraneous functions of KoroIRC are in the process of being moved to plugins (.kpl files), with kircapi.dll as their “call gate” into the main executable code. As such, it is possible to have a super minimalist, no-frills KoroIRC installation in only three files:

• KoroIRC.exe
• kirccore.dll
• TDEmu.dll

I shall also take the occasion to mention that KoroIRC can be used as a portable application since its very birth. The installer is provided merely as a convenience. If KoroIRC finds an INI file in the same folder as itself, it will use it for loading/saving settings.

Operating system requirements

In version 0.3, I had three separate builds to maintain: an Unicode build, an ANSI build and an x64 build. This was all magically hidden to the user by the installer, which automatically installed the right one.

Back in 2005, when I started version 0.3, I still knew a bunch of people stuck with old computers, still on Windows 98. So it was only natural to support these old operating systems, since they were still used. However, having to support them often meant a lot of glue code, such as loading stuff with LoadLibrary / GetProcAddress and having an “alternate code path” if the functionality was not present. This increased code size and complexity a lot, and limited my choice of APIs to use.

Thankfully, these days everybody uses Windows XP or Windows Vista now, so I think it is safe to remove support for the old operating systems. So version 0.4 will only support Windows 2000 and higher, and the code is being cleaned of old code paths. A good example of this is in the updater code, where I could just stick a call to CheckTokenMembership — which is only available starting with Windows 2000 — instead of having to manually loop through the groups in the token.

User interface changes

There won’t be much major user interface changes for this version. But there is one thing worthy of noting. I’m currently in the process of replacing all message boxes with much more user-friendlier task dialogs instead. The very cool thing is that it works in Windows 2000 and Windows XP too! And, since I’m doing that, I’ve also started using string table resources.

Also, I’m working hard in order to have High-DPI support. KoroIRC 0.3 only had that partially, which is why the executable wasn’t marked as “DPI-aware” under Windows Vista. I’m working hard to remove all remaining hardcoded sizes (which are often for bitmaps or icons) and making sure everything scales well no matter the size. Also, this is an area I’m dogfooding much, as I myself run at 120DPI on my new LCD monitor.

Also, for all those who complained that it was imposible to hide the lower pane, this version won’t have the possibility to hide it either, sorry. However, know that I heard you and that it is definitely planned for the following version, along with a slew of other user interface changes.

Tools

I have also added my own crash reporter. Yeah, I know this reeks of NIH, especially when Microsoft has Windows Error Reporting, but there are hard entry conditions on WER, and also my own crash reporting tool allows to collect additional information from the user before sending the dump file.

I have also added a “Files” pane as an optional plugin, which is merely an embedding of a shell folder right into the lower pane. It is very useful to be able to drag and drop files to send them to somebody real fast, without having to switch windows.

I plan to redo the user interface of the DCC Information Tool. For those who didn’t know, every time you receive a file by DCC, KoroIRC stores additional information from the DCC into an alternate data stream of the file. This tool allows you to see that stored information.

Status

I have much done, enough to say that KoroIRC 0.4 is already significantly different from version 0.3. However, there is still much work to be done in all areas, so I’d say it’s at about 50% done.

Why is development so slow?

The short answer is: because I’m not paid to do it. The long answer is that coding is an activity best done at night, and also needs long times of having nothing to do in order to be properly set in motion.

Thing is, with school and work being much more demanding than before, I simply do not have as much free time as I’d like to, and when I get some, I don’t necessarily feel like coding much. Back in 2004, I had whole months free, with nothing better to do than sleeping in the day and coding in the night, and thus KoroIRC 0.2 was born in about four months of concentrated efforts.

Sadly, this is not the case anymore, and sometimes months can pass without me writing a single line of code on KoroIRC. This is why it takes so much time to release new versions now.

Now, it ain’t so bad when applications restrict that to their client area. It is still useless and disrespectful of my settings, but at least it’s contained. But more and more apps take bolder steps at spitting in the face of my settings — hint: I set them that way for a reason, because I like it that way — and, sadly, Microsoft is no exception to this.

Windows Live Messenger is a big culprit in this case. Up until Wave 3, even though it defaulted to using custom window captions, a simple “Show the menu bar” would bring the regular ones back. But, as it seems to be the fashion these days, that possibility was removed. That, and they also now impose ClearType usage, even if you explicitly disabled it. Not that important now, since LCD screens are everywhere, but my old CRT monitor only broke 6 months ago.

But if you played a little with WLM9, you notice it reverts to regular window captions in certain cases, like if you maximize a window. A little poking around in WinDbg quickly shows that it’s just using window regions to do its bidding. That, along with a friend that showed me that under Aero Glass, it actually just lets the window manager do its job and uses regular captions, was more than enough to tip me off that something could be done very easily about this problem.

My first try was to try and block the SetWindowRgn call outright. I basically overwrite the code for that function in the process’ memory with the assembly equivalent of this:

int HookSetWindowRgn(HWND hWnd, HRGN hRgn, BOOL bRedraw)
{
    if (hRgn)
        DeleteObject(hRgn);
    return 1;
}

There are multiple problems with this approach. First, since WLM hides the whole caption and window borders, it has to handle WM_NCHITTEST in order to allow window resizing from within its client area. Since it also still thinks the caption and borders are hidden, it does not handle these cases, and as such, returns HTBOTTOM when the cursor is on the window caption. Also, the theming system in UxTheme.dll also calls this function — why it does not call NtUserSetWindowRgn directly is beyond me — in order to have those round window corners, and this “fix” disables that too.

My second and final solution came upon noticing that when WLM itself decides to show these captions, they work properly, and also the pseudo-caption inside the client area disapprears, too. If there was a way to trick WLM into thinking one of the “show the caption” conditions is met, it would by itself comply and show it without additional work. I first tried to hook the IsZoomed function directly to make it always return TRUE, but again it caused problems with UxTheme.dll.

I started by looking for calls to SetWindowRgn in all of WLM’s binaries. One of these files is UxCore.dll. Now, the fun part with exporting C++ classes or functions directly with __declspec(dllexport) is that all the decorated names are kept intact, which is very handy for reverse engineering like this since they contain full parameters and return type information. It did not take much time to find the UXFramelessManager class, which is responsible for hiding or showing the window caption, and handling everything that is associated with it. That class has a method called UpdateFrame, which does the work of determining if a window region needs to be set, and setting or clearing it as needed.

The UpdateFrame method checks that at least one of these three conditions is met:

• The window is maximized
• Aero Glass is enabled
• High Contrast Mode is enabled

If that is the case, it will set a NULL region for the window and not do any custom handling of the WM_NCHITTEST message. So, I figured, let’s make it think the window is always maximized! The code that does this check is:

7033e028  push  dword ptr [esi+8]
7033e02b  shr   eax,13h
7033e02e  and   al,1
7033e030  mov   byte ptr [ebp-1],al
7033e033  call  dword ptr [__imp__IsZoomed@4]

The instruction at 7033e028 pushes the HWND of the window on the stack. The next three instructions are interleaved code that does something else, probably due to agressive compiler optimization settings, then the call is done at 7033e033. So all we need to do is to change the code to just always assume IsZoomed returned TRUE, padding as appropriate with NOPs:

7033e028  nop
7033e029  nop
7033e02a  nop
7033e02b  shr   eax,13h
7033e02e  and   al,1
7033e030  mov   byte ptr [ebp-1],al
7033e033  mov   eax,1
7033e038  nop

All that was needed was to patch that new stream of instructions at the right file offset in UxCore.dll:

0003D428 -> 90 90 90 C1 E8 13 24 01 88 45 FF B8 01 00 00 00 90

Upon starting WLM, I had my window captions indeed:

(Yes, I went back to Windows Classic, despite my claims to the contrary.)

There is still a bug with this though. It it not apparent under Windows Classic, but UxTheme.dll causes problems again, albeit a minor one this time. Basically, UpdateFrame will still call SetWindowRgn on window creation with a NULL region, clearing the one set by UxTheme.dll. This is the code that does it:

7033e141  push   1
7033e143  push   ebx
7033e144  push   dword ptr [esi+8]
7033e147  call   dword ptr [__imp__SetWindowRgn@12]

Note that EBX is zeroed out at the beginning of the function, so this code is the equivalent of:

SetWindowRgn(m_hWnd,NULL,TRUE);

All we have to do is to replace that whole code sequence with NOPs again. I won’t present the code here, but directly the bytes to patch in the file:

0003D541 -> 90 90 90 90 90 90 90 90 90 90 90 90

Once this is patched, WLM will have regular window captions, with no glitch (that I found yet). It is sad though, that I had to resort to patching code for such a trivial matter, especially that older versions of WLM allowed this, so they actually had to remove code to make it not-work…

All code addresses and listings comes from UxCore.dll version 14.0.8050.1202 in the WLM installation directory. Make sure you have that exact same version before patching the file, of course.

Update: This also works with UxCore.dll version 14.0.8064.206, as none of the offsets have changed.

The core of the manifest checking is in the _check_manifest function, which is located in crtlib.c in the CRT source. As the name suggests, this code is only linked in when compiling a DLL version of the CRT.

Here is what the code does:

1. First, it checks for the presence of the FindActCtxSectionStringW function in KERNEL32.DLL. If this step fails (i.e. GetProcAddress returns NULL), then it assumes that the OS it’s running on does not support Fusion, and returns with success.
2. Then, it checks if both of MSCOREE.DLL and PGORT90.DLL are loaded in the process’ address space, and if yes, assumes it was loaded for instrumentation and returns success.
3. It then retrieves the path of where it was loaded and of the system32 directory.
4. When the paths are retrieved, it checks explicitly that it wasn’t loaded from system32. If it was loaded from there, it immediately returns a failure.
5. Then, it checks the current activation context with FindActCtxSectionString to check if it was referenced in the manifest. If that isn’t the case, it returns a failure.
6. It then makes sure it was loaded from under the WinSxS folder in the Windows directory by doing a string compare of that path and its own path. If that is the case, it returns with success.
7. This last check happens only if the previous check failed. It will try to find a file called Microsoft.VC80.CRT.manifest (or Microsoft.VC80.DebugCRT.manifest if it’s the debug version) in the same folder from which it was loaded, and if found, will return success.
8. If it comes here, it assumes that it was wrongfully loaded and returns a failure.

Note that over the course of these checks, it uses multiple fixed-size string buffers. The one that is used to retrive the path of the Windows and the system32 directories is MAX_PATH in size, whereas the others are 8000 characters in size. If any of these buffers overflow at any time, it will just bail out of the checks and return success.

Also, WINE does have an implementation of activation contexts, found here (KERNEL32 wrappers) and here (actual implementation in NTDLL). Except for some reason, it fails to go grab MSVCR80.DLL from the WinSxS directory, instead returning with status 0xc0000135. It’s not that the functionality is not there however, as a quick look into WINE’s source (in loader.c to be exact) shows a neat little function called find_actctx_dll that gets called from find_dll_file.

So, now that you understand how it works, the solution to bypass it becomes very simple.

You can take the long route and recompile your own version of the CRT with the _check_manifest function dummyfied. A quick look at some installed apps on my computer shows that a few apps do it. Firefox has its MOZCRT19.DLL and Winamp has NSCRT.DLL, although the latter is an older version of the CRT.

The previous solution is quite complicated for such a simple detail. Also, if you wish to redistribute the DLL with your application, you have to name it something else than MSVCR80.DLL. So you still have to redistribute it even if you got rid of the manifest check.

Follow me here for a much quickier-and-dirtier hack. Basically, you just have to patch 5 bytes in the DLL file to disable the manifest checking. Disclaimer: I don’t think the EULA allows you to do that, and it would not be a good idea to redistribute those patched DLLs. Do it at your own risk.

I have tested with versions 8.0.50727.1433 and 8.0.50727.3053 of MSVCR80.DLL and it worked well. After that, I was able to drop them into my system32 directory in a WINE install and they would work flawlessly. So, you need to patch the following bytes at the following file offset:

00001D76 -> B8 01 00 00 00 C3

This effectively turns the content of the _check_manifest function into nothing more than a return TRUE.

I hope that this goes to show again that using manifests for the CRT was a really bad idea. It just pushes more people to either statically link to it, compile their own or try to find another way to get over that restriction, all of which are not really beneficial in the long term. It defeats the purpose of DLLs, which was to share code between processes.

The simplest way: Don’t use it altogether

For a very small project, most of the time, the only reason you actually use the CRT, is because you don’t know that you can not use it. But you can tell the compiler that you don’t want it, and here’s how.

The first thing to do is to turn on the /Zl (omit default library names) compiler option in your project / makefile. I find this cleaner than using the /NODEFAULTLIB linker option, because it only affects the CRT default libraries. Anyway, at this point, you’ve already done it, the CRT will not be linked anymore in your binary.

But suddenly, your project will not link anymore. One of the first reasons for that is because the CRT inserts its own entry point and the linker expects to find it, but since you have removed the CRT you’ll have to supply your own versions of these. Hopefully, the names of the entry points don’t change much, it’s just a matter of picking the right one:

// __DllMainCRTStartup@12
extern "C" BOOL WINAPI _DllMainCRTStartup(HINSTANCE, DWORD, LPVOID);
// _WinMainCRTStartup
extern "C" __declspec(noreturn) void __cdecl WinMainCRTStartup(void);
// _mainCRTStartup
extern "C" __declspec(noreturn) void _cdecl mainCRTStartup(void);

You’ll instantly notice that the WinMain and main entry points are declared with __declspec(noreturn) and have a void return type. That is not totally true. You can return from that function, at least in Windows NT, and BaseProcessStart will happily terminate the thread. But only the thread. That is why I prefer to end these functions with a call to ExitProcess instead.

As for the DllMain entry points, there is a big probability that it won’t be needed. The CRT absolutely needs it to do some initialization, but if you’re like me, and try to do as little as possible in this function, you probably just have a call to DisableThreadLibraryCalls and then return TRUE. If that is the case, you can use the /NOENTRY linker option, which will link the DLL with no entry point at all.

Next, you will encounter linking errors because several “special” CRT symbols are referenced by code that is added by the compiler. Hopefully, these are easy to weed out:

Note that is you are doing operations on __int64’s or using structured exception handlers (SEH), you will need the CRT. More on this later.

The last part on getting rid of the CRT is to replace CRT calls to equivalent API calls. I have put together a quick little table mapping the must used functions:

I’m not going to list every function out there, but the point is, for the most simplistic functions of the CRT, there is often a straightforward Win32 API equivalent. When there is not, it is usually simple to code one (such as atol). But, as you can see, as soon as the project grows a little, it becomes quickly unusable in practice.

Also, note that wsprintf and wvsprintf do not support floating point.

The fraught-with-peril way: Use it a little.

The problem with the CRT is the lengthy initialization code it adds to an EXE, even when linked dynamically. It seems to want to call every KERNEL32 API under the sun, even if in the end you will just use it for a string compare or two.

But sometimes you absolutely need to link in some stand-alone code from the CRT, such as the __int64 support code (__xllmul and __xlldiv, respectively). One quick way is to skip the initialization code by redirecting the entry point with the /ENTRY linker option. That way, execution starts right to your code, and (in your release build at least) the CRT initialization code won’t be linked in at all.

I have to take a break and post a disclaimer here: skipping the CRT initialization code is dangerous. Lots of CRT functions, even simples ones as memcpy or strcmp, reference global CRT variables which need to be initialized. Use this at your own risk, and in case of doubt, double-check the CRT source code.

This therefore implies that you can’t really call CRT functions anyway, apart from standalone ones. So the same rules as if you were not using the CRT at all apply, except for the fact that accidentally referencing a CRT symbol will be much harder to spot because it won’t cause a link error anymore. So, obviously, this is not a way that I often use.

The safest way: Use another CRT

This is the method I use for KoroIRC. Basically, this is using another set of header files and library files when compiling the program.

I found that the safest way to do it is not to change VS’s library and include paths, but rather to build my release binaries using a special script, and build my debug builds using the regular CRT with the /MT compiler option. I don’t care if my debug binaries weigh 1MB and have tons of dead code in them, as I never ship them.

The trick is to make a little batch file like this:

@echo off
set INCLUDE=altcrt\include;%INCLUDE%
set LIB=altcrt\lib;%LIB%
devenv solution.sln /rebuild "Release^|Win32" /useenv

Replace altcrt with the proper path to your alternate CRT, run this in a Visual Studio Command Prompt, and let it churn.

I will now finish this post by presenting two alternate CRT’s you can use.

Lightweight but undocumented: NTDLL’s mini-CRT

A little-known fact is that NTDLL.DLL embeds its own CRT, probably for use by operating system components and native applications. Of course, you won’t find complex functions such as rand or time but all string functions, and more importantly, SEH support functions, are there. Since it is always loaded in all processes anyway, it costs nothing to use, except Windows 9x compatibility of course.

To use it, you’ll need the Windows DDK, which includes all the header files and library files needed in order to import from NTDLL. However, in order to be able to use it with PSDK-compiled applications, you will need to extract only the right files, that is, the whole contents of the inc\crt directory and the lib\wxp\i386\ntdll.lib file for x86 or lib\wnet\amd64\ntdll.lib for x64. Then it is only a matter of using them with the little script I presented earlier.

Harder but safer: Good old MSVCRT

In order to do that, you will need two things: an old Visual Studio 6.0 CD, and a copy of the Windows Server 2003 SP1 Platform SDK that was released just before Visual Studio 2005.

On the Visual Studio 6.0 CD, you will be able to extract the VS6 CRT headers from the VC98\INCLUDE directory, and the libraries from the VC98\LIB directory. The only problem is that they are mixed with Platform SDK files, so you’ll have to pick them one by one. Luckily, I have thown together this list of what files belong to the CRT.

The Platform SDK release linked above is special because it contailed a prerelease version of the x64 compiler that came with Visual Studio 2005. As such it also contains everything necessary in order to link with Windows x64’s MSVCRT.DLL. Hopefully, this time, the headers are in their own subdirectory, Include\crt. The libraries are in Lib\amd64 and the PDB files are in NoRedist\Win64\AMD64.

With all this in hand, you should be able to link with MSVCRT.DLL on x86 and x64 using the script.

Conclusion

With these methods, it is possible to reduce either the executable size or the download size (for not having to redistribute more recent CRTs) for your program. Of course, this only applies if you program mostly in C, because when you start using C++ or worse, the STL, these approaches stop working well.

1. On the graphical side: The skins that are built-in with Windows XP suck, although the silver one is a little less worse than the others. The title bars are oversized — especially in the days where screen resolutions like 800×600 and 1024×768 were still the norm — and you are stuck with choosing between happy-blue, dull-green or way-too-bright-silver as the only possible colors. Since I like to match my title bar and selection colors with my desktop background, it’s kind of a bummer. Also, I hate blue. I have a deep, passionated hatred for the color blue, which is even more fueled by the fact that it seems to be the default color everywhere. In fact, the first thing I always did in a fresh Windows install, was to change the blue colors to something else. So the non-ability to change it to say, forest green, was quite annoying. It’s not like it would have been hard to implement skin colorization, WindowBlinds was doing it already.
2. On the technical side: The whole UxTheme skin system is such a giant patch over Windows, it almost seems like it was written by a third-party and hastily integrated into the Windows code base. It uses a service with a global hook to apply skinning to the non-client area of windows, and applications have to explicitly request the “new” common controls in order to get skinned controls. This is quickly visible in the fact that console windows, hard error dialogs and WOW windows are not skinned at all. Also, all pre-XP applications still have the “old” controls, which contributes to the overall uglyness. The question is: why on earth couldn’t they — security and stability issues aside — plug the skinning code right into the window manager over the old code? They had the source code, and therefore the ability to do it, but instead they went the other way all around and added another layer of complexity.

But, as time has passed, these points have become pretty much moot. There are now a lot of user-created skins so #1 is not a problem anymore, and almost all applications include a common control manifest so the impact of #2 is quite minimized. Also, computers have gotten much faster since 2001, so the speed impact of drawing a bitmap instead of a solid fill is almost null.

Whilst user-created UxTheme skins have existed for a while, I have only since recently considered even using one because frankly, most of them sucked. They were either oversized, overcolored, had too much details or were blatant rips of Luna.

The first skin I ever used was Royale, although not for long, because it was blue. Not only the title bars, but every control and color had a blue hue. But I liked its glossy look, it was quite a change from Luna’s “deflated baloon” look. The first skin I really used, and fell in love with, was the Zune skin, which was Royale without the blue. It also made me realize that black is a color that fits with every other color, and therefore wallpaper, so I didn’t mind much not being able to customize it.

After scouring the web a little, I found some other good black UxTheme skins. I therefore make a little list here for future reference:

1. Watercolor Emico: Black by Gelosea: By far the most beautiful, most usable skin out there. It also comes in flavor of blue, a darker blue, olive green and silver. I use it on all my computers, enough said.
   
2. Zune Desktop Theme by Microsoft: This one is actually by Microsoft itself and was released as promotion for the Zune. It’s basically Royale without the blue, but is not Royale Noir, which still had some blue in it. The advantage of this skin is that, being from Microsoft, it’s signed and therefore needs no UxTheme patch to apply. I use this one at work or in other places where patching UxTheme would be prohibitive.
   
3. Luna Element by tornado5: I’d use this one if the two previous ones didn’t exist. Comes in blue and black.
   

With these, there’s no reason to stay in Windows Classic anymore!

Back in the days of Visual Studio 6.0 (still, in my opinion, the best version to have ever existed, despite its age¹), things were simple. There were no useless compiler flags to disable in every project, and the C runtime library was MSVCRT.DLL, which was distributed with the operating system. Actually, this is not fully the case, but MSVCRT.DLL has always been there due to the strong reliance of operating system components on it. It was therefore very simple to create small applications and to distribute them.

Then came Visual Studio 7.0, a.k.a. Visual Studio .NET 2002. Suddenly, someone somewhere decided that MSVCRT.DLL belonged “to the operating system” and not to Visual C++, and that therefore, its C runtime should now reside in a new, separate, redistributable DLL, MSVCR70.DLL. So suddenly, there was no real incentive to compile with /MD, as it would create the need to distribute a ~330k DLL along with the application. Personally, I would have remained with Visual Studio 6.0, but in the latest Platform SDK, which at the time was the then-new Windows XP SP2 Platform SDK, suddenly the format of the .lib files was just slightly incompatible with the aging linker.

I think it was in Visual Studio 7.1, which, by the way, I have never used personally, that the damned /GS compiler flag was introduced. What a better way to inflate code size uselessly than to add a prolog and epilog in every function that checks for a “security cookie”? Personally, I never allocate buffers and strings on the stack anyway, and when I do, I very strictly validate their length, so the protection offered by this flag is quite nil to me.

Then, in Visual Studio 8.0 (2005), somebody sure got angered at all the developers that were copying MSVCR7x.DLL around freely, so it was spoken: “From now on, the C runtime will only be installed by our own installer”. So, to install MSVCR80.DLL on a system, it’s not as simple anymore as just including the file in your installer and dumping it in the application’s directory during installation, you have to have a freaking manifest to even be able to load it! And of course, since this uses Fusion, the files need to be installed into specific subdirectories of the WinSxS directory, and therefore, the only “installer” qualified to do it correctly is the Visual C++ 2005 Reditributable Package, which weighs a whopping 2.6 MB! Quite a lot for what would have been an application of a few hundred kilobytes, now isn’t it? And to make sure you don’t ever try to bypass this “rule” and copy it in the application’s directory, the DLL does a check at startup to see if it was loaded “correctly”, and, if not, refuses to load.

Now, it isn’t that bad, I found a workaround to that (which I will explain in a future post), so I got used to that version and grew to like it.

I then recently got Visual Studio 9.0 (2008) and installed it. Not that it was really useful, since I already had the Windows Vista (February CTP) SDK installed over my Visual Studio 2005 installation, but I installed it just to be using the latest version. Actually, it’s not so bad, it’s even an improvement over the previous version. The /DYNAMICBASE and /NXCOMPAT flags are enabled by default (unless you migrate your project from Visual Studio 2005), and the operating system and subsystem version number in the PE headers were finally bumped to being set to 5.0 by default. That last point is also the frustrating point though. It was probably done that way because version 9.0 of the C runtime wouldn’t run correctly on anything lower than 5.0 anyway, but if you are not using the C runtime at all, there is no reason to set them to 5.0, other than artificially restricting the versions of Windows your program can run on. So, you might say, “let’s just tell the linker to set them back to 4.0 then”. Except, when you try to do that, you get this lovely little error:

LINK : warning LNK4010: invalid subsystem version number 4.0; default subsystem version assumed

Yes, you guessed right. The linker won’t let you set 4.0 as the subsystem version number. It looks quite like an useless restriction put there just to annoy some of us who still support, or just want to code for Windows 9x/NT4.

But as always, something like that isn’t enough to stop me, I created my own workaround:

The fact that an executable linked with Visual Studio 2008, but not using its C runtime, runs fine on Windows NT 4.0 afterwards proves how much of an artificial restriction that is.

The tool is up for download here.

1. It’s not so bad once you install WndTabs and work around the few bugs in the resouce editor.

Oddly, only the older projects in the solution had this problem, the newer were OK. I spent a while wondering if it might have been a linker bug, then I decided to look at the build log. Surprisingly, the affected projects had the /DYNAMICBASE:NO linker switch specified, even though I specified the opposite in the solution-global .vsprops files.

So I decided to take a look directly in the .vsproj files, and lo and behold, in the linker options, the following lines where there:

RandomizedBaseAddress="1"
DataExecutionPrevention="0"

Since I never add stuff directly to the .vsproj files, because I prefer .vsprops files which allow sharing common settings between projects, then in the migration from VS2005 to VS2008, it must have “helpfully” inserted these for me.

To quote Stan from South Park, “I learned something today…”