3 ms·

Is this needed because recent x86-64 processors / hardware are not able to run older 32bits binaries anymore?

by forty 2y ago

xcv123 2y ago
It runs on other CPU architectures and it emulates older PCs which include other hardware besides the CPU.
- forty 2y ago
  Ah yes, they have ARM binaries indeed in the download section. I got trapped by the "minimum requirements": Intel Core 2 or AMD Athlon 64 processor or newer, which made me think it only ran on x86
sedatk 2y ago
Did you mean 16-bit binaries?
userbinator 2y ago
AFAIK that's a software limitation, not a hardware one (yet).
- NikkiA 2y ago
  Intel dropped the "x86s" project to focus on a more collaborative approach with amd and others, so it's probably been shifted a few years out anyway.
- dfox 2y ago
  Technically it is an hardware limitation, amd64 in long mode has only vestigal support for memory segmentation (enough to implement Win32/ELF i386 TLS ABI and that's it), so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform.
  - userbinator 2y ago
    so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform. I don't know who has been spreading FUD (likely MS, just like they did with "32-bit Windows can't use more than 4GB of RAM") but that's not true. https://www.dkia.at/en/node/180 https://www.dkia.at/en/node/180 There's another article I can't find at the moment which discusses this in a lot of technical detail, making references to using the "unrestricted guest" virtualisation feature on CPUs that have it (quite new at the time) which essentially runs 16-bit code as a VM, or classic modeswitching that jumps between 16, 32, and 64-bit mode as needed. Nonetheless, it is quite irritating that despite the hardware being perfectly capable of 16-bit, 32-bit, and 64-bit operation, the designers made it harder than necessary to do so.
    - dfe 2y ago
      In the absence of VM extensions, which the earliest AMD64 CPUs did not have, once the CPU is in long mode, the base address of segments other than FS and GS doesn't work, it must be 0. That's not such a problem for 32-bit segments whose base is normally 0 anyway (flat 32), but most 16-bit protected mode Windows code expects the linear address of its code and data segments to be something other than 0, and even might expect to be able to use multiple data segments with different base addresses. So, sure, you can run 16-bit protected mode code with a base address of 0, but that's not very useful. Also there's no virtual 8086 mode when in long mode to support real mode code. With VM extensions it's possible to virtualize the CPU in regular (not long) mode, at which point the virtualized CPU will indeed support non-zero segment base addresses and virtual 8086 mode. In theory this can be done with an extremely light virtual machine layer, but the entry/exit to/from the 16-bit code, or even for that matter any code needing to use 16-bit data segments is going to require more than it would if the CPU weren't in long mode. And this is assuming you have virtual mode extensions. If you don't then you need a CPU emulator. My guess is that Microsoft felt it just wasn't worth writing all of this extra code needed to do this. There's a big difference between technically possible and makes even remote economic sense to do it.
      - rep_lodsb 2y ago
memsom 2y ago
Getting any legacy OS to run on modern hardware is very hard. For example, in my case, BeOS has no EFI boot capability, has a serious RAM restriction, doesn't really like anything past a P4, and has no drivers for anything but legacy hardware (like, no modern storage drivers - IDE only, no SATA unless there is legacy BIOS emulation.) A lot of this is able to be worked around with various hacks, but with 86Box, it will run the OS as is it was on the actual hardware, so it just makes it a no brainer. You can then also use it to emulate old PC hardware on other processor architectures - like ARM.
powerhugs 2y ago
It allows you to emulate MS-DOS or other legacy 16/32-bit operating systems on any supported hardware, such as ARM.
rnd0 2y ago
Strictly speaking, no. It's primarily developed (as I understand it) for cases (gaming, mostly, but some hobby/dev use) where emulating hardware accurately (think timings) is desireable. In a sense it's also a history preservation project, though I doubt they would characterize it as such themselves. They don't do the documentation that pcjs does; but I think it's similar in spirit, if not in implementation specifics.
- rnd0 2y ago
  I should clarify that when I say that, I don't mean documentation about the emulator (which is coming along nicely), but documentation about the computers being emulated. I was specifically thinking of things like this ( https://www.pcjs.org/machines/pcx86/compaq/portable/ https://www.pcjs.org/machines/pcx86/compaq/portable/ ) when I was writing that comment.

Is this needed because recent x86-64 processors / hardware are not able to run older 32bits binaries anymore?

by forty 2y ago

Is this needed because recent x86-64 processors / hardware are not able to run older 32bits binaries anymore?

xcv123 2y ago

It runs on other CPU architectures and it emulates older PCs which include other hardware besides the CPU.

forty 2y ago
Ah yes, they have ARM binaries indeed in the download section. I got trapped by the "minimum requirements": Intel Core 2 or AMD Athlon 64 processor or newer, which made me think it only ran on x86

sedatk 2y ago

Did you mean 16-bit binaries?

userbinator 2y ago

AFAIK that's a software limitation, not a hardware one (yet).

NikkiA 2y ago
Intel dropped the "x86s" project to focus on a more collaborative approach with amd and others, so it's probably been shifted a few years out anyway.
dfox 2y ago
Technically it is an hardware limitation, amd64 in long mode has only vestigal support for memory segmentation (enough to implement Win32/ELF i386 TLS ABI and that's it), so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform.
- userbinator 2y ago
  so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform. I don't know who has been spreading FUD (likely MS, just like they did with "32-bit Windows can't use more than 4GB of RAM") but that's not true. https://www.dkia.at/en/node/180 https://www.dkia.at/en/node/180 There's another article I can't find at the moment which discusses this in a lot of technical detail, making references to using the "unrestricted guest" virtualisation feature on CPUs that have it (quite new at the time) which essentially runs 16-bit code as a VM, or classic modeswitching that jumps between 16, 32, and 64-bit mode as needed. Nonetheless, it is quite irritating that despite the hardware being perfectly capable of 16-bit, 32-bit, and 64-bit operation, the designers made it harder than necessary to do so.
  - dfe 2y ago
    In the absence of VM extensions, which the earliest AMD64 CPUs did not have, once the CPU is in long mode, the base address of segments other than FS and GS doesn't work, it must be 0. That's not such a problem for 32-bit segments whose base is normally 0 anyway (flat 32), but most 16-bit protected mode Windows code expects the linear address of its code and data segments to be something other than 0, and even might expect to be able to use multiple data segments with different base addresses. So, sure, you can run 16-bit protected mode code with a base address of 0, but that's not very useful. Also there's no virtual 8086 mode when in long mode to support real mode code. With VM extensions it's possible to virtualize the CPU in regular (not long) mode, at which point the virtualized CPU will indeed support non-zero segment base addresses and virtual 8086 mode. In theory this can be done with an extremely light virtual machine layer, but the entry/exit to/from the 16-bit code, or even for that matter any code needing to use 16-bit data segments is going to require more than it would if the CPU weren't in long mode. And this is assuming you have virtual mode extensions. If you don't then you need a CPU emulator. My guess is that Microsoft felt it just wasn't worth writing all of this extra code needed to do this. There's a big difference between technically possible and makes even remote economic sense to do it.
    - rep_lodsb 2y ago

memsom 2y ago

Getting any legacy OS to run on modern hardware is very hard. For example, in my case, BeOS has no EFI boot capability, has a serious RAM restriction, doesn't really like anything past a P4, and has no drivers for anything but legacy hardware (like, no modern storage drivers - IDE only, no SATA unless there is legacy BIOS emulation.) A lot of this is able to be worked around with various hacks, but with 86Box, it will run the OS as is it was on the actual hardware, so it just makes it a no brainer. You can then also use it to emulate old PC hardware on other processor architectures - like ARM.

powerhugs 2y ago

It allows you to emulate MS-DOS or other legacy 16/32-bit operating systems on any supported hardware, such as ARM.

rnd0 2y ago

Strictly speaking, no. It's primarily developed (as I understand it) for cases (gaming, mostly, but some hobby/dev use) where emulating hardware accurately (think timings) is desireable. In a sense it's also a history preservation project, though I doubt they would characterize it as such themselves. They don't do the documentation that pcjs does; but I think it's similar in spirit, if not in implementation specifics.

rnd0 2y ago
I should clarify that when I say that, I don't mean documentation about the emulator (which is coming along nicely), but documentation about the computers being emulated. I was specifically thinking of things like this ( https://www.pcjs.org/machines/pcx86/compaq/portable/ https://www.pcjs.org/machines/pcx86/compaq/portable/ ) when I was writing that comment.