DLL paths no longer resolve to full path

[devnote-dev]

When using Crimson to install 1.12.0 (and now 1.12.1) the Crystal executable no longer runs in the terminal or in application processes. When setting up Crimson on Windows, the process goes as follows:

• Crimson's environment directory is created at C:\Users\user\AppData\Roaming\crimson
• Crimson's Crystal bin directory is created at C:\Users\user\AppData\Roaming\crimson\bin
• A target directory is created at C:\Users\user\AppData\Local\Programs\Crystal
• Symlinks for crystal.exe, crystal.pdb and shards.exe are created in the Crystal bin directory to the target directory
• The target directory is added to the PATH environment variable
• MSVC dependencies are installed (if necessary)

The \AppData\Local\Programs\Crystal directory points to \AppData\Roaming\crimson\bin which is used to switch the current Crystal version available on the system, this can point to any installed version (for example: \AppData\Roaming\crimson\crystal\1.10.1).

This system has worked for all available Crystal versions until 1.12.0, which when trying to run in a terminal or from an application, will not output anything and return exit code -1073741515. After investigating in the Discord server and Windows debugging, this came up:

This is one of several popups for libraries used by Crystal that could not be found. However, the actual executable itself works in the install directory (that being \AppData\Roaming\crimson\crystal\1.12.1). Manually linking all the libraries in said install directory to the same path as the symlinks in the target directory also gets the executable to work.

As stated before, this system works for all previous versions of Crystal which means that at some point, path lookups for DLLs changed to no longer resolve the full path. Could this be a result of dynamic linking becoming default in this version?

[HertzDevil]

Manually linking all the libraries in said install directory to the same path as the symlinks in the target directory also gets the executable to work.

Since the compiler itself is dynamically linked, this would now be expected from a complete installation, so yes, the tool has to symlink all the DLLs as well (automatically).

[straight-shoota]

Ah, so nowadays we have no influence on where DLLs are looked up, right? They need to be in PATH.
Only the original delay load implementation (with -Dpreview_dll from #13436) in the Crystal runtime we could accomodate to lookup in the real path of the executable.

[devnote-dev]

If there's no real use case for this functionality then I will update Crimson to symlink all DLLs too, but my understanding of the DLL search order was that the path of the executable is included if not the first location to look, and in this case the symlink path isn't the executable path.