Gallium Nine (winetricks) seems to be broken since Wine 8.3

[lorn10]

Hi all

Unfortunately it happened again. It really looks that Gallium Nine (installed via winetricks) is broken in Wine 8.3 devel.

When I start a d3d9 application like the CXBX-R Xbox emulator then I get on the CLI:

0024:err:module:import_dll Loading library d3d9.dll (which is needed by L"Z:\\home\\urs\\Downloads\\Cxbx\\2022\\cxbx.exe") failed (error c000012f).
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\urs\\Downloads\\Cxbx\\2022\\cxbx.exe" failed, status c0000135

This worked normally in Wine 8.2 (and earlier).

[dhewg]

We just switched the CI setup to ubuntu 20.04, so the builds are compiled with a more recent WINE. Does the build attached here work? https://github.com/iXit/wine-nine-standalone/actions/runs/4337549042

[dhewg]

v8.3 removed libwine, and our releases link to it. winegcc of the version we used to build a releases automatically links it tough. Ignore the version above, here're two, please give each one a spin: https://github.com/dhewg/wine-nine-standalone/actions/runs/4343698597 I guess 20.04 doesn't work and 22.04 does?

[lorn10]

Really sorry to say this, - I am just a more "technical interested" end-user with no compiling experiences. :wink:

Yes, I am on Kubuntu 22.04 LTS and I am also using the oibaf PPA (which includes latest Mesa devel Gallium Nine).

Currently installed is: Mesa 23.1.0-devel (git-0d8a54f 2023-03-06 jammy-oibaf-ppa)

Gallium Nine is installed trivially via winetricks galliumnine.

[dhewg]

np, you don't have to compile anything. There're two downloadable "Artifacts" in that last link. Those are binaries, please test each

[lorn10]

Yes, it really works again! :+1:

I have downloaded the ubuntu-22.04 variant and decompressed its "gallium-nine-standalone" folder into the home directory. Then I run chmod +x nine-install.sh and after that I have applied the script at one of my gaming prefixes WINEPREFIX=~/.wine_AHiT ./nine-install.sh.

Gallium Nine was successfully installed. Will look somewhat deeper into that but I think it works as it should.

[dhewg]

Alright, I assume the 20.04 version doesn't work just as the latest version from winetricks?

[dhewg]

For the details I have opened https://bugs.winehq.org/show_bug.cgi?id=54635 Let's see if that can be fixed for WINE or if we have to handle that

[lorn10]

Great, - will test the 20.04 build today evening at my 20.04 LTS iMac computer. :+1:

[dhewg]

Sorry, I meant to try the 20.04 build on your 22.04 Kubuntu. It's just on what distro/wine version this was built. The issue is related to specific versions.

[lorn10]

Okay, I have tried it at a different prefix with the 20.04 package and I am getting:

test@iMac-tmp:~/gallium-nine-standalone$ WINEPREFIX=~/.wine ./nine-install.sh
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
installing 32bit binaries to /home/test/.wine/dosdevices/c:/windows/syswow64
installing 64bit binaries to /home/test/.wine/dosdevices/c:/windows/system32
enabling gallium nine
wine: failed to start L"C:\\windows\\system32\\ninewinecfg.exe"
wine: failed to start L"C:\\windows\\system32\\ninewinecfg.exe"
Es konnte keine Anwendung gestartet werden, oder es ist keine Anwendung mit der angegebenen Datei verknüpft.
ShellExecuteEx fehlgeschlagen: Datei nicht gefunden.

While the 22.04 variant is working. :+1:

[dhewg]

Alright, as suspected. Thanks for the confirmation!

[toni-klimaks]

Okay, I have tried it at a different prefix with the 20.04 package and I am getting:

test@iMac-tmp:~/gallium-nine-standalone$ WINEPREFIX=~/.wine ./nine-install.sh
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
installing 32bit binaries to /home/test/.wine/dosdevices/c:/windows/syswow64
installing 64bit binaries to /home/test/.wine/dosdevices/c:/windows/system32
enabling gallium nine
wine: failed to start L"C:\\windows\\system32\\ninewinecfg.exe"
wine: failed to start L"C:\\windows\\system32\\ninewinecfg.exe"
Es konnte keine Anwendung gestartet werden, oder es ist keine Anwendung mit der angegebenen Datei verknüpft.
ShellExecuteEx fehlgeschlagen: Datei nicht gefunden.

