My progress in porting Wine

Yes, as in a Haiku-like Windows theme/colour scheme. What @X512 seemed to propose was not a theme, but rather integration between UXTheme and BControlLook.

It is odd, but perhaps it is avoided since Windows apps would prolly break too much due to the large gap in design between most Linux themes and Windows Classic. Maybe a Haiku-like theme will work better, since Haiku and Windows Classic both have similar designs from the 90s?

It seems like the best are an UXTheme and BControlLook integration, it should be beautiful if the software are perfectly integrated with the native decorator <3

Windows is a lot better at these things than the old standard POSIX APIs. They really do a lot of things kernel-side and so they have good APIs for asynchronous IO, etc. It’s normal that windows apps and libraries expect that to be there, so they just create a whole lot of kernel-side context and then use an efficient API to get notified whenever something happens on that side. Except we don’t have any efficient API for this.

So Wine uses poll as a fallback. And everytime it wants to know something from Kernel, it has to re-send the whole list of fds to the kernel side again.

Had the whole thing be designed with POSIX in mind, they would probably have split things differently, tried to group many things in a single file descriptor, or make small groups of file descriptors that could be polled spearately. Likewise iff designing for the BeAPI they would have created lots of separate threads to handle this. But it would be a bit much to ask from Windows developers to think about that :slight_smile:

10 Likes

Unfortunately it seems not implemented efficiently in Wine. Most NT kernel objects are handled in single threaded wineserver process and single global event loop. Maybe some kernel module can be made for NT objects handing or some objects can be mapped to Haiku objects.

8 Likes

Interesting and appealing idea. I wonder why this has never been implemented for Linux, given some of the daft junk that’s made it into the kernel over the years. I wonder if there’s anything else interesting that could be implemented this way? Though I guess “Posix” and “NT” are kind of the only significant base API’s left.

Plan9.ko from Haiku Inc? :wink:

1 Like

Because of “Stable ABI nonsense ™” and monolithic in-tree driver development I think. Haiku have no such problems and Wine kernel module can be out of Haiku tree and installed separately.

6 Likes

Probably we should just implement an event_queue and maybe a wrapper around kqueue, that should be all WINE really needs here. And a number of other asynchronous I/O libraries would benefit greatly from such an API as well.

11 Likes

That would be amazing!

Is it possible that ReactOS code could be used, or at least be useful, for doing this?

My kernel development knowledge is 0% so i’m not too sure how practical it would be.

Off-topic (and entirely “out there”) but i’d love to one day see a ReactOS NT subsystem supporting BeOS/Haiku applications.

1 Like

ReactOs shares a lot of code with Wine. It has pretty much nothing extra except native drivers.

Not really. ReactOS win32k.sys GUI subsystem kernel module is independent ReactOS code. In theory it is more efficient because it do not use poll() and it is multi-thread aware. Unfortunately it is unstable and less feature complete that corresponding Wine components.

1 Like

By the way, according to Hangover’s own github, it’s not that reliable. Wine is already kind of a hassle, so also using a workaround for its most common use case(32 bit programs) seems like it would compound that. Not to be a debbie the downer, but is it worth having a feature that will probably never work that well?

Who is talking about Hangover? The only use-case for that would be Wine on ARM or RISC-V.

ReactOS Explorer:

screenshot155

screenshot156

screenshot157

31 Likes

Actually there’s was work (in 5.16) to add WaitForMultipleObjects like capability to the Linux kernel.
Specifically for wine/proton.
I would imagine that the wine-side code changes can be useful for Haiku as well.

See:

https://lkml.org/lkml/2021/10/9/121

Some progress for Vulkan support in Wine. Currently crash after opening window.

screenshot162

20 Likes

Thank you for your incredible work!

If you are doing Vulkan integration anyway, I wonder if you could have a look at this Wine issue in the process, regarding Vulkan child window rendering.

Having Affinity Photo, Designer and Publisher running under Haiku with hardware graphics acceleration would be incredible. Moreover, if this was in Wine for Haiku first before being upstreamed, it could also generate quite a bit of interest in the Haiku project because there are lots of people who are stuck on Windows purely because of Adobe/Serif software.

7 Likes

Or something like uxtheme → BControlLook integration.

There is also the DrawFrameControl() function for older software that does not use uxtheme.

Vulkan is running in Wine. Currently in a wrong window.

screenshot165

44 Likes

Amazing. Duuuuuuuuuuuuuuuuuude!!!