Hi,

It appears that the OS function needs to be updated to correctly
report Windows 10:

OS(OS_FULLNAME)+" "+OS(OS_VERSION)

For Win 7 ver 6.1 build 7601 it correctly reports Windows 7 06.01.7601

For Win 8 ver 6.3 build 9600 it correctly reports Windows 8 06.03.9600

However...

For Win 10 ver 1511 build 10586 it reports Windows 8 06.02.9200

The above workstation Windows OS versions were obtained with
winver.exe but it also appears that MS has changed it's ver / build
format.

Regards... Jonathan


Jonathan Leeming
jonathan.leeming@the-family-centre.com

> It appears that the OS function needs to be updated to correctly
> report Windows 10:

you need to enhance you XP Manifest with "supportedOS"

Jonathan,

>It appears that the OS function needs to be updated to correctly report 
>Windows 10:

That already happened about 9 months ago. Xbase++ Build: 2.00.575, which 
was released on 02/24/2015, and all prior Xbase++ versions would report a 
Windows 10 machine as: Windows 8 06.02 Build 09200.

Starting with Xbase++ Build: 2.00.623, which was released on 08/17/2015, the 
same Windows 10 machine is reported as: Windows 10 10.00 Build 10586.

Updating to the latest official Xbase++ version, 2.00.685, released on 
04/28/2016, or any version after 2.00.575, should fix this issue for you.

The Windows 10 "Version 1511" (and "Version 1507") naming convention, which 
refers to the planned release dates of those official Windows 10 versions 
(July 2015 for the original "Threshold 1" release, and November 2015 for the 
"Threshold 2" update), is apparently not related to the OS version number. 

The latest/current release version/build of "Version 1511"/"Threshold 2" is 
(according to Wikipedia) 10.0.10586.318, and the latest preview (of the 
upcoming Windows 10 Anniversary Update "Redstone 1") is 10.0.14342.

I'm not able to test this right now, but it seems that the Xbase++ OS() 
function doesn't differentiate between the new sub-build numbers, like 
10586.0 through 10586.318, and won't report the (decimal) digits after the 
period in the build number. But I'm not sure if those digits are even of 
any significance to the average user.

Hope that helps.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC

Thanks Andreas,

I have been applying the upgrades to my development system but due to
some sloppy housekeeping on my part my Win 10 test machine was loading
old DLLs.

Cleaned up my act and all is good... Thanks... Jonathan

On Wed, 25 May 2016 17:56:14 -0400, Andreas Gehrs-Pahl wrote:

>Jonathan,
>
>>It appears that the OS function needs to be updated to correctly report 
>>Windows 10:
>
>That already happened about 9 months ago. Xbase++ Build: 2.00.575, which 
>was released on 02/24/2015, and all prior Xbase++ versions would report a 
>Windows 10 machine as: Windows 8 06.02 Build 09200.
>
>Starting with Xbase++ Build: 2.00.623, which was released on 08/17/2015, the 
>same Windows 10 machine is reported as: Windows 10 10.00 Build 10586.
>
>Updating to the latest official Xbase++ version, 2.00.685, released on 
>04/28/2016, or any version after 2.00.575, should fix this issue for you.
>
>The Windows 10 "Version 1511" (and "Version 1507") naming convention, which 
>refers to the planned release dates of those official Windows 10 versions 
>(July 2015 for the original "Threshold 1" release, and November 2015 for the 
>"Threshold 2" update), is apparently not related to the OS version number. 
>
>The latest/current release version/build of "Version 1511"/"Threshold 2" is 
>(according to Wikipedia) 10.0.10586.318, and the latest preview (of the 
>upcoming Windows 10 Anniversary Update "Redstone 1") is 10.0.14342.
>
>I'm not able to test this right now, but it seems that the Xbase++ OS() 
>function doesn't differentiate between the new sub-build numbers, like 
>10586.0 through 10586.318, and won't report the (decimal) digits after the 
>period in the build number. But I'm not sure if those digits are even of 
>any significance to the average user.
>
>Hope that helps.
>
>Andreas


Jonathan Leeming
jonathan.leeming@the-family-centre.com

Jimmy,

>interessing ... but what about old Apps ( not only Xbase++ ) ?
>MSDN say Windows 10 need Manifest with "supportedOS"

Of course, you don't need a manifest at all -- and many applications don't 
have one -- and you don't need the new <supportedOS> entry in your manifest 
file either.

>now try include OsVer.EXE ( v1.9.355) on Windows 10 and you will see 
>(green) it will tell you 10.0

But you are correct that adding a manifest with the "supportedOS" value for 
Windows 10 will tell the OS that your application was designed for (and 
tested on) Windows 10, and the OS will therefore return the correct OS 
version. But it will also treat your application as a Windows 10 app and 
will disable any compatibility options that would otherwise be enabled, 
which could have weird side-effects if your application depends on that 
older behavior.

Of course, if you use Xbase++ 2.00.623 or newer, you don't need a manifest 
with the new <supportedOS> XML element at all, and you will still get the 
correct Windows Version information from the Xbase++ OS() function -- minus 
the Revision part (the fourth set of digits in the version number, after the 
third period), which are always ignored by the Xbase++ OS() function.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[F]:   https://www.facebook.com/AbsoluteSoftwareLLC

Hi,
Function below works too in 1.9.355.
Carlos


FUNCTION WinVersion( nId )
   LOCAL cOSVers, cOSName
   DEFAULT nId TO 0
   cOSVers := ReadRegistry( "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows 
NT\CurrentVersion", "CurrentVersion" )
   cOSName := ReadRegistry( "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows 
NT\CurrentVersion", "ProductName" )
   IF nId == 1
      RETURN cOSName
   ELSEIF nId == 2
      RETURN cOSVers
   ENDIF
RETURN cOSName+" ("+cOSVers+")"


WinVersion() -> Windows 10 Pro (6.3)
WinVersion(1) -> Windows 10 Pro
WinVersion(2) -> 6.3



"Jonathan Leeming" escreveu na mensagem 
news:3hfbkbt029og4tdvr6j8ps70p59rf6im96@4ax.com...

Hi,

It appears that the OS function needs to be updated to correctly
report Windows 10:

OS(OS_FULLNAME)+" "+OS(OS_VERSION)

For Win 7 ver 6.1 build 7601 it correctly reports Windows 7 06.01.7601

For Win 8 ver 6.3 build 9600 it correctly reports Windows 8 06.03.9600

However...

For Win 10 ver 1511 build 10586 it reports Windows 8 06.02.9200

The above workstation Windows OS versions were obtained with
winver.exe but it also appears that MS has changed it's ver / build
format.

Regards... Jonathan


Jonathan Leeming
jonathan.leeming@the-family-centre.com