2 ms·

> > programs written in the Windows 95 32-bit era are guaranteed to never change again > Yeah, well, programs written for Linux 20 years ago also never change

> > programs written in the Windows 95 32-bit era are guaranteed to never change again > Yeah, well, programs written for Linux 20 years ago also never change again. That's the whole point of closed-source binary-only programs... This sentence is poorly phrased, but from the context it looks like they meant: programs written in the Windows 95 32-bit era are guaranteed to continue running without ever changing again

kristopolous 4y ago
It's one of the costs of closed source; binary compatible becomes really important. It'd be interesting if a company like Adobe open sourced everything at the 20 year mark. Hobbyists and enthusiasts would love them for it.
badsectoracula 4y ago
> 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.
- glowingly 4y ago
  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.

kristopolous 4y ago

It's one of the costs of closed source; binary compatible becomes really important. It'd be interesting if a company like Adobe open sourced everything at the 20 year mark. Hobbyists and enthusiasts would love them for it.

badsectoracula 4y ago

> 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.

glowingly 4y ago
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.