gurusgreat

Does anyone know if TOSVersion.Name still works on Windows 10?

I have a vcl application that has a form show event that gets the operating system details and displays them in a TMemo box using TOSVersion record from SysUtils.

The code executes without any issues on XP (Yes we're still using it (hangs head in shame)), Vista, Windows 7, Windows 8.1, Desktop PC's, laptops and Surface Pro's but not when installed on Windows 10.

When I debug using paserver, TOSVersion.Name comes back as := 'Windows 8'.Am I doing something wrong or am I expecting too much for TOSVersion to detect Windows 10? No exception is being triggered. Of the 2 x Windows 10 machines I have access to, one migration path was from Windows 8.1, the other one however was from Windows 7.

Many Thanks

2 Answers

Two things stop your code from returning the correct version:

1. The XE8 RTL that you use predates Windows 10 and so has no knowledge of Windows 10.
2. Your executable does not manifest itself as supporting Windows 10, and so GetVersionEx, which TOSVersion relies upon, will lie about the version.

It so happens that XE8 update 1, I believe, changes the version detection to use NetWkstaGetInfo which is not subject to this version lie. Although the call to NetWkstaGetInfo does leak memory, but that's probably not important since it is only called once.

Some links relating to this subject:

• And many many more..

If you absolutely must report the version to the user, then you have a variety of options:

• Add the supportedOS option to your manifest and include the GUID for Windows 10. That stops GetVersionEx from lying. Then use a modified version of TOSVersion, or some other means, to obtain the version.
• Use a WMI query.
• Call NetServerGetInfo.
• Call NetWkstaGetInfo.
• Call RtlGetVersion.

More details in this question: How to detect true Windows version? Although note that the accepted answer there is out-of-date.

As an example of the WMI approach, you could use this code:

Have you tried using a custom manifest ?

I use XE8 and have no issues with TOSVersion recognizing Windows 10 when using a manifest file that targets Windows 8.1 and Windows 10.

My custom manifest is made to make my application 'Windows 10' aware.

It is the following : Railway dlw varanasi exam date.

I got that from this link : https://msdn.microsoft.com/fr-fr/library/windows/desktop/dn481241(v=vs.85).aspx

And TOSVersion.Tostring on a Windows 10 1607 displays :

Not the answer you're looking for? Browse other questions tagged delphioperating-systemwindows-10delphi-xe8 or ask your own question.

Can anyone help me detect which version of Windows the user may be using?

I have seen some examples to do this, but they are not updated for Vista/7 Operating Systems.

Additionally it would be useful to detect if the OS is running on x32 or x64 architecture.

Thanks in advance.

4 Answers

On XE2 a new class was introduced to deal with this: TOSVersion.

• Read TOSVersion.Architecture to check for 32 or 64 bit OS.
• Read TOSVersion.Platform to check for Windows or Mac.
• Read TOSVersion.Major and TOSVersion.Minor for version numbers.
• Read TOSVersion.Name to obtain the basic product name, e.g. Windows 7.
• Read TOSVersion.ToString to obtain the full product name with version, e.g. Windows 7 Service Pack 1 (Version 6.1, Build 7601, 64-bit Edition).

For older versions of Delphi I recommend the following:

In order to check for 2000, XP, Vista, 7 I suggest you read Win32MajorVersion and Win32MinorVersion.

• major.minor = 5.0 => Windows 2000
• major.minor = 5.1 => Windows XP
• major.minor = 5.2 => Windows 2003 server or XP64
• major.minor = 6.0 => Windows Vista/2008 server
• major.minor = 6.1 => Windows 7/2008 server R2

The same information is available on MSDN, but the above came from my head!

If you are wanting very detailed product information then that takes a bit more work. Warren's answer gives one good route to obtaining that information. If you are wanting to test capability then version numbers are fine.

Use CheckWin32Version to check if the prevailing OS exceeds a certain version level. Although you should check that the function works correctly in your Delphi since the implementation of that function in Delphi 6 and earlier was incorrect.

To find out what the native OS architecture is (32 or 64 bit), use the GetNativeSystemInfo function. This function is not available on older operating systems so you should load it explicitly with GetProcAddress. Test for wProcessorArchitecture=PROCESSOR_ARCHITECTURE_AMD64 to check for 64 bit OS.

The JEDI JCL already does this, even on versions older than XE2. See David's answer for the built-in solution in XE2 and later.

Using the Jedi JCL, you can add unit JclSysInfo, and call function GetWindowsVersion. It returns an enumerated type TWindowsVersion.

Currently JCL contains all shipped windows versions, and gets changed each time Microsoft ships a new version of Windows in a box:

If you want to know if you're running 64-bit windows 7 instead of 32-bit, then call JclSysInfo.IsWindows64.

Note that JCL allso handles Editions, like Pro, Ultimate, etc. For that call GetWindowsEdition, and it returns one of these:

• Then, High-level commands are used in this software for completing the needs of the students. • Its main important feature is that it provides us the manual references inputs for the benefits of the user. Endnote free download with crack. • Very famous and demandable software for the professionals for meeting their needs and requirements. • This is very useful and helpful for both Mac and also with the computer system for doing their important tasks.

For historical interest, you can check the NT-level edition too with the NtProductType function, it returns:

Note that 'N editions' are detected above. That's an EU (Europe) version of Windows, created due to EU anti-trust regulations. That's a pretty fine gradation of detection inside the JCL.

Here's a sample function that will help you detect Vista, and do something special when on Vista.

Note that if you want to do 'greater than' checking, then you should just use other techniques. Also note that version checking can often be a source of future breakage. I have usually chosen to warn users and continue, so that my binary code doesn't become the actual source of breakage in the future.

Recently I tried to install an app, and the installer checked my drive free space, and would not install, because I had more than 2 gigabytes of free space. The 32 bit integer signed value in the installer became negative, breaking the installer. I had to install it into a VM to get it to work. Adding 'smart code' often makes your app 'stupider'. Be wary.

Incidentally, I found that from the command line, you can run WMIC.exe, and type path Win32_OperatingSystem (The 'Select * from Win32_OperatingSystem' didn't work for me). In future perhaps JCL could be extended to use the WMI information.

The unit (GetWinVersionInfo) shown here detects up to Vista. I can't imagine updating it for Windows 7 would be that difficult. I don't think it tells you x86.x64 though.

On delphidabbler.com there is a complete article about getting operating system version including 64 bits versions.The article hasn't been updated to include Vista/7 though. But the same functions might still work.