Incorrect Windows Version returned
Archives Forums/Win32 Discussion/Incorrect Windows Version returned
| ||
| When I try obtaining the OS either via (GetEnv("OS")) or by using the AdvApi32.dll registry queries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\" I am not getting the expected result. Although manually examining the registry with RegEdt32.exe shows that the values ProductName and CurrentVersion etc. are all as expected for Windows 8 (i.e. version = 6.2) Whenever I use BlitzPlus with Advapi32.dll decls or the GetEnv("OS") - the result obtained suggests Windows XP! It seems to be a similar situation to the one reported by a user of Wise install script: http://www.symantec.com/connect/forums/need-help-identifiying-vista-32bit-machine-my-wisescript-wise-installation-studio-70-0 I am running 32-bit version of Windows 8 only. |
| ||
| Vista was 6.0, Windows 7 is 6.1, windows 8 is 6.2 That's correct. They found lots of coders checking WRONG for the major windows version using those calls to ensure that windows was XP (and not older) by checking the major number was 5, so all those badly coded programs did not work on Vista when it reached the "6" so, to survive from bad code, they're now updating the minor number instead, in the hope to maintain a better backwards craptability ups, I meant, compatibility. I supose those coders that just checked equality with major version number, were the same ones that did cause the 2000 effect.... |
| ||
| Ziggy, this was nothing to do with interpretation, the actual values returned were inaccurate, suggesting WIndows XP (5.1) rather than Windows 8 (6.2) that should be returned. I even tried "Kernel32.dll" GetVersionEx() but with the same, incorrect results. edit: PROBLEM SOLVED! After all that, the version of IDEal I am using was set to run in WindowsXP Compatibility mode - Interesting point for the future, just how in-depth the compatibility mode actually seems to affect things :) |
| ||
| Compatibility mode affects SystemProperty("OS") but not GetEnv("OS"), at least on my 64-bit Windows 7 PC. GetEnv("OS") returns "Windows_NT" and that's exactly what cmd.exe shows. You can run the command processor on Windows 7 by typing cmd where it says "Search programs and files" in the task bar. To display all environment variables use the Set command with no arguments. Or you can use Set OS to show just the OS variable. |
| ||
| Aaah ok, I misread the post! Glad you solved it |
| ||
| Compatibility mode affects SystemProperty("OS") but not GetEnv("OS") Yes, sorryt I should have said SystemProperty() Regardless, taht's not really relevant to this situation. You can run the command processor on Windows 7 by typing cmd where it says "Search programs and files" in the task bar. To display all environment variables use the Set command with no arguments. Or you can use Set OS to show just the OS variable. Not sure how this would help in any way since "Windows_NT" is displayed for all OS since Windows 3.5 |
| ||
| How about this? Windows version detection |
| ||
| Thanks, James - but that would have returned the wrong value too, since that is how Kernel32.dll "GetVersionEx()" operates - Running IDEal without Compatibility mode for XP solves the whole thing though, so no worries. |
| ||
| 'incorrect' windows version returned by running in XP compatibility mode is prett ymuch the entire point of compatibility mode in the first place: It often allows you to run a poorly-written older piece of software that explicitly tests if it's running on XP (or XP + 2000, or...) and would otherwise simply refuse to run because it assumes you're running on something 'not supported', even when there's no technical reason for preventing this. Compatibility mode bypasses the OS check by lying to the program about what OS it really runs under, and in most cases it turns out that it will run just fine under Vista / 7 / 8 / whatever. |
| ||
| 'incorrect' windows version returned by running in XP compatibility mode is prett ymuch the entire point of compatibility mode in the first place: It often allows you to run a poorly-written older piece of software that explicitly tests if it's running on XP (or XP + 2000, or...) and would otherwise simply refuse to run because it assumes you're running on something 'not supported', even when there's no technical reason for preventing this. Compatibility mode bypasses the OS check by lying to the program about what OS it really runs under, and in most cases it turns out that it will run just fine under Vista / 7 / 8 / whatever. Oh absolutely, of course it is! And I don't consider this to be a bug or error or issue at all - In fact, it's really reassuring to see the level of 'detail'' that compatibility mode actually infers when considering such things. The problem was, that I had forgotten and didn't realise I was running under compatibility mode (Not even sure why I did so in the first place!) and so I was unaware and assumed I was just running IDEal / Blitz normally - which is why I was so puzzled :) |
| ||
| It's very easy to get confused by compatibility issues. I was reminded of this recently when some "drive letter" code showed drive Q, which does not exist. It was a virtual drive created long ago by a trial version of Windows Office. I know these things are difficult because even Mark Russinovich runs across behavior he hasn't seen before. |
| ||
| Incidentally, using the AdvAPI32.dll to query Registry, even when running in compatibility modes in Windows 8, "Windows '95" and "Windows 98" show up as Windows 8. I'm gonna risk a guess that the registry didn't hold the values in the same way pre Windows 2000 Not that I'm particularly fussed, since I doubt I'd really be too concerned with compatibility for pre-WindowsXP but I thought I'd just mention it, seeing as it's sort of related :) |
   |