Otvdm/winevdm: run old Windows software in 64-bit Windows
columbia.edu
columbia.edu
[1] Some of them might require Administrator to run if they were not sufficiently multi-user aware to support Windows NT.
The break is with 16-bit applications, which 64-bit Windows 10 no longer supports. You can still run them on 32-bit Windows 10.
All that winevdm does is emulate the 16-bit processor and translate 16-bit-Windows api calls to their modern equivalent, so you can run 16-bit programs on 64-bit Windows again.
In an alternative reality where PowerPC stayed competitive, I wonder how long they would have maintained the compat-layer. Given it's apple, probably not long, but I think it's worth pointing out backwards compat was only broken when both the OS and the CPU were changed (twice in the CPU's case).
My understanding is that running 16 bit code on a modern CPU is itself a sort of backwards compat mode which isn't supported in 64 bit operation, so you need a full emulator to run the executable. Neither Apple nor Microsoft seem keen on keeping CPU emulators around long term (IIRC Windows used to have something like this built-in for emulating 80286s for Win16, mostly for non-x86 arches like Alpha/MIPS/PowerPC, I think?)
It was a political choice by Microsoft to drop 16 bit Windows support in 64 bit Windows. This is the limit of their famous backwards compatibility -- still impressive, though.
This also happened during the era where they were getting criticism from all sides due to crappy Windows security (think XP pre-SP2 times) and they may have seen the 16 bit support code as a liability.
No... it wasn't political. It was a deliberate design decision for technical reasons ( https://docs.microsoft.com/en-us/windows/win32/winprog64/run... ) HANDLEs on 64bit windows have 32bits that are valid whereas HANDLES on 32bit windows only have 16bits that are valid. So unless Microsoft wanted to completely negate the value of going to 64bit in the first place, e.g. expanding the limits on programs to be less restrictive, it was always going to have something to give.
Because 32bit code often "thunked"^1 in 16bit code they couldn't really support it because even in 32bit mode HANDLEs still have 32bits of valid HANDLE. So a HANDLE passed to 16bit code wouldn't round trip correctly due to truncation.
Nor is it like MS could emulate this like the OPs code does, because that would require rewriting applications that had already shipped from ISVs that don't exist anymore or magically understanding when an application has 16bit code and needs to get fake HANDLEs neither of which is easy in reality. In the end it was easier to just ship a 32bit version of windows for those that still needed that support.
1^ This was only possible because FAR pointers in 16bit mode are still 32 bits and thus size of a pointer was in effect the same. So they could operate in the same address space. In 64bit mode this isn't the case because there are no FAR pointers and segmentation.
You could have just given 16bit handles to all 32bit programs, with the con being harder 64<->32 interoperability (since sending a handle from 64 to 32/16 would require faking it), but then you would not break _existing_ applications at least. Guessing 32bit handles also broke quite some 32 bit applications.
In retrospective, I would not have made it the way I describe either way, since it looks like people could care less about old 16-bit compatibility, and on the other hand 32<->64 coexistence was common for quite a while.
As for 16bit HANDLEs for 32bit programs, it wouldn't have solved the issue as the HANDLEs are kernel tokens. The kernel doesn't actually care whether the user space application is 32 bit or 64bit in many cases. That's all handled via WoW64CPU.dll and friends. They proxy all kernel calls from 32bit code and then segment switch to a 64bit segment before calling the kernel. The same happens in reverse when coming back. So it would incur significant performance overhead in many cases to add that when it isn't really necessary and would negatively impact already memory constrained programs. Instead MS chose to let them get the best benefits they could from 64bit mode: all 4GB the 32bit address space can be used for 32bit things instead of just the bottom 2/3GB (depending on being flagged /LARGEADDRESSAWARE). In the end it's a lot more complicated than just telling people that aren't using very memory intensive apps in the first place to just run 32bit Windows which already works... and supports vm86 mode.
...then use a translation table. If the system is 64-bit, there's certainly enough room and speed for one!
16-bit applications would not be able to handle more than 64k handles either way.
I guess I was confusing it with BSD -- on at least NetBSD and I think OpenBSD, there's an in-kernel (16 bit) x86 emulator used for certain ACPI functions, like calling VGA BIOS code (option ROMs?) when waking from suspend-to-RAM.
There's also an option to just use native real mode, but the man page says "this may result in direct reboots".
Whatever one _wants_ to do it or not is another story. Even on 32-bit kernels I don't think vm86plus is enabled by default (nor is LDT changing from user-space) because of the crazy ways you can use it to break things.
Even today all desktop computers I know still ship a BIOS compatibility module meaning they still carry a BIOS which includes 16 bits code. All Windows 32-bits (not only supported, but still being sold) require a BIOS. OEMs regularly use FreeDOS for flashing stuff -- which requires a BIOS.
Only a couple laptops I've seen as full-fledged UEFI (no CSM) devices. They won't boot 32bit Windows nor anything before Windows 8.
Like I'm running 95 era software and it mostly works fine on Win10, I have one application that cant deal with 64 bit, needs 32 bit windows, as it has serial drivers that dont work in 64 bit.
For example you can run Windows 95 release of The Neverhood in Wine, which has some 16-bit parts (though practically, ScummVM is a better option).
Does that work on 64-bit (ie any modern) linux? I remember there being some issue with switching back to 16-bit mode after entering (I think they were calling it) Long Mode, but I don't remember if that got fixed, and I don't have a 16-bit linux-userland-executable format handy to test it.
But I tested it last quite a long time go.
It's sad because VirtualBox used to work okay but the legacy AMD NIC and SoundBlaster drivers have been bitrotting in the last few years and Hyper-V's predecessor Virtual PC used to be great with older OSes too.
If you prefer free software KVM/virt-manager works just fine as well there's just a bit more fiddling with options to make things happy.
I can send it to you.
Regardless, I would argue Wine is an emulator. It emulates Windows's behavior, so it is perfectly fine to describe it as an emulator in some contexts. This pedantic nit-picking is really tiresome.
"Wine (originally an acronym for "Wine Is Not an Emulator")..."