My progress in porting Wine

What a timely comment. Happy New Year! :tada:


Hangover emulates a CPU and would be way overkill for this use-case (it might be a solution for Wine on Haiku RISC-V though). I didn’t know that the macOS x64 port of Wine used it.


The alternative would be to include an entire set of 32-bit libraries on 64-bit Haiku and make Haiku capable of utilizing that, which would not be preferable (I think).

Implementing Hangover will also allow running x86 Windows software on RISC-V (and ARM eventually).

I think Hangover is the best way way to go.


WoW64 Wine on amd64 macos still uses the 32 bit mode of the processor

This is beeing worked on sometimes already, it would also be needed for beos compat on amd64.
Personally I don’t see much of a point to use a port that uses cpu emulation, one could just use qemu the (and wine without wine32 is pretty useless in practise)


What are the security implications of this by the way? Doesn’t it mean that Windows *ware could compromise user data?

1 Like

Yeah, Windows applications can compromise user data. Just like Haiku applications can.


In theory encrypting ramsonware can encrypt your home directory (it is mapped to user directory in Wine).


Isn’t it possible to have sandboxing in Wine?

As far as I know using “winecfg” you can uncheck the linking of home directory to windows user directory. This way damage can only be done to the wine user directory but not home directory in general. Not sure though if wine still allows accessing host file system without those links.

Wine maps / to a windows disk by default. Even if it doesn’t however it does allow executing native applications from windows applications which can see the host filesystem normally, don’t expect any inherent security by unchecking those links.

edit: you would probably want to employ some OS isolation like a chroot, but that would have to be carefully checked also (on linux you can break out easily, on openbsd not so much, and even then you can still send BMessages to running servers and get them to do potentially destructive stuff)

1 Like

Wine doesn’t prevent programs from making system calls, so you can hardly rely on sandboxing MS-Windows programs by relying on Wine alone.


Impressive progress from @X512 and @waddlesplash .





I like and use Notepad++ on Windows…
But Koder is as good to use for my needs…


Do you manage to get my favourite Markdown editor Typora running and Darktable for RAW photo editing?

It looks really nice indeed for being emulated software. I prefer the look over QT applications, which usually looks quite “linuxy”.

A little off topic, but i like the look of old System 7-9, Windows 2000 and Haiku (Haiku looks way better than BeOS, more polished). Modern UI not so much, with the exception of Mac OS 10.6 up to about 10.9.

Keep up the good work!

1 Like

so now firefox and chrome will work long before firefox and chrome port? :joy:


I gave a quick look to your changes and I would like to suggest a small trick to simplify things.

The preprocessor of GNU tools and CLang provide a keyword called #include_next.
Sometimes its usage is not recommended, but here it could be useful.
The purpose of this keyword is to include the next file with the same name into the current search order.
For doing a simple example, you patched few files with something like this:

+#ifdef __HAIKU__

Since this change makes me suspect that SIGIO is undefined into the system headers of HAIKU, you can create a directory and call it for example haiku_wine_utils.
Inside this directory, create an include directory and then a sys directory inside include.
Finally, inside the haiku_wine_utils/include/sys, create a file called signal.h with a content like this:


#include_next <sys/signal.h>



Now, when you configure WINE, you can add to CFLAGS the path to the tree that you just created with an option like -I~/haiku_wine_utils/include (obviously, the right path must be used here).

That’s all.
Now, every time the sources will be compiled, the first sys/signal.h to be included will be the one that you just created, which will call the system header as first task, thanks to #include_next keyword. Then, it will provide the definition of SIGIO that will be needed by the sources of the framework.

The same trick can be used for emulating other macros that you wrapped with some #ifdef...#endif, like ESOCKTNOSUPPORT/CS6/CS7/CS8/etc…

This could allow to simplify the number of changes and perhaps, if some fixes will be accepted into the codebase of WINE but others not, it can allow to create a package “haiku_wine_utils” that provides some utilities and sources to be used at compile time and without touching the main core of WINE.

You could also “patch” the library functions actually. If you want to “adjust” the behaviour of ioctl() function, you may add another file like this one:


#include_next <sys/ioctl.h>

int haiku_utils_ioctl(int __fd, int __cmd, ...);

#undef ioctl
#define ioctl haiku_utils_ioctl


And, inside a sources that is compiled and added to LDFLAGS of WINE at configure time, you can handle some extra commands not handled by current implementation.

I don’t know how many changes will need WINE to be fully supported on HAIKU.
Perhaps, the number of fixes won’t be so huge.
However, WINE is a software constantly evolving and every time a new version will be released, then an updated patch will need to be prepared, kept up to date and this is a job that somebody will need to do.
Instead, the “utils” will make you free from doing this.

What do you think?



Remember that Wine is not an emulator… it’s an implementation of the Windows API for other OS’s so if we could run Firefox for Windows on Wine, it would run natively. There’s no shame in running software through Wine.

An actual port to Haiku would be preferable but if this allows me to run Inkscape on Haiku, then I’ve got all but two of my necessary applications on Haiku… the last two being OpenVPN and actual virtualized VM’s through Qemu or Virtualbox.

I’m getting my new workstation on Thursday and the first thing I want to try is to run Haiku on it. The prospect of having a near complete workstation experience on Haiku is amazing. Thanks for all the hard work!


If games through wine were to take off on Haiku (which I just learned about the other day through Hacker News) I would be so excited. I already am excited, to be clear - I would probably be over the moon itself with excitement if another OS steps up and can play some games.

I’m going to research, but is hardware acceleration the main hurdle after wine is properly ported? I am more than happy to get involved and test if/when the time comes.

Thank you for doing work on this!