Native arm64 macOS direction: low 4GB, x18, and layout work

[Alexey Rogatkin]

Hi,

I'm working on a research project around running Windows games on Apple
Silicon without Rosetta. It touches both translation layers needed for that:
DirectX-to-Metal on the graphics side, and a native macOS CPU-emulation backend
for x86-64 code in Wine. FEX already fills a similar role on ARM64 Linux, but
upstream FEX currently has no plans to support macOS:
https://github.com/FEX-Emu/FEX/discussions/3267

This brought me to the native arm64 macOS Wine runtime work, because that
backend needs Wine itself to run as an arm64 process. I currently have a small
local series on top of master that gets much further than stock Wine on Apple
Silicon: it fixes the host address-space limit probe with a Mach-based path,
moves Wine-owned low-address fixtures such as KUSER_SHARED_DATA and the initial
TEB block out of the mandatory 4GB __PAGEZERO, adjusts the loader flags needed
for native arm64 macOS, and handles the executable-protection issue for PE
image code. With that, native arm64 Wine boots a prefix and runs builtin PE
applications with winemac.drv.

Then I saw Alexandre's note on my GitLab account-verification issue saying
that Wine is working with Apple on the low 4GB space and the x18 register,
hopefully avoiding Wine-side workarounds. That's exactly the area my local
patches touch, so I tried to find the current plan before going further.

What I found publicly so far:

- Martin Storsjo's 2020 "[PATCH 0/4] macOS/arm64" series. The build fixes were
  merged, but the runtime issues described there (16KB pages, user_shared_data
  relocation, W^X) don't seem to have become an upstream runtime solution.
- Recent master has useful arm64/ARM64EC groundwork, but I couldn't find
  anything current for the native macOS low-4GB/x18 work.
- x18 seems to be handled differently on Linux; the Darwin side appears to be a
  separate platform problem.
- I couldn't find a current branch, merge request, or wine-devel thread tracking
  this. I may simply have missed it.

My questions are:

1. Is the native arm64 macOS work tracked somewhere public that I should follow,
   and if not, is there a good way for an outside contributor to get involved?
2. Which parts of this area are worth preparing as Wine merge requests now, and
   which are expected to be handled by Apple or by another upstream direction?
3. For x18 specifically, is Wine aiming for a durable Apple-provided mechanism,
   or should a Wine-side loader/toolchain accommodation be considered for now?
4. Does a small shared layout contract for Wine-owned fixed low addresses sound
   like a reasonable shape, or would maintainers prefer a different model?

I'm happy to send the local series as RFC patches, split or reshaped however is
most useful. I'd much rather align with Wine's architecture than carry private
platform plumbing.

For the record, I've worked only from public documentation, independent tests,
and public sources such as Wine, FEX-Emu, Apple's open-source XNU drops, and
Microsoft's public ARM64EC ABI documentation. I have not looked at Microsoft
Windows source code.

Best regards,
Alexey Rogatkin

[Brendan Shanks]

Hi Alexey,

Thanks for your enthusiasm and work on this, we have been working with Apple on these issues but unfortunately there isn’t much we can share right now. 

Something that is now public is the mechanism for handling x18. Apple has added a special “x18 custom ABI” mode that threads can switch into when running code that uses x18, and then switch out of when calling back into system frameworks. This was added publicly in macOS 26.5, take a look at <usr/include/os/arch/arm64.h> in a current SDK. Using this mode requires use of the com.apple.security.custom-x18-abi-toggle entitlement. I have a test app that exercises various parts of this API (which I’d like to clean up and post soon), and the xnu source tree also contains various tests around x18. I'm also working on using this API in Wine. 

Alternately, older versions of macOS (11/12) did not clear x18, and current versions of macOS continue to maintain that behavior for binaries built against those older SDKs. If you link with -Wl,-platform_version,macos,11.0,11.0, the kernel won’t touch x18.

You’ve clearly done a lot of work on this, and I apologize I don’t have more to share. We hope that situation will change soon.

