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 
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? 
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:
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:
Some progress for Vulkan support in Wine. Currently crash after opening window.
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.
44 Likes
Amazing. Duuuuuuuuuuuuuuuuuude!!!
It seems that Windows Vulkan sample binaries are older then Haiku (2017 year).
28 Likes