Arm64EC – Build and port apps for native performance on Arm
learn.microsoft.com
learn.microsoft.com
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:)
dup/dup2/dup3
creat/open/openat/openat2
cough
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
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?!"
[0]: https://learn.microsoft.com/windows/win32/api/memoryapi/nf-m...
Examples:
CreateWindowW -> https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
CreateWindowExW -> https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
If you have an Apple Silicon machine you can run a Windows Insider build via UTM in a VM.
EDIT: Or maybe what you're looking for is hybrid PEs? https://ffri.github.io/ProjectChameleon/new_reloc_chpev2/
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!
Down the rabbit hole...
> buy a Windows ARM computer
You can still get Surface Pro X (16G/LTE) on Amazon for $800
> ...Intel could've made ARM32/64-mode segments a reality...
While I myself admire this particular breed of masochism, the direction that Intel currently wants to take is apparently quite the opposite.
In May last year, they proposed X86S[1][2][3] which tosses out 16-bit support completely, along with 32 bit kernel mode (i.e. the CPU boots directly into 64 bit mode, 32 bit code is only supported in ring 3).
The proposal trims a lot of historical baggage, including fancy segmentation/TSS shenanigans, privilege rings 1 & 2, I/O port access from ring 3, non-flat memory models, etc... limiting the CPU to 64 bit kernel mode, and 64 or 32 bit x86 user mode. With the requirement for 64 bit kernel mode, it effectively also removes un-paged memory access.
[1] https://en.wikipedia.org/wiki/X86-64#X86S
[2] https://www.intel.com/content/www/us/en/developer/articles/t...
It's not just Intel. It's clear that ARM is also going in the same direction, by allowing newer cores to be 64-bit (AArch64) only, dropping compatibility with the older 32-bit ARM ISA (actually three ISAs: traditional 32-bit ARM, Thumb, and Thumb2), and IIRC some manufacturers of ARM-based chips are already doing that.
If anyone actually has a serious need to use ancient 16 bit software, emulators like 86Box work very well. Software that old doesn’t really need performance faster than, say, a Pentium 90, which 86Box has no trouble achieving on my M1 (ARM) MacBook.
You can also use winevdm[1] on modern 64 bit Windows operating systems. I have this in production use for a niche case where someone can’t give up a particular 16 bit app, and I didn’t want to tangle with a VM for them.
The technical details of making sure a modern CPU still functions exactly like an 80386, which in turn made sure it functioned like an 80286, when you fire up a 16 bit task on, say, 32-bit Windows 10 (or 64-bit with something like winevdm[1]) sound like a nightmare for a microcode engineer or QA tester.
...and thus it didn't get used, meaning Intel didn't make it faster, and so the vicious cycle continued.
Hardware task switching could've made software simpler and more forward-compatible.
Of course they eventually reinvented most of it with the virtualisation extensions anyway.
During that time, Linux had a limit on the number of processes, which was due the maximum number of TSS entries that fit in the x86 GDT.
Eventually the Linux kernel was changed to the more versatile context-switch method it uses today. Among other things, this change was important for thread performance, as thread context switches can skip the TLB flush. Same for kernel mode tasks. Software task switching also greatly increased the number of processes and threads that can be launched, from about 8000 (across all CPU cores) to millions.
I'd argue the break started with the Pentium Pro, at that point things shifted architecturally.
Some CPUs (I cannot remember which) built in an A20 gate to their CPUs to improve performance.
The P6 was a complete implementation of the 80286 and 80386, Virtual 8086 mode, TSS, and all - you could boot DOS or an 80286 operating system on a P6 without any problems, although the design was not optimised to improve performance of 16-bit software. This was enough of a problem that they rolled back that design by the Celeron era because there were still a lot of people using 16-bit apps.
All of that is a tiny amount of die area relative to the whole CPU. After all, a 386 has only 275k transistors.
X86S is Stupid. Intel apparently forgot what made them worth choosing over competitors like ARM and now RISC-V. Non-compatible x86 makes little sense.
...and if they want to include the virtualisation extension, they still need to include that backwards-compatible functionality.
Notice that only 32bit kernel/R-0 is removed, but not usermode/R-3 so even when reducing this your 64bit Windows will still run clean 32bit software built for Win95 from the 90s.
Even today you need to run a virtualized 32bit OS to run old 16bit software (the negative part is if you still run a virtualized 32bit OS then it'll need to be emulated instead of HW virtualized if the virtualization solutions allowed that).
People (myself and others I know) choose ARM chips because they don't absolutely mandate the purchase of sanctioned chipsets/other supporting components you don't have access to, impossible-to-obtain specs, etc.
Everything seems to converge more and more toward RISC-V these days.
It seems like this is when you have the source or the libs but choose to mix x86 and arm?
It would seem if you have the source etc you should just bite the bullet and port everything.
* Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.)
* Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)
So if you're doing incremental stuff might as well stub out the calls with "not implemented", and start filling them in.
At least in theory, we'll see how it actually pans out in practice.
Wouldn't it make more sense to have a translator that translates the assembly, instead of an emulator that runs the machine code?
These sorts of things are only conceived in conversations between two huge corporations.
Like Microsoft needs game developers to build for ARM. There’s no market there. So their “people” author GPT-like content at each other, with a ratio of like 10 middlemen hours per 1 engineer hour, to agree to something that narratively fulfills a desire to build games for ARM. I can speculate endlessly how a conversation between MS and EA led to this exact standard but it’s meaningless, I mean both MS and EA do a ton of things that make no sense, and I can’t come up with nonsense answers.
Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Like the fucking devices are out! It’s too late for any of this to matter.
You can’t play Overwatch on a Snapdragon whatever (https://www.pcgamer.com/hardware/gaming-laptops/emulation-pr... ) End of story. Who cares what the ABI details are.
Microsoft OWNS Blizzard and couldn’t figure this out. Whom is this for?
Arm64EC is not new. It was released back in 2021.
So what should developers do re: Win10 users? Separate builds for them?
If you meant x86 win10 users you can use the win11 sdk to target them
In reality, yes, different builds, like it already happened with previous Windows versions.
The last build of win10 on arm supported x64 and many of us who do not want win11 still use it.
Snapdragon 835 is also horribly slow.
If not, is this not just another target architecture? You cannot use it on arm64 architectures, and your app already supports x86.