Windows versions supported by older Delphis

[Peter J 1]

I'm trying to find out which are the oldest versions of Windows that different versions of Delphi could target, going back to Delphi 2009.

 

Embarcadero have documented as far back as Delphi XE4, which required Windows XP SP2 (32-bit only) or Windows Server 2008 as a minimum. Googling hasn't turned up any more info, so far.

 

So can anyone help with Delphi 2009 through to XE3 please? I'm particularly interested in XE, because I still use it for some jobs.

 

EDIT: For clarity, I'm interested in the minimum versions of Windows that programs compiled by the various versions of Delphi will run on, not the Windows version that the IDE will run on.

 

Thx

Edited October 2 by Peter J

[rvk 33]

1 hour ago, Peter J said:

I'm particularly interested in XE, because I still use it for some jobs.

XE3 was the first to support Windows 8. Delphi 2009 was the first to support Windows 7.

see https://nl.wikipedia.org/wiki/Delphi_(software) So finding the highest versions supported is not difficult.

 

But are you more interested in the lowest version?

For Windows XP it was always advised to upgrade to at least SP2 from very early on.

Do you still have machines with SP1 or even without SP ??

From an old Delphi XE PDF (at the bottom): http://www.embarcadero.com.pl/produkty/starter-tools/xe/delphi-data-sheet.pdf

Quote

Supported Operating Systems

• Microsoft® Windows® 7 (32-bit and 64-bit)

• Microsoft Windows Vista SP2 (32-bit and 64-bit, requires administrator rights)

• Microsoft Windows XP Home or Professional (32-bit and 64-bit, SP2 or SP3)

• Microsoft Windows Server 2003 (SP1) or 2008 (32-bit and 64-bit)

 

Edited October 2 by rvk

[Anders Melander 1782]

1 hour ago, Peter J said:

I'm trying to find out which are the oldest versions of Windows that different versions of Delphi could target, going back to Delphi 2009.

You seem to be confusing "target" and "run on".

In theory, all 32-bit compilers can target any 32-bit version of Windows and all 64-bit compilers can target any 64-bit version of Windows.

 

1 hour ago, Peter J said:

Embarcadero have documented as far back as Delphi XE4, which required Windows XP SP2 (32-bit only) or Windows Server 2008 as a minimum.

That page just document the IDE requirements and it doesn't really reflect the reality; Before I upgraded to Windows 10 I had been running Delphi 10, 11 and 12 on Windows 7 with no issues. The installer complains but it ran just fine.

[Peter J 1]

1 minute ago, rvk said:

But are you more interested in the lowest version?

For Windows XP it was always advised to upgrade to at least SP2 from very early on.

Do you still have machines with SP1 or even without SP ??



Thank you very much - that's exactly what I needed.

I'll take note of the SP2 requirement and make it a minimum.

No, I don't have machines with XP at all these days. 

 

Yes, interested in the lowest version. I do like to make my open source apps work on as many version of Windows as possible, even though I only use Win 11 myself.

 

The reason for asking is that I've got some old library code that works around APIs missing from older Windows versions, or falls back to older APIs where necessary. This stuff was originally written to be compiled on Delphi 4 (I think) and ran on Win9x and WinNT. I want to update it to be able to be compiled with Delphi 12 back to XE, and possibly 2009 as the oldest Unicode Delphi. There's no point in keeping the API code that only exists on Windows versions that XE compiled apps won't run on!

 

My interest in getting info back to Delphi 2009 is because I still have a license for it & I have a soft spot for older Delphis. I still use XE a lot, and still used Delphi 7 until a couple of years ago!

 

[Peter J 1]

2 minutes ago, Anders Melander said:

You seem to be confusing "target" and "run on".

In theory, all 32-bit compilers can target any 32-bit version of Windows and all 64-bit compilers can target any 64-bit version of Windows.

 

That page just document the IDE requirements and it doesn't really reflect the reality; Before I upgraded to Windows 10 I had been running Delphi 10, 11 and 12 on Windows 7 with no issues. The installer complains but it ran just fine.

Thank you.

 

Target vs run on - to clarify, I mean the OS that the compiled application will run on.

 

I was thinking that the page was talking about minimum Windows version for the generated applications, not the OS required for the IDE. I've been assuming it was related to the Windows API calls that the VCL etc depended upon.

[Rollo62 536]

