5 ms·

x86_64 Linux and x86_64 Mac

inshadows 6y ago
ELI5 please? If I one has Windows executable they would want to run it via this instead Wine, because ...? I couldn't quite grasp it from the README.
- sanxiyn 6y ago
  Because you want to run on non-x86 architectures. This is Wine + QEMU. (You can actually run x86 Wine on QEMU and it works, the improvement here is running Wine code native instead of with x86 emulation.)
  - skavi 6y ago
    What’s the point of the x86-64 Mac version when Wine Mac already exists?
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 ago
  Very cool.
- edoceo 6y ago
  Can you point us to it?
  - brian_herman 6y ago
    I believe this is what he is referring to https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
    - lunixbochs 6y ago
      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#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 ago
    I've found https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine with a google.
- specktr 6y ago
  Would love a link!
  - brian_herman 6y ago
    https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
- 1996 6y ago
  I would love to see an old version of Microsoft Office on a Pi
  - andylynch 6y ago
    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.
  - Jaruzel 6y ago
    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.
- marcthe12 6y ago
  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.
- marcodiego 6y ago
  I 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 ago
    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 https://github.com/ptitSeb/box86 which is more like the OP and does HLE.
- thehappypm 6y ago
  too much wine you get a hangover.
molticrystal 6y ago
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] [0] https://github.com/AndreRH/hangover/commit/73a88ff807e308862eaee7673d9a281e1c732b3c https://github.com/AndreRH/hangover/commit/73a88ff807e308862... [1] https://github.com/AndreRH/hangover/commit/c61a3a58be78e27175c0dab709dafffc3ed119b7 https://github.com/AndreRH/hangover/commit/c61a3a58be78e2717...

ELI5 please? If I one has Windows executable they would want to run it via this instead Wine, because ...? I couldn't quite grasp it from the README.

sanxiyn 6y ago
Because you want to run on non-x86 architectures. This is Wine + QEMU. (You can actually run x86 Wine on QEMU and it works, the improvement here is running Wine code native instead of with x86 emulation.)
- skavi 6y ago
  What’s the point of the x86-64 Mac version when Wine Mac already exists?

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 ago
Very cool.
edoceo 6y ago
Can you point us to it?
- brian_herman 6y ago
  I believe this is what he is referring to https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
  - lunixbochs 6y ago
    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#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 ago
  I've found https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine with a google.
specktr 6y ago
Would love a link!
- brian_herman 6y ago
  https://github.com/lunixbochs/wine https://github.com/lunixbochs/wine
1996 6y ago
I would love to see an old version of Microsoft Office on a Pi
- andylynch 6y ago
  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.
- Jaruzel 6y ago
  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.
marcthe12 6y ago
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.
marcodiego 6y ago
I 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 ago
  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 https://github.com/ptitSeb/box86 which is more like the OP and does HLE.
thehappypm 6y ago
too much wine you get a hangover.

molticrystal 6y ago

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] [0] https://github.com/AndreRH/hangover/commit/73a88ff807e308862eaee7673d9a281e1c732b3c https://github.com/AndreRH/hangover/commit/73a88ff807e308862... [1] https://github.com/AndreRH/hangover/commit/c61a3a58be78e27175c0dab709dafffc3ed119b7 https://github.com/AndreRH/hangover/commit/c61a3a58be78e2717...