RFR: 8348828: Windows dll loading now resolves symlinks

[Benjamin Peterson]

On Wed, 7 May 2025 21:19:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
> 
> What if instead this were the following
> 
> ```
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando.dll
> ```
> 
> where `.dll` is appended to the target?

I expect that would work given the `LoadLibrary` documentation you've quoted.

> 
> > At this point, the path to load will be `$PWD\rando` due to symlink resolution.
> 
> Which is in fact correct, no?

Correct in that that's the library that should be loaded. `LoadLibrary` doesn't want to cooperate, though.

> 
> > Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail.
> 
> Indeed from the `LoadLibrary` documentation
> 
> ```
> If the string specifies a module name without a path and the file name extension is
> omitted, the function appends the default library extension ".DLL" to the module name.
> To prevent the function from appending ".DLL" to the module name, include a trailing
> point character (.) in the module name string.
> ```
> 
> so a trailing `.` character on `rando` might equally resolve the problem?

Perhaps. In my usecase, files come into the system "anonymously"; files that make up the symlink tree are received before it's known what the layout of the tree will be. A link to a given file could turn out to be, e.g., `myaudio.mp3`, `MyClass.java`, or `jimage.dll`. I'm disinclined to append `.` or `.DLL` to every file in off chance that it turns out to be a library that Java wants to load.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2860469015