Whenever I write about old software, it still strikes me how absurd it is that it’s easier to run software from the 90s and 2000s on a modern computer than it is to run an iOS app from 15 years ago.
@misty Unless it is some web based app obviously…
@misty Is it because there are no iOS emulators out there? Anything else can be run on emulation software. But that's not what you mean, right?
@misty This is how all 21st century tech works. Or doesn't work.
@misty People used to complain about Lotus. Lotus was a streamlined miracle compared to modern work.
@misty Yes. Or even Windows 95-XP apps. I run Apple II, C64, Amiga, DOS, classic Mac, etc. apps without any problem at all but Windows from ten years ago? Such a pain. And as you say, old iOS or Android apps are a nightmare.
@PastaThief That’s because you’re using emulators, I guess! Whereas 32-bit Windows executables from arbitrary time periods tend to work fine for me on modern Windows.
@misty reminded me of this post from a few days ago! And I jokingly wanted to suggest to some of my co-workers the idea to port our archival description software to a GBA/NDS… like LSDJ exists, it should be technically possible to do archival description work on a gameboy 😆
Proprietary systems age really poorly.
And ones from today will be totally borked in 8-15 years from now, cause it's all relying on cloud services now
@mansalia You say that, but the software from 15 years ago that still works fine today is all for Windows. It’s less proprietary vs not than it is about the incentives to keep backwards compatibility. And MS is locked into eternal backwards compatibility whether they like it or not.
@sashin @mansalia That’s right. Microsoft’s main competitive advantage is that there’s 40 years of software written for Windows, and many businesses depend on a lot of it. They’ve only intentionally broken binary compatibility twice in Windows history (once when they cut off pre-Windows 3.0 executables, and a second time when they cut off 16-bit software).
@misty it's a great feature of windows IMO, that I can pick up an old game whose development studio died and it still works.
On android, every few years I get a notice to update my app because they're deprecating APIs that I'm using.
Microsoft is carrying the weight of legacy so that the rest of us don't have to.
The weird thing is, they aren’t. I really struggled to get late ‘90s software to run on Windows 10, but it worked flawlessly in WINE. They have a lot of technical debt from trying to keep old software working but, at the same time, they accidentally break old software all of the time.
Apple’s approach with OS X was more sustainable: provide a copy of MacOS 9 that runs in an isolated process and can forward individual windows to the host OS and integrate with the host filesystem and clipboard.
This was also the approach that Singularity / Midori used for backwards compatibility. It was one of the major factors that killed the project because it added about 30 MiB of RAM overhead per program (not necessarily per process, a set of related processes could share a Drawbridge / Windows environment) and that was infeasible at the time. Now, it’s pretty trivial: the amount of memory used by a userspace process dwarfs the amount used by the kernel, so a separate copy of the kernel and all supporting libraries is feasible for legacy programs when you want to migrate.
The Xbox does something similar. Games often have tight dependencies on the host OS and, especially, on the exact amount of RAM it uses so that they can carefully size their own code for the remainder. Each Xbox game comes with its own copy of Windows that runs in a VM with GPU pass through (this is also how the ‘Quick Resume’ feature on the Series X/S works: it just suspends and resumes the VM). If the host copy of Windows is upgraded in a way that would break the game, this doesn’t matter because the game doesn’t use it.
@david_chisnall this approach of providing an older version of the system (both the Mac and Xbox variants) makes a lot of sense to me.
It reminds me a bit of Docker essentially packing a Linux distro with your app (though it does share the kernel).
Docker is indeed how I ran an old app for work, made for a super old java version and super old MySQL version, without installing those on my main machine.
@misty "The following are observations and notes from running named 4.8.3 (1990) from 4.3BSD-Reno ported to 386BSD running on NetBSD as a caching resolver and an authoritative server."
-
[:] https://dnsinstitute.com/research/2021/ancient-1990-bind-4.8.3.html