>>Sorry to repeat an old topic...
>>
>>Since versions of Windows since 8.1 (and later) essentially lie to a program about version, would the NetWkstaGetInfo() API function ( http://www.news2news.com/vfp/?example=436&function=734 ) work as an alternative to the VFP built-in OS() and GetVersionEx() API function to identify the operating system? On the few tests that I've performed thus far, it appears to give the desired result without having to muck with the manifest (which could be a pain, as each new OS version would likely requires an additional GUID to be added to the manifest). Would there be restrictions to the API (e.g. user privilege level may prevent running the function) that might cause use of this function not to give valid results? One downside thus far I've seen is that the NetWkstaGetInfo() API does not appear exist in 95/98/Me platforms and NT platforms prior to Windows 2000.
>
>
>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
>
>snip:
>
>Windows 8.1 6.3*
>Windows Server 2012 R2 6.3*
>Windows 8 6.2
>...
>
>* For applications that have been manifested for Windows 8.1 or Windows 10 Technical Preview. Applications not manifested for Windows 8.1 or Windows 10 Technical Preview will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10 Technical Preview, refer to Targeting your application for Windows.

As I'd stated previously, with the somewhat limited tests I'd performed, I was indeed getting 6.3 in Windows 8.1 and 10.0 in Windows 10 using NetWkstaGetInfo() -- *without* having to muck with the manifest, while GetVersionEx() would not (they would get "stuck" on 6.2) unless I've modified the manifest. I currently don't have Server 2012R2, so I've not tested with that platform yet.

The page you refer to seems to conflict with the results I'm seeing so far. From what gathered from posts and discussion elsewhere, that the GetVersionEx() function would not return the correct values (unless you muck with the manifest), but the "helper" functions would operate as expected. Does that page which you reference imply that Microsoft is intending to change the behavior so that the "helper" functions will give the same results as GetVersionEx() ? Aside from the manifest affecting the OS version query -- I was reading elsewhere that it may also affect behavior other API functions (though not specified). That is, if you don't explicitly specify compatibility level, you get the "older" behavior (compatible with older OS), but if you do specify compatibility with the newer OS, you may indeed get newer (and possibly incompatible) behavior that could cause your program to not function properly (unless you've explicitly programmed for the newer behaviors).

Of course all this seems confusing and perhaps nonsensical -- at least until you look at things differently. Rather than a statement of the situation, perhaps the reported version along with the compatibility declaration in the application manifest acts as a contractual agreement between the application and the OS? Of course, this does make things very hard to explain to an enduser -- you may make a claim that your program works in a particular version of the OS -- but in reporting the OS version, your application indicates and earlier version for the OS. In the mind of an enduser, that would appear that your application is NOT compatible (even though it would otherwise function normally).

If this is indeed the way the reported version information is to be interpreted, let's not talk about behaviors we'd seen previously -- such as when we tagged application to run in compatibility mode -- the reported OS version was the same as the host OS and not the compatibility setting used... Would the newer versions of the OS change this behavior? This is starting to sound like the game rules for Fizzbin (fictitious card game with rather confusing and somewhat contradicting rules described in an episode of the 1960s Star Trek -- used as a ploy by Captain Kirk as a ploy to distract and confuse the his captors to escape).