Yeah I've seen that Wine has ARM support, so it sure makes sense to see it on Apple M1... However, Wine as of late, has gotten a lot of regressions that don't seem to get properly addressed anymore and I don't know what to think.

Case in point: There are a lot of RtlpWaitForCriticalSection deadlocks that never used to happen... stretching all the way back to when I was stuck on Wine 1.8 on a Linux Mint install I could never successfully dist-upgrade...

Because where it stands, Wine is completely useless to me now and I have to basically VM Windows XP at this point.

I literally cannot finish a single sitting (as in, without saving or loading once, without stopping or closing the game itself) Unreal 1 playthrough without it eventually getting stuck endlessly on "RtlpWaitForCriticalSection" with apparently no failsafe method of forcing a break out of said deadlock. (Why even bother printing "retrying 60 secs" if you're not going to just forcefully ignore the lock?)

Oh, and there's plenty of bogus "out of memory" errors because apparently the VIRT usage is broken now too, fantastic. I can't even play Oblivion stock without running into a bogus "out of memory" error in wined3d now. 64-bit programs have no issues though. (Gee, I wonder if this is going to be a recurring trend these days)

I don't want to get involved with the Wine bugtracker because I do not have a system I can use to constantly compile, git-bisect Wine ad nausem to the point of discovering the actual regression at hand. Even then, I'm not a C/C++ x86 assembly programmer so I wouldn't even understand what I'm even doing trying to provide all this info to the bug tracker.

Jo22 wrote on 2021-06-08, 14:47:

It's apparently now possible to run Win64 applications on macOS 11.6 and up (M1 is an ARM64 derivative).

To be more precise, I think it is Wine64 support for AArch64. That is, if one had only Win64 AArch64 applications, then Wine64 could run the applications on macOS/Linux AArch64. It doesn't magically make win32/win64 x86/x86_64 Windows applications run on macOS/Linux for non-x86 architecture.

In reality, AArch64, regardless of Windows/Linux/macOS, does not have that much of software legacy baggage to begin with.

It is in Apple's advantage to bridge macOS and IOS to unify the software ecosystem.
It is in Google's advantage to bridge ChromeOS and Android to unify the software ecosystem.
Linux does not seem to care.
Microsoft has nothing to bridge due to their failure in mobile strategy, but they can make Windows 10 ARM run both Android & IOS applications 😁

DracoNihil wrote on 2021-06-08, 17:28:

Case in point: There are a lot of RtlpWaitForCriticalSection deadlocks that never used to happen... stretching all the way back to when I was stuck on Wine 1.8 on a Linux Mint install I could never successfully dist-upgrade...

Have you checked if disabling "CSMT" would fix your issue? You can also check with single-CPU Linux VM.

I'm definitely in the DON'T CARE crowd. As long as I can get stuff done on the systems I've got I'm happy 😉.

DracoNihil wrote on 2021-06-08, 17:28:

Case in point: There are a lot of RtlpWaitForCriticalSection deadlocks that never used to happen... stretching all the way back to when I was stuck on Wine 1.8 on a Linux Mint install I could never successfully dist-upgrade...
.

Isn't that a rather old version of Wine? Hmmm 2015. What version of Linux Mint was it?

As long as /home is on a separate partition you can just do an fresh installation of the new version without loosing your settings or files. I found that out when I just learning about LInux,20 years ago as I'd never heard of it until then, that was a lot quicker than doing a dist-upgrade. Sometimes after doing one there seemed to be have a number of issues. Things may have improved since then.

Of course you just could have uninstalled Wine, did the upgrade then reinstall Wine couldn't you. But I am not a Computer Tech.

Caluser2000 wrote on 2021-06-08, 19:52:

Isn't that a rather old version of Wine? Hmmm 2015. What version of Linux Mint was it?

Rosa. And yes it was a pretty old version of Wine, it even ran UnrealEd 1.x better than Wine even cares to now even with all the required VisualBasic native overrides.

The only thing I noticed with Wine 6.x is that wine-mono can now run a old terrain editor I need to use to make terrain brushes for my Unreal maps, before it'd just always error out.

kjliew wrote on 2021-06-08, 18:36:

Have you checked if disabling "CSMT" would fix your issue? You can also check with single-CPU Linux VM.

I didn't think "CSMT" could be disabled anymore, a lot of the supposed registry keys in Wine don't actually do anything anymore, but I'd try it though isn't "CSMT" for wined3d? I'm using OpenGL in Unreal. (yes OpenGL in 224, 225, etc will work as long as you MESA_GL_VERSION_OVERRIDE=1.2 MESA_EXTENSION_MAX_YEAR=1998 beforehand)

"CSMT" is for WineD3D or DDRAW with GL backend. Even though you used Unreal OpenGL renderer, the driver also invoked DirectDrawCreate. You can also fallback to GDI backend for DDRAW and that should completely take out "CSMT". GDI backend for DDRAW was deprecated long ago. So if it has any bugs, it will likely never be fixed. Wine GDI32 implementation wasn't that great either.

I also set UseDirectDraw to false in Unreal.ini as well, but I still don't think it's a rendering path critical section deadlock, it literally happens as a result of loading and garbage collection can trigger it too.