Wine 8.14 is out now and here's what's new

​This wine version with ./configure --enable-archs=i386,x86_64 work and steam also still working in my case

!link

however dragon dogma arisen is very heavy for recording (before screen stay with recording active aka ffmpeg quicksync) and occur similar nvenc error (in my case if gpu stay around 95% or more sound are completly desynchronized without forget fps performance have huge penalty, in my case around 15fps)

similar issue occur with samurai shodown UE4 title, curiously use video enhance according intel gpu top in my intel tests
i dont see video enhance activated

however is impressive see how a tiny igp like uhd can run this but with before quicksync cited situation i pass to make this video gameplays maybe delay for better hardware (i think about help amd if appear apus in socket am5 with good specs)

!link

!link

Almost forget samurai shodown aspect ratio is 16:9 but with HxD can possible change that in game executable (searching value 39 8E E3 3F and replace for AB AA AA 3F)

​


Last edited by mrdeathjr on 21 August 2023 at 9:50 am UTC

​This wine version with ./configure --enable-archs=i386,x86_64 work

Finally... I hate building Wine twice.

I went back to Wine 8.6.1 for my uses because everything is 100% (had one game that wouldn't work with Wine 8.12), but I'll be happy when I can do it like that when internal thunking is viable, and 32 bit games can be run on a non-multilib system.

P.S. I don't think I have one single 32 bit Linux native game anymore, it's only Windows games. Old eON translated binaries are all shit and I've switched any of those games to the Windows versions with Proton.

So when that's ready, I can run whatever kind of Linux system I want. I do really good customized from-scratch systems (for me only, I mean), but it's too onerous to do all those dependencies with their lib32 counterparts etc. I only play 64 bit Linux native games there (and I do have several, both open source and GoG)

Eventually Valve will finally extract crania from recta and stop being so silly with our Steam client, too. We shouldn't need a multilib system to run a native game client if we don't intend to interface with any 32 bit games. If they still want to support 32 bit Linux distributions, by golly, do a 32 bit build like everyone else would in our ecosystem.


Last edited by Grogan on 20 August 2023 at 11:19 pm UTC

Finally... I hate building Wine twice.

Oh, so it is easy to build WoW64 Wine now? Before this process was so convoluted that I never bothered doing it when I needed to build it.


Last edited by Shmerl on 21 August 2023 at 6:42 am UTC

Oh, so it is easy to build WoW64 Wine now? Before this process was so convoluted that I never bothered doing it when I needed to build it.

Apparently so, though I couldn't say how well it would work out.

You still need both i686 and x86_64 mingw cross toolchains for it to build correctly though. I was reading where it'll silently drop the i386 PE code if the 32 bit mingw is not present (which sounds like a "WTF" head scratcher when it doesn't work lol). There's a merge request to make configure fail in that situation, but it's not in there yet.

