Created attachment 258697 [details] git-formated patch
Thank you for the update, Thibault. I hope I do not miss anything - can you please drop the formatting changes to files/patch-dlls_ntdll_unix_loader.c which do not appear to fix anything and create churn and, worse, divergence with other ports like emulators/wine? In fact, can the whole change to files/patch-dlls_ntdll_unix_loader.c be dropped? (If not, a brief explanation in the commit message would be good. Similar for the ${MV} ${STAGEDIR}${PREFIX}/bin/wine64 change.) Can you share how tested your patch?
(In reply to Gerald Pfeifer from comment #1) You are welcome, The patch to files/patch-dlls_ntdll_unix_loader.c is needed due to a change between 10.1 and 10.2 in how the loader is found by wine. 10.2 introduced the possibility to use the new wow64 mode for wine (which is not working on FreeBSD for now, but a work in progress can be found here https://github.com/shkhln/freebsd-wine) Without reverting to the old behavior, wine cannot found the loader. In addition they renamed wine64 to wine for the 64bit part, thus the need to rename wine to wine64.bin instead of wine64 to wine64.bin. As for testing, I did test (with an additional patch that allow the games to launch past the login screen: https://gitlab.winehq.org/wine/wine/-/merge_requests/5213 ) the following games: Cyberpunk 2077 The Wither 3 wild hunt Dead Cells Unbound World Apart Basically I mainly tested games on an amd64 OS, (with of course the 32bit version built installed with pkg32.sh) I will think about a brief explanation and update the commit message.
(In reply to Thibault Payet from comment #2) I forgot to said at runtime for this part, it was possible in the past but at build time you would had to enable it (on Linux). - 10.2 introduced the possibility to use the new wow64 mode for wine
Hey Gerald and Thibault Payet, Do you think it would be better to jump from 10.1 to 10.5? It was released a few days ago and it includes some useful changes to both Mono (V10) and WPF that I am now using as part of me being able to successfully run my Diablo II version switcher on FreeBSD (https://themovingcaravan.com/threads/cactus-2025-04-05-1430-is-now-available-wine-freebsd-linux-are-now-officially-supported.297/). I've been playing around with Wine 10.0 on FreeBSD and I use poudriere to build all my packages for both my server and laptop on x64, and I now have a 32 bit jail specifically for wine and mesa-libs. I understand why the split is required but the whole flow is definitely weird. Also I haven't been able to figure out how to get my host system to have both my x64 and x32 bit repos working together, enabled, and not get ABI errors when running a normal pkg update on the host. However that's the only way I've been able to satisfy the pkg32.sh message to get the 32 but build to install in the home first i386 folder. I'm interesting in helping to understand the flow better and maybe I can help a little with maintenance. This would be my first official dive into FreeBSD porting. I have contributed a bit before to doc, and also I was a previous OpenZFS maintainer for Gentoo Linux back in 2018, so I'm familiar with Gentoo's portage / ebuild system that were partly inspired by FreeBSD (one of the reasons I moved to FreeBSD many years ago). Please let me know of any advice that you would find useful for me, and that would also help make my setup a bit easier. I would probably end up writing some documentation on my blog about getting a wine setup running easier for people that use poudriere on x64. Thank you
(In reply to Jonathan Vasquez from comment #4) > Do you think it would be better to jump from 10.1 to 10.5? 10.5 would not even build (I proposed a patch upstream), and even 10.2 won't build with newer versions of GCC (I have a patch that I am thinking how to be submit upstream). My recommendation is to land the update to 10.2 and proceed incrementally. One benefit is that it makes it easier to catch and bisect regressions. Maybe the two of you can sync and split the work? (And, yes, FreeBSD's support for 32-bit libraries and apps on a 64-bit system and mixing the two is ... not great. I'm hoping Wine's native approach is going to mature so that we can avoid the current hack.)
That sounds good Gerald. We can go to 10.2 then. And yea I'm hoping the new SysWOW64 dual arch method would make things easier since we would only need a 64 bit prefix and 32 bit stuff would just work. Do you use poudriere to build your 64/32 bit packages? How do you use them together? ATM I have both of my repos in separate files in /usr/local/etc/pkg/repos and I would enable the 32 bit repo just before I run the pkg32.sh script. Afterwards I disable it so I don't constantly get wrong ABI messages on the host. It works since I basically usually only need to pluck the 32 bit files once, and then it's set. But I'm wondering if there is a better way since there isn't much documentation on this specific situation. Perhaps the output messages in the wine loader alert (regarding poudriere users making appropriate symlinks and configuring the ABI correctly could be expanded?)
(In reply to Jonathan Vasquez from comment #6) To have both repository enabled, you could use the ABI variable for that. For instance, I have something like this in my repository conf: url : https://pkg.mydomain/${ABI}, then on my webserver, I expose amd64 build inside the directory: FreeBSD:14:amd64 and on i386 it is the directory: FreeBSD:14:i386 This should also apply to local file based repository normally.
Created attachment 259377 [details] git formated patch Here with a more detailed description, and the actual changelog.
Thanks for that Thibault! My mental model was off but this makes it clearer. My current set up was actually having two separate package directories (basically one set of packages for 64 bit built by poudriere, and the second set of packages was the 32 but built by poudriere). I then exposed those two directories in my internal http server (same domain but different dir, example: 142x64 and 142x32). Then I had to different conf files in my repos.conf, one for each of these. But I see what you mean, I should have only one core directory with two separate folders based on ABI, then if I use the ABI variable in my conf each PKG call (PKG on 64 bit host and pkg32) will auto select the appropriate directory from the same repo but based on ABI. This makes sense.
I was able to modify my poudriere setup with the recent adjustments and now it's working smoothly. Only one repo conf file (one repo enabled) and the client can switch between x64 and x32 via the ABI. I changed my server so that instead of having something like: https://internal/packages/142x64/ https://internal/packages/142x32/ and having two separate repo entries on the client side, I now have: https://internal/packages/FreeBSD:14:amd64 https://internal/packages/FreeBSD:14:i386 and only one repo entry on the client side that says: Internal: { url: "http://internal/packages/${ABI}", enabled: yes } and that allows the client to do normal pkg install/updates on x64, and pkg32 will seamlessly fetch files from the right directory. I really appreciate this feedback, it makes my life a lot more simple, thank you!
(In reply to Jonathan Vasquez from comment #4) > [Wine] 10.5? It was released a few days ago and it includes some > useful changes to both Mono (V10) [...] I just pushed an update of wine-mono-devel to version 10.0.0. (In reply to Thibault Payet from comment #8) > Here with a more detailed description, and the actual changelog. I reverted the formatting changes and adjusted the commit message a bit here and here (for example adding a colon after the portname in the first line), am doing some final tests; then should be able to push this Wednesday morning. Thanks!
Thanks Gerald. I'll give Wine Mono 10 a test soon (and 10.2 when ready). It's nice that it could be independently updated.
Hey Gerald, I've tested wine-devel-mono 10 and it works great. I checked it out and it seems it's just an msi. After I installed the package I did: WINEPREFIX=$HOME/prefix/someprefix wine /usr/local/share/wine/mono//usr/local/share/wine/mono/wine-mono-10.0.0-x86.msi and it installed. Doing a WINEPREFIX=$HOME/prefix/someprefix wine uninstaller, showed that 10.0.0 was installed. I ran my Cactus program and it opened up fine and functioned properly. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=309d3c189e787b29ab7a81a76716329ca0507c49 commit 309d3c189e787b29ab7a81a76716329ca0507c49 Author: Thibault Payet <monwarez@mailoo.org> AuthorDate: 2025-04-08 23:19:21 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2025-04-09 07:53:44 +0000 emulators/wine-devel: Update to Wine 10.2 This is the second snapshot of the Wine 10.x branch. It includes the following changes: - Bundled vkd3d is upgraded to version 1.15. - Support for setting thread priorities. - New Wow64 mode can be enabled dynamically. (Not yet on FreeBSD!) - More progress on the Bluetooth driver. - Various bug fixes. Upstream renamed the wine64 binary to wine; account for that when renaming it to wine64.bin. Revert the support for new WoW64 mode detection at runtime since it is not supported on FreeBSD yet (files/patch-dlls_ntdll_unix_loader.c). PR: 285446 emulators/wine-devel/Makefile | 4 ++-- emulators/wine-devel/distinfo | 6 +++--- .../wine-devel/files/patch-dlls_ntdll_unix_loader.c | 17 ++++++++++------- emulators/wine-devel/pkg-plist | 5 +++++ 4 files changed, 20 insertions(+), 12 deletions(-)
Note how diff -u wine/files/patch-dlls_ntdll_unix_loader.c wine-devel/files/ of what I committed is more clear than the original submission and similarly for wine-proton. Also, I have an update to 10.3 in the works, @Thibault and @Jonathan. :-)
This is great Herald. Thank you, much appreciated!
Gerald*. Also I'll be happy to test any future Wine patches / releases.
Hey Gerald, I was able to test wine 10.2, it built fine for both x64 and x32 but for whatever reason there is no mouse rendered in any of the wine windows (Doing a 'wine winecfg' shows the window but no mouse cursor, also it seems winecfg doesn't work anymore, did wine change the alias to 'wine winecfg'?). I tried installing with Wayland support and also just keeping X11 and either way I didn't get a response. I also ran the wayland.reg recommendation and I also didn't get a cursor (I'm on sway). 10.0 works fine, so not sure if this is an upstream regression or if I need to do something given 10.1+ has the Wayland flag. - Jonathan
(In reply to Jonathan Vasquez from comment #18) Yes it seems that those alias no longer works (maybe because they are a symbolic link to wine ? And thus the shell script would need to take it into account ?) I am also using sway, and don't really have the issue with the mouse cursor. Once build with wayland support, enabling wayland with the suggested reg files will only make wine use wayland as a fallback (so you will need to remove the xwayland info from the env so that it does not see a DISPLAY variable). What I usually do to enable wayland by default is to use winetricks on my prefix, go in select default prefix, change settings, then select graphics=wayland. Once this is done, you will have a wayland window for your wine application.
I just updated emulators/wine-devel to version 10.3. Maybe you want to give that a try and perhaps one of you wants to submit an update to 10.4?
Hey Thibault, Gerald, I did a fresh install of 10.2 and for whatever reason now everything works again through XWayland haha. After testing I'm actually going to need to stick with XWayland since for whatever reason my Cactus application shows a black window when ran directly through wayland. But Wine 10.2 works perfectly fine on XWayland for both my application and also winecfg, so this is really good. The following shows some of my sway trees with XWayland Wayland directly (I applied the regedit wayland.reg as well, and just need to do DISPLAY= <command> to temporarily unset it and let it fall to wayland directly. When ran through Wayland directly, the winecfg window and the Cactus window also would obey the sway window maximization rules so it would fill up the entire screen rather than being contained within their own dimensions haha. But the above are Wine issues, not FreeBSD. So 10.2 looks good. Through XWayland: #56: floating_con "Wine configuration" (xwayland, pid: 0, instance: "winecfg.exe", class: "winecfg.exe", X11 window: 0x1A00001) #61: floating_con "Cactus - 3.1.0" (xwayland, pid: 0, instance: "cactus.exe", class: "cactus.exe", X11 window: 0x1A00005) Through Wayland (DISPLAY=) #71: floating_con "Wine configuration" (xdg_shell, pid: 32667, app_id: "winecfg.exe") #73: floating_con "Cactus - 3.1.0" (xdg_shell, pid: 37900, app_id: "cactus.exe") I'll compile 10.3 now in poudriere and test, Gerald. Will let you know how it goes.
https://forum.winehq.org/viewtopic.php?p=142727#p142727
Hey Gerald, Just finished testing Wine 10.3. Everything is working well :). You are on fire haha. I'll be traveling later tonight so if 10.4 isn't already in the tree in around 2 weeks, I'll be interested in trying to update the port to 10.4. Stay safe, Jonathan
Was testing a bit again and for whatever reason the mouse cursor issue re-appeared. I can see keyboard events work in the XWayland window, but no mouse. If I unset DISPLAY I can get the window to open in Wayland and the mouse cursor works, but the bad news is that for whatever reason my .NET application is completely black in Wayland. Someone else had a similar issue and there problem was fixed by running it in a 64 bit wine prefix, for me that didn't work. Although one difference is that I'm on Wine Mono directly and they used winetricks to install dotnet46 and corefonts. These issue aren't related to this ticket but wanted to mention it given my previous reports on this ticket related to this same issue (which was previously reported as working). https://forum.winehq.org/viewtopic.php?t=40232
Regarding the window dimensions not being respected in Wayland/wine, it actually wasn't a wine issue. It's just that in XWayland the wine windows were being floated automatically so the dimensions were correct automatically. When Wayland native, sway will properly maximize the window (but for our wine case I actually want them floating so they can keep their original dimensions). Basically I need to add a floating enable entry for every wine window/application that is running on Wayland directly through wine. For my purposes at the moment, it will most likely just be the following (and maybe I'll add explorer/notepad and some extra in the future): for_window [app_id="winecfg.exe"] floating enable for_window [app_id="cactus.exe"] floating enable
Some more updates and some progress. I noticed that even though I don't have Wine Mono 9.4.0 installed (or atleast not in the /usr/local/share/wine/mono directory) my new wine prefixes were using 9.4.0 (may be related to bundling, I'm not sure atm). But either way, I manually upgraded it to Wine Mono 10.0.0 by doing WINEPREFIX=... wine /usr/local/wine/mono/ <version 10> , that upgraded to 10.0.0. Opening my .NET application after this allowed the window to no longer be black, but the window cursor still wasn't working. I then ran the wayland.reg so that it can have wayland driver as a fallback, after this the window was able to open and the mouse cursor was working inside the window. There are some weirdnesses though but I think for now that can conclude my updates in this ticket.
(In reply to Jonathan Vasquez from comment #25) > Regarding the window dimensions not being respected in Wayland/wine, it > actually wasn't a wine issue. Wayland itself is not fully mature as far as I am concerned (and its approach re window placing and dimensions is, let's say, interesting at best), and Wine support for Wayland in particular still is under active development, so caveat emptor. Definitely worth giving it a try and reporting issues upstream - there has been quite some progress in the last 12, 15 months.
(In reply to Jonathan Vasquez from comment #23) > if 10.4 isn't already in the tree in around 2 weeks, I'll be > interested in trying to update the port to 10.4. Sounds good. After maintaining the wine port(s) for some twenty years I really needed reduce my effort. Still happy to help a bit, just the time has come where users and others hopefully step up...
Thanks for that Gerald. I've switched back to i3 for now but will keep sway for testing stuff on Wayland (and other usages). I'm also back from my trip so will see about playing with the Wine 10.4 update. Hopefully it isn't as crazy as the 10.5 stuff you are working on.
I also noticed 10.6 was recently released lol. It's a pretty fast moving train it seems. I'm tempted to just chill on wine stable haha.
(In reply to Jonathan Vasquez from comment #30) > I also noticed 10.6 was recently released lol. It's a pretty fast > moving train it seems. I'm tempted to just chill on wine stable haha. Yes, Wine runs bi-weekly development snapshots and yearly releases. It's good to have the former and ensure they keep building and working, or once a year we'd have a new release that does not. Plus it tends to enable new applications and game. Yes, it's an effort, and fully transitioning has not succeeded for some four years now (so I ended up releasing maintainership and supporting others like you.)
(In reply to Jonathan Vasquez from comment #30) > I also noticed 10.6 was recently released lol. It's a pretty fast > moving train it seems. I'm tempted to just chill on wine stable haha. In the meantime I updated wine-devel to Wine 10.6. And https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286078 has a patch by scf@ that you may want/need (and that I'll push fit there is enough positive feedback. (Beyond that I am not planning to do further updates, hoping for others to step up like Thibault has done here - which lead to a sequence of updates and improvements. :-)