It does not modify it, it adds a library with this name to the Windows folder which has priority over System32 folder
Please, if we spread information, let's makre sure it is correct. The Windows folder doesn't have any priority over System32, that's a misinformation that can cause a lot of trouble.
When applications load external libraries, they use system provided functions like `LoadLibraryW` and `LoadLibraryExW`. Developers can choose either to provide the full path to the library they want, which ensures the loader loads it from the path specified only, either only its name, in which case the loader adopts a strategy for identifying a library with that name on the system and loading it. This is useful for a ton of reasons I won't go into. What is important is understanding what is the strategy the loader adopts in such a case.
Unless the app runs under some special condition (it uses some compatibility shim etc) and unless the app requests a particular search strategy from the loader, the default behavior, largely is this (it is more in-depth documented [here](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order)):
* The folder where the application is located
* System32 folder
* Windows folder
* Folders in PATH
As you can see, the loader will first attempt to load a library from the folder where the application resides into.
In the case of `explorer.exe`, weirdly enough it lives in `C:\Windows` instead of the more usual `C:\Windows\System32`. It references `dxgi.dll`, so the loader attempts to load that library. In a clean Windows install condition (i.e. without EP installed), it tries to load `dxgi.dll` from the application's folder (`C:\Windows`) and it fails, then it tries from System32, where it finds it and probably succeeds; this is per the search strategy listed above.
As you can see, there is a window of opportunity here, where if you create a library called `dxgi.dll` and place it in `C:\Windows`, that will get loaded instead of the one in `C:\Windows\System32`. So, ExplorerPatcher places itself in `C:\Windows` named `dxgi.dll` in order to have the loader load it instead of the OG `dxgi.dll` when `explorer.exe` runs. One thing to note here is that, theoretically, all executables from `C:\Windows` would load the EP-provided `dxgi.dll`, but since `regedit.exe` and what's in there do not actually use `dxgi.dll`, it only really affects `explorer.exe`. The EP-provided `dxgi.dll` exports the same entry points as the OG `dxgi.dll` and redirects calls to those entry points to the OG `dxgi.dll`. The injection happens when `explorer.exe` calls `DXGIDeclareAdapterRemovalSupport`, which happens very early when `explorer.exe` starts. Then, EP sets itself up, and then forwards the call to the OG `dxgi.dll`, as usual.
So no, EP doesn't actually screw with other applications, as those will surely, unless placed in `C:\Windows`, load the OG `dxgi.dll` from `C:\Windows\System32`, which is correct.
Also, of very important note is to make sense of why was `dxgi.dll` specifically chosen:
* As said above, one of its function is called very early when `explorer.exe` loads, thus ensuring `explorer.exe` hasn't done much so EP can patch it freely and extensively. Side note: when the loader loads a DLL, it actually calls a function from it (`DllMain`). So injection could happen there as well, right? Well, not really, since in this case, injection means patching things from other libraries used by `explorer.exe`, libraries which may not have been loaded yet (the load order is hard to predict in a maintainable way). Thus, one would net to load those libraries in code. The trouble is, the loader is already loading our library, so if we attempt loading other libraries, it may enter a deadlock (library loads are serialized) or loop indefinitely, idk exactly how it is implemented (imagine the EP-provided `dxgi.dll` loading `shell32.dll`, for example, which, hypothetically, also loads and requests `dxgi.dll` - this would lead to an infinite loop). So yeah, not doable, the proper way to do the patching is to do it when some function from the exploited DLL is called by the originale executable.
* The loader uses a special search strategy that only looks for the DLL in `C:\Windows\System32` for highly-sensitive DLLs that are located on the `KnownDLLs` list from `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\`. When you request the loader to load a path-less DLL that is located on the `KnownDLLs` list, it always searches it in System32 instead of following the usual search order. This is to make sure that the kind of behavior I described above cannot be deployed against most DLLs that are likely to be linked to by every application (99.99% of the apps link to certain DLLs, like `user32.dll`, for example). `dxgi.dll` is not on that list, for example, so I use it to have EP load in `explorer.exe`. Another one that's not on the list is `wincorlib.dll` and that's how I inject EP in `StartMenuExperienceHost.exe` to bring back the Windows 10 Start menu. Side note: `StartMenuExperienceHost.exe` also references `dxgi.dll`, but by the time something from `dxgi.dll` is called, the code for deciding which Start menu to use already has run and thus, the decision to run the Windows 11 menu has already been taken and cannot be patched anymore. Entry points from `wincorlib.dll` run way earlier, thus giving the opportunity to make this patch and have the Windows 10 menu show.
The idea with EP is to have things patched at runtime, so that it survives Windows updates, `chkdsk.exe`, it doesn't tamper the system files etc. Only thing it does it adds its DLLs near some of the applications it hooks, but doesn't replace any system file. When Windows updates come, EP always survives, things that usually happens is Microsoft changes some functionality code wise and EP has to be reworked for that, or the symbols which are used for something else entirely (described in the wiki) have not been published for that build.
I hope this clarifies more how the app works in the regards mentioned lately.
