What happenedRecently I've needed to upgrade an application to use 4.0.3 of the .Net Framework. The upshot of this was that the application was no longer XP compatible.
Not a valid win32 application
This was un-expected, there isn't a compatibility issue with XP and this version of the framework. However, upon inspection, the compiler had marked the application as being for Vista OS onwards. Explicitly set this to XP and the application is once more a valid win32 application.
This is how it was done.
- We inspected the application.exe header using dumpbin. This is a Visual Studio command line utility.
- Here we could see that it was targeting /subsystemversion 6.00 which is Vista, considering the change we made, this is neither desired or required. Ideally we would ask the compiler to mark this correctly for us, but msBuild doesn't expose this switch. So instead we would need to change this post compilation.
- So we added a build step to adjust this flag after compilation. For this we used editbin. Another Visual Studio command line utility. To set the
editbin.exe "$(TargetPath)" /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1
You can use DUMPBIN to examine COFF object files, standard libraries of COFF objects, executable files, and dynamic-link libraries (DLLs). You can start this tool only from the Visual Studio command prompt. You cannot start it from a system command prompt or from File Explorer.
You can use EDITBIN to modify object files, executable files, and dynamic-link libraries (DLL). You can start this tool only from the Visual Studio command prompt. You cannot start it from a system command prompt or from File Explorer.
Specifies the minimum version of the subsystem on which the generated executable file can run, thereby determining the versions of Windows on which the executable file can run.
Specifies the execution environment that's required by the executable image.