none
Windows 8.1 Preview GetVersionEx reports 6.2.9200

    Question

  • Can anyone comment on why the GetVersionEx API on Windows 8.1 Preview reports 6.2.9200 instead of 6.3.x?

    C:\>getversionex.exe
    6.2.9200 N/A Build 9200

    systeminfo.exe obtains the version information through WMI: Win32_OperatingSystem and reports the "correct" version:

    C:\>systeminfo

    Host Name:                 WIN-QJNHK7TGRV7
    OS Name:                   Microsoft Windows Server 2012 R2 Datacenter Preview
    OS Version:                6.3.9431 N/A Build 9431
    OS Manufacturer:           Microsoft Corporation

    getversionex.cpp

    #include "stdafx.h"
    
    
    int _tmain(int argc, _TCHAR* argv[])
    {
    	OSVERSIONINFOEX osvi = {0};
    	osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
    	::GetVersionEx((OSVERSIONINFO*)&osvi);
    	if(osvi.szCSDVersion[0] == _T('\0'))
    	{
    		_tcscpy_s(osvi.szCSDVersion, L"N/A");
    	}
    	CString version;
    	version.Format(L"%u.%u.%u %s Build %u", osvi.dwMajorVersion, osvi.dwMinorVersion, osvi.dwBuildNumber, osvi.szCSDVersion, osvi.dwBuildNumber & 0xFFFF);
    	
    	_tprintf_s(version.GetString());
    
    	return 0;
    }





    • Edited by Euclid Tuesday, June 25, 2013 7:06 AM
    • Moved by HCK Moderator Friday, June 28, 2013 6:04 PM This is an API question. Not related to HCK.
    Tuesday, June 25, 2013 6:09 AM

Answers

