I have on my GitHub what I think is a simpler variant of this.
I implemented a dual architecture wine, that runs the wineserver natively and has native EXEs available, but allows running x86 binaries.
It (mostly) doesn’t share any pointers between architectures so there’s no thunking at the windows layer. It’s basically a very small patch to wine to allow wine to handle multiple exe architectures at once, and a method of compiling both a native arch and Intel wine into the same prefix and picking between them when an exe is executed.
For performance I have a method for thunking alsa and OpenGL to native libraries at the Linux layer, as well as an ABI compatible desktop OpenGL implementation using ES as the backend.
The library thunking stuff wasn't included in any of the projects involved, so I couldn't upstream that. My glshim project was most of the work involved and is still around and still capable of proxying opengl through a usermode emulator, and rendering fixed function GL via GL ES or software rendering.
My performance changes to QEMU would definitely not have been accepted based on sentiment when talking to the QEMU core team at the time.
My changes to WINE were extremely minimal (read the commits) and don't make sense to live in WINE unless you mash together a dual arch WINE distribution in the exact same, manual, way I did, so they don't make much sense to upstream.
I've explored trying to run a circa 2008 windows server in something QEMU on a Pi, so I have keep my home Active Directory running, but not have the hungry power requirements of a larger server. After a lot of research I came to the conclusion that Win32 under QEMU on a Pi is just not feasible as even the Pi4 isn't fast enough.
Looks like you can persuade Windows 10 to run on a pi4, even if it’s not supported, so I guess there’s a decent chance even recent versions are runnable too.
In addition to that, see this thread on the Pandora forums, including this post where I released a hybrid arm QEMU WINE with OpenGL passthrough (the download still link works).
I haven’t looked at this project in years, but maybe run “file” on all the executables in the hybrid download if you want to see how I mixed x86 and arm wine binaries.
For the OpenGL thunking, I originally used a modified QEMU with a custom syscall to call functions directly in a native host library, but now my upstream glshim project uses a shared memory ring buffer approach for remote rendering that works anywhere shared memory mmap works.
I couldn't find the reason but Android development was discontinued a few months ago. It might be problems that the parent wine project is having on newer Android OS. I believe the stuff related to it was removed about 10 days ago [0], but not before one last bit of code related to building for android was added. [1]
I implemented a dual architecture wine, that runs the wineserver natively and has native EXEs available, but allows running x86 binaries.
It (mostly) doesn’t share any pointers between architectures so there’s no thunking at the windows layer. It’s basically a very small patch to wine to allow wine to handle multiple exe architectures at once, and a method of compiling both a native arch and Intel wine into the same prefix and picking between them when an exe is executed.
For performance I have a method for thunking alsa and OpenGL to native libraries at the Linux layer, as well as an ABI compatible desktop OpenGL implementation using ES as the backend.