4 ms·
They are mostly 32-bit, so you can run them on any Windows 10 build. MS has worked pretty hard to maintain backward compatibility. They should mostly work, mayb
by anonunivgrad 6y ago
They are mostly 32-bit, so you can run them on any Windows 10 build. MS has worked pretty hard to maintain backward compatibility. They should mostly work, maybe requiring a little fiddling with the compatibility settings. But it’s not perfect, and I hear you might have better luck with WINE with some applications.
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.
- Aloha 6y agoI'm always super impressed with windows backwards compatibility, it'd be like unmodified system 7 applications still running on a modern mac.
- spijdar 6y agoI don't have the right hardware to test this right now, but I believe unmodified system 7 binaries (and earlier) should run on up to OS X 10.4.11 from 2007 on PowerPC Macs, using the Classic environment. 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?)
- deleted 6y ago[deleted]
- AshamedCaptain 6y agoActually, running 16 bit code is perfectly supported on 64 bit CPUs (for obvious reasons -- you still need 16 bit to boot a BIOS), and even you can seamlessly switch between 16bit and 64bit modes at runtime (early 64 bit linux could even run vm86plus). 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.
- hackmiester 6y agoI'm not sure that reason is so obvious... can't imagine why you would need to boot a BIOS, aside from very old software.
- AshamedCaptain 6y agoThe AMD64 architecture is older than UEFI. When it was released, _all_ computers booted using a 16bit BIOS. 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.
- spijdar 6y agoOh, sure -- the CPUs themselves can run in 16 bit mode, but after switching to 64 bit long mode I was under the impression you couldn't invoke vm86 mode. But I've never really played with 16 bit before. 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".
- 6y ago