Back during the Windows 7 upgrade cycle, my company discovered that the old timecard software they were using no longer worked. Fortunately, the IT department came up with a solution: issue everyone in the commpany an Ubuntu VM, and have them run the software under Wine. That went on for years until the eventually switched over to a web based solution.
I bet that the timecard application was a 16 bit executable. 32 bit Windows was able to run 16 bit executables using the NT Virtual DOS Machine (NTVDM), but 64 bit Windows couldn't.
Wine is however able to run 16 bit executables on 64 bit hosts using their version of NTVDM.
This is one of the rare use cases where Wine on Windows actually makes sense - you can build it under SFU/SUA, or at least you used to be able to. (I never managed to get FreeType working, so messages weren't sized properly for dialogue boxes, but it was enough to do what I needed).
Not rare at all! If you work with older games, you often will struggle to get the correct version of direct3D to work on Windows 11. Most of those games start first try in Wine on Windows.
You are right that Windows 7 x64 is unable to run 16-bit applications but I suspect it would have been far easier to do a Windows 7 x86 installation than Ubuntu VM + Wine per PC.
And I honestly never understood this apart from Microsoft wanting to finally kill Win16: after all, it’s not like V86 mode (whose absence in x86-64 is the official justification) is actually required—non-x86 versions of NT had perfectly serviceable Win16 support through the extremely expected approach of having a full PC emulator inside[1]. (Some even extremely briefly had x86 Win32 support[2], but that wasn’t resurrected for Windows for ARM either, perhaps because the sheer amount of stuff in the system has grown so much since that time.)
Mind you, the decision was made with the release of (I think) Windows XP for x86-64, in 2005. I actually briefly used a computer with Windows 3.11 on it around that time (oh the wonders of school IT). I’m not saying Microsoft’s decision was wrong, though, only that the official rationale is kind of bullshit.
... I’m trying to imagine how one’d handle interrupts in this setup, and it sounds kind of terrifying. Reprogram the LAPIC each time? Carefully code the interrupt entry to work as both 32- and 64-bit code to determine if it needs to switch back? Ouch.
You don't need to use the same IDT as in long mode. Just have a 32-bit one that decides whether to handle an interrupt (e.g. vm86 traps/emulation) or re-enable long mode and forward it to the 64-bit handler.
But you don't have to imagine -- early amd64 Linux could do it, and there was a patch floating around that kept that feature all the way to 2.6.2x series.
My girlfriend is a fan of the old point-and-click Nancy Drew games. Nearly all of them are sold on Steam, and while some work fine, others won't even launch or have immediate breaking issues. We discovered that the games run better (granted, not really well enough to actually play them..) on Linux via Steam Proton than they do on modern Windows.
I have had much better experiences with gog.com instead of Steam for old games. They tend to actually make sure something runs before putting it up for sale.
Might be worth checking out for you. Though I see only one Nancy Drew game there.
We once bought Parallels licenses for 3 marketing users that demanded Macs.
The main reason was so they could our timecard software. We could have just gave them a $2 RFID card like the production employees, but then they would have to walk down to the time clock and "punch in".
I think they also ended up using it for the Windows version of Outlook because there was some feature they wanted to use that the Mac version did not have.
My first mac at work was around 2009. To facilitate using all the internal tools all mac users were issues a windows virtual machine (vmware) that booted the company maintained windows image. Some of that stuff included some things that were dependent on IE 6 era APIs. Which at that point were already deprecated. But MS still supported that stuff.
The amazing stuff was that that vm ran circles around my previous windows laptop, which at that point was three years old. Just way faster than that ever was. Virtual machines and emulators are a good solution for legacy applications. Much easier than pretending ancient APIs are still supported. MS could have saved themselves a lot of grief by just embracing that decades ago and breaking compatibility with each new windows version. Just run the old crap in some vm or emulator. Apple has done that a few times when they switched CPU architectures and when they introduced OS X. They of course removed legacy support as well. But the point is valid: emulation works great.
And it works well enough with Linux support in windows these days; so why not apply that for legacy stuff as well. There's no reason why you wouldn't be able to run everything from the DOS era forty years ago up until now on a modern laptop. And there's no reason to burden modern APIs with all that crap.
It’s worth remembering the x86 emulation on Apple Silicon is as good as it is (reportedly better than most other x86-on-ARM efforts) in part due to CPU features Apple added to the host platform for that explicit purpose, from memory ordering[1,2] to obscure flag bits[3].