All replies

  • I confirm that detection - this is unthinkable that even the build version did not change. We just noticed that here also.

    Someone at MS should check the build process.


    • Edited by chksr Thursday, June 27, 2013 11:56 AM relation
    Thursday, June 27, 2013 11:55 AM
  • It also seems that as of Windows 8.1 GetVersionEx is deprecated:

    From the 8.1 SDK (Visual Studio 2013 Preview):

    NOT_BUILD_WINDOWS_DEPRECATE
    WINBASEAPI
    __drv_preferredFunction("IsWindows*", "Deprecated. Use VerifyVersionInfo* or IsWindows* macros from VersionHelpers.")
    BOOL
    WINAPI
    GetVersionExW(
        _Inout_ LPOSVERSIONINFOW lpVersionInformation
        );


    • Edited by Euclid Friday, June 28, 2013 7:32 PM typo
    Friday, June 28, 2013 8:54 AM
  • This is explicitly addressed in the updated appcompat cookbook

    http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx

    In short: GetVersion(Ex) lies to you unless you explicitly embed a manifest to indicate your app is compatible with Windows 8.1.

    Note: VerifyVersionInfo doesn't lie to you and works as expected for "you must be this high to ride this ride" style checks which is really the only kind of OS check that's remotely safe in terms of forward app compat.



    Friday, June 28, 2013 9:08 PM
  • ... but the "IsWindows* macros from VersionHelpers." are not defined in VS2012.

    Just what I expected - sorry, but I'm tired of the loops we have to jump through just because "compatibility" problems of other people, or that MS thinks that could happen.

    Is there any way to detect the presence of such a manifest (that is, if you're lied to), if you're a plugin? Otherwise people will start looking at other ways to detect the "real" version (at least, in our case, just for a LOG file that shows the "real" environment) - we do it by querying the KERNEL32 version, which is a hack that is forced by MS just because they have no way to switch off that intermediate layer.

    A new TRUEOSVERSIONINFOEX struct that tells Windows to return the "real" values (different size to the OSVERSIONINFOEX structure) would resolve the issue.

    • Edited by chksr Monday, July 01, 2013 10:24 AM new API idea
    Monday, July 01, 2013 10:15 AM
  • It also seems that as of Windows 8.1 GetVersionEx is deprecated:

    From the 8.1 SDK (Visual Studio 2013 Preview):

    NOT_BUILD_WINDOWS_DEPRECATE
    WINBASEAPI
    __drv_preferredFunction("IsWindows*", "Deprecated. Use VerifyVersionInfo* or IsWindows* macros from VersionHelpers.")
    BOOL
    WINAPI
    GetVersionExW(
        _Inout_ LPOSVERSIONINFOW lpVersionInformation
        );


    But the official API description (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx) does not tell us anything about deprecation, just that it might lie due to the appcompatibility settings. Not wrong per se, but for debugging (log file) I'd like to know the compatible AND the real version.
    Monday, July 01, 2013 10:28 AM
  • If you're a plugin, you must conform to the process environment you live in. If the process believes the world is NT 6.2, it is no other than NT 6.2.

    If you need your own environment to see the real world, why don't you use your own process for that purpose?

    Monday, July 01, 2013 10:38 AM
  • Imagine it's a plugin that can execute things the application cannot (most of the times, that's what plugins are for). And imagine, the plugin knows it can use a feature under 8.1 (or whatever version) that the application if not built for? Why should the application (created by developers I don't even know) foresee all features my plugin (unknown to the app's creators) would like to use? That makes no sense, it limits the usefulness of plugins (external modules etc).

    To make it clearer, assume you have a printing plugin. And the app does not know what the printing plugin could use to do its job. Why should the application foresee the APIs (or other features of "the process environment") it uses to fulfill the job? Imaginge different plugins, some more sophisticated (using newer APIs) and some older ones...


    Monday, July 01, 2013 12:47 PM
  • Chuck: Thank you. Since GetVersionEx has been deprecated, what is the recommended way on how to get the real Windows version (e.g. for logging/reporting)? WMI? Registry?
    Monday, July 01, 2013 6:40 PM
  • That's exactly why MS has stopped trusting developers and started the version lie. "I'll do one thing on version==x.x and another on version==x.y" blah blah broke many things.

    For version criteria, VerifyVersionInfo() serves.

    Monday, July 01, 2013 7:08 PM
  • If you are writing a Win32 native EXE, the use of the embedded compatibility manifest is probably the simplest and most robust thing to do.

    I believe WMI will also give you correct information, but you should check that...

    Monday, July 01, 2013 8:10 PM
  • Chuck: There are a few problems with the GetVersionEx API:

    1. As it is declared as deprecated we cannot easily use in an application when using the Windows 8.1 SDK. Hacks are required to suppress just this one warning/error and not all others.

    2. What guarantee do we have that the correct version is reported for post Windows 8.1 versions? If a new compatibility/application/supportedOS entry is required in the manifest for every new Windows version, we will have the same problem again.

    Yes, WMI reports the correct information regardless of the appcompat shims.

    Tuesday, July 02, 2013 1:57 PM
  • What you describe is "By Design". Unless your application has the GUID to indicate compatibility with the current OS, then the OS may provide older information to avoid app compat bugs.

    It is not a 'hack' to use #pragma warning(push) #pragma warning(disable:4995) #pragma warning (pop) around code, but you at least know that the API in question is deprecated and you should look to see if (a) you really need to call this API and (b) if there are better alternatives. How about the GetFileVersionInfo on kernel32.dll recommendation from MSDN? 

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms724429(v=vs.85).aspx

    Tuesday, July 02, 2013 5:52 PM
  • Yes, but Plugins/DLLs etc are not "the app".

    They might have different requirements.

    Otherwise it sounds as if you're not allowed to modify your car with newer accessories as the ones that existed when the car was designed (no navigation kit for cars older than 10 years!).

    No, this is bad design, IMHO.


    Thursday, July 04, 2013 10:15 AM
  • Hello)

    Be calm) All problems solved with simple solution!

    If VerifyVersionInfo recommended, so then we will use it and one more numeric method - bisection method.

    New api the same. Function name is GetVersionExEx, sources available here - https://bitbucket.org/AnyCPU/findversion

    Implemented in C. Test app available too.

    Heh, write in C, let it C)))

    Thanks)


    • Edited by iContribute Monday, July 08, 2013 6:14 PM addition
    Monday, July 08, 2013 6:13 PM
  • VerifyVersionInfo is intended for simple "you must be this high to ride this ride" compatibility tests or to exclude specific versions. It's not a great option if you are just trying to capture a version string for use in logging or diagnostics.

    If you read the MSDN link I provided above, getting the File Version info off the KERNEL32.DLL is probably the best way to get just the version for logging. I would NOT guard any feature app or installer behavior based on this.

    iContribute's post just recreates the same problem that deprecating GetVersionEx was fixing in the first place. Please don't use this kind of thing...

    Monday, July 08, 2013 8:06 PM
  • 
    

    At least two big projects that I know will start accept some bug requests related to this deprecation.

    One of them is Mono Project - alternative .NET implementation.

    It's used by Environment.OSVersion property. To be fair an official .NET version does not have this issue and mentioned property returns valid info under Windows 8.1.

    So, VerifyVersionInfo and numeric bisection method are better friends here.

    Guidelines - good, deprecation without alternative - not. And let's users/developers choose what is better.

    And finally... I want super-duper about dialog with valid version numbers.

    Chuck, to be fair again.. I don't recreate problem, I fix her. It's custom solution, You want it - You get it.

    Oh, and "getting the File Version info off the KERNEL32.DLL" What is it? Joke? Seriously? Only bad words. Embedding manifest, WMI win32 class, system file version - it's all - Kung Fu.

    Write, Compile, Copy, Run = Fun.

    Thank you very much for your attention!

    P.S.: Deprecation it's really bad decision.

    P.P.S: Numeric methods rulz! 



    • Edited by iContribute Monday, July 08, 2013 8:59 PM addition 2
    Monday, July 08, 2013 8:50 PM
  • My point is that going the route iContribute recommends will result in a future version of Windows having to lie to VerifyVersionInfo to avoid appcompat problems..

    The key question gets back to why you are calling GetVersionInfo(Ex) in the first place... Most use of this function is problematic and probably not needed, so the API has been deprecated.

    The MSDN link provides the alternatives.

    Monday, July 08, 2013 11:07 PM
  • In that case VerifyVersionInfo,GetFileVersionInfo, VerQueryValue, WMI win32 class... even.NET assembly that can be consumed in code - good candidates to be deprecated... (heh, kernel32.dll will be deprecated too?).  Instead simple os api call, we need write a spaghetti code that does the same and even in this case used api maybe will deprecated. Sure.... Yeah... it's right way.  Code above uses: simple code, recommended api (ms725492(v=vs.85).aspx "It is preferable to use  VerifyVersionInfo rather than calling the GetVersionEx function to perform your own comparisons." and others places on MSDN), same api that in VersionHelpers.h (Who need this header?), precise algo and good old plain C. Oh, no.. it's good... definitely will be deprecated.

    So, provided above "alternatives" also will be deprecated if will widely used?

    Tightening the screws is the right way)

    • Edited by iContribute Tuesday, July 09, 2013 4:19 AM addition 3
    Tuesday, July 09, 2013 4:14 AM
  • The right solution is for developers to step back and look at why they are trying to determine the OS version.

    For logging and diagnostics, the GetFileVersionInfo solution seems to be the recommended approach given a fallback that can handle 'version information unknown' as a failure case instead of crashing the application. WMI is also a robust way to achieve this.

    For install 'you must be this high to ride this ride' checks, that would be best handled with VerifyVersionInfo.

    Otherwise, developers should try to eliminate use of GetVersion(Ex) entirely. Often there are other methods for detecting the presence of features that are much more robust. For example, an error return code on a factory method or a failed attempt to QueryInterface. These are the scenarios that deprecating GetVersion(Ex) is explicitly trying to address.

    For all other applications that really do need the functionality of GetVersion(Ex) to return the difference between Windows 8 and Windows 8.1, the EXE manifest is probably the best choice. A manifest is nothing more than  piece of text included as a Win32 resource. For C++ developers, adding a manifest is fairly trivial. For Someone using the VS IDE to build their projects, it's a build setting that isn't terribly difficult to add via the "additional manifests" option. Getting this manifest support built into VS has already been raised with the appropriate team. Clearly for .NET and Mono developers, this is something that should be handled automatically if possible as the compatibility manifest elements are likely to get leveraged by appcompat more over time.


    Tuesday, July 09, 2013 6:15 PM
  • It's called - what to do to make more fun.
    Tuesday, July 09, 2013 9:04 PM
  • Chuck,

    sorry - but "For all other applications that really do need the functionality of GetVersion(Ex) to return the difference between Windows 8 and Windows 8.1, the EXE manifest is probably the best choice. A manifest is nothing more than  piece of text included as a Win32 resource. For C++ developers, adding a manifest is fairly trivial. " just does not do it! It works for the application code, but not the code of modules (DLLs, plugins - you name it) inside that application. Which might be unknown at application build time.

    Well, I guess we can stop here. No sense arguing if the case is not understood well at MS's side. Time for us "real world" developers to find (cludgy) workarounds. Which might give MS more headache at a later time.

    Developers using GetVersion(Ex) to rely on features should be banned anyway ;)

    Wednesday, July 10, 2013 6:14 AM
  • "The right solution is for developers to step back and look at whythey are trying to determine the OS version."

    No, it's not.  It's not up to you to make morality judgments about my code.

    I'm agog that you really can't see what's wrong with this.  Microsoft told us in 1995 or so that GetVersionEx was going to be the right way to get the OS version in the future.  We believed you, and now you are lying to us.

    It just seems completely idiotic that it was OK to have GetVersionEx tell the truth in every NT version from 3.51 through 8.0, and now with version 8.1 you suddenly decide that it's necessary to lie.  How could there possibly be any failed appcompat scenario in code that was not produced by a complete moron?  How could the decision to lie in such a fundamental, low-level and non-dangerous API possibly have passed through a technical review without being laughed out of the meeting?

    Of course it's possible to come up with workarounds in new code, but in the real world outside of Redmond, people run EXISTING binaries, forever.  Those binaries will now print out incorrect information, unnecessarily.  THAT is an appcompat failure.


    Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

    Wednesday, July 10, 2013 7:10 AM
  • FWIW, GetVersionEx has routinely lied to applications via various appcompat shims which had to be applied to hundreds of individual applications every release of the OS. One of the Application Verifier tests is "HighVersionLie" because this is an extremely common source of appcompat problems.

    If your existing binary runs on Windows 8.1, that's an appcompat success. The tradeoff here was to get more applications to work "as is" without the need to individually shim hundreds of them in trade for diagnostic logs displaying slightly outdated information (6.2 instead of 6.3) in some applications.

    Wednesday, July 10, 2013 4:18 PM
  • chksr and Tim Roberts,

    +1!

    Yes, to do more precise testing of feature availability will used something that do it best.
    But this change just adds a little pain in back side, nothing new or useful.

    The best <<How could the decision to lie in such a fundamental, low-level and non-dangerous API possibly have passed through a technical review without being laughed out of the meeting?>>. Getting version number of core OS(not its features) via system file info and much longer code - not bad too.

    The lie it's allways very bad.

    Wednesday, July 10, 2013 6:22 PM
  • My.Computer.Info.OSVersion.ToString in .NET Framework 4.0 also lies!

    It reports 6.2.9200!

    Wednesday, July 10, 2013 10:58 PM
  • Technical note: You can use the Manifest Tool (MT.EXE) to inject a manifest into an existing EXE (i.e. without having to rebuild it). The only downside is if the EXE was code-signed which would of course modify it and invalidate the signature.

    RE: plug-ins, the best option if you can't avoid the need to use GetVersoin(Ex) would be to get the host application manifested--assuming that's an option.

    Wednesday, July 10, 2013 11:35 PM
  • I believe this is expected unless the .NET application EXE is manifested with the compatibility section.
    Wednesday, July 10, 2013 11:38 PM
  • "RE: plug-ins, the best option if you can't avoid the need to use GetVersoin(Ex) would be to get the host application manifested--assuming that's an option."

    More often than not, this is no option. We sell add-on tools for other developers - no way to ask them to do that, they would react correctly and ask if we're crazy.

    We use GetVersionEx for "large" changes like theming availability, which are definitely version-bound, all other features are decided upon API or interface availability. And the wrong descriptions in the MSDN (a lot of APIs that existed in NT2000 are not "supported starting Windows XP") does not make life easier for us programmers. Why does the documentation change for the worse?

    For me, this is a theoretical discussion, as I think Microsoft should leave some decisions to the developers, and also give them the blame if they do something wrong. I know there are a lot of developers out there which make your hair stand on end, but suppressing mistakes of these will not raise the level to be considered a "developer", to the contrary. And the others will make workarounds that make compatibility harder at a later time.

    In Germany, we say "gut gemeint ist das Gegenteil von gut", which means "well-meant is the contrary of well-done".

    • Edited by chksr Thursday, July 11, 2013 1:30 PM change
    Thursday, July 11, 2013 1:20 PM
  • osvbnet, should recompiled with new toolset
    Thursday, July 11, 2013 6:36 PM
  • "We sell add-on tools for other developers - no way to ask them to do that, they would react correctly and ask if we're crazy."

    Why would that be 'crazy' exactly? Presumably the host application(s) are intended to be fully compatible with Windows 8.1?

    I fully appreciate that relying on the host application doing this in a timely fashion for your add-ons is unrealistic, but longer-term the intent is for every application that explicitly supports Windows 8.1 to have these elements in an embedded manifest.


    Thursday, July 11, 2013 6:38 PM
  • chksr, ... or ... well are determined to make life complicated
    • Edited by iContribute Thursday, July 11, 2013 7:16 PM 777888
    Thursday, July 11, 2013 7:02 PM
  • Why not? Stable frozen API. Embedded manifest does not guarantee anything for app or add-on. All bugs remain in its places.

    New feature - old bugs adapted for new OS (proved by manifest). That what we need)


    • Edited by iContribute Thursday, July 11, 2013 7:15 PM 12345
    Thursday, July 11, 2013 7:14 PM
  • So I used the below code and now everything's alright!

    However, where to find supportedOS Id for Win XP, Server 2008, Server 2008 R2 to add to manifest?


        <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
            <application> 
                <!-- Windows 8.1 -->
                <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
                <!-- Windows Vista -->
                <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
                <!-- Windows 7 -->
                <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
                <!-- Windows 8 -->
                <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            </application> 
        </compatibility>
    Friday, July 12, 2013 6:34 AM
  • These manifest elements were introduced in Windows Vista. Windows XP ignores them.

    The Windows Vista GUID applies to both Windows Vista and Windows Server 2008.

    The Windows 7 GUID applies to both Windows 7 and Windows Server 2008 R2

    The Windows 8 GUID applies to both Windows 8 and Windows Server 2012

    The Windows 8.1 GUID applies to both Windows 8.1 and Windows Server 2012 R2

    Friday, July 12, 2013 6:15 PM
  • Thank you for the valuable information, however, the provided GUID for Win 8.1 & Server 2012 R2 Preview versions will be the same as the RTM?
    Saturday, July 13, 2013 8:46 PM
  • I don't know for sure, but the Windows 8 GUID was fixed as of the Developer Preview. There's not much reason to change it...
    Monday, July 15, 2013 2:45 AM
  • Assuming you would a photoshop plugin, would you really ask Adobe to alter the manifest of Photoshop (although they might gain nothing out of it, even if they are "fully compatible" -> principle "never change a running system")? If your plugin will/should also work in an older, non-maintained version?

    I guess not. You can try anyway, but you will not succeed.

    Still you would like to get the "correct" Windows version (8.1) in your plugin, if only for debugging purposes if your plugin has problems and you would like to reproduce the problem using the correct environment (and, say, assuming the problem is problem appearing in 8.1 only - and YES, that might happen, even if MS does not like it).

    So now MS has the problem that all modules wanting to be independent of the app (i.e. third-party tools) must use some other way to get the correct Windows version, and there's no way to "virtualize" these calls later if MS wants to. Whatever for.


    Tuesday, July 16, 2013 9:46 AM
  • all modules wanting to be independent of the app
    That's where you're going wrong and creating problems by yourself.
    Tuesday, July 16, 2013 10:30 AM
  • What do you expect that tool developers should do? Remain at the stage of the host app, even if they know they can or must exploit the OS more? No sir. Add-ons might know better what to do, depending on the host OS ;)

    OTOH, at least for debugging purposes, we need the real version number. The rest (API flavours etc) is queried on demand (at least, most of it). So as I said it's irrelevant, except it shows some app-centric thinking.

    (And why does this control change the font size when I kill a superfluous line break? Sigh.)

    Tuesday, July 16, 2013 11:55 AM
  • The process is the resource partition and the application is the owner of the process. In-process modules must obey the process environment created for the application. It is as simple as that.

    If you need independent freedom, you can have it in your own process.

    Thursday, July 18, 2013 9:11 AM
  • I would love to know why you think that.

    Might make sense in some cases, but obviously not for developer tools (some customers use - yes - VB 6, Access, Alaska xBase, ...). Do you really think MS will add a corresponding "Win 8.1-compatible" manifest to VB6? ;)

    Well as long as it's only a "GetVersion()" lie, we can live with it, use the workaround, and feel good. But otherwise, if "real" features themselves are limited according to some application-only manifest, I will send a **** (NSA blackened no-no-word of an explosive) to Redmond.


    Tuesday, August 13, 2013 1:55 PM
  • "If you need independent freedom, you can have it in your own process."

    You think we need to rewrite customer's applications or whole development environments just to allow them to use new OS features?

    See my comment above. This would cost us a lot of customers who cannot change their IDE/development environment just as their underwear. For some applications, these are fixed for a whole lifetime of that application. Still the customers like new features of our tool, of course!

    The obvious solution would be an out-of-process server, but that would be overkill and a speed brake.

    Tuesday, August 13, 2013 2:06 PM
  • You think we need to rewrite customer's applications or whole development environments just to allow them to use new OS features?

    VB6 is long out of support: http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=visual+basic&Filter=FilterNO

    In all technical environments there comes a time to cut old stuff to medernize. That is the way...

    You should be able to solve your problem if you add an manifest as resource to your application (maybe in a post build process, if you can not add user resources in VB!?!? - I',m no VB user). Than GetVersionEx will work. I did this manifest stuff for an old VC++6 application some time ago, and it worked without problems. Why not doing the same in VB?


    Best regards

    Bordon

    Note: Posted code pieces may not have a good programming style and may not perfect. It is also possible that they do not work in all situations. Code pieces are only indended to explain something particualar.

    Thursday, August 15, 2013 7:28 AM
  • You think we need to rewrite customer's applications or whole development environments just to allow them to use new OS features?

    No. The applications should run just fine on the new OS. That's exactly why the version lie is there. It enables the application to work flawlessly on the new OS without rewrinting the application at all.

    Thursday, August 15, 2013 10:01 AM
  • Sorry, but is it that hard to understand that "You should be able to solve your problem if you add an manifest as resource to your application " is not possible, as the application is not MINE, but from a customer that just uses our tool to print nice reports?
    Thursday, August 15, 2013 2:45 PM
  • Yes. The application.

    But I'm talking about our DLL in a host application not written by us. And our DLL would like to see all OS features (right now we can see everything, but once Windows "lies" about features, we get into troubles), and the true OS version (for now, just for debug logging).

    So right now, it's a non-issue, but it makes me wonder what the MS developers think. There used to be a "divide the work and reuse these parts"-pattern, that's what DLLs are for, and now MS becomes EXE-centric and forgets about the myriad of DLLs that do not care about the OS version that is presented to the application. If at all, they would need their own small "lie" according to a manifest in the DLL.

    Imagine, the host application says "well, I can live with and use Windows 8.1's features", but then one of these DLLs gets into trouble as it can NOT support these? Will the developer of the EXE (even be able to!) ask all DLL manufacturers about their attitude towards an entry in the manifest that he likes to set because HE likes to express new Windows-compatibility with HIS application?

    It just does not fit the system of Application and DLLs.

    Thursday, August 15, 2013 2:58 PM
  • An EXE that consumes 3rd party DLLs already has to take responsibility for integration testing. If they add the manifest entry to the EXE that declares support for Windows 8.1, then presumably they actually tested it on Windows 8.1. This is why the compat manifests use a GUID so that developers can't just throw in "I support all the Windows" and then fail to actually test it on a future OS that believes it is compatible.

    There are of course special challenges for an EXE that use as-yet-unseen 3rd party DLLs as a 'plug-in' model. The point here is that the host application is not declaring full support for Windows 8.1, so the whole process is treated as if it in a compatibility mode.


    Thursday, August 15, 2013 6:18 PM
  • Here is a new CodeProject article about detection of "true" Windows version.

    Still it is a mystery why we have to take all these hoops. Doesn't this mean that the next OS technically is not  "Windows" or "Windows NT" any more, so the query becomes meaningless?

    -- pa

    • Proposed as answer by elbix Thursday, January 16, 2014 2:38 PM
    Monday, November 11, 2013 12:53 PM
  • This seems to be a case of "the cure is worse than the disease".

    For most people, the solution is pretty easy.

    * Remove use of GetVersion and GetVersionEx everywhere you can. Use built-in versioning mechanisms like gracefully failing to initialize a component.

    * Use VersionHelpers.h if you can or the VerifyVersionInfo() API for 'you must be this high to ride this ride' style of checks.

    * If you still need it for a reason other than logging, then add the manifest elements and continue to call GetVersion/GetVersionEx.

    * For logging, just grab the version string from kernel32.dll and use it as an opaque string (i.e. don't try to parse it).

    I do understand that people who are writing plug-ins are in a bind until the core application updates itself with the manifest elements, but that doesn't mean the rest of world of application developers should go crazy over this.


    Tuesday, November 12, 2013 6:50 AM
  • I guess fundamentally you don't get it, which is why the guys are jumping on you about it.  Don't lie in your API calls. Period.  Some of us have written stable, unchanging, working, industrial code that may be even older than you are.  the API is a contract and you broke it. Don't go defending that change.  What the developers are doing with the information is their own bad or good decisions and the OS manufacturer has no place in handling our code.  Of course, maybe it's that your own MICROSOFT applications have issues and your trying to help your brethren out.

    Regardless, there are business reasons we have customers that do not permit changes to released/paid-for code that they put on newer operating systems. If Microsoft built buildings like they do software, the buildings would fall down yearly and require reconstruction. Great for employment, bad for business.

    Wednesday, January 08, 2014 2:42 PM
  • There are a number of appcompat behaviors contingent on application manifests spanning the past few releases of Windows. A summary of the key ones is covered by this blog post.

    http://blogs.msdn.com/b/chuckw/archive/2013/09/10/manifest-madness.aspx

    Wednesday, January 08, 2014 6:37 PM