4 ms·
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 av
by lunixbochs 6y ago
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.
- qwerty456127 6y agoVery cool.
- edoceo 6y agoCan you point us to it?
- brian_herman 6y agoI believe this is what he is referring to https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
- lunixbochs 6y agoIn 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). https://pyra-handheld.com/boards/threads/wine.72133/page-6#post-1236760 https://pyra-handheld.com/boards/threads/wine.72133/page-6#p... 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.
- gdsfahgadsfgad 6y agoI've found https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine with a google.
- specktr 6y agoWould love a link!
- brian_herman 6y agohttps://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
- 1996 6y agoI would love to see an old version of Microsoft Office on a Pi
- andylynch 6y agoLooks 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.
- Jaruzel 6y agoI'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.
- marcthe12 6y agoCould you explain me the details. Could this be upstreamed. I am looking a way to reduce 32 bit deps of 64 bit systems for stuff like wine.
- marcodiego 6y agoI am impressed:https://www.youtube.com/embed/mh4-Zz1uWaQ?feature=oembed https://www.youtube.com/embed/mh4-Zz1uWaQ?feature=oembed It was 7 years ago... why didn't you try to upstream it?
- lunixbochs 6y agoUpstream which part exactly? 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. A sort of spiritual successor to my work here is https://github.com/ptitSeb/box86 https://github.com/ptitSeb/box86 which is more like the OP and does HLE.
- thehappypm 6y agotoo much wine you get a hangover.