Wine fails to load executables that reference dxil.dll

[Graham Wihlidal]

Hello!

I have been doing a lot of recent work in getting Windows graphics utilities (especially shader compilers) running on Linux, and some of these tools require Wine to operate correctly. The new DirectX shader compiler now compiles on Linux, but the signing must occur using a signed validator (dxil.dll that ships with Windows 10).

I wrote a little utility that loads dxil.dll and can do dxil signing post-compilation, and the hope was to run this in Wine, but I get some errors when trying to do so. I blogged about the adventure here: https://www.wihlidal.com/blog/pipeline/ ... t-compile/https://www.wihlidal.com/blog/pipeline/2018-09-16-dxil-signing-post-compile/

I'm hoping someone can shed some light on what the issue here is, preferably with a fix or some instructions on how to debug this on my end. My utility that reproduces the Wine error is open source in case someone wants to give it a whirl (prebuilt Windows binaries in the releases area): https://github.com/gwihlidal/dxil-signing

Thank you,
Graham

[Stefan Dösinger]

Hi,

Going by the following line in your blog:
> wine: Call from 0x7b44d447 to unimplemented function api-ms-win-crt-private-l1-1-0.dll._o__initialize_onexit_table, aborting

This line says that dxil.dll (or something else - we don't know where the call is coming from) calls a function in Wine's api-ms-win-crt-private-l1-1-0.dll that we do not yet implement. The correct solution is to implement the necessary function(s). A stop-gap workaround is to use the native (Microsoft's) version of this DLL. Because this DLL usually just contains forwards to other DLLs, mostly ucrtbase, you'll also need native ucrtbase and probably others.

You can use the native DLL by dropping the .dll file in C:\windows\syswow64 and/or C:\windows\system32 and setting the DLL to native or native, builtin with winecfg. This will also fix the earlier problem that made you solved via static CRT. Using static CRT has the same effect, except that you embed the CRT in the binary. Note that the MS CRT license agreement probably prohibits you to redistribute the CRT for non-Windows operating systems.

Stefan
> Am 02.12.2018 um 15:12 schrieb Graham Wihlidal :
>
> Hello!
>
> I have been doing a lot of recent work in getting Windows graphics utilities (especially shader compilers) running on Linux, and some of these tools require Wine to operate correctly. The new DirectX shader compiler now compiles on Linux, but the signing must occur using a signed validator (dxil.dll that ships with Windows 10).
>
> I wrote a little utility that loads dxil.dll and can do dxil signing post-compilation, and the hope was to run this in Wine, but I get some errors when trying to do so. I blogged about the adventure here: https://www.wihlidal.com/blog/pipeline/ ... t-compile/ https://www.wihlidal.com/blog/pipeline/2018-09-16-dxil-signing-post-compile/
>
> I'm hoping someone can shed some light on what the issue here is, preferably with a fix or some instructions on how to debug this on my end. My utility that reproduces the Wine error is open source in case someone wants to give it a whirl (prebuilt Windows binaries in the releases area): https://github.com/gwihlidal/dxil-signing https://github.com/gwihlidal/dxil-signing
>
> Thank you,
> Graham

[Fabian Maurer]

Hello Graham,

I've submitted 2 Patches to address this issue. For me the program seems 
to work now, but I can't verity the signing was done correctly. Mind 
testing this out?

The patches are https://source.winehq.org/patches/data/155381 and 
https://source.winehq.org/patches/data/155382

Regards,
Fabian Maurer

[Graham Wihlidal]

Thank you very much!

I haven’t built Wine from source before, what’s the easiest way to accomplish that? Can either build it on macOS or Arch Linux (whichever is easiest). Should I just clone latest Wine source, and apply your patches on top?

Cheers,
Graham

From: Fabian Maurer 
Date: Sunday, December 2, 2018 at 4:02 PM
To: "[e-mail]" 
Cc: Graham Wihlidal 
Subject: Re: Wine fails to load executables that reference dxil.dll

Hello Graham,

I've submitted 2 Patches to address this issue. For me the program seems to work now, but I can't verity the signing was done correctly. Mind testing this out?

The patches are https://source.winehq.org/patches/data/155381 and https://source.winehq.org/patches/data/155382

Regards,

Fabian Maurer

[Fabian Maurer]

Hello Graham,

yes, checkout latest source and apply the patches on top.

I for my part work on Arch Linux, so that's easiest to me.
Just configure and make should work fine, if you have problems feel 
free to contact me.

Regards,
Fabian Maurer

[Graham Wihlidal]

Hi Fabian,

Your patches did the trick! My signing tool is now able to successfully load and call into dxil.dll correctly.

Any idea how long until these patches are available in a version of Wine?

Thank you,
Graham

From: Fabian Maurer 
Date: Sunday, December 2, 2018 at 4:19 PM
To: "[e-mail]" 
Cc: Graham Wihlidal 
Subject: Re: Wine fails to load executables that reference dxil.dll

Hello Graham,

yes, checkout latest source and apply the patches on top.

I for my part work on Arch Linux, so that's easiest to me.

Just configure and make should work fine, if you have problems feel free to contact me.

Regards,

Fabian Maurer

[Fabian Maurer]

Hello Graham,

Good to hear.
I don't know when they will be accepted, but I guess if not before codefreeze 
(7.12.) they'll have to wait until mid January. But then again, it's not really big 
changes, so maybe it goes fast.
Always depends on whether I made a mistake, too.

Regards,
Fabian Maurer