directx9 can't be installed (in 64-bit wineprefix at least)

[Danfun64]

I'm testing Debian in a virtual machine, and am trying to install the directx9 package in wine (yes, I know it's "overkill", but...). Unfortunately, there appears to be something... off ... with directx_feb2010_redist.exe

http://paste.debian.net/1063871/

I'm running Debian Testing with the winehq repository and the latest winetricks. I was hoping to play a 64-bit only game, hence why I'm using a 64-bit wineprefix.

[Danfun64]

I suspect the problem involves cabextract. Maybe I shouldn't be using the debian repository cabextract with winehq wine?

I tried bypassing the directx9 package but I still had issues. I also had issues with Visual C++ 2010 x64.
http://paste.debian.net/1064230/

[austin987]

What version of cabextract do you have?

[Danfun64]

1.9-1 . Checking the version revealed that at least part of the problem wasn't with cabextract. The main change of 1.9-2, which is what SID uses, is "Force libmspack0 version >= 0.9.1-1 to avoid bugs in that package". Lo and behold, libmspack0 in Debian Testing is 0.8-1 as of this writing, with SID of course having the newer version. Having backported libmspack0 0.9.1-1 to Testing, I deleted my wineprefix and cache and started from scratch. I'll let you know the results in a moment.

[Danfun64]

http://paste.debian.net/1064520/

[austin987]

Executing wine64 regsvr32 quartz.dll
0009:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\devenum.dll"
0009:err:ole:CoGetClassObject no class object {4315d437-5b8c-11d0-bd3b-00a0c911ce86} could be created for context 0x3
regsvr32: Failed to register DLL 'quartz.dll'

Yeah, it's a real issue, but only in 64-bit. I'll take a look.

[austin987]

When registering quartz, it loads devenum. While winetricks has 32/64 bit quartz, there's only 32-bit devenum, so it fails to load.

We'll probably have to find a 64-bit devenum, but the only one I've found is a .msu (https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2016/ms16-007)

[austin987]

For a workaround, we could skip those dlls on win64:
austin987@834c279

does that, if you'd like to test.

@gverm what do you think, since you added those dlls? I suspect qcap may need to go too (it at least registers without issue).

[gverm]

@austin987 Wouldn't skipping them defeat the purpose of the verb? Maybe, although unfortunate, we should not allow directx9 to be used in a 64bit prefix?

Also, does this bug affect other verbs that call quartz, e.g. directmusic?

[yurirc]

Hi, Guys. @Danfun64 I don't know if this is your problem too but I was having problems installing directx on debian via winetricks. Looks like is really a problem with cabextract 1.9-1 on debian. Option -F is corrupting files or something like that.
Here is the report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914263
Problem is solved in version 1.9-2 (unstable).
Hope this helps!

[Danfun64]

That was my first problem, but I figured it out fairly quickly. The problem now is that Microsoft 64-bit devenum is hard to find apparently.

As I mentioned, the main difference between cabextract 1.9-1 and 1.9-2 appears to be that 1.9-2 requires a newer version of libmspack0.

[yurirc]

Oh sorry! Newbie thing. I read your messages but doesn't figured it out.

[gverm]

@austin987 Ping (for my previous comment)

[austin987]

Hi @gverm

Thanks for the ping (and sorry for missing your comment before).

I didn't realize that native directmusic called quartz. This is a tricky one. AFAICT, some dlls would still be useful (e.g., d3dx), but can be installed via separate verb. The dpn* stuff is only 32-bit on 64-bit windows AFAIK, so those also shouldn't attempt to be registered as 64-bit (though registering only as 32-bit should work).

My initial thought is that directx9 should be win32 only, but in the process, we should:

1. Add individual verbs for everything under directx9 that doesn't have one (e.g., dxdiag.exe). Some may not be feasible, and others may belong under different verbs (e.g., dpnaddr/dpnlobby are in directx9, but not directplay).
2. When running directx9 under 64-bit mode, mention the others verbs that they can use.
3. Probably do 2) under 32-bit as well, to discourage use of directx9 in general.

For 2/3, my thought is something like:
64: "directx9 is not supported under 64-bit prefixes. Please try $verb1 $verb2 ... instead which are supported under 64-bit prefixes."
32: "Using directx9 is discouraged, as it is very invasive. Please try $verb1 $verb2 ... instead, depending on what dlls you need."

(better wording of course preferred).

[austin987]

Feedback would be appreciated by everyone ^

[zfigura]

Is there really any reason for directx9 to exist?

[austin987]

At this point, mostly historical. I mostly avoided touching it since it's references so many places (for better or worse).

My initial thought is that it should be deprecated and replaced with a warning and replacement verbs, but I'd a wider discussion changing it.

Given that you've touched several directx components recently @zfigura, I'd love your input.

[zfigura]

I don't get the impression it's ever common to need all of native DirectX, or even most of it. For developers I get the impression it makes things a little more difficult since it means polluting the prefix, and when something is fixed with directx9 it's not clear even what part of Wine the problem is in. I honestly had the impression it was already kind of deprecated. I'm trying to think of reasons to keep it around, but besides not breaking people's scripts, I'm not sure I can think of any.

But perhaps others have different opinions.

[austin987]

@zfigura I've wanted to remove it for a while, guess I was subconsciously waiting for someone to ask :).

b5545c3 feedback welcome, particularly on the wording.

[zfigura]

I don't know if it's common to check the exit code of winetricks, but since that verb is no longer doing what is expected, it may make sense to return nonzero exit code in that case (i.e. w_die I guess).

[austin987]

I was debating that. Then I had the thought that it was often called when it wasn't needed. I'll think on it some more.

[zfigura]

That's a fair point. I'd still lean towards failing in this case, as a way of warning people that calls to directx9 should be replaced, even if it should be replaced with nothing.

I did a quick search of bugzilla, and less than 50 (and perhaps significantly less) bugs report using directx9. About half of the ones I checked also report using individual verbs that are installed by directx9 (e.g. people will do winetricks directmusic directplay directx9). The impression I get is that most people assume they should use it because the game uses DirectX 9 (usually meaning that it uses Direct3D 9) and doesn't work OOTB. Sometimes this works and sometimes it doesn't.

[austin987]

Thinking about this a bit more, I agree that returning an error makes sense.

However, I'd like to minimize collateral damage, so my plan is to make a release soonish, then make this commit afterward, so it only affects git users, and regressions can be fixed before the next release.

[DarkShadow44]

FWIW, the same quartz issue also affects directmusic, which I sometimes use to fix issues with old games.

[austin987]

Directmusic/quartz situation is #1263.

winetricks directx was removed in 181441a