Winbatch+Compiler - Manifests for Windows 8.1 / Windows Server 2012 R2 ?

[DexterSinister]

I have an app written in Winbatch [currently v2013c] and compiled ...

Because some of the functions of this app are OS version specific, it checks
the OS version on when it is started and proceeds accordingly ... this works
fine on OS versions from XP through Windows 8 / Windows Server 2012, but
is failing on Windows 8.1 / Windows Server 2012 R2.

I found a post in this forum from someone with a similar issue, and his solution
was to use WMI for the moment and wait until the next release of Winbatch for
a longer term solution ... that option doesn't work for me ... so ... what is the
schedule for releasing an updated version of Winbatch+Compiler that has built-in
support for Windows 8.1 / Windows Server 2012 R2 ?  Is it possible to only release
a 'patched' version of the compiler with this support ... ?

Anxiously Waiting for Release,

-dmm

[Deana]

The next release is in the pipeline. It contains the updates that will correct the results from WinVersion. There is no set release date, the release will depend on how well testing goes.

Okay here is a quick explanation as to why the WinVersion function is returning 6.2 (Windows 8.0) rather than 6.3 (Windows 8.1). The underlying GetVersion(Ex) API has been deprecated on Windows 8.1. Microsoft says that is to prevent compatibility problems. Personally, I think it is a horrible idea to break the API in that way.

Possible workarounds:

• MS recommends using the VerifyVersionInfo API instead: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx. You could write a DllCall to call this API.
• Use RegQueryValue to query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT[CurrentVersion]. On 8.1 CurrentVersion will give you 6.3.
• Use Wmi Win32_operatingSystem Class to query the windows version

Here is a code sample for the WMI and Registry workarounds:

Code (winbatch) Select Expand

v = WinVersion(5)
Platform="Unknown"
if v=="1-4-0" then Platform="Windows 95"
if v=="1-4-10" then Platform="Windows 98"
if v=="1-4-90" then Platform="Windows ME"
if v=="2-3-51" then Platform="Windows NT 3.51"
if v=="2-4-0" then Platform="Windows NT 4.0"
if v=="2-5-0" then Platform="Windows 2000"
if v=="2-5-1" then Platform="Windows XP"
if v=="2-5-2" then Platform="Windows 2003 Server"
if v=="2-6-0" then Platform="Windows Vista / 2008"
if v=="2-6-1" then Platform="Windows 7 / 2008 R2"
if v=="2-6-2"
   ; WMI workaround
   ;objWMIService = GetObject("winmgmts:\\.\root\cimv2")
   ;colItems= objWMIService.ExecQuery("Select Version from Win32_OperatingSystem")
   ;ForEach objItem In colItems
   ;      If ObjectTypeGet(objItem)=="EMPTY" Then Continue
   ;      v = objItem.Version
   ;      break
   ;Next
   ;v = StrReplace(StrSub( v, 1, 3 ),'-','.')

;Registry workaround
v = RegQueryValue(@REGMACHINE,"Software\Microsoft\Windows NT\CurrentVersion[CurrentVersion]",64)

   if v == '6.2' then Platform="Windows 8.0 / 2012"
   if v == '6.3' then Platform="Windows 8.1"
endif
Message("Platform",Platform)
Exit

[td]

With the exception of the WinVersion function WinBatch has no known compatibility issue with Windows 8.1 and Windows 2012 R2. 

It is interesting to note that even the lastest version of MSFT's dotNet framework's OperatingSystem class reports the same 6.2 version for both Windows 8 and 8.1. So WinBatch is not alone.  MSFT has decided that checking the OS version is evil for some very dubious reasons.

As demonstrated there are several other ways to obtain the OS version without using WMI or the WinVersion function.

[DexterSinister]

Deana - Thanks for the amazingly fast response!

I'll try your suggestion and will also try to be patient ... good testing = good products

Best regards,

-dmm