Brendan
> On Jul 11, 2026, at 3:30 PM, Alexey Rogatkin via Wine-Devel <[e-mail]> wrote:
>
> Hi,
>
> I'm working on a research project around running Windows games on Apple
> Silicon without Rosetta. It touches both translation layers needed for that:
> DirectX-to-Metal on the graphics side, and a native macOS CPU-emulation backend
> for x86-64 code in Wine. FEX already fills a similar role on ARM64 Linux, but
> upstream FEX currently has no plans to support macOS:
> https://github.com/FEX-Emu/FEX/discussions/3267
>
> This brought me to the native arm64 macOS Wine runtime work, because that
> backend needs Wine itself to run as an arm64 process. I currently have a small
> local series on top of master that gets much further than stock Wine on Apple
> Silicon: it fixes the host address-space limit probe with a Mach-based path,
> moves Wine-owned low-address fixtures such as KUSER_SHARED_DATA and the initial
> TEB block out of the mandatory 4GB __PAGEZERO, adjusts the loader flags needed
> for native arm64 macOS, and handles the executable-protection issue for PE
> image code. With that, native arm64 Wine boots a prefix and runs builtin PE
> applications with winemac.drv.
>
> Then I saw Alexandre's note on my GitLab account-verification issue saying
> that Wine is working with Apple on the low 4GB space and the x18 register,
> hopefully avoiding Wine-side workarounds. That's exactly the area my local
> patches touch, so I tried to find the current plan before going further.
>
> What I found publicly so far:
>
> - Martin Storsjo's 2020 "[PATCH 0/4] macOS/arm64" series. The build fixes were
>  merged, but the runtime issues described there (16KB pages, user_shared_data
>  relocation, W^X) don't seem to have become an upstream runtime solution.
> - Recent master has useful arm64/ARM64EC groundwork, but I couldn't find
>  anything current for the native macOS low-4GB/x18 work.
> - x18 seems to be handled differently on Linux; the Darwin side appears to be a
>  separate platform problem.
> - I couldn't find a current branch, merge request, or wine-devel thread tracking
>  this. I may simply have missed it.
>
> My questions are:
>
> 1. Is the native arm64 macOS work tracked somewhere public that I should follow,
>   and if not, is there a good way for an outside contributor to get involved?
> 2. Which parts of this area are worth preparing as Wine merge requests now, and
>   which are expected to be handled by Apple or by another upstream direction?
> 3. For x18 specifically, is Wine aiming for a durable Apple-provided mechanism,
>   or should a Wine-side loader/toolchain accommodation be considered for now?
> 4. Does a small shared layout contract for Wine-owned fixed low addresses sound
>   like a reasonable shape, or would maintainers prefer a different model?
>
> I'm happy to send the local series as RFC patches, split or reshaped however is
> most useful. I'd much rather align with Wine's architecture than carry private
> platform plumbing.
>
> For the record, I've worked only from public documentation, independent tests,
> and public sources such as Wine, FEX-Emu, Apple's open-source XNU drops, and
> Microsoft's public ARM64EC ABI documentation. I have not looked at Microsoft
> Windows source code.
>
> Best regards,
> Alexey Rogatkin

Hi Brendan,

Thanks a lot for the quick and substantive reply — this is more than I
expected to learn.

Good to have the x18 approach confirmed: that's exactly how I ended up
solving it — my loader is linked with -Wl,-platform_version,macos,11.0,12.3
after tracing the behavior to machine_task_process_signature() in the
published xnu sources. The new per-thread "x18 custom ABI" mode in macOS
26.5 with a public com.apple.security.* entitlement is great news — a
durable public mechanism was exactly the piece I considered missing. I'll
study <os/arch/arm64.h> and the xnu tests; looking forward to your test app
and the Wine-side integration.

Given that, I'll hold off pushing my current changes for now and keep
running on my own tree — it already unblocks the parts I need for my
project. If the situation changes — the Apple work becomes public or the
x18 API lands in Wine — I'd appreciate a ping; on my side I'll be following
your activity as well.

Thanks again,
Alexey