How hard can be have wine on haiku?.. i know this is not the max propose for haiku but, think it, haiku never gonna have the same amount of software like windows…ok maybe not in this next 4 years at least, and wine is a great tool… i dont know if the deps are ported for haiku now… i know a version of wine for mac and supose is in that way how should be ported.
Wine can theoretically be ported to Haiku, but it requires an X server to function in any real way, which Haiku lacks. I think there’s a few dodgy assumptions in Wine code too making it difficult to port.
There’s many reasons when it comes down to it, and if it was a case of a few dependancies and a recompile, i expect it would have been done already.
I believe BeWine development was abandoned due to some missing memory mapping functionality in Beos. From what I know Haiku does not suffer from this drawback so atleast from that standpoint a port should be feasible.
I think there are two major issues that any porter will have to deal with. First, most *nix systems use the X server, and Wine relies on it for those ports. There has been work on making Wine use the native server in Mac OS X, I don’t know how far they are with that. Anyhow, a Haiku port will have to use whatever Haiku provides (app_server? Not exactly sure) instead.
Sound support will also have to be dealt with. Wine now supports ALSA, OSS, SDL, Jack and maybe others. Support for Haiku’s media_server will have to be written. I personally oppose the idea of settling with SDL or any similar library, as Wine is already a layer for foreign applications, and it emulates DirectX and maybe other things. We should really be careful with latency and performance.
Personally, I’m trying to get everything off Windows and onto ReactOS under QEMU. I think that it would be more worthwile trying to make an ultra-fast lightweight QEMU that could run a possible stripped-down ReactOS version, i.e. make a QEMU that is less technically accurate with regards to exact hardware emulation, and just keep the basics, and cut the ReactOS kernel to a basic explorer and program running. Of course, the latter would require someone from their project helping, or someone who knows a lot about compiling operating systems.
You might as well use a stripped down version of Linux with Wine in QEMU. It should be possible to run Wine in Linux without a DE running if I remember correctly. I have supported ReactOS for many years because I really like the idea, but in my experience at least, Wine is a lot more stable and compatible.
But what is great about Wine is that it emulates API’s, and not hardware. This makes it naturally fast. A port for Haiku would be better IMO.
As sparklewind said, Wine maps out windows api calls to native posix equivalents where applicable and rewrites those functions for which there is no posix equvivalent. This means that the speed penalty for using wine instead of real windows is generally very small (in fact sometimes faster due to the posix implementations/function rewrites being more efficient than the original windows functions). VM’s like QEmu and VirtualBox will be generally slower due to them using a higher level of virtualization for code and hardware (atleast that is my impression). Downside to Wine is that since it’s not Windows (as in running real Windows under a virtual machine) it suffers from incompabilities. Still, it keeps on progressing all the time and has great support for a wide range of windows software. Reactos is a very nice project, but it has a long way to go before it reaches the compability of Wine (not surprising since Reactos is a entire reimplementation of Windows, top to bottom).