pouët.net

Hello fellow Demosceners!



The new Revision 64k Compo Rules mention that they are "controversial". Welcome to that controversy.



1. Introduction

1.1. TL;DR

The Revision 2025 Compo Rules dropped a few weeks ago and 64k Intros are now allowed to use certain DirectX 12 DLLs, some of which are not part of any standard Windows install. We think that this rule change in particular does not achieve what it is trying to achieve, and would change what 64k is all about. Furthermore we think this rule change was announced really way too late for this Revision.

We would like to appeal to everyone to keep their 64k Intros real and not make them depend on additional non-standard DLLs. We would like to see this change revoked.

1.2. Background

Newer 3D APIs like Vulkan and DirectX12 are more difficult to use with size restrictions than older ones.

These APIs no longer provide a shader compiler that can compile shader source code into a binary form which is usable by the API framework or driver as part of either the API runtime framework itself, or as part of the driver. So, you either have to pre-compile shaders to a binary format, or ship a compiler, which would exceed the 64k limit.

One concern with this whole situation is that PC sizecoding might get stuck on older APIs (OpenGL and DirectX 11) due to these obstacles. Therefore one would be unable to take advantage of modern GPU features. How much this is already the case, or will be the case in the future, is not 100% clear, but at least that was the concern that got people thinking about potential solutions that involve compo rules changes.

There was a discussion among a decent number of 64k coders with the Compo organizers at Revision 2024. There was an attempt to also include remote people, but that didn't really work, and the ad hoc nature of that meeting meant that it was not at all representative - which is okay, nobody claimed that it was supposed to be. There were several proposals for things that might be a possible rule change (most of them a variation of "make a standard DLL package"), and there was no real consensus. A good amount of people were against any kind of rule alteration, and those in favour agreed that more research was needed to find out what to do exactly, if anything. If memory serves, the only real consensus was that whatever happened, it would need to be communicated well in advance of the actual change happening. As far as we know, none of this has been communicated publicly after Revision 2024.

Now, we do see a change in the Compo rules, very late in the cycle, a bit hidden in the small print, and on top of this the details of the change itself are a bit weird in our opinion (see "Technical Aspects" below). We are confused about all that and would like to raise some objections. Please keep in mind that we have lots of love and respect for those who organize Demoparties in their own free time, and we are thankful for everyone who contributes in whichever capacity. We just think that a rule change like this is not going in a good direction and even questions core Demoscene principles (see "Cultural Aspects" below).



2. The Rule Change



