My progress in porting Wine

I thought we have PosatgreeSQL?

seem you mean postgresql

100 points for the candidate…

1 Like

Wine makes these windows apps look surprisingly native, I expected them to look vastly more foreign.


Wine 7.4.



consider me thoroughly impressed with all this progress. are you some kind of programming grand master wizard? :hushed:


A lot of the work needed to get WINE on Haiku was done over the past few years (e.g. PulkoMandy’s changes for WebKit’s JITs to stop crashing all the time), and X512 has just done the “last few bits” (some of which were quite necessary, of course) and then written a Haiku platform driver for WINE.

He also provided some nice testcases for the Haiku bugs he uncovered while working on the port that impeded it, including one rather bad one in our virtual memory manager which I fixed last week. So, like all things, it’s a team effort :slight_smile:


Naturally, the whole Haiku team has me thoroughly impressed with the OS design from the ground up, as soon as a stable accelerated graphics driver and wine package hit the repo I will probably drop linux and windows wholesale. As a programmer I know what its like to try and plug on someone elses code, wasnt expecting to see an accelerated driver plus a wine port, from the same dev no less, and then seeing X11 decoupled so quickly as a wine dependency was over the top, every other time i’ve seen wine on a non linux platform it was also with X tacked on.


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.