A little note about section "Wine's implementation": the implementation described in Ken's email was never really used in Wine, intentionally (in vanilla Wine that kind of hack is not accepted). It has been used for a few years in CrossOver, CodeWeavers' fork of Wine (more recently also used by Apple for its Gaming Toolkit). Wine is currently moving towards supporting x86-on-ARM emulation properly by better separating the guest and host code, in a manner similar to how Windows itself does the same thing.
EDIT: Another quick thought: in the project readme you mention the observation that "win32 is the stable Linux userland ABI". The origin of that remark might have been this blog post by Arek Hiler: https://blog.hiler.eu/win32-the-only-stable-abi/.
I think the general sentiment has been around for much longer, but it’s very well put. For instance old Loki Linux ports became useless after only a few years, but you could then run the Windows game in Wine no problem.
Not useless. You had to set something like OSSPD and some MESA variables and the games would run fine with the old libc libraries. I think both Debian and Slackware had "compat" libraries for a while.
Came to this headline thinking "Please be about something other than running DOSBox on a Mac".
But indeed, this is fairly novel. It's about running 32 bit i386 binaries in long mode (yeah, on a mac/Rosetta) via setting the compatibility/word-size bits in the code segment using an LDT.
FWIW, from the article:
> (PS: I love how the "base" address is chopped up into pieces and sprinkled into random seeming places. I believe it's because the format of this data was itself evolved over time across processor versions.)
Sort of. The descriptor table was added in the 286 which only had 16 bit registers. The segment base/limit fields there were natural and clean. The 386 needed to squeeze in the top bits somewhere without otherwise wasting memory or breaking compatibility.
> One idea I'm considering is instead putting my 64-bit code at a "high" but not outside of 4gb range address, to eliminate the intermediate step. I think on win32, addresses in the 2-4gb range were reserved for the kernel so maybe I could load there, not sure.
This was originally true and (theoretically) some executables might actually expect <2GB addresses and break if given unexpected pointers but eventually that restriction was lifted to allow more than 2GB per process. Windows executables can opt into the full 32-bit address space using the large address aware flag [0] but for an compatibility layer like Wine it makes sense to be able to override it and use the full address space even for executables that don't have the flag set because the emulation and/or OS/driver differences can increase the virtual memory usage compared to Windows. Or some executables don't have it set but need it when working with large enough data - this is often the case with heavily modded 32-bit games. Hence Proton's PROTON_FORCE_LARGE_ADDRESS_AWARE override.
It cleaned up dramatically what Apple had to support going forward for ARM. They COULD have kept supporting it, they decided since we needed an ISA change, may as well go all 64-bit at the same time and kill off compatibility cruft.
Right, but could they have done something like Wine/you are doing and kept it? A compromise of sorts? Edit: I see you're saying they chose a clean break.
It makes some sense to me. To support 64-bit x86 they need to ship 64-bit x86 versions of lots of system libraries, which itself is probably kind of a hassle and a waste of disk space for many users. Supporting 32-bit x86 would require an additional copy of all that code.
Meanwhile I imagine most of the software people might want to run is 64-bit x86 anyway; 32-bit x86 is these days really only a thing you care about for old games, which is pretty esoteric. If Wine can be made to support it then that keeps the support load limited to Wine.
If anyone is wondering: With X64 the author is referring to x86_64 a.k.a. AMD64. Wondering why they're introducing yet another name for the same thing.
I wouldn’t say that they’re introducing it, I see x64 used to refer to 64-bit x86 in a lot of places. If you don’t like it or think it’s technically wrong for some reason that’s one thing, but you’ll be fighting an uphill battle if you want it to go away.
It was called AMD64 when AMD and Microsoft designed it, but Intel objected using the term when they adopted the architecture and coined their own: EM64T. So, Microsoft came up with a compromise and started calling it x64.
Intel originally named it "IA-32e" to try to make it sound it was just a small extension on the 32bit x86 architecture whereas the Itanium IA-64 architecture was the future.
The post says '64-bit x86 ("x86-64" or "x64")' which is also roughly what the first sentence of Wikipedia has to say about it. I personally picked it just because it was shorter to type and easily understood in context.
Readit News
A little note about section "Wine's implementation": the implementation described in Ken's email was never really used in Wine, intentionally (in vanilla Wine that kind of hack is not accepted). It has been used for a few years in CrossOver, CodeWeavers' fork of Wine (more recently also used by Apple for its Gaming Toolkit). Wine is currently moving towards supporting x86-on-ARM emulation properly by better separating the guest and host code, in a manner similar to how Windows itself does the same thing.
EDIT: Another quick thought: in the project readme you mention the observation that "win32 is the stable Linux userland ABI". The origin of that remark might have been this blog post by Arek Hiler: https://blog.hiler.eu/win32-the-only-stable-abi/.
I think the general sentiment has been around for much longer, but it’s very well put. For instance old Loki Linux ports became useless after only a few years, but you could then run the Windows game in Wine no problem.
https://www.applegamingwiki.com/wiki/Game_Porting_Toolkit
and this thread (talking about installing 32 bit with wine64):
https://www.reddit.com/r/macgaming/comments/15l0onw/dark_and...
it's for a specific video game, but very similar (using wine)
But indeed, this is fairly novel. It's about running 32 bit i386 binaries in long mode (yeah, on a mac/Rosetta) via setting the compatibility/word-size bits in the code segment using an LDT.
FWIW, from the article:
> (PS: I love how the "base" address is chopped up into pieces and sprinkled into random seeming places. I believe it's because the format of this data was itself evolved over time across processor versions.)
Sort of. The descriptor table was added in the 286 which only had 16 bit registers. The segment base/limit fields there were natural and clean. The 386 needed to squeeze in the top bits somewhere without otherwise wasting memory or breaking compatibility.
This was originally true and (theoretically) some executables might actually expect <2GB addresses and break if given unexpected pointers but eventually that restriction was lifted to allow more than 2GB per process. Windows executables can opt into the full 32-bit address space using the large address aware flag [0] but for an compatibility layer like Wine it makes sense to be able to override it and use the full address space even for executables that don't have the flag set because the emulation and/or OS/driver differences can increase the virtual memory usage compared to Windows. Or some executables don't have it set but need it when working with large enough data - this is often the case with heavily modded 32-bit games. Hence Proton's PROTON_FORCE_LARGE_ADDRESS_AWARE override.
[0] https://learn.microsoft.com/en-us/cpp/build/reference/largea...
Meanwhile I imagine most of the software people might want to run is 64-bit x86 anyway; 32-bit x86 is these days really only a thing you care about for old games, which is pretty esoteric. If Wine can be made to support it then that keeps the support load limited to Wine.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
There's even a guide from Intel that uses the term x64:
https://www.intel.com/content/dam/develop/external/us/en/doc...
It's probably the clearest term to use when you're talking specifically about Windows binaries (PE files).
Deleted Comment
The original name was x86-64. Quoting myself (https://news.ycombinator.com/item?id=36075840):
> I still shake my head at how they were able to successfully rebrand it from amd64 to x86-64
It's the opposite: the original name was x86-64, and amd64 is a later rebranding. See, for instance, the original web site for this (then) new architecture: https://web.archive.org/web/20000829042251/http://www.x86-64...
(you didn't know? https://wiki.debian.org/X32Port)
Deleted Comment