My progress in porting Wine

The WINE package is already in the repo, if that’s what you were waiting for. :slight_smile:

1 Like

I also made a simple launcher that allows to running *.exe files: WineLauncher. As final solution I plan to introduce add-on system to runtime_loader that allows to run PE executables directly and also show them correctly in process lists.

runtime_loader add-on system also can be used to run Haiku binaries on incompatible CPU (x86 binaries on RISC-V/ARM etc.). Add-on can load user mode CPU emulator and second instance of runtime_loader of target architecture inside virtual machine.


nice, so the reviews for the kernel changes are completed and merged with the nightlies I take it? Now I need to replace the VRMs in my designated haiku rig so I can get back into testing and software development.

That will be the icing on the cake, for sure.


Shouldn’t it also be possible to integrate winedvm at this point even and run really old stuff like Word 5.0 etc… ? Also I believe it uses emulation internally (optionally using acceleration) so it should be possible to get it to work quite easily.

It would be quite comical for Haiku to have better Windows application backwards compatibility than Windows.


I for one, wound find that very very amusing, and useful


I ran Word 5.0 on it on windows a while ago and was very surprised that it actually integrates with modern Office 365… so if you create a table in Word 5.0… the popup is from modern word and all the machinations in between (OLE & DCOM And such I think) to make that work between 16bit and 64bit actually functions amazingly.

1 Like

winedvm seems to be 32 bit only.

I have an idea how to run 32 bit Wine on 32 bit Haiku, but it will need modifying Haiku TLS offsets and potentially break compatibility.


Is there a way to encapsulate this on 64bit ? Haiku

The one @cb88 linked runs on 64-bit. And, once WINE finishes the PE conversion, 32-bit WINE should run on 64-bit OSes without 32-bit OS support, right?

Yes it seems. It may be also possible to build 32 bit secondary Haiku libs with modified TLS offsets.

I also found that it is easily possible to chain runtime_loader. I loaded second runtime_loader with dlopen(), started its entry point and successfully run payload applications. It should be possible to run Haiku applications on not matching CPU architecture by loading second runtime_loader into userland virtual machine and forward syscalls. I want to experiment with running riscv64 applications on x86_64 because it seems easy to implement.


Yep, I wasn’t aware of the wine PE conversion, but the Winedvm linked is specifically for 64bit systems.

I also get the feeling that many of the QEMU emulators aren’t very fast so there is room for alternative faster emulation runtimes… also not sure how this would interact with multithreading, there is some support for that in QEMU these days depending on the emulation target.

Keep up the good work all coders and testers!
I hope it will be ready for Beta 4, can’t wait.
I used BeOS i386 in the old days, and have followed Haiku a long time.
Now with own HW too, before in VirtualBox mostly.


Hi there,

I’ve install wine_bin on the latest nightly to give it a try.
Although I can run the included .exe applications (explorer, notepad), every external 64bit I’ve tried so far ends up in internal error starting from explorer.exe or from the terminal command wine64 /path to exe inside c_drive.
I’ve tried 64bit installers for filezilla and notepad+.
Am I missing something?

1 Like

No, installers are usually 32 bit even for 64 bit software.


@Roberto_Costa it’s possible to use Portable zip version of Notepad++.

@X512 I added new File Type for Windows app with .exe extensions associate to Winelauncher, but I fail to start app directly from tracker. Do i forget something ? update: i set the windows exe file to application/x-win32-pe and it can be started directly. Nice


How far are we from fixing this?

I made some successful experiments with 64-32 mode switching in UserlandVM. But TLS registers control need special kernel support with manipulating GDT/LDT entries.

For current Wine version running 32 bit host OS applications seems required, so UserlandVM x86 guest or old ia32 compat kernel patch shpuld be completed. Or wait until Wine itself implements full 64 bit support without host OS multilib.


Doesn’t it already for macos?

It use special LLVM Clang patches to generate 64-32 thunks that is rejected by mainstream Wine.