win32 exe compiled in Delphi11 does not run on W2000

[rudy999 2]

A 'legacy' environment - with 'old...' applications running on Windows Server 2000.

I have a support application running on the same server that was developed in earlier versions

of Delphi and lastly compiled in Delphi 10.4.2.

 

I recently compiled the same app in Delphi 11 - win32 and tried to run that app om W2000.

'not a valid win32 application'.

Just to test and verify that it is Delphi 11 and not the app---

I created a test VCL app with a FORM and no manifest or other 'newer' project options enabled

and tried to run that on w2000.  - same message.

(*Just Curious and want to learn*) - I know W2000 is no longer a valid o/s to work with (maybe now that win32 apps would not work on XP!).

QUESTION -

what internal new 'feature' in Delphi 11 causes the compilation to create a win32 app exe in the file that is not recognized now?

-the answer may be in a Delphi 11 release note ?

Thanks in advance

[Martin Sedgewick 30]

https://github.com/ideasawakened/DelphiKB/wiki/D28.ALEXANDRIA.11.0.0.0

This might help

• Can no longer build executables for Windows XP without customization:
  • Project Options->Building->Delphi Compiler->Linking->Set OS Version fields in PE Headers (and Set SubSystem Version fields in PE Headers" to 5.1 (it now defaults to 6.0)
  • If you use System.Threading, then need to change GetTickCount64 references to a new routine matching something like the code below and then use a modified system.thread.dcu in your projects (or update \lib\win32\debug and \lib\win32\release with new versions of System.Threading.dcu)
  • More info from Michal Mutl on Delphi PRAXIS forum message

function _GetTickCount64: UInt64;
begin
if TOSVersion.Major<6 then
  Result := TThread.GetTickCount
else
  Result := TThread.GetTickCount64;
end;

• XP Compatibility notes

  • As reported by Marco Cantu on Delphi PRAXIS, better HighDPI support was the reason for the PE header change. And the GetTickCount was un intentional.
  • Changing the PE format to target newer versions was a design decision. It's the same Visual Studio does. And it does make a difference in the results when invoking some HighDPI related Windows APIs. They fail to return the right value if the app is for XP, so if you change the PE setting (doable) you'll have some trouble on the latest systems. The introduction of an XP breaking issue with GetTickCount64 was not intentional and discussed. We don't test on XP by design, no one in the beta did, most likley. While we don't officially support XP, such a simple change is doable -- as long there is zero impact on newer systems and it costs a limited time. I doubt we'll release a patch for it, though...

[rudy999 2]

Martin

thank you for this information.

I had to set the PE Versions to 5.0 to get the O/S to recognize it, and now it runs.

regards and all the best!

[Martin Sedgewick 30]

Excellent, although Kudos should go to @Darian Miller for maintaining the resource.

[Darian Miller 361]

2 hours ago, Martin Sedgewick said:

Excellent, although Kudos should go to @Darian Miller for maintaining the resource.

 

Thanks.  I'm glad someone uses it besides me!   😃

 

And if anyone has other info to add to the page, just let me know.

[Nathan Wild 3]

Indeed..  I was delighted to find a post about this, but even with the PE version set to 5.0, I am still getting "Not a valid Win32 application" on Windows 2000.  Is there anything else that might cause this?

[Brian Evans 105]

6 hours ago, Nathan Wild said:

Indeed..  I was delighted to find a post about this, but even with the PE version set to 5.0, I am still getting "Not a valid Win32 application" on Windows 2000.  Is there anything else that might cause this?

No problems here on Windows 2000 Pro SP4 - a simple form with a close button compiled with Delphi 11.2 runs.

 

Make sure both Set OS Version fields in PE Header as <major>.<minor> and Set Subsystem Version fields in PE Header as <major>.<minor> are set to 5.0. Those are the only two changes I made from a default project for Windows 32-bit. 

 

[Lars Fosdal 1792]

Still running Windows 2000... I can't find the words...

[Uwe Raabe 2057]

My customer base has machines running even with Windows 95. It is quite common that such kind of machines are not able to get a new version anymore. 

[dummzeuch 1505]

1 hour ago, Lars Fosdal said:

Still running Windows 2000... I can't find the words...

There are computers running old versions of Windows (or in our case even DOS) that cannot be upgraded easily, usually because of some special hardware requirements. As long as these commuters are not connected to the network, there is no problem with running old OSes.

 

We still run 2 computers with Windows XP and 3 with DOS. The former will hopefully be replaced with Windows 10 this year, but the DOS machines will probably stay for some more years. At least one is required for the maintenance of some specialized equipment that is actually used with other computers that run Windows 10. Oddly enough, you can still buy hardware that is DOS compatible, but the supply for Windows XP compatible hardware is drying up.

Edited January 7, 2023 by dummzeuch

[Lars Fosdal 1792]

Industrial machines that are not connected to a LAN - ok.
IMO, any machine that is on a network - even if it can't reach the internet by itself - needs to be continously updated/patched, and replaced before EOL.

It is like insurance. Money that feels like a waste until something bad happens.

[Uwe Raabe 2057]

29 minutes ago, Lars Fosdal said:

needs to be continously updated/patched, and replaced before EOL.

Seems like the machine manufacture prefer the replace option. Sometimes they provide a replacement of the controller hardware, but often that turns out incompatible to the machine equipment.

 

I would love that to be different, as it would allow me to sell updates to newer versions of my software developed with more recent Delphi versions.