Hello. I am getting the same message. When installing the binary version. (nine-install.sh) Does it look like it's working?

enabling gallium nine

But I can't login to the GUI.

wine: failed to start L"C:\\windows\\system32\\ninewinecfg.exe"
Es konnte keine Anwendung gestartet werden, oder es ist keine Anwendung mit der angegebenen Datei verknüpft.
ShellExecuteEx fehlgeschlagen: Datei nicht gefunden.

It does not matter if it works, but I would like to understand why this error occurs and how to fix it.

[dungeon007]

Probably binary is better to have one LTS and one RNR versions. So users of stable WINE versions to use LTS... and Rock 'n' Roll for else, he, he :D But lets hope if backward compat could be fixed somehow and wont be broken, to not need to run into that. I guess if Ubuntu 20.04 and Debian 11 do not default to WINE 5, but let say to 6... then this shouldnt be a biggie, so just make a new binary release requiring WINE 6 or up and so be it. 22.04 have that 6, Debian 12 have 8, so. Niciest is one to rule them all, but maybe it is just a time to bump it up....

[lorn10]

@toni-klimaks When you are on Wine 8.3 you can use the 22.04 named build, - even if you use (K)Ubuntu 20.04 LTS. :wink:

[lorn10]

@dungeon007 It looks that at least Ubuntu 20.04 is still using Wine 5.x as default build. So it was not upgraded in the original PPA to any higher version.

And that's in some way also one reason for the problems here I think. (If they would use Wine 6.x the above mentioned 22.04 package should work.)

[dhewg]

But then we might have different problems, as a binary build with a newer WINE won't work on an older WINE.

[dungeon007]

That is why i propose LTS and RNR versions, slow moving vs fast moving targets :D I guess you can built one even against WINE 2 that works on WINE 8 isnt it? So that binary could be called LTS (assuming stable users and these requiring backcompat) or if this gets fixed or be figured out by the time, anyhow there is no push as there is a time. Meanwhile RNR version could go wild without so much compat, and where you can always assume most recent and not so much backcompat. Just look at a DXVK 2.0 release that happened. They release it requiring VK 1.3 and WINE 7.1. At the time even stable WINE 8 wasnt released yet and they dont support even 7. That was like just 9 months of backward compatibility :D

[dhewg]

I guess you can built one even against WINE 2 that works on WINE 8 isnt it?

Up to 8.2, 8.3 obviously not anymore

And if possible I'd like to keep the "one binary works everywhere" approach, I'm looking at possible hacks atm

[dhewg]

Can you guys please test if this build ("Artifact") works for you? https://github.com/dhewg/wine-nine-standalone/actions/runs/4365790268

Does someone have WINE v5.0 to check if it works there?

[dungeon007]

Why 5 that is too new, when i have 4, just WINE 4.0.4 32bit. so: $ ./nine-install.sh installing 32bit binaries to /home/me/.wine/dosdevices/c:/windows/system32 wine64 not found, skipping 64bit enabling gallium nine err:d3d9nine:__wine_dll_register registering DLL for WINE backwards compatibility err:d3d9nine:__wine_dll_register registering DLL for WINE backwards compatibility

It kind of erroring out there, but GUI behave OK and games actually working OK too.

$ wine ninewinecfg err:d3d9nine:__wine_dll_register registering DLL for WINE backwards compatibility err:d3d9nine:__wine_dll_register registering DLL for WINE backwards compatibility 0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32e794,0x00000000), stub! 0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32e794,0x00000000), stub! 0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",1,0x32e794,0x00000000), stub! 0009:fixme:win:EnumDisplayDevicesW ((null),1,0x32e794,0x00000000), stub! Native Direct3D 9 v0.9.0.395-devel is active. For more information visit https://github.com/iXit/wine-nine-standalone

