> However, it doesn’t require any additional .dlls to be shipped with the application.
Many video games already do this with all the proprietary middleware they use (Bink, SpeedTree, PhysX, etc). Most launchers (Steam, GOG, Epic, etc) also require their respective .DLLs. Many games also use D3D11On12. Many shipping games in my list have dxil.dll amongst their installed files.
Therefore, an honest question: what's the problem with shipping an additional DLL? The work done here to reverse-engineer and re-implement the code-signing is fantastic—especially the fact that it is bitwise equal to dxil.dll's output. But I am ridiculously lazy and prefer to take the easier way out, and would've just shipped the DLL.
This opensource implementation can be included in existing game engines without requiring the programmer to know or understand what dxil.dll even is. The Mach engine, for instance, can use this to create a compiler that compiles zig code into shaders across all its targeted platforms in a way that doesn't require any additional setup or dependencies for the end user, it's just built into Mach's core.
There are more games than AAA games and there are more graphics applications than games. Something that is fine for your average 100GB AAA game may not be for a 30MB game (of which 24MB are DXC) on itch.io or a 3D model viewer/converter/animator/whatever on someone's website.
In addition, even for AAA games (but also for other games and software, this adds extra dependencies that may be broken outside your control. At a company i worked several years ago, we spent more effort upgrading Visual Studio because for some middle we only had DLLs (and their libraries) to link against and had to obtain new versions (part of the effort was that the company that wrote said middleware hadn't upgraded their own so we also became QA for their compatibility with the newer VS, though i don't remember if there were any issues in practice).
Of course having the code doesn't mean updates will be frictionless, but there will certainly be way less friction and you wont need to wait for someone else.
(btw i think Visual Studio has tried to be backwards compatible in recent versions with binary C++ libraries, but i don't think this is something you can rely on in the long term)
Also all that are with the assumption that the requirement is that your code remain on the same platform and targets. But at some point you may want to work with another platform (be it as host or target) and not having source code can make that from incredibly difficult to impossible. This may not seem much of an issue for something as platform-specific as DXIL - but actually notice the article mentioning that the binary blobbiness of DXIL made it impossible to precompile shaders on platforms outside specific Windows and Linux architectures for which the DLL was provided by Microsoft.
Many video games already do this with all the proprietary middleware they use (Bink, SpeedTree, PhysX, etc). Most launchers (Steam, GOG, Epic, etc) also require their respective .DLLs. Many games also use D3D11On12. Many shipping games in my list have dxil.dll amongst their installed files.
Therefore, an honest question: what's the problem with shipping an additional DLL? The work done here to reverse-engineer and re-implement the code-signing is fantastic—especially the fact that it is bitwise equal to dxil.dll's output. But I am ridiculously lazy and prefer to take the easier way out, and would've just shipped the DLL.