Windows can still run software from the 80's, backwards compatibility has always been a selling point for Windows, so I'd call that a win.
Or Wine, which is less reliable but funnier.
Wine itself doesn't run on Windows AFAIK.
It does, if you use an old enough version of windows that SUA is available :). I never managed to get fontconfig working so text overlapped its dialogue boxes and the like, but it was good enough to run what I needed.
Mind you, Wine might lose that too ...
You'd expect Microsoft to support things because it doesn't make money for them anymore or some other calculated cost reason, but Microsoft is supporting old things few people use even when it costs them performance/secure edges.
Though personally, while I care a lot about using old software on new hardware, my desire to use new software on old hardware only goes so far back and 32 bit mainstream CPUs are out of that range.
Open source isn't where I'd expect abandonware to happen.
Depends on how much power it's wasting, when we're looking at 20 year old desktops/laptops.
> 32 bit is still valid for many applications and environments that don't need >3GB~ ram.
Well my understanding is that if you have 1GB of RAM or less you have nothing to worry about. The major unresolved issue with 32 bit is that it needs complicated memory mapping and can't have one big mapping of all of physical memory into the kernel address space. I'm not aware of a plan to remove the entire architecture.
It's annoying for that set of systems that fit into 32 bits but not 30 bits, but any new design over a gigabyte should be fine getting a slightly different core.
> For example, routers shouldn't use 64bit processors unless they're handling that much load, die size matter there
I don't think that's right, but correct me if I missed something. A basic 64 bit core is extremely tiny and almost the same size as a 32 bit core. If you're heavy enough to run Linux, 64 bit shouldn't be a burden.
Linux goal is only for code compatibility - which makes complete sense given the libre/open source origins. If the culture is one where you expect to have access to the source code for the software you depend on, why should the OS developers make the compromises needed to ensure you can still run a binary compiled decades ago?
NTVDM leverages virtual 8086 mode which is unavailable while in long mode.
NTVDM would need to be rewritten. With alternatives like DOSBox, I can see why MSFT may not have wanted to dive into that level of backwards compat.
NTVDM as it existed Windows NT (3.1 through 10) for i386 leveraged V86 mode. NTVDM on Windows NT (e.g. 4.0) for MIPS, PowerPC, and Alpha, on the other hand, already had[1] a 16-bit x86 emulator, which was merely ifdefed out of the i386 version (making the latter much leaner).
Is it fair of Microsoft to not care to resurrect that nearly decade-old code (as of Windows XP x64 when it first became relevant)? Yes. Is it also fair to say that they would not, in fact, need to write a complete emulator from scratch to preserve their commitment to backwards compatibility, because they had already done that? Also yes.
[1] https://devblogs.microsoft.com/oldnewthing/20060525-04/?p=31...
> Lucovsky was more fastidious than Wood, but otherwise they had much in common: tremendous concentration, the ability to produce a lot of code fast, a distaste for excessive documentation and self-confidence bordering on megalomania. Within two weeks, they wrote an eighty-page paper describing proposed NT versions of hundreds of Windows APIs.
and chapter 6 mentions the NTFS spec being initially written in two weeks by Miller and one other person on Miller’s sailboat.
> Maritz decided that Miller could write a spec for NTFS, but he reserved the right to kill the file system before the actual coding of it began.
> Miller gathered some pens and pads, two weeks’ worth of provisions and prepared for a lengthy trip on his twenty-eight-foot sailboat. Miller felt that spec writing benefited from solitude, and the ocean offered plenty of it. [...] Rather than sail alone, Miller arranged with Perazzoli, who officially took care of the file team, to fly in a programmer Miller knew well. He lived in Switzerland.
> In August, Miller and his sidekick set sail for two weeks. The routine was easy: Work in the morning, talking and scratching out notes on a pad, then sail somewhere, then talk and scratch out more notes, then anchor by evening and relax.
(I’m still relatively confident that the Win32 spec was written in 1990; at the very least, Showstopper! mentions it being shown to a group of app writers on December 17 of that year.)