OS Version

[DXRW4E]

Now that the GetVersionEx was declared deprecated, it seems that the manifest mod

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
        <!-- 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}"/>
        <!-- Windows 8.1 -->
        <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
        <!-- Windows 10 -->
        <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    </application>
</compatibility>

is not the best way, AutoIt in Windows 10 @OSVersion return WIN_81 (v6.x not v10.x) and @OSBuild return 9600, I think is better to use RtlGetVersion to always be sure that everything is Ok

expandcollapse popup

#ifndef _LOAD_NTDLL_
    #define _LOAD_NTDLL_
    #include <windows.h>

    /////////////////////////////////////////////////////////////////////////////////
    // The NtXxxRoutines functions have no associated import library. You must use 
    // the LoadLibrary and GetProcAddress functions to dynamically link to ntdll.dll.
    /////////////////////////////////////////////////////////////////////////////////
    HMODULE hNtDll = LoadLibraryW(L"Ntdll.dll");

#endif  /* _LOAD_NTDLL_ */

#ifndef NTSTATUS_EX_
    #define NTSTATUS_EX_
    typedef _Return_type_success_(return >= 0) LONG NTSTATUS;
    typedef NTSTATUS *PNTSTATUS;
#endif  /* NTSTATUS_EX_ */

#ifndef STATUS_SUCCESS
    #define STATUS_SUCCESS    ((NTSTATUS)0x00000000L)
#endif  /* STATUS_SUCCESS */


#ifndef Run_Time_Library_RTL_Routines
    #define Run_Time_Library_RTL_Routines

    BOOL _Check_Get_Version_(void);
    typedef NTSTATUS(WINAPI * PFN_RTLGETVERSIONEX)(OUT LPOSVERSIONINFOEXW lpVersionInformation);
    PFN_RTLGETVERSIONEX RtlGetVersionEx = (PFN_RTLGETVERSIONEX)GetProcAddress(hNtDll, "RtlGetVersion");
    static const BOOL _b_G_V_ = _Check_Get_Version_();

    //typedef NTSTATUS(WINAPI * PFN_RTLGETVERSION)(OUT LPOSVERSIONINFOW lpVersionInformation);
    //PFN_RTLGETVERSION RtlGetVersion = (PFN_RTLGETVERSION)RtlGetVersionEx;
    //#undef GetVersion
    //#define GetVersion RtlGetVersion

    #undef GetVersionEx
    #define GetVersionEx RtlGetVersionEx

#pragma warning( push )
#pragma warning( disable : 4996 )
    BOOL _Check_Get_Version_() { if (!RtlGetVersionEx) RtlGetVersionEx = (PFN_RTLGETVERSIONEX)GetVersionExW; return TRUE; }
//#pragma warning( default : 4996 )
#pragma warning( pop )

#endif  /* Run-Time Library_(RTL) Routines */

//OSVERSIONINFOEXW osvi = { sizeof(osvi), 0, 0, 0, 0,{ 0 }, 0, 0 };
//GetVersionEx(&osvi);
//// return
//dwOSVersionInfoSize - 284
//dwMajorVersion      - 10
//dwMinorVersion      - 0
//dwBuildNumber       - 9901
//dwPlatformId        - 2
//szCSDVersion[ 128 ] -
//wServicePackMajor   - 0
//wServicePackMinor   - 0
//wSuiteMask          - 256
//wProductType        - 1
//wReserved           - 0

Ciao.

Edited January 21, 2015 by DXRW4E

[francoiste]

interesting finding, indeed.

this would also eliminate the requirement that both, autoit itself and also the scripts to be compiled need to be manifested.

for example see these related discussions:

• https://www.autoitscript.com/forum/topic/161110-windows-8-detect-the-different-versions/
• https://www.autoitscript.com/forum/topic/167470-osversion-and-win-10/

 

i strongly vote for implementing the proposal by DXRW4E.

this seems to be a "feature request" or "change request" addressed at the AutoIt developers.

(not really clear from the initial post)

there is already a related pending feature request:

• https://www.autoitscript.com/trac/autoit/ticket/2989

 

side note:

also the dev team of the "WiX Toolset" has implemented a similar fix starting with WiX 3.8: http://wixtoolset.org/issues/4061/

--

some remaining question:

in current context i have seen the following calls being discussed:

• GetVersionEx
• NetWkstaGetInfo
• RtlGetVersion

are there any references that RtlGetVersion will not be affected by the "OS version lie" by microsoft.

not even in the future (e.g. for windows 10 RTM release)?

Edited June 16, 2015 by francoiste

[DXRW4E]

Native API never wrong, if they are wrong after ehhhhh (how to say a catastrophe happens in system)

 

Ciao.

[FredAI]

The real problem is not GetVersionEx(). It's the AutoIt compiler that does not set the application's manifest correctly. And before anyone asks, yes I am using the latest 3.3.14.1 version, and yes, I'm using the #pragma compile(Compatibility, win10) directive.

I opened my compiled file with resource hacker and got this:

The entry for Windows 10 (<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>) is missing! After adding that entry everything works fine, including @OSVersion and GetVersionEx(). Microsoft explains why that happens in the GetVersionEx() documentation page.

Hope this gets fixed soon.

[Jon]

Did you compile it with aut2exe directly (this adds a win 10 manifest, I checked). Or scite? I thought Jos had fixed the win10 manifest but it might be in the beta version.

Edited August 4, 2015 by Jon

[Jos]

Did you compile it with aut2exe directly (this adds a win 10 manifest, I checked). Or scite? I thought Jos had fixed the win10 manifest but it might be in the beta version.

 

The Manifest in the first post is generated with AutoIt3Wrapper and the one without the  "<!-- Windows 10 -->" comments by aut2exe.
It is correct what is stated by FredAI, The default Manifest is correct but when adding the #PRAGMA statement the WIN10 code isn't there.

Jos

 

Edited August 4, 2015 by Jos

[Jon]

Hmm, I'll take a look tomorrow. I think I caught the command line switches but maybe I missed pragma. 

[archrival]

FYI, it appears calls into GetFileVersionInfoSize and/or VerQueryValue also require the manifest to be updated when asking for the version of system files.

The string values (FileVersion and ProductVersion) don't change, but when asking for the root "\" this causes FileGetVersion($filename) to return different results depending on the manifest applied to the executable. As long as AutoIt3Wrapper and Aut2Exe both apply the Windows 10 manifest by default now it won't be an issue, but I'm just mentioning it because I have not seen any mention from Microsoft about the manifest affecting File version checks.

I have attached an archive containing a sample script and compiled scripts with different manifests applied that show the issue. The value of dwFileVersionMS changes depending on the manifest. AutoIt has the Windows 10 manifest applied to it so if you just execute the script without compiling it will show you 10.0.

VersionTest.au3

VersionTest.7z

[Jos]

The issue is already fixed and will be part of the next beta.

Jos