I am playing around with Wine 10 configure script just for fun. Even i have Xlibe installed when i run configure in 64 mode it does not detect X11 64 libs…It also fails to detect freetype libs and sound if i remember correctly.I also see that .so files on Haiku have version suffix.How did you pass the requirements when you build Wine 7.9?
I don’t think Haiku support has been upstreamed to the Wine project. If you would like to take a stab at porting Wine 10, you can study the old recipe and patches here: haikuports/app-emulation/wine at master · haikuports/haikuports · GitHub
Btw, the Haiku port has its own driver for windowing and doesn’t need X11.
I am trying to compile Wine 10 from source just for experimenting.The 7.1 recipe requires libvulkan,libusb and libfreetype.I also see --without-x option in 7.1 recipe but not in 7.9 recipe.
I am sure a lot of people will be grateful to anybody who manages to get WINE working properly on Haiku. If I can’t get Win11 to work on my laptops I will be a full-time Haiku user, and will need WINE to work. I could of course buy a new computer but the existing ones work perfectrly well.
2 Likes
Is the Haiku port of Wine actually completed or still WIP?
I’ve never actually been able to get it to work correctly. every attempt I have made to use it results in none of the windows of the win application being actively redrawn, in order to see what is in the window i have to drag another BWindow over top of it to force it to redraw the contents.
I looked at the 7.9 recipe out of curiosity ('cause there’s no way it’s built using X11 libs), that one just unpacks an already made Haiku package, removes its info and repacks it.
The source of the package is this Wine fork for Haiku: (GitHub - threedeyes/wine)
Which is in turn a fork of (GitHub - X547/wine)
Even though I see mentions of 7.8 and not 7.9 in this second repo it seems to have the most recent activity of the two.
My conclusion? …errr… Wine is a mess to port I suppose?
Afaik it worked fine in Beta 4 but then broke some months after. (before/around June 2023)
There is an open ticket for the broken redraw on Trac (#19496), if anybody has the time and is willing to test the various Haiku dev versions after Beta 4 to find the commit that broke window drawing on it, then report it back in that Trac ticket, they’d be a great help in getting that redraw bug fixed.
Iirc it’s a WIP, some years behind, but it could run a bunch of stuff ok.
My 2 cents, I won’t be looking into porting/updating Wine as I don’t see the point in it, why would you? Maybe some games (non 3D) that don’t work on Haiku?
For other applications I gues that most is covered in current ports, if not, there is a topic where one can ask (if possible) for a port for something that isn’t already in the depot.
Dear Begasus, thank you for your work and everything you do to port applications, but can I give you my 3 cents? With your words, you are scaring away potential new Haiku users. There are 2 types of users - some remember the great times of BeOS 30 years ago and others who don’t know about it. They just want to get away from the nightmare of Windows and Linux. They just want to use it every day during work hours and a little after work. And there is a lot of software that cannot be ported to Haiku, for example, I have 50+ utilities for programming devices, they are proprietary and 32 bit. Do I have to reboot into Windows every 5 minutes to run them for 10 minutes and back to Haiku? Haiku has simply become good thanks to the work of the Haiku developers and many perceive it, unlike the bulk of people who are on the forum, not as a hobby, but as a tool for everyday work. And this, excuse me, is a completely different requirement for the OS and its software. P.S. for example, many Matrix clients have been ported, but none of them allow you to communicate with Haiku (even the native chat-o-matic crashes), they usually crash for me or have such a design that you want to close the laptop lid and forget about this horror. Yes, a bug report is needed, but what is the problem, мaybe these are bugs in the program, Haiku, or the Matrix server? Thanks again for the work of everyone involved in Haiku. Sorry, English is not my native language.
3 Likes
Hi @kaban4ik thanks for responding, what you mention here is a valid concern on why Wine would be handy/needed, my appoligies for being a bit narrow minded (it just triggered my nerve I guess as it once again popped up as something that is required), sorry about that.
There are plenty of tools around, are they perfect? Maybe not, but in my case (again my 2 cents 
) it works for me, for instance I combine the use of Quaternion and NeoChat (Chat-O-Matic was a GSoC project that came to a halt and I don’t think ever got finished) for matrix. Some bugs are known, but then again, those could use an eye of a “real” developer, where my skill are less to none. But bug reports are still welcome, if nothing else one could take it up with upstream and try to come up with a fix.
1 Like
Personally i am looking for a Windows 10 alternative when it will be out of support for several PCs. The obvious choice for me would be a Debian based Linux OS even if it’s bloated.Haiku is way more stable than ReactOS (ReactOS still gives BSODs on real hardware) but not having a working Wine is a big minus for me If the redraw issue is solved Haiku will be my first choice.
1 Like
if i run configure with the following options : configure --enable-win64 --without-x --without-freetype --without-xshm then the operation is completed…but when i run make i get ~/wine-10.0> make
tools/winegcc/winegcc -o dlls/acledit/acledit.dll.so --wine-objdir . -m64 -mno-cygwin -fasynchronous-unwind-tables
-shared dlls/acledit/acledit.spec -Wb,–prefer-native dlls/acledit/main.o
dlls/winecrt0/libwinecrt0.a dlls/ucrtbase/libucrtbase.a dlls/kernel32/libkernel32.a
dlls/ntdll/libntdll.a
/bin/ld: warning: dll_soinit.o: missing .note.GNU-stack section implies executable stack
/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/boot/system/develop/tools/bin/…/lib/gcc/x86_64-unknown-haiku/13.3.0/…/…/…/…/x86_64-unknown-haiku/bin/ld: cannot find -ldl: No such file or directory
collect2: error: ld returned 1 exit status
winegcc: /bin/gcc failed
make: *** [Makefile:1525: dlls/acledit/acledit.dll.so] Error 2
…Any ideas?
-ldl is a “linker flag” that is often used when compiling on Linux & al., it tells the linker to use a library that is not present in Haiku, it’s very likely being set somewhere in the main configure file, search for it and edit/disable the line so “-ldl” is not passed to the linker tool (in this case ld) when compiling for Haiku. If it’s not in the main configure file you can hunt for it using TextSearch (Opt+Alt+G) in the source directory.
1 Like
As Kaban has said, there are a great many applications that will never be ported to Haiku but that are useful and in some cases vital to those who do use them.
I think that a properly working version of WINE (or an equivalent) could be the single biggest reason for many people to turn to Haiku.
2 Likes
Something that seems to have been missed with this discussion about getting Wine working again on Haiku x86_64 is that as it stands it will not run 32 bit Windows applications due to the underlying OS being 64 bit only under x86_64.
From what I have seen in previous discussions, Wine on Haiku in its current port only runs on x86_64. If that’s the case, then the best bet to get 32 bit Windows applications working would be to looking into getting Wine to work on Haiku x86, if that is possible.
Another way would be to add 32 bit application support to Haiku x86_64. There have been discussions in the past on various methods to implement this.
There is also an option of running QEMU but without virtualisation support it won’t run particularly fast (There has been recent attempts at adding virtualisation but it’s in an unfinished state). Also there may be issues with passing through the physical hardware to the VM if that’s the purpose of running the Windows applications in the first place. That said I have used it for older versions of Windows on QEMU on Haiku and its okay for the basics if you are patient with it.
Wine these days has WoW64. 32-bit applications should “just work” on a pure 64-bit system as long as you have a recent version of Wine.
As a bonus, WoW64 also makes it relatively easy to run x86 Windows applications on ARM or RISC-V.
does wine on our 64bit revo has this?
No, I believe WoW64 has been ready since Wine 9.0: Wine 9.0 · wine / wine · GitLab
If i understand correctly the Makefile is generated so the changes should be done on wine/configure.ac at master · wine-mirror/wine · GitHub and wine/configure at master · wine-mirror/wine · GitHub? All i see there is llvm -ld flags.
I think so, but sometimes it is not as straightforward as I made it out to be. The only mention of -ldl I see is at line 2073, try and see if editing AC_SEARCH_LIBS(dlopen, dl) into AC_SEARCH_LIBS(dlopen) does the trick. If not it could be set somewhere else or be called some other ways, like “libdl”, “dl” or something like that.
Also, I can imagine it being confusing but -ldl and -ld are 2 different things, people in FOSS seem to love coming up with the most confusing names ever for things.