box64 behavior after execv(wine) on x86_64 vs ARM64

[parkjunhyung2021046762]

Hi,
I'm currently running box64 + wine on an x86_64 native machine (AMD Ryzen 5), and I've been tracing the execution flow.
From what I observed, the flow looks like this:
box64 emulates wine launcher (64-bit ELF)
↓ wine calls execv → wine-preloader
box64 is gone after this point
↓
wine-preloader runs natively (no box64 involvement)
↓
wine main process + ntdll/kernel32 loaded (all native x86_64)
↓
hello.exe runs → "Hello!" printed

My understanding is:

1. On x86_64, once wine calls execv to launch wine-preloader, the kernel runs it natively without involving box64 again — because the machine can already execute x86_64 binaries directly.
2. Therefore, after execv, box64 completely disappears from the process and never comes back.
3. On ARM64, every execve of an x86_64 binary would automatically re-invoke box64, so the flow would be box64 ↔ wine repeating throughout the entire execution.

My questions:

1. Is this understanding correct? On x86_64, does box64 only participate in the very first step, and then wine runs natively after execv?
2. Is there any mechanism in box64 that re-attaches or re-invokes itself after execv on x86_64?
3. On ARM64, does box64 stay involved throughout the entire execution (including wine-preloader, wineserver, the actual PE binary, etc.)?

I'm trying to build a continuous execution tracer that covers the full flow from box64 → exec → wine → PE entry point, and I want to make sure I understand the architecture correctly before deciding between a box64-level hook vs. a ptrace-based external tracer.
Thank you!

[ptitSeb]

Hi, I'm currently running box64 + wine on an x86_64 native machine (AMD Ryzen 5), and I've been tracing the execution flow. From what I observed, the flow looks like this: box64 emulates wine launcher (64-bit ELF) ↓ wine calls execv → wine-preloader box64 is gone after this point ↓ wine-preloader runs natively (no box64 involvement) ↓ wine main process + ntdll/kernel32 loaded (all native x86_64) ↓ hello.exe runs → "Hello!" printed

My understanding is:

1. On x86_64, once wine calls execv to launch wine-preloader, the kernel runs it natively without involving box64 again — because the machine can already execute x86_64 binaries directly.
2. Therefore, after execv, box64 completely disappears from the process and never comes back.
3. On ARM64, every execve of an x86_64 binary would automatically re-invoke box64, so the flow would be box64 ↔ wine repeating throughout the entire execution.

My questions:

1. Is this understanding correct? On x86_64, does box64 only participate in the very first step, and then wine runs natively after execv?
2. Is there any mechanism in box64 that re-attaches or re-invokes itself after execv on x86_64?
3. On ARM64, does box64 stay involved throughout the entire execution (including wine-preloader, wineserver, the actual PE binary, etc.)?

I'm trying to build a continuous execution tracer that covers the full flow from box64 → exec → wine → PE entry point, and I want to make sure I understand the architecture correctly before deciding between a box64-level hook vs. a ptrace-based external tracer. Thank you!

I should not work like that.

execv will check if the target program is an x86_64 (or x86), and if that's the case, it will use box64 (or box86) to run to program.
Also wine-preloader is detected by box64 and will skip it, loading wine directly. This mecanism is independant of the native architecture.

[parkjunhyung2021046762]

If my host machine is x86_64, but I run an Ubuntu VM and then run box64 + Wine inside that VM, does that mean the execution will continuously go back and forth between box64 and Wine (i.e., box64 being re-invoked on every exec of x86_64 binaries)?

[ptitSeb]

Wine should work from box64 itself in that case, it should be emulated by box64.

[parkjunhyung2021046762]

“So does that mean if I run box64 + Wine on an x86_64 architecture (not ARM), the execution model is the same as when running it on ARM?”

[ptitSeb]

Yes.
The notable difference will be that on x86_64, there is no dynarec, so it will run on interpreter only, so much slower than on arm64 were the dynarec can be used.