6 ms·

I 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 P

I 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 ago
Actually, 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 ago
  I'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 ago
    The 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 ago
  Oh, 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".
  - AshamedCaptain 6y ago
    Yes you can switch back to 16bit, and in early x64 Linux there was even support for the vm86plus() API, which allowed stuff such as dosemu to run natively (and even let DOS programs bitbang your IO ports). Eventually this was removed from upstream but there was a patch floating around which I used for some time. 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.
  - deleted 6y ago
    [deleted]
- leeter 6y ago
  > 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. No... it wasn't political. It was a deliberate design decision for technical reasons ( https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications 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.
  - AshamedCaptain 6y ago
    Fair enough, though it's still not a hardware reason. 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.
    - leeter 6y ago
      So unfortunately people do care, it's why 32bit windows is still a thing. Most of the people that care however are large legacy enterprises that are running line of business applications that they don't have the source code for or require libraries they don't have the source code for. While they are migrating it's not a quick process in many cases. 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.

deleted 6y ago

[deleted]

AshamedCaptain 6y ago

Actually, 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 ago
I'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 ago
  The 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 ago
Oh, 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".
- AshamedCaptain 6y ago
  Yes you can switch back to 16bit, and in early x64 Linux there was even support for the vm86plus() API, which allowed stuff such as dosemu to run natively (and even let DOS programs bitbang your IO ports). Eventually this was removed from upstream but there was a patch floating around which I used for some time. 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.
- deleted 6y ago
  [deleted]
leeter 6y ago
> 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. No... it wasn't political. It was a deliberate design decision for technical reasons ( https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications 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.
- AshamedCaptain 6y ago
  Fair enough, though it's still not a hardware reason. 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.
  - leeter 6y ago
    So unfortunately people do care, it's why 32bit windows is still a thing. Most of the people that care however are large legacy enterprises that are running line of business applications that they don't have the source code for or require libraries they don't have the source code for. While they are migrating it's not a quick process in many cases. 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.