TL;DR: workaround at step 3 below. The root cause seems to be in Windows' Prism emulator, not
Parallels; posting so others with Delphi/x87 apps can find it.
Environment
- Mac16,10 (Apple Silicon), Parallels Desktop 27.0.3 (58680)
- Guest: Windows 11 ARM64 25H2, build 10.0.26200.9711
- App: 32-bit x86 EXE (Delphi 13, Win32) running under Windows' Prism x86 emulation
Problem
32-bit x86 apps get only 53-bit precision on x87 instead of 80-bit. A 64-bit integer loaded with
"fild qword" is rounded, so code that relies on it returns wrong values. Delphi's Win32 compiler
converts UInt64 to Double this way, so UInt64(5) -> Double gives 0. Real-world effect: the
JsonDataObjects library reads -3.5 as -3, 47.5 as 47 and 1234567890.5 as 1234568192.
The same EXE (same sha256) passes all 138 tests on a real Intel PC (Windows 10 22H2) and fails
19 per x87 mode in the VM. Win64 builds are not affected (they use SSE, not x87).
What I tried in the guest
1. Properties > Compatibility > Change emulation settings > "Disable floating point optimization":
saved (HKCU AppCompatFlags\Layers = "~ ARM64ENABLESTRONGFLOAT") and applied to the process, but
NO effect. wow64.dll still loads xtajit.dll, which has no StrongFloat support.
All other presets and options (Safe, Strict, Very strict, disable hybrid, disable cache) also
had no effect.
2. Global HKLM\SOFTWARE\Microsoft\Wow64\x86 (Default) = xtajitf.dll: every x86 process crashes
at start (0xC0000005) and WerFault loops (768 processes). Do NOT do this. Reverted.
3. Working workaround, per EXE (admin needed for the HKLM value):
- HKLM\SOFTWARE\Microsoft\Wow64\x86\<app.exe> = "xtajitf.dll" (REG_SZ, just the file name)
- HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\<full path to exe>
= "~ ARM64ENABLESTRONGFLOAT ARM64CHPEDISABLED"
- EXE on a local disk (see below)
With this, results match real x86 exactly. All three parts are needed: without CHPEDISABLED
xtajitf.dll crashes; without StrongFloat it still rounds.
Parallels-specific observation
AppCompat compatibility layers are NOT applied to EXEs run from the Parallels shared folder
(\\Mac\Home mapped as Z
. The same EXE copied to C:\ gets the layers. Is this expected?
Questions for the community
- Has anyone else seen x87 precision issues with 32-bit x86 apps on Windows 11 ARM guests
(26100/26200 builds)?
- Has "Disable floating point optimization" worked for anyone with a 32-bit app? It looks like
wow64.dll only switches to xtajitf.dll through the per-EXE registry value above.
- Can anyone confirm that compatibility layers are ignored for EXEs on the shared folder?
I’m reporting the Windows part through Feedback Hub. Happy to share the minimal test EXE and
per-configuration results if it helps anyone reproduce it.
Parallels; posting so others with Delphi/x87 apps can find it.
Environment
- Mac16,10 (Apple Silicon), Parallels Desktop 27.0.3 (58680)
- Guest: Windows 11 ARM64 25H2, build 10.0.26200.9711
- App: 32-bit x86 EXE (Delphi 13, Win32) running under Windows' Prism x86 emulation
Problem
32-bit x86 apps get only 53-bit precision on x87 instead of 80-bit. A 64-bit integer loaded with
"fild qword" is rounded, so code that relies on it returns wrong values. Delphi's Win32 compiler
converts UInt64 to Double this way, so UInt64(5) -> Double gives 0. Real-world effect: the
JsonDataObjects library reads -3.5 as -3, 47.5 as 47 and 1234567890.5 as 1234568192.
The same EXE (same sha256) passes all 138 tests on a real Intel PC (Windows 10 22H2) and fails
19 per x87 mode in the VM. Win64 builds are not affected (they use SSE, not x87).
What I tried in the guest
1. Properties > Compatibility > Change emulation settings > "Disable floating point optimization":
saved (HKCU AppCompatFlags\Layers = "~ ARM64ENABLESTRONGFLOAT") and applied to the process, but
NO effect. wow64.dll still loads xtajit.dll, which has no StrongFloat support.
All other presets and options (Safe, Strict, Very strict, disable hybrid, disable cache) also
had no effect.
2. Global HKLM\SOFTWARE\Microsoft\Wow64\x86 (Default) = xtajitf.dll: every x86 process crashes
at start (0xC0000005) and WerFault loops (768 processes). Do NOT do this. Reverted.
3. Working workaround, per EXE (admin needed for the HKLM value):
- HKLM\SOFTWARE\Microsoft\Wow64\x86\<app.exe> = "xtajitf.dll" (REG_SZ, just the file name)
- HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\<full path to exe>
= "~ ARM64ENABLESTRONGFLOAT ARM64CHPEDISABLED"
- EXE on a local disk (see below)
With this, results match real x86 exactly. All three parts are needed: without CHPEDISABLED
xtajitf.dll crashes; without StrongFloat it still rounds.
Parallels-specific observation
AppCompat compatibility layers are NOT applied to EXEs run from the Parallels shared folder
(\\Mac\Home mapped as Z
. The same EXE copied to C:\ gets the layers. Is this expected?Questions for the community
- Has anyone else seen x87 precision issues with 32-bit x86 apps on Windows 11 ARM guests
(26100/26200 builds)?
- Has "Disable floating point optimization" worked for anyone with a 32-bit app? It looks like
wow64.dll only switches to xtajitf.dll through the per-EXE registry value above.
- Can anyone confirm that compatibility layers are ignored for EXEs on the shared folder?
I’m reporting the Windows part through Feedback Hub. Happy to share the minimal test EXE and
per-configuration results if it helps anyone reproduce it.