Hacker News Reader

Comment by lunixbochs | Hacker News Reader

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.

View on HN

I am impressed:https://www.youtube.com/embed/mh4-Zz1uWaQ?feature=oembed

It was 7 years ago... why didn't you try to upstream it?

Upstream 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 which is more like the OP and does HLE.

Could 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.

I would love to see an old version of Microsoft Office on a Pi

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.

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.

Can you point us to it?

I believe this is what he is referring to https://github.com/lunixbochs/wine

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).

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.

Would love a link!

https://github.com/lunixbochs/wine

Very cool.

too much wine you get a hangover.

Reply on news.ycombinator.com