How To Get The OS Version. 2

[Glenn9999]

I posted a FAQ (faq102-7848). While odd, the introductory text will explain why I'm doing this.

Please let me know if you run into any problems.

 

[whosrdaddy]

Nice work.
Can you expand it so that it returns a full version string, like the old FAQ did?

/Daddy

-----------------------------------------------------
Helping people is my job...

 

[Glenn9999]

The new functions they point you to are existence tests more than version returning functions, so you'd have to call them with every number possible until it starts failing in order to return a version number from them. Of course, then piecing a full version string from there shouldn't be a problem.

The "problem" I think that's coming from this is that Microsoft has designed to make versioning irrelevant in their OSes. At least from an API standpoint. The major thing that seems to indicate version is the application compatibility manifest (as noted, GetVersionEx will return the correct answer if 8.1 compatibility is indicated there).

I can't say I know all the ins and outs of this, but I'm thinking of playing around. Maybe try GetVersionEx with an app manifest indicating only vista support and see if it returns 6.0 or not. Maybe try the same with these applications. I'm thinking perhaps with the concern of compatibility, the application is the one that determines version more than the OS. Which means the app compatibility manifest is a requirement.

Right now, the only thing I'm completely sure of in discovering this is that it'll be an issue. What it means exactly and how to address it is something I've yet to figure out.


(FWIW, I can add some stuff about the application compatibility manifest to that FAQ if necessary.)

 

[Glenn9999]

FWIW, here's output from a quick test I did calling IsWindowsVersionOrGreater. My idea seems good if you want to pull a version number out of these functions. Like I said though, GetVersionEx might be fine in terms of what the application manifest indicates as compatibility.

Windows Version: 4.0 SP 0 OK
Windows Version: 4.0 SP 1 OK
Windows Version: 4.0 SP 2 OK
Windows Version: 4.0 SP 3 OK
...
Windows Version: 6.0 SP 0 OK
Windows Version: 6.0 SP 1 OK
Windows Version: 6.0 SP 2 OK
Windows Version: 6.0 SP 3 OK
Windows Version: 6.1 SP 0 OK
Windows Version: 6.1 SP 1 OK
Windows Version: 6.1 SP 2 OK
Windows Version: 6.1 SP 3 OK
Windows Version: 6.2 SP 0 OK
Windows Version: 6.2 SP 1 OK
Windows Version: 6.2 SP 2 OK
Windows Version: 6.2 SP 3 OK
Windows Version: 6.3 SP 0 OK
Windows Version: 6.3 SP 1 OK
Windows Version: 6.3 SP 2 OK
Windows Version: 6.3 SP 3 OK
Windows Version: 7.0 SP 0 not OK
...
Windows Version: 10.3 SP 3 not OK

 

[Beunders]

Hi,
I tried your code with the "GreaterThen.." functions, but unfortunately they fail when tested on a Windows 10 machine.
Looking at your code it looks like you assume a Major Version number of 10 for Windows 10, but we all know that this scheme was thrown overboard after Windows 8 by MS.
So everything later than Windows 8 will return the Windows 8 version.
Did you check this?
Thanks,
Joop

 

[Glenn9999]

Looking at your code it looks like you assume a Major Version number of 10 for Windows 10, but we all know that this scheme was thrown overboard after Windows 8 by MS.

The constant was specified in the header API when I converted it. It may be very likely that an application compatibility manifest is required now. As I wrote above:

The "problem" I think that's coming from this is that Microsoft has designed to make versioning irrelevant in their OSes. At least from an API standpoint. The major thing that seems to indicate version is the application compatibility manifest (as noted, GetVersionEx will return the correct answer if 8.1 compatibility is indicated there).
...
(FWIW, I can add some stuff about the application compatibility manifest to that FAQ if necessary.)

If you would like, I could go ahead and add that to the FAQ?

 

[Beunders]

Think that's a good idea. Pls also include a section on how to add the manifest to a Delphi program.
I found also another source (sip attached), but it does not compile properly, but I do see differences in OS type when I made it ready for compilation.
I am not a low-level programmer, so maybe it can help you to solve things without using this stupid manifest requirement from MS.
Thanks

 

[Glenn9999]

The stuff in the file you included basically does the same stuff we've been talking about and using over the years. One is another person's translation of versionhelpers.h, which is what the FAQ I posted is, basically. The other one is an attempt to translate the output of GetVersionEx to something akin to the OS branding.

