CrossOver not working

[memegauste]

CPU: r5 3600
macOS version: 10.15.4
15h/16h or 17h: 17h
I am using and can reproduce on the latest patches: yes, using newest kexts from Acidanthera and OpenCore

Describe the bug
CrossOver is not working on Catalina, but I don't quite understand why, since OPEMU is deprecated in Catalina. From far what I know CrossOver is using com.apple.security.ldt-in-64bit-process function to work properly, according to this:
https://twitter.com/comex/status/1204919560010223618

Not sure if that's an bug, support request, and where bugfix should be implemented.

Screenshots

[memegauste]

I tried to run Wine taskmgr, and it starts, but it's crashing after 2-3 seconds:

Maybe this is fixable and not releated to OPEMU and so on? Anybody want to help?

[dhinakg]

From that link:

Impressive achievement. They have a special entitlement com.apple.security.ldt-in-64bit-process letting them run 32-bit code

I am not a developer, so I'm not 100% sure on this, but 0 32-bit code works on AMD because of (missing) OPEMU, so this is why CrossOver does not work.

[memegauste]

So I tried to run NosTale (old game which I was playing in the 2015) or use built-in wine that is located under CrossOver, with results like this:

Seems that wine64 and wineboot can't run. For interesing reason, when I use computer whole day the address in NosTale stack overflow error should change, and it's not, so I am interested in this value:
0x1007:0x7bcb125f

From that link:

Impressive achievement. They have a special entitlement com.apple.security.ldt-in-64bit-process letting them run 32-bit code

I am not a developer, so I'm not 100% sure on this, but 0 32-bit code works on AMD because of (missing) OPEMU, so this is why CrossOver does not work.

Yeah, but is com.apple.security.ldt-in-64bit-process releated to OPEMU, or it's something outside it? I could go deep into XNU kernel sources, but I'm somehow tired today. That's all info I collected.

EDIT: Disabling SIP does not help either.

[im-not-a-dev]

Impressive achievement. They have a special entitlement http://com.apple.security.ldt-in-64bit-process letting them run 32-bit code, but they still need to rely on 64-bit system libs.

You cannot run 32-bit code on AMD systems. It indeed has to do with OPEMU or rather the lack thereof.

[stefand]

Wine/CodeWeavers dev here. A guy on our IRC channel brought my attention to this bug. I am currently waiting for a compile to finish so I am dropping a few quick notes. I'm afraid I can't spend a lot of time though because we don't support hackintoshes.

For some technical detail see https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html . The 32 bit execution magic works by creating 32 bit LDT entries via i386_set_ldt. That's what the special permission is needed for, although it seems 10.15.4 removed that requirement. The other way around the permission is to disable system integrity protection.

LDT entries aren't CPU specific (unlike HW Hypervisors, and the Apple hypervisor API that is very intel specific), so in theory this should work. If I understand the screenshots right and taskmgr is at least starting up, and if that cmd is running in 32 bit code, the important thing is working.

What is probably a problem is system calls and signal delivery to a process/thread that currently has %cs pointing to a 32 bit code segment. If you have some custom kernel modifications or modules that's the first place to look.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

[stefand]

Ah yes, the CrossOver 19 source code, or at least the Wine parts, are available at https://www.codeweavers.com/products/more-information/source. I believe the modifications we made to Clang to handle 32 bit pointer sizes in 64 bit environments are also in there. At very least I don't think we're deliberately keeping them secret, it's just a really messy piece of code. Upstream Wine doesn't want it as is, the plan there is to eventually work without a magic compiler.

[KenThomases]

Another Wine/CodeWeavers dev here. :)

CrossOver is still running 32-bit code directly on the CPU. It is not emulating or translating that code to 64-bit. If I understand the purpose of OPEMU correctly, it's for emulating certain Intel-only instructions that AMD CPUs don't support natively in 32-bit mode. So, IOIIIO is correct, the lack of OPEMU will prevent CrossOver from running 32-bit Windows programs. The fact that it ran some to a certain extent might simply be because they didn't attempt to execute one of the instructions that require emulation until relatively late in the run.

I would expect that the same would be true on Mojave and earlier using this project. So, it's not directly related to our 32-on-64-bit support.

The reason why OPEMU is deprecated with Catalina is because one is not expected to run any 32-bit code on Catalina, so it shouldn't be necessary. Well, surprise! It is necessary for CrossOver's 32-on-64-bit support because we are running 32-bit code.

[JoelNichols]

To add on to this, whilst OPEMU is deprecated with Catalina for the purpose of hackintoshing, it still genuinely may be useful for some 64-bit apps that require Intel-specific instructions to be present, i.e. Adobe, REAPER, etc.

[palxex]

Doubt that what crossover19 needs is OPEMU.

0. background information: https://wiki.osdev.org/SYSENTER
1. AMD CPU does not totally unable to run ANY 32bit code in previous kernel-patched macOS. Then why when opening wine/32bit app on kernels that without OPEMU, we got illegal instrument error? That's because AMD lacks sysenter/sysexit in 64-bit compatible mode, only the two instrument which commonly used for implementing syscall in 32bit OS, any other i386 instrument working natively, at least on zen2. To verify it, just install 10.13.6 with IOIIIO's guide, then compile Shaneee's High Sierra Kernel with this minimal OPEMU patch which I've commented all other instruments emulation besides sysenter/sysexit, you'll still get wine/32bit macOS app running, but if you comment opemu_sysenter call which emulates sysenter/sysexit , you'll get illegal instruments.
2. All OPEMU implementations( that I've seen 😄 ) modifies kernel_trap and user_trap, wait CPU throw invalid opcode exception and then handling it. Though no patched Catalina kernel found, but there is another way: dynamic hooking. There was a OpcodeEmulator, which is a Lilu plugin( so can be loaded on both 10.13 and 10.15), source code was found at available on GitHub. I've verified that it could work on High Sierra, make wine/32bit macOS app work with kernel opemu turnes off; BUT, it does not work on Catalina. After some modification, I successful making it works on Catalina (by modify max version), then I adds some logging, after that ( AND turn to FakeSMC since this plugin hooks kernel_trap which conflicts VirtualSMC ), the reason was finally found: when running wine32on64, no ANY invalid opcode exception even CATCHED ( but page fault exception often be watched, which tells that hooks working ) . That should means: 1. in Catalina, since no 32bit syscall exist, sysenter/sysexit was totally replaced by syscall/sysret, which already handles well on AMD CPU; 2. wine32on64 does not uses any other instrument that AMD not supported, or at least invalid opcode exception should be watched.

I think a conclusion can be deduced from all above: what blocks crossover19 from running on Catalina is NOT simply lacking of OPEMU. Though I also don't know what it actually IS, yet : )

[memegauste]

Doubt that what crossover19 needs is OPEMU.

1. background information: https://wiki.osdev.org/SYSENTER
2. AMD CPU does not totally unable to run ANY 32bit code in previous kernel-patched macOS. Then why when opening wine/32bit app on kernels that without OPEMU, we got illegal instrument error? That's because AMD lacks sysenter/sysexit in 64-bit compatible mode, only the two instrument which commonly used for implementing syscall in 32bit OS, any other i386 instrument working natively, at least on zen2. To verify it, just install 10.13.6 with IOIIIO's guide, then compile Shaneee's High Sierra Kernel with this minimal OPEMU patch which I've commented all other instruments emulation besides sysenter/sysexit, you'll still get wine/32bit macOS app running, but if you comment opemu_sysenter call which emulates sysenter/sysexit , you'll get illegal instruments.
3. All OPEMU implementations( that I've seen smile ) modifies kernel_trap and user_trap, wait CPU throw invalid opcode exception and then handling it. Though no patched Catalina kernel found, but there is another way: dynamic hooking. There was a OpcodeEmulator, which is a Lilu plugin( so can be loaded on both 10.13 and 10.15), source code was found at available on GitHub. I've verified that it could work on High Sierra, make wine/32bit macOS app work with kernel opemu turnes off; BUT, it does not work on Catalina. After some modification, I successful making it works on Catalina (by modify max version), then I adds some logging, after that ( AND turn to FakeSMC since this plugin hooks kernel_trap which conflicts VirtualSMC ), the reason was finally found: when running wine32on64, no ANY invalid opcode exception even CATCHED ( but page fault exception often be watched, which tells that hooks working ) . That should means: 1. in Catalina, since no 32bit syscall exist, sysenter/sysexit was totally replaced by syscall/sysret, which already handles well on AMD CPU; 2. wine32on64 does not uses any other instrument that AMD not supported, or at least invalid opcode exception should be watched.

I think a conclusion can be deduced from all above: what blocks crossover19 from running on Catalina is NOT simply lacking of OPEMU. Though I also don't know what it actually IS, yet : )

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

[memegauste]

I can confirm CrossOver 20 beta1 doesn't work on Ryzentosh, either using Windows 10, 7 or XP 32-bit bootle.
Windows 10 x64 bootle though works normally.

[palxex]

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

Sorry for the late reply, but I cannot. Not owe a copy :( Using build here, so need waiting new open source releases.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

@stefand Could you please give a simple code example? That will helps greatly! Thanks in advance.

[memegauste]

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

Sorry for the late reply, but I cannot. Not owe a copy :( Using build here, so need waiting new open source releases.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

Could you please give a simple code example? That will helps greatly! Thanks in advance.

You can test Crossover 20 by downloading it from beta section on CodeWeavers site (there was no official release so far).
https://www.codeweavers.com/compatibility/beta