Seems to work in practice, regradless of erroring out one or two lines constantly on init like this:

err:d3d9nine:wine_dll_register registering DLL for WINE backwards compatibility err:d3d9nine:wine_dll_register registering DLL for WINE backwards compatibility

And it works on WINE 2.0.5 too, same way like on 4.0.4 on this... throwing err, but works. So works far away, if that is just a false possitive err.

[dhewg]

Ok, thanks! The err:d3d9nine:__wine_dll_register registering DLL for WINE backwards compatibility message is new, it's not an error, just something I added to confirm if that code is executed. But there's another issue with those binaries on v8.3, let's see if that fixable...

[dhewg]

It's a tricky situation :\ Can you guys please give this build a spin? https://github.com/dhewg/wine-nine-standalone/actions/runs/4371650304 Please try to test that against older WINE versions!

[dungeon007]

Now the opposite of yesterday. Works on 8.3, fails on 4.0.4 with:

$ ./nine-install.sh installing 32bit binaries to /home/me/.wine/dosdevices/c:/windows/system32 wine64 not found, skipping 64bit enabling gallium nine wine: Bad EXE format for C:\windows\system32\ninewinecfg.exe.

On WINE 2.0.5 the same as on 4.0.4. Meanwhile on 5.0.5, looks like same distance just a bit different wording:

$ ./nine-install.sh installing 32bit binaries to /home/me/.wine/dosdevices/c:/windows/system32 wine64 not found, skipping 64bit enabling gallium nine 002e:err:module:__wine_process_init failed to load L"C:\windows\system32\ninewinecfg.exe", error c000012f

Works on 8.0... lemme check 6.0.4, but i guess it works there... yep, it works on 6.

One breaks newer, other breaks older... so, sounds like LTS and RNR. libwine vs no libwine builds, if it cant be just one then two to rule them all.... install this one if you have libwine (WINE 2-8) or the opposite (require WINE 6+), really 5.7 and 8.3 but whatever, i guess it is more clear for an user if you write rounded numbers :D If you like, you can name them even LEGACY and CURRENT(RNR or NO NAME works too :D), so if somebody wanna go far back then use legacy build, otherwise for current build WINE 6 is a minimal req. Legacy you can build on 18.04, but this newest if built on 22.04 and 6 would also raise glbc req too much, but well it is not ideal for going back anyway. And then what will 20.04 user do, if he wanna newest (not always) the greatest? It is stupidly tricky this way in various ways. Maybe just install Ubuntu 18.04 in a virtual machine plus WINE repos, it have all troubled versions... and build both there against default and 6 . :D

[dhewg]

I don't like any of that option because that's just too much bending over for what? If we don't find a way to extend the compatibility, the next version will just be for WINE >=v5.7. For older versions one can always use the current version. I think that should work for everybody?

[dungeon007]

Well, i saw that Ubuntu 18.04 also have 8.3 in WINE repos... so that is why i started to think this way. But if that scenario is not supported anymore, then OK, you can do build with higher glibc req. How much they will still build for 18.04, no idea. I could only guess, by let say looking as how much they building it for Debian 10, from 2017-06-23 to 2022-09-10, so like 5 years 2,3 months. And since first build for Ubuntu 18.04 was in 2018-06-16 i could only guess they will stop at about august/september, but today it seems is kind of still supported.

[dhewg]

18.04 will be unsupported in ~3 weeks as CI, so that's out of the picture anyway.

So you need 20.04 for the next v0.9 in any case as that's going to be binary incompatible for older distros. One can use v0.8 for older distros. Same for WINE <v5.7. 22.04 is the current LTS, which is ~1year old. With that v0.9 will work with just the ubuntu wine package.

And all of that is just specific to the binary releases here. Building from source works everywhere.

Sounds okay to me?

[dungeon007]

Yep, sometimes things does not exactly match everywhere. Couple weeks here, couple months there. Sure building source is OK, we are just talking about binary to serve them all versions and i guess all users, minus some, time, sometimes :D