Maybe these lists are intersting too, although not 1:1 what you're asking for:
https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List

https://en.wikipedia.org/wiki/History_of_Delphi_(software)

Edited October 2 by Rollo62

[Peter J 1]

5 minutes ago, Rollo62 said:

Maybe these lists are intersting too, although not 1:1 what you're asking for:
https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List

https://en.wikipedia.org/wiki/History_of_Delphi_(software)

Thanks. I've seen the latter but the github repo is new to me - I've starred it.

 

Not 1:1 as you say, BUT, very helpful for updating a web page where I try to maintain a list of Delphi features and the versions of Delphi where they were introduced. 

[Anders Melander 1782]

16 minutes ago, Peter J said:

I was thinking that the page was talking about minimum Windows version for the generated applications, not the OS required for the IDE. I've been assuming it was related to the Windows API calls that the VCL etc depended upon.

The required Windows version really depends on the the VCL features you use. If you're using something that is only available in Windows 10 then naturally your application will use Windows 10 specific APIs. Otherwise it will not.

 

 

[Lajos Juhász 293]

Also third party components could in theory use some API not only VCL.

[Angus Robertson 574]

Suggesting you support an OS you don't at least test once is not a good idea. 

 

I have a Windows 7 VM that has Delphi 6 to XE installed, and I build and run stuff with a few of those compilers occasionally, so I know it still works. Trying to support anything older is dangerous.  That VM still gets some Windows security updates, so has minimal support from Microsoft.  

 

One common API to avoid for Windows 7 is GetTickCount64 which was added with Vista and Windows 2008, don't think Delphi uses it internally.

 

Angus

 

[Anders Melander 1782]

29 minutes ago, Angus Robertson said:

One common API to avoid for Windows 7 is GetTickCount64 which was added with Vista and Windows 2008, don't think Delphi uses it internally.

It does but the Win32 API is declared delay-load and the RTL resolves it dynamically with fallback to GetTickCount if it isn't available.

I also believe Indy uses it but with a similar dynamic fallback.

 

Winapi.Windows.pas

function GetTickCount64; external kernel32 name 'GetTickCount64' delayed; // 6.0

System.Classes.pas

function InitGetTickCount64: UInt64; stdcall;
begin
  if TOSVersion.Major >=  6 then
  begin
    var kernelLib: THandle := LoadLibrary(kernel32);
    GetTickCount64Func := GetProcAddress(kernelLib, 'GetTickCount64');
    FreeLibrary(kernelLib);
  end
  else
    GetTickCount64Func := @Winapi.Windows.GetTickCount;
  Result := GetTickCount64Func;
end;

 

[Kas Ob. 121]

I opened a thread about GetTickCount, that safely replace this GetTickCount64, but will wait until confirmation of success result as explained there, before suggesting to replace any short coming of GetTickCount64 this with that direct (emulated) version.

 

 

[Angus Robertson 574]

ICS has a unit that emulates GetTickCount64 using QueryPerformanceCounter on older OSs, meaning it does not wrap at 49 days as using GetTickCount instead would. 

 

QueryPerformanceCounter is also more accurate than ticks if you are timing milliseconds.

 

But 49 days running is rare nowadays, even for servers which Microsoft will forcibly reboot to load Windows Updates unless you take severe measures to stop it.  

 

Angus

 

[Kas Ob. 121]

7 minutes ago, Angus Robertson said:

QueryPerformanceCounter is also more accurate than ticks if you are timing milliseconds.

Well, not exactly, QueryPerformanceCounter does have higher resolution but with lower accuracy, it is tied to the CPU cycles, at that low level, yes it has very high resolution, but when the CPU throttle or switch power profile it will start to return far from accurate result, also will be far from accurate in hibernate, GetTickCount on other hand depends or gets its clock timing using BIOS clock interrupt which in turn gets its time from the MotherBoard chipset, this one doesn't suffer from power profile effect, these chipset runs at constant frequency and they are very accurate but with lower precision than the CPU, due to their difference in base frequencies (CPU and motherboard chipset).

[Angus Robertson 574]

OK, QueryPerformanceCounter 'was' more accurate in the days before CPU speed could be changed dynamically <g>  And might still be over a few seconds timing an algorithm.  And Ticks are probably more accurate than 20 years ago with faster motherboards. 

 

Angus

 

 

 

[Anders Melander 1782]

Good thing we can invent new problems when we run out of actual ones to solve.