I don't think I'm going to try that just yet (not for my system wine anyway, which is TKG'd)

Finally... I hate building Wine twice.

Oh, so it is easy to build WoW64 Wine now? Before this process was so convoluted that I never bothered doing it when I needed to build it.

Yeah only ./configure --enable-archs=i386,x86_64 and make -jN (N are cpu cores you assign to make)

Almost forget in this mode wine64 binary dont exist, is only wine binary but run both 32 and 64bits windows apps

!link

However still dont appear icons in appetizer app folders but when push to execute work normally compared regular deb provided for wine team aka (wine-devel.deb - wine-devel-amd64.deb - wine-devel-i386-i386.deb and winehq-devel.deb)

!link




Last edited by mrdeathjr on 21 August 2023 at 10:29 am UTC

Almost forget in this mode wine64 binary dont exist, is only wine binary but run both 32 and 64bits windows apps

Oh, that's nice. I was waiting for it to happen. Good to see that.

update with wine 8.14 (wine official lunar deb packages)

Steam dont work in my case, shows a windows asking restart client and other 5 options but dont work with anyone*

*this error appear sometime ago around wine 8.10 deb packages and are fixed around wine 8.11

however with ./configure --enable-archs=i386,x86_64 build steam works ok




Last edited by mrdeathjr on 21 August 2023 at 2:45 pm UTC

wine staging 8.14 deb packages are out, in my case main wine desktop window back to work* (in my case seriously affected since wine staging 8.10)

*no more error:

0134:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.

0134:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."

​

!link

however steam show same error window than regular wine from deb packages, curiously steam works with regular wine compiled using this ./configure --enable-archs=i386,x86_64

​

Oh, that's nice. I was waiting for it to happen. Good to see that.

Yeah only ./configure --enable-archs=i386,x86_64 and make -jN...

OK, mrdeathjr you convinced me. I got brave and tried it. I was not disappointed. I grabbed this (ready patched Wine 8.14 TKG):

https://github.com/Kron4ek/wine-tkg

Built it like this... and it worked

../$pkgname/configure \
    --enable-archs=i386,x86_64 \
    --prefix=/usr \
    --libdir=/usr/lib \
    --with-x \
    --with-gstreamer \
    --disable-tests

  make -j10

(--libdir is necessary for me on Arch, for we don't use lib64 convention... lib32 for 32 bit)

That sure gets rid of a lot of gymnastics in my PKGBUILD (packaging steps too), though it still takes about the same amount of time to build.

Indeed, no wine64 binary.

I have /usr/lib/wine/i386-windows, x86_64-unix and x86_64-windows in there (nothing in /usr/lib32 anymore)

Installed as my system wine package, in Lutris, most of the games I've tested work (except Star Wars Battlefront 2 in EA, which I expected not to work with this version of Wine, the reason I went back to 8.6.1, but I'll figure something else out for that)

While they are working, I do seem to have trouble with some 32 bit games not exiting properly, needing to be killed. I'm not sure if that's a thing or just a one off, but it happened to both Bioshock Infinite (32 bit Windows version) and Dead Space 2 in EA App.

Now, I have the full complement of 32 bit dependencies on my system. I doubt we're at the point yet where we don't need 32 bit deps at the back end, but it would be an interesting test (couldn't build it on such a system though)

I'm going to keep this configuration now. I'll work around anything that doesn't work (use other wine runners etc.)

If single wine binary is a thing in the new version, why does their 8.14 build for Debian still contain wine64? They decided not to remove that split yet by default?


Last edited by Shmerl on 22 August 2023 at 3:09 am UTC

Hmm:

checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
checking whether i686-w64-mingw32-gcc works... no
configure: error: MinGW i386 compiler not found.
This is an error since --enable-archs=i386 was requested.
make: *** No targets specified and no makefile found.  Stop.

That's weird since I have gcc-mingw-w64-i686-posix installed for building dxvk / vkd3d-proton. What am I missing?

i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 12-posix
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It's currently set to i686-w64-mingw32-gcc-posix, but setting it to i686-w64-mingw32-gcc-win32 doesn't work either.


Last edited by Shmerl on 22 August 2023 at 3:34 am UTC

It's currently set to i686-w64-mingw32-gcc-posix, but setting it to i686-w64-mingw32-gcc-win32 doesn't work either.

You'd have to look at the config.log, as what's happening there is the compile test is failing for whatever reason. It could be as stupid as something bad in your environment causing the command to fail. (It doesn't really mean it's not found of course)

Oh bugger, here's a show stopper (for me, in Lutris). I can't seem to create new wine prefixes

Started initial process 1225 from /usr/bin/wine winecfg.exe
Start monitoring process.
fsync: up and running.
wine: '/storage3/shit/justcause2' is a 32-bit installation, it cannot support 64-bit applications.
Monitored process exited.

I actually updated that prefix OK and the game worked, but I decided to do a test of creating a new wine prefix for a 32 bit game. Good thing I did, because this will not do.

I then forced it to be a "64 bit architecture" (Lutris has a setting that is Auto by default) and got

wine: could not load kernel32.dll, status c0000135

This is all 64 bit wine binaries

It's got to be something related to Lutris hard coding paths or something, because I can do

rm -r /home/grogan/.wine
wine winecfg.exe (and get the progress dialog, and winecfg opens)
wine notepad.exe

Sigh... time to go poking the python.

P.S. Got it to work, to generate a prefix with the "64-bit" architecture setting in Lutris (still can't get "Auto" to work)

The 32 bit Just Cause 2 game works just great in this "64-bit" arch Wine prefix, so the thunking is working.


Last edited by Grogan on 22 August 2023 at 5:39 am UTC

Well, I have to say I've now seen that this isn't completely appropriate yet for 32 bit games. I'm going to have to go back to the old method, moreover, I'm just going to go back to my recently recompiled wine 8.6.1 before I go converting more wine prefixes to this. It's a shame, because I'm mostly OK.

In testing Fallout 3, it didn't run correctly. I could hear the background audio, but the launcher program drew no window. So I ran the Fallout3.exe directly, and found that it needed to be "installed". It's a game that has to be installed correctly or it doesn't find mods and dlc, only the base game.

'Twas then that I found out that a lot of 32 bit programs won't indeed run, including GoG installers! Even for 64 bit games, the installers are 32 bit.

wine client error:124: sendmsg: Bad file descriptor

I get the same with a newly generated ~/.wine prefix (not only in lutris)

But other important programs won't run either, like the 32 bit wine mono installers

009c:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-8.0.0\\support\\removeuserinstalls-x86.exe" in experimental wow64 mode
00a4:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-8.0.0\\support\\installinf-x86.exe" in experimental wow64 mode

So, right now, for me, prefixes that updated properly STILL have old files that work. Updating a prefix doesn't remove files, if another dll was there it will still be there etc.

Some 32 bit games were OK running after being given new prefixes because they didn't run afoul of anything that wouldn't run. Like Just Cause 2 and Bioshock Infinite, for example.

This will not do for my system wine, obviously.


Last edited by Grogan on 23 August 2023 at 5:13 am UTC

I assume it's not ready indeed. Otherwise Wine project would have switched to a single binary already.

Well, I have to say I've now seen that this isn't completely appropriate yet for 32 bit games. I'm going to have to go back to the old method, moreover, I'm just going to go back to my recently recompiled wine 8.6.1 before I go converting more wine prefixes to this. It's a shame, because I'm mostly OK.

In testing Fallout 3, it didn't run correctly. I could hear the background audio, but the launcher program drew no window. So I ran the Fallout3.exe directly, and found that it needed to be "installed". It's a game that has to be installed correctly or it doesn't find mods and dlc, only the base game.

'Twas then that I found out that a lot of 32 bit programs won't indeed run, including GoG installers! Even for 64 bit games, the installers are 32 bit.

wine client error:124: sendmsg: Bad file descriptor

I get the same with a newly generated ~/.wine prefix (not only in lutris)

But other important programs won't run either, like the 32 bit wine mono installers

009c:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-8.0.0\\support\\removeuserinstalls-x86.exe" in experimental wow64 mode
00a4:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-8.0.0\\support\\installinf-x86.exe" in experimental wow64 mode

So, right now, for me, prefixes that updated properly STILL have old files that work. Updating a prefix doesn't remove files, if another dll was there it will still be there etc.

Some 32 bit games were OK running after being given new prefixes because they didn't run afoul of anything that wouldn't run. Like Just Cause 2 and Bioshock Infinite, for example.

This will not do for my system wine, obviously.

In my case work however i use 1 prefix for all and this prefix is created when use wine staging from deb packages

Respect fallout 3 of gog runs ok and sound is ok

!link

!link

personally maybe needs a previously wow64 staging prefix, however debian based distro is completly different than arch based distro

Curiously in my case just cause 2 dont work, in my case show this:

0328:fixme:vulkan:wine_vkAllocateMemory Using VK_EXT_external_memory_host

0364:err:d3dcompiler:D3DCompile2 <anonymous>:6:121: E5017: Aborting due to not yet implemented feature: Load() sampling index parameter.

however another thing can be affect is amd radv drivers are different than intel anv




Last edited by mrdeathjr on 23 August 2023 at 12:42 pm UTC

what I think happened with Fallout 3 is something in the wine prefix got overwritten. The game did run, but it needed reinstalling. Fallout 3 has something "sneaky" because it used to be a Games for Windows Live game. They've defanged it with a fake dll but there's something that makes the game need installing (it can't just be dropped in by copying). It won't find content.

If I could have reinstalled it (GoG installers wouldn't run) it would have worked. I switched it to another wine (my Proton-TKG) and it reinstalled OK. Converting it back to my wine 8.6.1 didn't break it again. Weird.

There is no benefit for me to use this new Wine implementation at this time, and a lot of problems with 32 bit applications. My 8.6.1 built the normal way is 100% for everything I use it for. Pretty easy choice :-)

I really wanted this to work. I convinced myself that I was just going to work around all the problems, but this will just be the start of the problems I would likely encounter. (I thought it was great until I started uncovering them)

The only good thing about beating your head against the wall is that it feels good when you stop :-)


Last edited by Grogan on 23 August 2023 at 6:53 pm UTC

what I think happened with Fallout 3 is something in the wine prefix got overwritten. The game did run, but it needed reinstalling. Fallout 3 has something "sneaky" because it used to be a Games for Windows Live game. They've defanged it with a fake dll but there's something that makes the game need installing (it can't just be dropped in by copying). It won't find content.

If I could have reinstalled it (GoG installers wouldn't run) it would have worked. I switched it to another wine (my Proton-TKG) and it reinstalled OK. Converting it back to my wine 8.6.1 didn't break it again. Weird.

There is no benefit for me to use this new Wine implementation at this time, and a lot of problems with 32 bit applications. My 8.6.1 built the normal way is 100% for everything I use it for. Pretty easy choice :-)

I really wanted this to work. I convinced myself that I was just going to work around all the problems, but this will just be the start of the problems I would likely encounter. (I thought it was great until I started uncovering them)

The only good thing about beating your head against the wall is that it feels good when you stop :-)

In my case fallout 3 with gog gfwl dont affect however i remember various titles have this virus called GFWL

Curiously in my case gog installers work ok, with this wine i test mighty switch force collection installer and others

My GoG installers would run too on an updated (but not newly created) prefix with the Wow64 build.