Neither will help anything at all, since Microsoft has left the "versioning" to the application at hand. More or less that means the programmer decides the "version" of the program through the "stupid manifest requirement from MS". It probably was preferable anyway, because the programmer can dictate what OS the program *should* run on through his own testing and then Microsoft can apply appropriate settings to the program on the fly when it's run.

I'll post how to do an application compatibility manifest into the FAQ. More or less, it'll catch one or two other issues as well (namely UAC considerations), but it'll be good to do all of it. I'm sure the sparking new Delphis have been redone to present these options to the programmer, but what I'll post will be good for most all Delphis. I use it under Delphi 3, myself.

 

[Beunders]

Good idea, but pls check also the code I send you. I know most of it is identical (more or less) to what you did, nut the main unit (which does not compile) does other things as well. The compiler stops at "TOSVersionInfoEx" as undeclared identifier. When you leave out the "Ex" is does compile and then the "FOStype" changes between OS'es, but not exactly according to the enumeration given. XP returns correct, nut W7 and W10 are incorrect.
I am still using Delphi 7. Tried all the other ones up to XE5 but find D7 still by far the best and most stable.
Cheers,
Joop

 

[Glenn9999]

FAQ Edited: faq102-7848

Note I have renamed it to be consistent with adding the Application Manifest information.

 

[Glenn9999]

Good idea, but pls check also the code I send you. I know most of it is identical (more or less) to what you did, nut the main unit (which does not compile) does other things as well.

Evidently what the code you linked to is doing is calling GetVersionEx with the extended parms (OSVERSIONINFOEX) as opposed to the standard ones (OSVERSIONINFO). Interestingly enough, the call with the extended info returns 6.3, but as Microsoft has stated, it is best to use the manifest if you're interested in more full compatibility. If the non-extended call fails, I'm sure the extended one will fail soon enough.

To correct the source file you have (developed in Free Pascal I believe) so it'll compile, add to winosversion.pas:

function GetVersionEx(var lpVersionInformation: TOSVersionInfoA): BOOL;
         stdcall; external kernel32 name 'GetVersionExA'; overload;
function GetVersionEx(var lpVersionInformation: TOSVersionInfoExA): BOOL;
         stdcall; external kernel32 name 'GetVersionExA'; overload;

function GetVersionExA(var lpVersionInformation: TOSVersionInfoA): BOOL;
         stdcall; external kernel32 name 'GetVersionExA'; overload;
function GetVersionExA(var lpVersionInformation: TOSVersionInfoExA): BOOL;
         stdcall; external kernel32 name 'GetVersionExA'; overload;

function GetVersionExW(var lpVersionInformation: TOSVersionInfoW): BOOL;
         stdcall; external kernel32 name 'GetVersionExW'; overload;
function GetVersionExW(var lpVersionInformation: TOSVersionInfoExW): BOOL;
         stdcall; external kernel32 name 'GetVersionExW'; overload;

Since Delphi is strongly typed, the extended and original calls within your WINDOWS.PAS will not co-exist without the overload directive.

 

[Beunders]

The "TOSVERSIONINFOEX" definition cannot be found by the compiler.
When I add the definition from your link then "FExtendedInfo := GetVersionEx(LOSVE);" crashes because "LOSVE" does not have the right format....

 

[Glenn9999]

I forgot an edit:

type
  TOSVersionInfoEx = TOSVersionInfoExA;

Put that above what I wrote before. It compiles here.

 

[Beunders]

Compiles OK now, but Win10 still returns Win8.0 (6.2) here...???

 

[Glenn9999]

Compiles OK now, but Win10 still returns Win8.0 (6.2) here...???

Evidently the manifest is a requirement now. Add that to your project and see what happens.

 

[Beunders]

I added the manifest according to your instructions and now it works.
I modified my own check procedures to accommodate Win81 and Win10 and now it works fine.
I attached a zip with a demo program including all sources.
Due to this "automatic" adjusting of MS, my GUI looks quite different on Windows 10 compared to Win7 and WinXP.
Something I really and absolutely dislike. I like to be in control when it comes to GUI layout and MS should keep their hands off.
Thanks for your help and advise.
Cheers,
Joop

 

[Glenn9999]

Due to this "automatic" adjusting of MS, my GUI looks quite different on Windows 10 compared to Win7 and WinXP.
Something I really and absolutely dislike. I like to be in control when it comes to GUI layout and MS should keep their hands off.

They never did keep it consistent between versions (or now themes as the user changes them). Always different fonts and sizes and the like that would change things up. FWIW, you can disable the theming behavior via code within your application (I have that here), or delete that section in the manifest when you use it. Though the end user will likely find it strange that your program doesn't obey the theme scheme and will find it "odd" or "old".