Windows 8.1 detection

[Anders]

Originally Posted by LoRd_MuldeR

Restricting VerifyVersionInfo() to only accept what would have been accepted by the older Windows version obviously doesn't aid the golad to improve compatibilty.

Well, I don't agree with this at all.

Imagine this program:

if (IsVistaOrLater())
DoVistaThing();
else
DoXPThing();

With this code, what happens when you choose a compatibility option in the .exe properties depends on the implementation of the IsVistaOrLater() function in this program. If GetVersion[Ex] was used then the program will fall back to XP behavior like the user requested but if VerifyVersionInfo was used then the users choice is ignored. You could argue that this is not a compatibility issue since the program knows about Vista but perhaps DoVistaThing() stopped working in 7 and you need to fall back to XP behavior for the program to work at all.

Imagine another scenario: A program uses VerifyVersionInfo but one of the 3rd party DLLs it depends on uses GetVersion, the combined program logic will now be out of sync!

VerifyVersionInfo was invented because people wrote broken comparison code like:

if (major >= 5 && minor >= 1)
DoXPThing();
else
MessageBox("Not supported on this version of Windows");

(This is broken on Vista and would think it is < XP but works correctly again on 7)
IMHO VerifyVersionInfo should not act like some backdoor that ignores the requested compatibility mode and should just report the same results as GetVersion.


I also don't understand your compatibility != emulation argument. Emulation is exactly what it does, when the program is started the loader replaces standard Windows functions with a different function that is designed to work like it did in the older OS ( http://blogs.technet.com/b/askperf/a...new-stuff.aspx ). A couple of the shims even have Emulate in their name ( http://technet.microsoft.com/en-us/l...=ws.10%29.aspx )

A real world scenario where the version lie is not even about compatibility but the desire to emulate older behavior is/was MSN messenger. On 7 if you want it to use the tray icon mode you have to emulate a OS that does not have the new taskbar api.

[Lenge]

Originally Posted by Anders

Well, I don't agree with this at all. [...]

I respectfully disagree. I fully agree with MuldeR in this respect. As a developer, I definitely need a reliable way to detect the exact true Windows version that my application is running on, regardless of whatever manifest or compatibility options have been set.

What I do not need is a vendor that tries to tell me that I wouldn't want to know (or am not even allowed to know). Of course, we're all trying to make our apps as compatible with different versions of Windows as possible. But if I decide to query the real version, I do that for a reason, and I want to be sure that the result is correct.

However, I have no objections against having separate functions for "GetWindowsVersion" and "GetRealWindowsVersion", where the second one is not affected by whatever compatibility setting.

[Anders]

Originally Posted by Lenge

I respectfully disagree. I fully agree with MuldeR in this respect. As a developer, I definitely need a reliable way to detect the exact true Windows version that my application is running on, regardless of whatever manifest or compatibility options have been set.

What you are saying does not make any sense to me. The reason the compatibility shims exist in the first place is so people can apply them on broken applications. If you are asking for a way around that then you are just going to end up causing extra pain for end users down the road unless you write perfect bug free software.

For diagnostics, sure, include kernel32 version, registry version or a GetRealWindowsVersion based on VerifyVersionInfo but for decisions made at run-time I don't think it is wise to fight whatever shims someone has applied to your process.

Before 8.1, things in the manifest only unlocked new features and it is sad that MS has decided to change that. I still think it is a good idea to wait for 8.2 to see if the 8.1 guid is enough to unlock GetVersion before we start thinking about ways to bypass everything...

Originally Posted by Lenge

What I do not need is a vendor that tries to tell me that I wouldn't want to know (or am not even allowed to know). Of course, we're all trying to make our apps as compatible with different versions of Windows as possible. But if I decide to query the real version, I do that for a reason, and I want to be sure that the result is correct.

When you say vendor, do you mean NSIS or MS?

As a user I feel that it is my machine and if I want to put your application in compatibility mode then that should be my decision and there should not be anything you can do about it. Sadly because the version functions are implemented differently, Win8.1 leaves us in nowhere land where all of this depends on which function the developer chose to use.

[Lenge]

Originally Posted by Anders

When you say vendor, do you mean NSIS or MS?

I mean Microsoft (the OS vendor that controls the APIs). NSIS is more like a partner that helps me work around some of their OS design decisions. After all, the entire NSIS concept is a way to avoid the "official standard" (which is MSI).

Originally Posted by Anders

As a user I feel that it is my machine and if I want to put your application in compatibility mode then that should be my decision and there should not be anything you can do about it.

Good point, yet still:

1.) While I agree that "GetWindowsVersion" should be the "normal" method to use in most cases, I still sometimes need "GetRealWindowsVersion". And when I do so, I know what I'm doing and why I'm doing that. (And, I promise, it's not for the purpose of insulting the user or making the application break. More of the opposite.) So if there is no cleanly defined "GetRealWindowsVersion" API, I'm forced to use some hack, which in turn is more likely to cause problems than any clean solution.

2.) In the case of Windows 8.1, you (as a user) just cannot decide to not run an application in compatibility mode. Microsoft has already decided that you must run every app in Win8 compatibility mode, unless the app has an explicit 8.1 manifest (which you as a user cannot influence).

[LoRd_MuldeR]

Originally Posted by Anders

Well, I don't agree with this at all.

Imagine this program:

With this code, what happens when you choose a compatibility option in the .exe properties depends on the implementation of the IsVistaOrLater() function in this program. If GetVersion[Ex] was used then the program will fall back to XP behavior like the user requested but if VerifyVersionInfo was used then the users choice is ignored. You could argue that this is not a compatibility issue since the program knows about Vista but perhaps DoVistaThing() stopped working in 7 and you need to fall back to XP behavior for the program to work at all.

Imagine another scenario: A program uses VerifyVersionInfo but one of the 3rd party DLLs it depends on uses GetVersion, the combined program logic will now be out of sync!

VerifyVersionInfo was invented because people wrote broken comparison code like:

(This is broken on Vista and would think it is < XP but works correctly again on 7)
IMHO VerifyVersionInfo should not act like some backdoor that ignores the requested compatibility mode and should just report the same results as GetVersion.


I also don't understand your compatibility != emulation argument. Emulation is exactly what it does, when the program is started the loader replaces standard Windows functions with a different function that is designed to work like it did in the older OS ( http://blogs.technet.com/b/askperf/a...new-stuff.aspx ). A couple of the shims even have Emulate in their name ( http://technet.microsoft.com/en-us/l...=ws.10%29.aspx )

A real world scenario where the version lie is not even about compatibility but the desire to emulate older behavior is/was MSN messenger. On 7 if you want it to use the tray icon mode you have to emulate a OS that does not have the new taskbar api.

Well, I think we can agree that for any possible behavior of the "compatibility mode" we could probably find a program that (still) won't behave as intended with the "compatibility mode" enabled. I think it's just not possible to fix any broken program out there with just a single "compatibility mode" switch - simply because we cannot know what the programmer had originally in mind or what bugs are present in the program. The actual "compatibility mode", as it exists today, has probably been designed to hack around the most common issues.