You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that is_nine_symlink reads the symlink file d3d9.dll and compares the returned target with the hard-coded string d3d9-nine.dll, shouldn't the function nine_set call create_symlink to let d3d9.dll directly target d3d9-nine.dll instead of targetting the dli_fname of d3d9-nine.dll?
For the install carried out using nine-install.sh, d3d9.dll is a symlink targetting d3d9-nine.dll, which in turn is another symlink targetting d3d9-nine.dll.so. In such a setup, dli_fname of d3d9-nine.dll is the same - d3d9-nine.dll.
But when installed using wine-nine package of Arch Linux, d3d9-nine.dll isn't a symlink but a fake-dll d3d9-nine.dll.fake renamed to d3d9-nine.dll. For such a setup, the dli_fname of d3d9-nine.dll is d3d9-nine.dll.so. Arch's install seems to follow the same division for this wine dll as it does for other wine dlls/exes - the fake dll gets inserted into a dir i686-windows while the corresponding so gets installed into a dir i686-unix. The pairs aren't linked through a symlink, as assumed by nine.
But this setup breaks the assumption, made by is_nine_symlink, that d3d9.dll targets d3d9-nine.dll. Here, d3d9.dll targets d3d9-nine.dll.so.
If nineassumes that absolutely needs d3d9.dll symlink must to target d3d9-nine.dll (given the behaviours of is_nine_symlink and nine-install.sh), can it not call create_symlink directly for the d3d9-nine.dll instead of passing through dli_fname?
The issue that this breakage causes is that in the nine's UI, the "Enable Gallium Nine for better..." check-box remains unchecked, and cannot be checked even after clicking. Once nine is enabled through the cmdline ninewinecfg, it cannot be disabled, either through the command-line or through the GUI. These symptoms are the result of is_nine_symlink returning false.
After installing Arch's wine-nine and enabling it with ninewinecfg, one can manually retarget the d3d9.dll symlink to point to /....../i686-windows/d3d9-nine.dll, and the GUI checkbox shows nine as Enabled. The disabling of nine also works. That is, is_nine_symlink starts working as the target is now the same as the expected, hard-coded string d3d9-nine.dll.
The text was updated successfully, but these errors were encountered:
Given that
is_nine_symlink
reads the symlink filed3d9.dll
and compares the returned target with the hard-coded stringd3d9-nine.dll
, shouldn't the functionnine_set
callcreate_symlink
to letd3d9.dll
directly targetd3d9-nine.dll
instead of targetting the dli_fname ofd3d9-nine.dll
?For the install carried out using
nine-install.sh
,d3d9.dll
is a symlink targettingd3d9-nine.dll
, which in turn is another symlink targettingd3d9-nine.dll.so
. In such a setup, dli_fname ofd3d9-nine.dll
is the same -d3d9-nine.dll
.But when installed using
wine-nine
package of Arch Linux,d3d9-nine.dll
isn't a symlink but a fake-dlld3d9-nine.dll.fake
renamed tod3d9-nine.dll
. For such a setup, the dli_fname ofd3d9-nine.dll
isd3d9-nine.dll.so
. Arch's install seems to follow the same division for this wine dll as it does for other wine dlls/exes - the fake dll gets inserted into a diri686-windows
while the correspondingso
gets installed into a diri686-unix
. The pairs aren't linked through a symlink, as assumed bynine
.But this setup breaks the assumption, made by
is_nine_symlink
, thatd3d9.dll
targetsd3d9-nine.dll
. Here,d3d9.dll
targetsd3d9-nine.dll.so
.If
nine
assumes thatabsolutely needsd3d9.dll
symlinkmustto targetd3d9-nine.dll
(given the behaviours ofis_nine_symlink
andnine-install.sh
), can it not callcreate_symlink
directly for thed3d9-nine.dll
instead of passing through dli_fname?The issue that this breakage causes is that in the
nine
's UI, the "Enable Gallium Nine for better..." check-box remains unchecked, and cannot be checked even after clicking. Oncenine
is enabled through the cmdlineninewinecfg
, it cannot be disabled, either through the command-line or through the GUI. These symptoms are the result ofis_nine_symlink
returning false.After installing Arch's
wine-nine
and enabling it withninewinecfg
, one can manually retarget thed3d9.dll
symlink to point to/....../i686-windows/d3d9-nine.dll
, and the GUI checkbox showsnine
as Enabled. The disabling ofnine
also works. That is,is_nine_symlink
starts working as the target is now the same as the expected, hard-coded stringd3d9-nine.dll
.The text was updated successfully, but these errors were encountered: