We have an existing (old) codeline that we have recently converted from VC6 to VS2008 (converting to VS2005 along the way). After our conversion, all (or most) of our vcproj files set WINVER to 0x0500 via the Preprocessor Settings. In quite a few of our precompiled headers (typically stdafx.h), WINVER is set to 0x0500 (some still set it to 0x0400). If I use dumpbin /headers on our main exe, it shows that the Operating System Version is 5.0 (Windows 2000).
After changing the vcproj preprocessor settings so that WINVER and WIN32_WINNT are 0x0501 and making a similar change in the stdafx.h file and rebuilding, dumpbin stil shows that the operating system version is 5.0.
I have also created a brand new console app (as well as a brand new MFC app) using VS2008 and built them. Those exes also show an operating system version of 5.0, even though WINVER (and WIN32_WINNT), as set via the targetver.h file, is 0x0600.
I would have guessed that setting WINVER and/or WIN32_WINNT to 0x0501 or 0x0600 would have some effect on the operating system version shown by dumpbin. Am I right, should I expect dumpbin to show an operating system version corresponding to WINVER and/or WIN32_WINNT?
I have read some good articles on this (“Using the Windows headers” on msdn, “What is the difference between WINVER…” on The Old New Thing, and this particularly interesting one:
http://blogs.msdn.com/dsvc/archive/2009/06/19/troubleshooting-not-a-valid-win32-application-error-at-the-startup.aspx
While it is probably not a huge issue exactly what version appears in the operating system version field, we would like to understand the behavior and be able to do the “right” thing to ensure that we are using these macros and settings correctly.
Thanks for any help
The value of the “operating system version” field is set by LINK /SUBSYSTEM.
As an aside, the LINK /VERSION switch updates the “image version” field.