Its interesting to see how developers get into a mindset, based on their life experience.
What we're seeing here is 40 year old code compile and run with minimal effort. Largely because the C language has respected backwards compatibility.
Yes, there were breaking changes along the way, but they were trivial to resolve in hours. And (more interesting) the author believed that to be true and so persevered.
I saw this recently as well. I run a lot of programs on Windows. Many are 32 bit, written in the 90s for Windows 95, or 98. They all still run. Microsoft bends over backwards to keep things compatible.
I also get to write a lot of web API clients. I tell customers that it won't work forever. Web APIs are constantly changing. The service (especially Google) will change something soon to break it.
The people building those APIs are expecting only currently-maintained apps to run. They have no concept (or experience) of 40 or 30 year old code "just running". Crumbs, if you get 5 years out an API client you're doing well.
Yeah, the "porting" part was pretty trivial, all things considered. Any difficulty was really only as a consequence of certain patterns being unfamiliar or evolved. Once those patterns were identified, it was only "roll up your sleeves and do the work" to get it going again.
Working on this kind of got me re-thinking my approach to my personal projects again. What can I do today to best ensure my own code will be this easy to run in 30 years? As a corollary to that, what can I build today that will be interesting enough to want to run again in 30 years?
I think part of that is because those old Windows apps were distributed and forgotten about. There was no update procedure for many of them, and if there was it was just "buy a new disk" or at most "check the website and download a new EXE". Now that people have always-on internet connections, they expect to be able to get things instantly, and companies then expect to be able to push their updates instantly, and other companies expect that they can push their own update if someone else breaks their API, and so on and so forth until everyone expects everyone to have "the latest version" of everything.
It's the era of constant updates. I find it pretty annoying.
... all presuposing of course that the authors of that code are still around, and still want to make the effort of updating it.
In the enterprise world lots of software is more than a decade old, and no one is prepared to "update" it. The mindset in that space is for things to have longevity.
It's more of a mindset I think. Microsoft is clearly very focused on keeping things running. Apple (as a contrast example) is happy to change architecture, remove 32 bit support, and so on.
I agree it's a mindset, I just mean that that mindset has kind of coevolved with a bunch of other stuff.
Even Microsoft seems to be slipping. It seems like these days the (unstoppable!) Windows updates may actually change functionality and UI, which was much less common in the past. And of course the new versions of Windows are more aggressive about updating. They still maintain backwards compatibility for running third-party programs, but I feel like their mindset used to include more stability in their own software as well.
NTVDM is still out there from or based on NT source and still works too - 16 bit apps generally run as well. Microsoft chooses to not support them. last week I ran down the rabbit hole of how this works and how someone ported it to x64.