Wow! This might actually make it possible for Actually Portable Executable to support running on Windows ARM. I'm already putting the ARM code inside all my binaries. There's just never been a way to encode that in the PE headers. But if my emulated WinMain() function for x86-64 could detect that it's being emulated and then simply ask a WIN32 API to jump to the ARM entrypoint instead, it'd be the perfect solution to my problems. I actually think I'm going to rush out and buy a Windows ARM computer right now.
And this kind of beautiful insanity is why you're one of my favorite developers of this era.
Also,
> I'm already putting the ARM code inside all my binaries.
Wait, I thought CPU architecture was the one limitation that did affect APE - you mean on unix-likes APE binaries are already compatible across amd64 and aarch64?
Edit: rereading https://justine.lol/cosmo3/ it does say that, doesn't it - and ARM64 listing "Windows (non-native)" just means that one platform uses (for the next few hours-days, at least...) emulation. That's amazing:)
I would recommend getting an official consumer build to test all of the latest consumer features like Copilot
Parallels has a Microsoft partnership and has an official AMR64 image which I was able to grab (and run in anything). I’m sure there are a lot more now, though!
Even more: clone3, __clone2 (only exists on Itanium), fchmodat2, preadv2, pwritev2, pipe2, sync_file_range2, mmap2 (only certain architectures; for x86, only 32-bit), renameat2, mlock2, faccessat2, epoll_pwait2
My personal prediction is sooner or later we'll see execveat2, to permit setting /proc/PID/comm when using execveat [0].
I doubt we'll ever see clone4, because clone3 is passed a structure argument with the structure size, so new fields can be supported just by increasing the structure size. If other syscalls had done that from the start, much of the 2/3/etc would have been avoided. It is actually a very common practice on Windows (since NT), it has only much more recently been adopted in the Linux kernel
I work on a team that supports some equipment related to airplanes. An acronym for one piece of equipment that is decades old is "RCSU". When I got a support call talking about "RSCU", I assumed the person meant "RCSU".
Nope. It turns out, when they made their next-generation piece of equipment, the vendor differentiated it by swapping the inner two letters in an already easy-to-say-wrong acronym.
My reaction was, "WTF didn't they just call it the RCSU2?!"
The vague convention, as far as I understand, is that Ex denotes an extended variant of a function for more advanced use cases (e.g. with additional parameters/options) which is functionally a superset of the original function, whereas numbered versions are intended to be complete replacements and/or may change the semantics compared to the prior version.
