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.
Yeah... So to use the program you have to go through a treasure hunt across the internet to find your message, then understand what it means, then follow the steps, then try running the program. Maybe it will work, maybe it won't. That's the Linux adventure!
Linux adventure? Ever heard of PCGaming Wiki and running DX7-9 era games today? That's a clusterfuck of wrappers. Heck, Direct Draw games run dog-slow under Windows > 7 unless you use a DDraw->OpenGL wrapper from WineD3D for Windows and hex-edit the DDL's to avoid name clashes.
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.
The smart move for Apple would be to always be ready to emulate any old platform. Build the emulator as an app, so that one day, when that app gets too old, run it itself in an emulator.
That way it can be emulation all the way down, and you get binary compatibility forever with minimal ongoing engineering cost. The performance would be atrocious if not for the fact computers today are faster than 1980's computers so it really doesn't matter.
That's a pretty good point, it is odd for Apple to not have provided even a simple WINE-like utility for emulating 32 bit apps, even without any effort put into optimization it would have still been useful for M1/M2 chips.
The problem with this is that it effectively gives license for companies to even more frequently toss a binary over the wall and make no attempt at long term maintenance, because that old binary still technically works.
It also means more users using more emulated binaries more frequently, which can make the hardware’s battery life and performance seem worse than they actually are, especially to less technically inclined users who don’t know the details but notice their laptop dying a lot faster than it should.
I'm not sure why it matters if shady companies are slightly incentivized more to be shady?
If they don't really care, they're going to put the minimum possible effort on a separate 64 bit version too and it'll be just as inefficient anyways, except with no backwards compatibility.
By cutting off 32-bit support, Apple gets more people to buy a new computer, as new software versions are only available on 64-bit computers. It also removes the incentive for software vendors to keep producing 32-bit software versions.
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.
Which also means that if you've been dealing with anything referencing build matricies in Visual Studio, you've been using "x64" too. Perhaps exclusively.
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.
Yes, but that doesn't contradict with what I said. AMD had pivoted to "AMD64" soon after and that was before Intel had released their own name: EM64T. Microsoft coined x64 around that time, probably found it more marketable than x86-64, becuase they had used it in commercial branding such as "Windows XP Professional x64 Edition" too. (They couldn't call Windows XP "64-bit edition" because that term was used for their Itanium-based (IA64) products).
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.
The Grief over the use of x64 for AMD64 or X86-64 is based in the prior use of "x64" for the DEC Alpha architecture in the hardware naming: "DECchip 21x64" [0]
Digital was earlier to market the Alpha as a 64 bit ISA than either Intel's Itanium ( IA-64) or AMD's x86-64 which is also called AMD64 [1]
I live in a cave called "x86 Hackintosh" -- it sure looks like all this would work on an x86-64 Mac, maybe similar x86-64-only environments like WSL1. Very cool to see wine32on64 being done differently -- without a magick-infused compiler!
A lot of personal sites such as this one are built on a public repo someplace, and one is often invited to submit typo corrections etc. upon finding the source. In this case, though, my search dead-ended at code for your custom, minimalist static site generator. https://github.com/evmar/cms
Date stamp is part of the metadata passed into the generator, according to https://neugierig.org/software/blog/2022/10/blog-software.ht..., but I don't see anywhere that the Go code checks whether a post's date is in the future. Did you intend to add a post-scheduling feature but haven't gotten to it?
Wow, you are thorough! I just include the date as metadata in the post input file and typed it wrong this time. I don't have any scheduling feature, the whole thing is incredibly manual ("make" followed by "rsync" to publish). I don't publish my blog's source because it includes other things like unpublished drafts.
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/.