(https://2025.revision-party.net/competitions/pc/)

This change is neither mentioned on the new and noteworthy page (https://2025.revision-party.net/competitions/new-and-noteworthy/), nor in the compo rules announcement (https://2025.revision-party.net/blog/05-compo-rules/).



3. Technical Aspects

3.1. dxcompiler.dll and Compressibility of Binary Shaders

dxcompiler.dll is the Microsoft DirectX Shader Compiler that allows compiling HLSL code into DXIL binary. It does not by itself enable the use of modern hardware features. All this change does is help with compression. Modern features can be used perfectly well by shipping DXIL code in Intros.

Revision stated it does not want 64k Intros to be unable to access modern hardware features. We then have to question why this change was only implemented for DirectX but not for Vulkan, which is in a very comparable situation with GLSL->SPIR-V shaders. This appears to give Direct3D an arbitrarily crafted unfair advantage compared to Vulkan with no explanation given. The DirectX Shader compiler is only shipped in the Windows SDK (and as a completely separate Open Source project) and not with any system installation of DirectX. Neither is any of the SPIR-V shader compilers installed by any Vulkan driver. While we would also disagree with implementing a similar change for Vulkan, among other things for obvious fairness reasons, we strongly disagree with making the DirectX Shader Compiler available for 64k Intros.

DirectX 12 is not excluded from being usable in 64k Intros because of its use of binary shaders, and neither is Vulkan. This whole "issue" is nothing new. The challenges involved with using binary shaders have been known since at least back in 2012 when SPIR-V was originally discussed and released. We do have a pretty good plan of what would be necessary to tackle these challenges once the need arises for us. This is not trivial at all, such is true, however we do not consider this unsolveable at all. As far as we know, frankly nobody has even tried hard enough yet to consider claiming anything else.

3.2. d3d12core.dll

D3D12Core.dll is the Direct3D system runtime (called simply D3D12.dll in earlier versions). D3D12.dll has been split up into a smaller loader part in D3D12.dll that loads the actual runtime from D3D12Core.dll. This change was made by Microsoft in order to facilitate applications using more modern versions of D3D12 (as published via the Direct3D Agility SDK) compared to what is provided with the system itself (https://devblogs.microsoft.com/directx/gettingstarted-dx12agility/). D3D12 is still updated with every Windows Update Release though, and all changes/features are supposed to land there eventually. Direct3D in Windows 10 is not updated anymore, because support for Windows 10 is being phased out in general. The version of D3D12Core.dll as shipped by Windows 11 24H2 is only slightly behind the version referenced in the Revision Compo rules (v612 vs v615) (https://devblogs.microsoft.com/directx/directx12agility/).

The most notable changes between these versions are Shader Model 6.8 and Work Graphs. As far as we understand, some newer D3D12 features do additionally require operating system support of the corresponding WDDM driver version while some others may not (https://en.wikipedia.org/wiki/High-Level_Shader_Language, https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-display-driver-model-design-guide). Windows 10 only supports WDDM 2.7 while Windows 11 24H2 supports WDDM 3.2 (https://en.wikipedia.org/wiki/Windows_Display_Driver_Model). We consider it somewhat insignificant which precise features are unavailable on Windows 10, as the fact alone that some of them are missing shows that the Revision Compo Rules changes do not actually provide what they claim to provide. It is not an inherent problem of Direct3D that makes "sizecoding to become another old-school competition banned from using modern hardware features". It is sticking to a severely outdated operating system that completely lacks modern features that does that. Switching to the latest Windows release would render ~50% of the "controversial" changes completely pointless.

D3D12Core.dll from the latest DirectX 12 Agility SDK still does provide features not available with the version shipped by Windows 11 24H2. Work Graphs (https://github.com/microsoft/DirectX-Specs/blob/master/d3d/WorkGraphs.md) however do not provide any qualitative new feature compared to not having them - they merely provide a possible performance optimization in avoiding unnecessary GPU<->CPU roundtrips. While it could certainly be desirable to have access to them for performance reasons, not having them is pretty far from what the Revision Compo Rules claim: limiting access to modern hardware features. A significant part of Work Graphs is not even implemented yet and merely "proposed" (https://github.com/microsoft/DirectX-Specs/blob/master/d3d/WorkGraphs.md#graphics-nodes), which makes Work Graphs a "beta" feature at best (which in turn somewhat warrants not being included in the Direct3D version as shipped by Windows). Shader Model 6.8 primarily deals with interfacing with Work Graphs (https://github.com/microsoft/DirectX-Specs/blob/master/d3d/HLSL_ShaderModel6_8.md). All other changes are very minor and also do not appear to be necessary to make use of modern hardware features.

Considering that this does not add much compared to what features would be available in Windows 11 24H2, it seems unnecessary to go through these lengths and supply D3D12Core.dll as an additional library.



4. Cultural Aspects

Compressing binary shaders requires different techniques and tools and skills compared to compressing source code. This might even imply that compressing binary shaders requires different people to work on these challenges compared to people who worked on compressing shader source code, may it be because of different skill sets or different interests. This is nothing new in the Demoscene. In the past, the skill set required to make good 64k or 4k or 8k Intros has shifted significantly multiple times, either due to external reasons (new hardware, new APIs), or due to internal reasons like new tools (20to4, 4klang, Crinkler, kkrunchy, Shader Minifier, Shadertoy, squishy, V2, ...) being publicly available that solve some aspect of Intro making in a good enough fashion for everyone to focus on other aspects from then on, or due to expert knowledge becoming common knowledge inside the Demoscene.

The inclusion of dxcompiler.dll in the provided environment completely takes away one such challenge. The 4k/8k/64k PC Intro scene has done that before only once, but that change has since been revoked (D3DX9_??.dll, see below). Addressing such challenges by external means takes away significance from people who enjoy working on such aspects of Intro making, and shifts the focus even more towards the generally more-exposed graphics coders and artists. There is no need to do that. For people who want to solely focus on the graphics APIs and assets, and do not want to be bothered by dealing with how to make the resulting Intro compressible, there has always been the Demo Compo. Taking away these challenges can be perceived as fundamental disrespect towards everyone who has worked on making 64k/8k/4k Intros feasible in the first place in the past. It also really takes away a core part of what the Demoscene is for a lot of people: It takes away making the seemingly impossible possible. It takes away the pride in what we are doing.

4.1. Outreach Effect

The Revision Compo Rules mention "[...] the effect you get from downloading a tiny file". In our experience, this is the single most important aspect of making the Demoscene comprehensible for moderately knowledgable people outside of the Demoscene. Arbitrarily adding additional libraries that are not available on stock installations supports one of the most uttered criticism frequently seen in Youtube and Pouet comments of Demoscene productions: "It's not 64k because it uses a huge graphics API runtime!". We do not need to discuss inside the Demoscene why this is a weak argument. The most important way to argue against that towards outside people is the equal playground (for Demoscene productions, as well as for games which Demoscene productions are most commonly compared against) that was established by the pre-existing and externally determined stock operating system installation. When the Demoscene requires downloading additional non-stock runtimes in order to be able to run any Intro, this makes defending against the argument brought up by outsiders completely infeasible. It makes the Demoscene as a whole implausible/inauthentic to outsiders. This in turn devalues the work of numerous people involved with Demoscene Outreach over the past years.

4.2. 4k/8k/32k/64k/96k Intros

We really do not see any argument in favour of such significant rule differences between these competitions. If a DLL counts towards the size limit for one of these competitions, it should count towards the size limit for all of them.



5. Legal Implications

The DirectX 12 Agility SDK and the Windows SDK grant explicit permission to distribute D3D12Core.dll and dxcompiler.dll for applications that make use of them. This does not automatically imply that anyone is allowed to do so independently of distributing an application. The likely holds also true for Revision as a hypothetical provider of a runtime package, which would be required to keep the Intros runable long-term. These DLLs are legally only distributable included with the application using them (see LICENSE-MS.txt in https://github.com/microsoft/DirectXShaderCompiler/releases/download/v1.8.2407/dxc_2024_07_31.zip).

5.1. Long-Term Forward Compatibility

Microsoft has shown in the past that it will not keep providing old versions of its software available for download forever. As dxcompiler.dll is only published as part of the Windows SDK (and as a separate Open Source project), this poses the risk that sometime in the future, when old Windows SDK versions are no longer supported, it may not be available for public download anymore. This might even happen sooner than anticipated when Shader Model 7 switches from DXIL to SPIR-V (https://devblogs.microsoft.com/directx/directx-adopting-spir-v/). As it is legally questionable to provide a separate "Demoscene Intro Runtime" for download, this could make it unnecessarily hard to run Intros in the future.



6. APIs

6.1. D3DX9_??.dll

D3DX9_??.dll was allowed to be used in 4k Intros at most parties for a long time. Microsoft published multiple versions of this DLL, which has made running 4k Intros difficult. Furthermore, Microsoft does not provide them for download anymore. These DLLs have to be sourced and installed separately and are not part of the core operating system. In later SDK versions, Microsoft absolutely unambigously documented that applications are supposed to distribute this DLL themselves, making it infeasible to use it in 4k/64k Intros.

6.2. API Advantages and Disadvantages

Without D3DX, Direct3D 9 Intros could maybe be considered disadvantaged against OpenGL Intros back then, and with D3DX they could be considered advantaged against OpenGL. There really was no fair solution either way. D3DX was also not necessary to access "modern hardware features". Using a different API, one that allows fitting the desired Intro into 4k, has always been an option back then, as well as it is now for 64k. We understand a size-limited Compo not as something that is made to allow for certain APIs to be usable, but instead as something that defines a clear frame and environment with which to work with. If one API is better suited than another API, then anyone with sufficient requirements is free to use the proper API for the job. However, we highly doubt that D3D12 or Vulkan are even at any significant disadvantage compared to OpenGL, or limited in what hardware features are feasibly accessible.

6.3. Vulkan / SPIR-V

We also do have additional arguments against doing the same, or something analogous, for Vulkan/SPIR-V as what has been done for Direct3D12. As this has not been announced at the moment, we prefer to keep silent on that matter for now, in order to keep the discussion focused.



7. Communication

We are somewhat confused about the lack of public communication about the supposed issue, the discussion, the conclusion, and the lateness of any such significant Compo Rules changes. In our experience, early January would have been the latest possible date for such a change to be announced in order to allow for working on a high profile 64k Intro.

After our internal discussions (and our conclusions as outlined here), we did contact the Revision 64k Compo organizer, and did ask about what the status of any such Compo Rules changes was, and did communicate our concerns. We offered to discuss our concerns, however, we sadly did not receive any response.

Then, after the expected Compo Rules did not go online with the release of the Invitation, we had actually assumed that the whole thing would not be on the table anymore because it was actually really way too late to implement any changes of that magnitude.

One of the reasons why this response is late is the very late and sudden announcement of the changed Rules.



8. Final Words

8.1. Demoscene

We would like to encourage the Demoscene to discuss changes of such significance in a more representative and transparent way.

8.2. Demoparties

As the biggest Demoscene-only event, Revision serves at least to some degree as a role model for other parties. We hope that Compo organizers of other parties will not just adopt these changes blindly, but instead take part in a discussion on the subject, and come to their own conclusions.

8.3. 64k Groups

As we see very obvious problems with the new Rules at Revision 2025, we would like to encourage everyone to not make use of the granted possibilties, and keep their 64k Intros truely inside 64kB. When the rule is not actually needed, it will hopefully go away rather soon again.

8.4. Personal Perspective

We have invested significant amounts of time to research this matter now, and to show how ill-advised this whole idea is - work that we should not be needing to do to begin with. And now also work that lies outside our core area of expertise - we are not even using D3D12 in our Intros. It might even be the case that we got some aspects wrong due to that. However, we are willing to take that risk, because someone has to speak up - and so far, we are not aware of anyone else who did or does or plans to. The amount of (maybe unintentional) disrespect thrown towards non-graphics tool and infrastructure coders makes at least some of us feel unwelcome and uninvited to Revision. We prefer to not take part in any Revision 64k Intro Compo under these circumstances.



The whole 64k and 4k tools and techniques scene has been standing on the shoulders of giants for decades now. When they, or we, begin to stumble, we do not just ask for a helicopter to fly us back up, no, we build bigger giants.



Signed,
Mercury

using a pushbuffer-level lowlevel API is useless for 90% if not more of the prods these days (and before) anyway

good call.

Well put together and informative post on the topic and I agree that the change is coming late, especially in light of what was said at the live discussion last year. I think this may mean that we won't see wide adoption of the use of these assets.

The spirv vs dxil issue is going to go away in time luckily.
The other technical hurdle that's not been mentioned in this post, which is that nvidia is dropping newer features from being accessible in their 32 bit drivers is similar to the compiled vs binary shader question in that it's a technical challenge that has partially already been overcome thanks to squishy.

For our end (speaking for anyone historically using my toolchains: Conspiracy, United Force, Digital Dynamite, Val) any theoretical releases at the 64k compo will be adhering to the old rules.

While I agree with the outreach section of the post, if there are more entries in the compo due to this change this year I welcome them without ire. Further discussion of the topic is well warranted.

Thank you for the thoughtful arguments. I don't agree with all your points, but they have the merit of considering the issue under a wide range of points of view.

I think the point I disagree the most with, is the pride one.
64k is notoriously difficult, and while that's also what makes it interesting, the low number of "serious" releases and the occasional cancelled compo illustrate that. Personally, I would rather like to see more 64k productions and more interesting competitions thanks to a lower entry bar, than years with and years without because the 64k scene is paralysed by its own difficulty (side note: 64k Scene is an effort in that direction).
I also don't see how lowering the bar is a problem for those who take the tough route. Nobody is complaining that publishing size coding or compression tools has taken away challenges and is disrespectful towards those who have worked hard on size coding, even though it means you can work on a 64k without knowing how to write a packer or a synthesiser.

I could, however, get behind the argument that in this case, we're not solving the problem and merely getting a free pass. The question then becomes whether we accept that.

In the context of newer APIs, I completely agree with the sentiment behind this change of compo rules. The elephant is the room being that hardware ray tracing GPU instructions have been out for 7 years now, and as far as I know we are yet to see a any size coding production take advantage of it. If a change of compo rules is what it takes to encourage exploring that direction, I think it's a good thing.

As you pointed, this solution is not without flaws, some less obvious that others, and it's good to have this discussion. Personally, I would like to see 64k intros take advantage of modern hardware without cheating, but as a matter of fact, we're not quite there yet.

It does feel very arbitrary to only have this rule for 64k intros, so I'll assume this will eventually apply to 4k intros too.

I personally don't see the point of creating a 64k/4k intro if I have to ask the user to also download a 2 MB file (in same ZIP or from a Microsoft installer, I don't care).

At that point I really do find more interesting if we had a competition for 64k scripts for p5.js, or even Unity. Such a compo is easier to explain to outsiders, makes our stuff more relatable and mainstream (yes that's good), it lowers the bar, and the content will be a lot more awesome. All that while still being able to proudly speak of "size coding" (golfing really), "optimizing", "procedural content", "compression" and "coder magic", which is for me the point of it all.

Still, I think we should try preserving the standalone rule for 64k and 4k intros without extra files, and if we find the energy, work around the platform blockers they way we've always done*.


* unless somebody has already given a serious attempt to compressing high level ASTs, or simply transforming spir-v into entropy friendly format, and can inform back that all attempts have miserably missed the mark by an order of magnitude.

It boils down to a question what is a "platform".

I think it's fair to include those DLLs as long as the platform is called: "Windows/DX12", which would be different to "Windows/DX11". And perhaps "Windows/Vulkan" as a 3rd alternative.

Note: WebGL is a separate platform as well. But technically, you should include Chrome browser with every intro.

Either way, +1 for unifying those rules for all size-coding competitions (4k/8k/64k).

Just reacting to the *webgl platform + Chrome" comment as for Windows+whatever, you're all far more qualified than me

Webgl ain't a platform. The Web is a platform and it works from any Web server, and as convenience to some extent from file system, in any modern browser.

The rule is an oddly specific workaround for a nonexistent problem IMHO. It's not that minified shader source is going to vanish as option for intro gfx anytime soon.

What was wrong with "download 65535 bytes to a fresh windows install, double-click and it runs"? I have difficulty arguing to myself why installing additional dlls wouldn't be cheating. If not the specific compo at Revision, then at least the expectation of the other nerds I send my releases to.

Or why don't we then allow the java runtime explicitly. which is explicitly excluded per rule on the same compo IIRC.

my 5 cents without having 64k credentials, but sounds very odd. I'm with mercury on this one.

> I have difficulty arguing to myself why installing additional dlls wouldn't be cheating.

Keep in mind they are not just arbitrary additional DLLs. They only provide functionality that was available to 64k intros in older APIs (OpenGL or DirectX 11).

Following this logic, you may ask if any intro that has minified shader code instead of closer to binary DXIL/SPIR-V IR is cheating? I would say "a bit", but somehow it didn't bother anyone for years, so why sudden change of thought?

yeah, no, nobody is asking that. binary is binary, its meaning is irrelevant. It's a tool that is available by default on windows and as such its use in 64k intros is perfectly justified.

If we start having to install a 2mb extra dll to run embedded shader code, that's where we reach the point of cheating.

Thank you mercury for this concise and well put together statement.

My stakes in this matter are low but still, the fact that these intro's wouldn't run stand-alone on a typical end-user machine seems to run diametrically against the whole concept of an (modern day) intros being tiny stand-alone executables creating awesome output. Apart from this I also really dislike how oddly specific this is (...) and how it does the opposite of leveling the playing field, I have a hard time buying the argument of not wanting size-coding to become an old-school compo, if that's the intention then why no solution for Vulkan/SpirV(glslc), and further why disallow usage in smaller intros especially since here it's unlikely to provide a significant competitive advantage.


+1

If I undertand the sentiment of the previous discussion about shader compressibility correctly, DXIL is a horrible format which is a pain to work with, let alone transform into something decently compressible, whereas such a transformation is definitely feasible for SPIR-V.

It is only a matter of time before someone makes a 64k-suitable SPIR-V transformer that rivals shader source text in size and shares it for everybody to use.

Thus, the situation will indeed resolve itself when Microsoft switches to SPIR-V. This is at worst a temporary issue.

It's not embedded shader code, but shader compiler.

Maybe I wasn't clear enough. Every single 4k to 64k intro (or at least 99.9%) made within 10 years or so for Windows platform has embedded shader code in it in text format and relies on external DLL library that compiles it to binary/machine code. It's just for OpenGL and DX11 this library was coming with standard Windows installation and for DX12 it's not.

It's been a (too) long time since I created my last 64k intro and I couldn't care less about Direct3D, but I am a compo organizer of another party, so here's my 2 cents: Don't do this.

What the Revision compo rules propose is an almost literal repetition of the D3DX DLL hell that we had for 4k intros around the 2005 to 2010 timeframe.
Intros don't run on standard systems without installing (or shipping) special DLLs first? Check.
These DLLs come straight from the Direct3D SDK? Check.
There's no nice one-click web installer for said DLLs from Microsoft? Check.
There's not just one fixed set of DLLs, but different ones for each SDK version? Check.
I'm very happy that we left these "dark ages" behind us, and I'm not at all eager to have that situation again.

I somewhat understand the wish to use D3D12 or Vulkan for intros, and I'm fully aware that these APIs aren't as lean as D3D11 and OpenGL, and that they have hard(er) requirements to use some rather verbose binary shader IR instead of compact, well-compressible source code, but hey, that's life. DXIL and SPIR-V are too large? So develop better compression for them if you want to use them. Requiring hard-to-obtain external libraries is not the solution, it's a lame shortcut.

Right, right... and using those lean APIs (DX11) that provide you way too much, plus standard Windows fonts and even GM sound banks or text to speech engine that just happened to be included in vanilla Windows installation because of some random egghead decision at Microsoft to make it part of "platform" is not lame at all.

as someone who has no interest or involvement in actually doing this practically anymore, i can only fully agree with what iq said. the rule has always been more or less "anything goes as long as it's completely standard on a windows install" and runs out of the box. that's part of the magic on of it and changing that devalues it somewhat.

minified text based shader code has always felt like cheating anyway. :) 64ks are meant to be hard!

Lol the hypocrisy..so you, smash and iq, were using minified shaders code for years and now that you are not interested anymore, you want to make it harder for others...nice!

"completely standard on a windows install" in today's world only means it will work until next bigger update

Not true. Microsoft's product policy is highly questionable at times, but if there's one thing that they're commited to, it's backwards compatibility. Whatever is in C:\Windows for a stock install of version N, it'll be in version N+1 too, and it'll continue to work, even though it may officially be called deprecated.

Fonts are there, because even Windows itself has to them to draw text.
GM.DLS is there, because MIDI playback is a Windows feature since 1992 and it shall continue to work in the absence of hardware synthesizers in sound chips.
The speech synthesizer is there, because accessibility.

Ok, KeyJ, let's see how your belief in Microsoft mission to provide backwards compatibility will age in a few years.

So sure, at this point, let's just invest some time compressing DXIL. It's definitely not gonna be discontinued (irony implied). All because life suppose to be hard (which was BTW on easy mode for DX11 generation, but whatever).

They care about normal/standard use of their OS regarding nowadays computers & modern mass storage not about executables crafted by a bunch of weirdos to be as small as possible, exploiting every hole they can find thus living on it like parasites.

...or SPIR-V? Or, controversially: GLSL? That one has the advantage of being a solved problem :)

Personally I wouldn't rely on backward compatibility. From time to time Microsoft drops system components. E.g. they removed (instead of fixing the security issues) the last legacy video codec (Indeo first, and later Cinepak). So there is no video codec left that works on all Windows versions. This is not an issue for the demo scene, but for running old games (however, since DirectDraw is dead, they need emulation anyway...).

Let's say this because I think it hasn't been said enough in this thread:

I wanna express my huge respect and gratitude for all compo organizers.
I know it's a tiring and often thankless job.

And I do have respect for not going the easy "Let's do it like we did every year"
way and thinking about rule changes that might be beneficial to the category.
Especially in a context a of diminishing number of 64k intros and no intros making use of the more modern APIs, I can understand thinking about including those DLLs.

I partly attended the sizecoding meeting at last Revision after having fixed our entry and I've been made aware of it by our compos organizer, procyon.

I remember this DLL thing being discussed there, with opinions rather balanced but with a tendency to allow it if I remember correctly. I was a bit irritated by that, but I was thinking "I don't have a horse in that race, and don't really now about the technical specifics, so if the 64k windows guys can mostly agree on that 🤷‍♂️".

Thanks Mercury for the lengthy writeup and explanation.
I do agree with most of your points. I think including those DLLs is a bad idea and it should have been communicated much more openly and earlier.

I do believe this SPIR-V compression thing will be sorted out at some point and the reason for it not being sorted out already is more because the old APIs are still mostly good enough.

That particular point can at least be addressed by requiring such DLLs to be part of the distributed archive, instead of already being available on the compo machine.

Regarding removed Windows components: Good point about the missing codecs. There's an explanation for those though: Indeo and Cinepak are third-party components. The license with Intel seemed to have run out at some point, so there's no Indeo any longer. Cinepak is still there (at least in Windows 10), but only in 32 bits, as MS never had the source code for it and therefore couldn't port it to 64 bits. Microsoft's own codecs (RLE and Video 1) are still available, even in 64 bits.
I must admit that this might be a problem for GM.DLS at some point in the future too, as that one's licensed from Roland.
But still, my point stands: Microsoft's dedication to keep old stuff running is second to none in the operating system market. It's not perfect, and it can't be, but at least they try.
So, please let's stop this tangent now - the discussion about whether using certain system components is cheating or not is as old as Windows demos themselves, and the general concensus so far has been "if it runs on a stock install, it's fine". Allowing extra DLLs from various SDKs, however, was a bad idea in the late 2000s, and it's going to be a bad idea again in the late 2020s.