My progress in porting Wine

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

4 Likes

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:

7 Likes

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__
+#define SIGIO SIGPOLL
+#endif

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:

#ifndef __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
#define __HAIKU_WINE_UTILS_SYS_SIGNAL_H__

#include_next <sys/signal.h>

#define SIGIO SIGPOLL

#endif // __HAIKU_WINE_UTILS_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:

#ifndef __HAIKU_WINE_UTILS_SYS_IOCTL_H__
#define __HAIKU_WINE_UTILS_SYS_IOCTL_H__

#include_next <sys/ioctl.h>

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

#undef ioctl
#define ioctl haiku_utils_ioctl

#endif // __HAIKU_WINE_UTILS_SYS_IOCTL_H__

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?

Sincerely.

14 Likes

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!

8 Likes

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!

2 Likes

@spinningd20 see Vulkan lavapipe software rendering is working on Haiku

Essentially: GPU acceleration is in progress and showing some pretty nice results for radeon cards (the title of the thread is a bit misleading because hardware rendering is now working).

And for playing games in wine on haiku… AFAIK yeah I guess you need wine and hardware 3D acceleration. I think it will be a bit of time yet before these WIP features reach users though. It’s a very exciting time to be using haiku!

2 Likes

I suspect that if these two projects, wine and hardware acceleration, reach a good progress, there will be a mass transfer of new users who will arrive from both sides, both from linux and from windows and from mac, perhaps for different reasons … but tired of both windows and linux and mac

5 Likes

It certainly sounds that way reading hacker news. There are still quite a few rough edges in haiku but it’s really picking up momentum… 2022 should be even better for haiku than 2021 was!

8 Likes

If the Wine port matures before 3D acceleration, you might still be able to use the Windows version of SwiftShader to get some mid-2000 D3D9 games running. It will look a bit choppy, but still really cool to play around with (and quite playable if you’re not too picky) as we wait for 3D acceleration.

1 Like

Last I saw benchmark numbers, Mesa LLVMpipe was generally more performant than SwiftShader, so it may not really matter.

3 Likes

Just wow @X512 and @waddlesplash - you’re doing amazing work :slight_smile:

8 Likes

LLVMpipe is for OpenGL. It could be paired with Wine’s D3D9 → OpenGL wrapper though. Lavapipe paired with DXVK could also be something to try.

Shouldn’t Wine’s D3D9 → OpenGL wrapper be the default anyway, since that is what would be able to use hardware acceleration once it is available?

Anyway, the recent developments in the project are amazing. Wine and Xlibe will allow so many more apps to run on Haiku that it opens up many more possibilities to use it as a main system for more people.

1 Like

Considering that the Vulkan driver work seems to be getting farther along, using DXVK and VKD3D (upstream or VKD3D-Proton) would prolly be the faster ways to get hardware acceleration in Wine.

2 Likes

Oh, makes sense. I’m guessing OpenGl then will work in Wine using Zink eventually. Cool!

2 Likes

Wine on Haiku currently has significant performance problem caused by poll() in wine_server. It spends significant time in kernel. wine_server seems designed to use epoll that is not available on Haiku.

screenshot126

screenshot127

31 Likes

I spend last days to creating Haiku native windowing intergation driver for Wine winehaiku.drv without using X11 or Xlib in any way. It is already quite usable and outperforms winex11.drv + Xlibe in many aspects.

Native Haiku Wine windowing intergation driver will also simplify Vulkan and DXVK integration a lot, no GLX stuff.

What works:

  1. Displaying window contents. Wine drawing engine is used, drawing result is displayed with BView::DrawBitmap().
  2. Mouse input (left, right, middle buttons, wheel).
  3. Keyboard input (VK_* codes translation, Haiku native keymap handling).
  4. Native Haiku window borders and window styles.
  5. Windows move, resize, show/hide.

What do not work:

  1. Focus contol.
  2. Window Z-order control.
  3. Wine - Haiku window position syncronization sometimes works wrong.
  4. Detecting screen size.

screenshot141

screenshot142

55 Likes

This is really nice.
Soon we will have a lot of windows applications that will work better than other platforms, especially due to the lightness of HAIKU which uses the minimum of available resources, giving all the rest of the resources to the applications, as it should be.

Philosophizing, HAIKU now is beautiful because it is orderly, elegant and essential.
The other os are fat and a bloated chaotic and bureaucratic waste of resources.
HAIKU attracts because this free lightness is projected on the psyche of our consciences, and in this historical phase there is a great need for this free lightness.

2 Likes