Maybe nonsense (I’m a bit inexperienced…), but I still have a CD somewhere with a 3D CAD (including photogrammetry, etc.) that I could look for … if there was even the possibility …
Requirements at that time:
Pentium PC from 200 MHz, 64MB RAM, 100MB memory,
for Win95 / 98 / ME / NT / 2000 (was queried during installation, i.e. ‘adapted’).
this would be really fun, I can’t wait to see some famous windows application, entirely with the haiku skin 
Yeah, next time JLG will have better chance to post an actual Be/Haiku screenshot.
(Not like last time where he posted a reskinned windows screenshot as BeOS).
1 Like
Is this theoretically feasible? Even on platforms officially supported by CodeWeavers (Linux, macOS), Wine doesn’t do similar kinds of integrations with GTK, Qt, or Cocoa.
1 Like
Windows 98, 2000 etc supported custom colors for normal winforms controls, it should be possible to have this be based on Haiku colors atleast.
Wine already has a theme selector build in aswell, that no linux distro makes use of this for integration is kind of wierd : )
A thread spending over half its time in poll() likely indicates either one of two things: there are thousands of FDs being run through poll (this seems rather unlikely if you only have one WINE application working), or there is an event being triggered every time poll is invoked, or within a few ms at most (much more probable.) This may be due to a bug of some sort either in WINE or in Haiku; possibly there is some error condition not being cleared. It is worth investigating on the WINE side of things to see what is precisely happening.
6 Likes
250 fd when running notepad. 264 fd when running image viewer with animation. According to my SystemManager, new sem_id with name “select” is created on each poll() call.
4 Likes
That’s a lot of FDs! Why so many? How often does poll wake up?
1 Like
Note that all Win32 synchronization primitives (semaphore, event, etc.) are implemented on wineserver side. wineserver is single threaded with one global event loop.
2 Likes
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 
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