> programs written in the Windows 95 32-bit era are guaranteed to continue running without ever changing again
This needs the caveat of how well written those programs were: even with all the compatibility features modern Windows have, some programs did abuse the underlying APIs and had memory issues.
Also some programs at the time used "thunking" to mix 16bit and 32bit code (via DLLs) or simply used some DOS-based programs for some tasks even though the "main" program was 32bit, so those wont work with 64bit Windows. AFAIK Borland C++ 5 is a case of an application doing both, even though the main IDE is 32bit (and works in modern Windows), some of the helper stuff relies on DOS and Win16 code that doesn't work.
I have run into something similar with really old MinGW compiled applications. Old MinGW used to start allocating the heap at an non-recommended, but technically working address. After Windows 7, however, MSFT enforced memory safety rules a bit more firmly, making this address non-valid and breaking the program. Visual Studio provides a tool to rebase the heap allocation address, so that old 15+ year old program works again in Win10. I chose another address, admittedly one that might fall into the same category as before, but all of us at work hope to be off this old program by the time that happens again. Or we'll just virtualize it again.
This needs the caveat of how well written those programs were: even with all the compatibility features modern Windows have, some programs did abuse the underlying APIs and had memory issues.
Also some programs at the time used "thunking" to mix 16bit and 32bit code (via DLLs) or simply used some DOS-based programs for some tasks even though the "main" program was 32bit, so those wont work with 64bit Windows. AFAIK Borland C++ 5 is a case of an application doing both, even though the main IDE is 32bit (and works in modern Windows), some of the helper stuff relies on DOS and Win16 code that doesn't work.