"22.04 is the current LTS, which is ~1year old. With that v0.9 will work with just the ubuntu wine package."

Sounds like building on 22.04 will break not just 18.04 but even 20.04 users, but as you wish. For me it sound OK, if there is not other solution, go on. But OK, i see you wanna do it on 20.04 against winehq 6.0, that is completely OK, just note req in release note.

[dhewg]

I confirmed that this build https://github.com/dhewg/wine-nine-standalone/actions/runs/4373801118 works on v5.7 but not on v5.6. And it works on v8.3.

@lorn10 & @toni-klimaks can you please test if that version works for you? It it does I'll push it and release it as v0.9

[dungeon007]

It works, if you ask me. Such build should work on distros like Ubuntu 20.04 / Debian 10 or later. And on WINE 5.7 or later.

Including offender such as 8.3 :D Please use 0.8 release, if you need WINE 2, 3, 4, 5 backward compatibility.

And on 0.9 you can say we have to break backcompat to certain degree, because of libwine removal, sorry.

That gave me idea, maybe together with 0.9 (RNR) you can also do 0.85 (FSH) binary release with included changes from 0.9, but built on 18.04 while it still lasts... just to say one good farewell to that for the last time and thanks for all the fishes. THat would also make a backward compatibility note more clear, Rock 'n' Roll & Fishes :D

[lorn10]

This seems to work, - but with some strange messages which aren't present at the 22.04 labeled build:

Edit: This was because no prefix was present with the corresponding name and then there was made a new prefix while Gallium Nine was installed at the same time. This resulted then in those error messages.

tmp@iMac-tmp:~/gallium-nine-standalone$ WINEPREFIX=~/.test_g9install ./nine-install.sh
wine: created the configuration directory '/home/tmp/.test_g9install'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0050:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0050:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0050:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0050:err:ole:start_rpcss Failed to open RpcSs service
0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0048:fixme:imm:ImeSetActiveContext (000000000001002E, 0): stub
0048:fixme:imm:ImmReleaseContext (0000000000010020, 000000000001002E): stub
002c:fixme:imm:ImeSetActiveContext (0000000000010056, 1): stub
002c:fixme:imm:ImmReleaseContext (0000000000010054, 0000000000010056): stub
0094:fixme:file:NtLockFile I/O completion on lock not implemented yet
0094:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
009c:fixme:file:NtLockFile I/O completion on lock not implemented yet
009c:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
00ac:fixme:imm:ImeSetActiveContext (00000000000100A8, 1): stub
00ac:fixme:imm:ImmReleaseContext (000000000002009C, 00000000000100A8): stub
009c:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 5)
009c:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 5)
0094:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1)
0094:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1)
0108:fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
0134:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0134:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0134:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
wine: configuration in L"/home/tmp/.test_g9install" has been updated.
0134:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
installing 32bit binaries to /home/tmp/.test_g9install/dosdevices/c:/windows/syswow64
installing 64bit binaries to /home/tmp/.test_g9install/dosdevices/c:/windows/system32
enabling gallium nine
done

[dhewg]

While that release is build on 20.04, it was with winehq v6.0 packages. The other 22.04 build was using debian v6.0 packages. I don't see how that difference would yield those messages? It's more likely related to the WINE version you're installing this into?

Anyway, the debug spam looks unrelated to nine

[lorn10]

Yeah, my fault sorry. It looks that I have made a typing error and the above output is because there was established a new prefix while gallium nine was installed on the same time.

This is the output when the wine prefix is already present:

test@iMac-tmp:~/gallium-nine-standalone$ WINEPREFIX=~/.g9install ./nine-install.sh
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
installing 32bit binaries to /home/test/.g9install/dosdevices/c:/windows/syswow64
installing 64bit binaries to /home/test/.g9install/dosdevices/c:/windows/system32
enabling gallium nine
done

Everything okay! :+1:

[dhewg]

Released: https://github.com/iXit/wine-nine-standalone/releases/tag/v0.9

[dhewg]

winetricks PR which handles the incompatibilities: https://github.com/Winetricks/winetricks/pull/2044

[dhewg]

Should all be fixed then