4 ms·

>> I would be surprised if Delphi 5 ran without a hitch on Windows 10/11 I'd be surprised if it didn't. Not Delphi, but I've been helping a client update their

>> I would be surprised if Delphi 5 ran without a hitch on Windows 10/11 I'd be surprised if it didn't. Not Delphi, but I've been helping a client update their Windows program, from a compiler which shipped in 1998. Their program, with that compiler, runs just fine on Windows 11. The backward compatibility of the Win32 API is such that I regularly use programs last compiled 20 years or more ago.

magicalhippo 2y ago
Microsoft sure has done a great job, but I have experienced some issues around Program Files and registry virtualization, along with UAC. I suppose if you run it as admin and/or install it outside Program Files it'll make it a lot less troublesome. So, not unexpected, but I'd still be mildly surprised.
- chungy 2y ago
  > some issues around Program Files and registry virtualization, along with UAC. Now that's rattling a thing in my brain. I recall disabling UAC was one of the more consistent ways to get Delphi 6 to even run on Windows 7, and even then it wasn't a guarantee. Yeah, I had the displeasure around 2009-2011 of trying to get an old IDE version running on then-current versions of Windows, with multiple Vista and 7 computers in the office. It ran fine on Windows XP, but newer OSes were not so lucky. Perhaps the solution was to purchase a newer Delphi, but that avenue wasn't sought after.
- tracker1 2y ago
  Yeah... I saw a lot of poorly written apps using localized data in the application's directory, when they started locking down Program Files, all kind of bugs started to pop up. I don't blame MS much, they had some compatibility shims in place, but it was still troublesome. Mostly blame the early app devs for not understanding separation of the application/libraries and the data the app uses/manipulates.
jchw 2y ago
It's more hit or miss than you might think. If you're just using mostly basic parts of the Win32 API then it is basically about as solid as any backwards compatibility ever has been. The fall off occurs as you veer off into deeper holes: - Multimedia software and games tend to hit on areas of Windows where compatibility is far from perfect. - Even 32-bit software would sometimes have random Win16 binaries, and those are not emulated; I don't blame Microsoft or anything, but they could support it if they wanted to. (Understandably, they do not.) - Software that uses truly obsolete Windows components may no longer work. AFAIK .NET Framework 1.1 hasn't been supported since Windows 8. Old ActiveX and COM components can also be a problem. This has led to some situations where you might actually have better luck running the old software under Wine and Linux than modern Windows, especially for some older games. It's not that Microsoft didn't do immense amounts of work here, but in practice there are some holes I've run into.
- magicalhippo 2y ago
  > Even 32-bit software would sometimes have random Win16 binaries InstallShield being a common one in that regard. So common that 64-bit Windows, which doesn't support 16-bit binaries, contains code to handle specifically[1] InstallShield and Acme 16-bit binaries[2]. [1]: https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=2783 https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27... [2]: https://learn.microsoft.com/en-us/windows/win32/winprog64/application-installation https://learn.microsoft.com/en-us/windows/win32/winprog64/ap...

magicalhippo 2y ago

Microsoft sure has done a great job, but I have experienced some issues around Program Files and registry virtualization, along with UAC. I suppose if you run it as admin and/or install it outside Program Files it'll make it a lot less troublesome. So, not unexpected, but I'd still be mildly surprised.

chungy 2y ago
> some issues around Program Files and registry virtualization, along with UAC. Now that's rattling a thing in my brain. I recall disabling UAC was one of the more consistent ways to get Delphi 6 to even run on Windows 7, and even then it wasn't a guarantee. Yeah, I had the displeasure around 2009-2011 of trying to get an old IDE version running on then-current versions of Windows, with multiple Vista and 7 computers in the office. It ran fine on Windows XP, but newer OSes were not so lucky. Perhaps the solution was to purchase a newer Delphi, but that avenue wasn't sought after.
tracker1 2y ago
Yeah... I saw a lot of poorly written apps using localized data in the application's directory, when they started locking down Program Files, all kind of bugs started to pop up. I don't blame MS much, they had some compatibility shims in place, but it was still troublesome. Mostly blame the early app devs for not understanding separation of the application/libraries and the data the app uses/manipulates.

jchw 2y ago

It's more hit or miss than you might think. If you're just using mostly basic parts of the Win32 API then it is basically about as solid as any backwards compatibility ever has been. The fall off occurs as you veer off into deeper holes: - Multimedia software and games tend to hit on areas of Windows where compatibility is far from perfect. - Even 32-bit software would sometimes have random Win16 binaries, and those are not emulated; I don't blame Microsoft or anything, but they could support it if they wanted to. (Understandably, they do not.) - Software that uses truly obsolete Windows components may no longer work. AFAIK .NET Framework 1.1 hasn't been supported since Windows 8. Old ActiveX and COM components can also be a problem. This has led to some situations where you might actually have better luck running the old software under Wine and Linux than modern Windows, especially for some older games. It's not that Microsoft didn't do immense amounts of work here, but in practice there are some holes I've run into.

magicalhippo 2y ago
> Even 32-bit software would sometimes have random Win16 binaries InstallShield being a common one in that regard. So common that 64-bit Windows, which doesn't support 16-bit binaries, contains code to handle specifically[1] InstallShield and Acme 16-bit binaries[2]. [1]: https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=2783 https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27... [2]: https://learn.microsoft.com/en-us/windows/win32/winprog64/application-installation https://learn.microsoft.com/en-us/windows/win32/winprog64/ap...