I know I can call the GetVersionEx Win32 API function to retrieve Windows version. In most cases returned value reflects the version of my Windows, but sometimes that is not so.
If a user runs my application under the compatibility layer, then GetVersionEx won't be reporting the real version but the version enforced by the compatibility layer. For example, if I'm running Vista and execute my program in "Windows NT 4" compatibility mode, GetVersionEx won't return version 6.0 but 4.0.
Is there a way to bypass this behaviour and get true Windows version?
How about obtaining the version of a system file?
The best file would be kernel32.dll, located in %WINDIR%\System32\kernel32.dll.
There are APIs to obtain the file version. eg: I'm using Windows XP -> "5.1.2600.5512 (xpsp.080413-2111)"
The best approach I know is to check if specific API is exported from some DLL. Each new Windows version adds new functions and by checking the existance of those functions one can tell which OS the application is running on. For example, Vista exports GetLocaleInfoEx from kernel32.dll while previous Windowses didn't.
To cut the long story short, here is one such list containing only exports from kernel32.dll.
Writing the function to determine the real OS version is simple; just proceed from newest OS to oldest and use GetProcAddress to check exported APIs. Implementing this in any language should be trivial.
The following code in Delphi was extracted from the free DSiWin32 library):
--- updated 2009-10-09
It turns out that it gets very hard to do an "undocumented" OS detection on Vista SP1 and higher. A look at the API changes shows that all Windows 2008 functions are also implemented in Vista SP1 and that all Windows 7 functions are also implemented in Windows 2008 R2. Too bad :(
--- end of update
FWIW, this is a problem I encountered in practice. We (the company I work for) have a program that was not really Vista-ready when Vista was released (and some weeks after that ...). It was not working under the compatibility layer either. (Some DirectX problems. Don't ask.)
We didn't want too-smart-for-their-own-good users to run this app on Vista at all - compatibility mode or not - so I had to find a solution (a guy smarter than me pointed me into right direction; the stuff above is not my brainchild). Now I'm posting it for your pleasure and to help all poor souls that will have to solve this problem in the future. Google, please index this article!
If you have a better solution (or an upgrade and/or fix for mine), please post an answer here ...
real version store on PEB block of process information.
Sample for Win32 app (Delphi Code)
Note: Gabr is asking about an approach that can bypass the limitations of
GetVersionEx
. JCL code uses GetVersionEx, and is thus subject to compatibility layer. This information is for people who don't need to bypass the compatibility layer, only.Using the Jedi JCL, you can add unit JclSysInfo, and call function
GetWindowsVersion
. It returns an enumerated type TWindowsVersion.Currently JCL contains all shipped windows versions, and gets changed each time Microsoft ships a new version of Windows in a box:
If you want to know if you're running 64-bit windows 7 instead of 32-bit, then call
JclSysInfo.IsWindows64
.Note that JCL allso handles Editions, like Pro, Ultimate, etc. For that call GetWindowsEdition, and it returns one of these:
For historical interest, you can check the NT-level edition too with the NtProductType function, it returns:
Note that "N editions" are detected above. That's an EU (Europe) version of Windows, created due to EU anti-trust regulations. That's a pretty fine gradation of detection inside the JCL.
Here's a sample function that will help you detect Vista, and do something special when on Vista.
Note that if you want to do "greater than" checking, then you should just use other techniques. Also note that version checking can often be a source of future breakage. I have usually chosen to warn users and continue, so that my binary code doesn't become the actual source of breakage in the future.
Recently I tried to install an app, and the installer checked my drive free space, and would not install, because I had more than 2 gigabytes of free space. The 32 bit integer signed value in the installer became negative, breaking the installer. I had to install it into a VM to get it to work. Adding "smart code" often makes your app "stupider". Be wary.
Incidentally, I found that from the command line, you can run WMIC.exe, and type
path Win32_OperatingSystem
(The "Select * from Win32_OperatingSystem" didn't work for me). In future perhaps JCL could be extended to use the WMI information.The following works for me in Windows 10 without the Windows 10 GUID listed in the application manifest:
Update:
NetWkstaGetInfo()
would probably also work, similar to 'NetServerGetInfo()`, but I have not try it yet.WMI QUery:
EDIT: Actually better would be:
You could implement this in Delphi like so: