How to detect Windows 11 using Delphi 10.3.3 - delphi

I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)

As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.

Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer

Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.

The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?

Related

Create Windows 95, 98, 2000, XP NT, 7, 10

I come across the following link - https://github.com/felixrieseberg/windows95
Running windows 95 as Electron APP
Is it possible to create any existing application as portable or cross-platform using electron like above?
Can we use Windows 7 or 10 like above without Oracle Virtual Box or VM in an existing Windows 8 machine ?
Need more details on how it is possible to bring an application via electron
Thanks.
If I'm hearing you right, you're wondering if you can put a whole OS into a JS VM running in Electron - and then run your app on top of that.
Please don't do that. Electron is a fantastic cross-platform solution, but my project windows95 was mostly an educational experiment showcasing how powerful modern JavaScript and Electron can be.
This project uses another project called v86, which is capable of virtualising a x86 platform and display its output on a HTML element. Electron is browser-based so that is why this works.
But there are some limitations: It virtualises the x86 platform, which is pretty old by now, and when you have a look at the specification, it says it is at a Pentium-1 state. The demo links on the project's GitHub ReadMe also do not contain any "modern" OS because v86 does not support SSE(2). And since Microsoft requires its users to have a SSE2-compatible CPU* it is not possible to run anything like Windows 7 or newer (Linux may work, anyway).
OSses which support this kind of (deprecated) hardware, may work. As you can see from the "Compatibility" section of the project's ReadMe, some Linux versions and Windows XP "work" but older software, like OS/2, and even newer stuff, like Android, don't (really). So you can't say that everything will work as expected because the execution environment is really limited.
Now to answer your first point, no, I don't think that you can wrap every existing app into an Electron application and run it on new hardware. It may work with old software (which do not require SSE, if you use v86, and that would require a lot of hackery on the v86 side because it is designed to run OSses), but don't quote me on that.
* The section in question reads (at the time of writing) like this:
A Stop error occurs on computers that don't support Streaming Single Instructions Multiple Data (SIMD) Extensions 2 (SSE2).
Upgrade your machines with a processor that supports SSE2 or virtualize those machines.
(emphasis mine, source: https://support.microsoft.com/en-us/help/4088875/windows-7-update-kb4088875)

Add DirectX-9 to inno-setup installer

I have an old software that uses DirectX 9. It's quite obsolete but there are still people using it.
Win10 does not come with DX9 preinstalled and I want to add it to my installer. So far I see that there's a large (100mb) DX package from Microsoft that contains all the versions and builds of DX9 and 10. (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en)
Among the many version, I see, for example, "Jun2010_d3dx9_43_x86.cab" that contains the .dll, .cat and .inf. I'd say that this is sufficient for what I need so I'd add this to my program's installer (inno-setup).
I am a bit outdated on DX and DLLs knowledge. Can someone give some pointers on how to proceed and if it's right installing only one of that dll?
Thanks!
DirectX 9.0c does in fact come with Windows 10. Starting with Windows XP Service Pack 2, the "DirectX End-user Runtime" never installs DirectX on any version of Windows. The only way to update "DirectX" is to install a Service Pack, a Windows Update, or move to a new version of Windows.
See Not So Direct Setup for the full story here.
Your old application, however, likely does rely on some optional side-by-side components like D3DX9, D3DX10, D3DX11, XAudio2_7, XInput1_3, D3DCompile #43, Managed DirectX 1.1, or other thing that is only deployed by the legacy DirectX End-User Runtime. In that case, you should download the latest DXSETUP package (the April 2011 refresh of the end-of-life DirectX SDK June 2010 release on MSDN).
You can then configure a minimal package that will deploy just the DLLs you actually use. For example, if you used the D3DX9 June 2010 DirectX SDK for a 32-bit application, but that's all you needed, you can get away with an install package of just:
dxsetup.exe
dsetup32.dll
dsetup.dll
dxupdate.cab
Jun2010_d3dx9_43_x86.cab
Of course, if your application is old enough to be using a previous version of D3DX9, then you need to figure that out and use the right .cab.
See Where is the DirectX SDK? as well.

Was compatibility for NDIS 5.x drivers removed in Windows 10?

I have an NDIS 5.x Passthru driver that was adapted from this sample. Obviously NDIS 6 has been available for quite some time, rendering 5.x obsolete, but backward compatibility has allowed the driver to continue to run in up to and including Windows 8.1 so the code has not been updated.
Now the same driver does not function on Windows 10. (Edited to add: The driver loads, but "netcfg /b" shows that it did not bind to any adapters.) The sys file is the same, installed the same way and with the same signature that works in Win8.1. I can't find any official source that NDIS 5.x compatibility has been removed from Windows 10, but I do find several people with the same problem who are speculating that is the case.
Do we know officially if NDIS 5.x compatibility been removed from Windows 10, and/or is there some kind of compatibility mode that can be activated to allow me to keep using my existing driver until I come up with Plan B?
No, NDIS backward compatibility was not removed in Windows 10. A new network class Installer called NetSetup was added with a shim for the old NetCfg calls. Apparently, there's a bug in the shim that causes drivers like mine to install but not bind to any adapters. They're assigning someone to work on it, and I will update this answer when there's a resolution.
Edited to add: Microsoft has decided not to resolve this issue because few are affected by it.

Performance Object cannot be seen in Windows 7

I wish to register some of status of my application as a performance object, so that I can monitor its performance by utilising the Windows Performance Monitor.
But I had a problem with Windows 7: the performance object cannot be seen in the list of Performance Monitor, even if my application is running.
My code is exactly the same as the Delphi project in this tutorial:
http://www.wehlou.com/Code/perfmon/index.htm
However, the solution provided in this tutorial doesn't work in Windows 7 either.
Such solution works fine in Windows XP and 2003.
I don't know if there are some changes in Windows 7 which makes my performance object missing.
Please help. Thanks a heap in advance.
Is your Windows 7 computer a 64-bits machine? You may have to provide both a 32 and 64 bits version:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371636(v=vs.85).aspx
The short answer:
Yes you can fix manually the 2 object performance counters (DeltaCount & RawCount) issue under Windows 7 x32. The 2 files generated by PerfMonClient.exe are usable (namely symfile.h and symfile.ini).
Nota: Refer to MSDN for the usage of lodctr.exe.
Prior to that an entry to the registry as follows should created:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PerfMonClient\Performance]
"Open"="PerfData_Open"
"Close"="PerfData_Close"
"Collect"="PerfData_Collect"
"Library"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,50,\
00,65,00,72,00,66,00,4d,00,6f,00,6e,00,44,00,4c,00,4c,00,2e,00,64,00,6c,00,\
6c,00,00,00
Nota: Library point to %SystemRoot%\System32\PerfMonDLL.dll (location of the performance DLL).
Any attempt to install and/or uninstall them using PerfMonClient.exe App doesn't work even under Windows XP. Forget about that.
Look an feel:
Listing
symfile.h:
#define OBJECT_1 0
#define DEVICE_COUNTER_1 2
#define DEVICE_COUNTER_2 4
symfile.ini:
[info]
drivername=PerfMonClient
symbolfile=symfile.h
[languages]
009=English
[text]
OBJECT_1_009_NAME=PerfMonTest Performance Counters
OBJECT_1_009_HELP=A demo application for your unbridled pleasure
DEVICE_COUNTER_1_009_NAME=RawCount
DEVICE_COUNTER_1_009_HELP=A count of something that goes up and down
DEVICE_COUNTER_2_009_NAME=DeltaCount
DEVICE_COUNTER_2_009_HELP=Something going up all the time, Windows shows difference per time unit

What hardware/software is necessary to develop Mac or iOS apps in Delphi XE2?

Obviously, one needs a PC with a copy of Delphi XE2. But, do you need a Mac or iPad? Mac OSX running in a virtual machine? ... Can you create and compile the application entirely on a PC?
You require a Windows PC (32 or 64 bit, running Vista or 7 - though XP has limited support) to use Delphi XE2's IDE and compiler. These simply will not work on any other platform, so you can only develop on a Windows PC!
With only a Windows 32 (or 64) bit PC, you can build Win32, Win64 and OSX applications.
To test/run 64bit Windows applications you require a 64bit system with a 64bit edition of Windows installed.
To test/run OSX Applications, a Mac system running 10.6 (Snow Leopard) or 10.7 (Lion) is required. A "Hackintosh" or VM running MacOSX will not work (and is a violation of Apple's EULA)!
To produce iOS Applications, you require the same criteria as stated above for testing OSX applications, with the additional requirement of installing the FireMonkey iOS package (containing the FreePascal compiler and FireMonkey libraries), XCode, and the iOS emulator.
The iOS Emulator will run Delphi-made iOS applications, though of course testing on the physical device is often considered better.
You can create and compile the entiry application on a PC.
You need OS X version 10.6 or 10.7 to test it on a MAC: Prerequisites
Watch Andreano Lanusse video
Found with Google: Mac in a VM
a bit late, but the question still stands (me at least, I'm researching the subject)
regarding the virtualization part of the mac, which is dismissed by everybody above, and how that is not possible to be used instead of a physical mac (same for the open-gl FM related comment above), I'd quote XE5 official documentation:
"All FireMonkey applications require a graphics processing unit (GPU) on both the target platform and the development system. The GPU can be accessible either directly or through virtualization" (http://docwiki.embarcadero.com/RADStudio/XE5/en/FireMonkey_Platform_Prerequisites)
Take note that this is not XE5 requirement, it will work as well with XE2, because having the GPU accessible to the VM basically means giving the VM direct control to it (in case of vmware, through passthrough aka VMDirectPath I/O, although in this aprticular case there are limitations). XEN, on the other hand, it said to do very nicely with GPU passthrough.
I've been using this method for a lot of other, non delphi-iOS related, activities that also require access to a physical GPU, and they all work just nice (the "how nice" depends on the chosen hardware so care must be taken there, of course).
so the short answers are: no, yes, yes.
as others said, it is advisable to test your applications on the actual target systems, so at one point you may want to consider purchasing some 2nd hand device for the job.

Resources