On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> When the static launcher was introduced in > [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and > resource constraints, it was only working properly on Linux and macOS, while > the Windows port compiled but did not work. Now the time has come to fix that. > > Most of the changes mirrors the kind of changes that were made for Linux and > macOS in JDK-8339480. There are still limitations to static builds on Windows > (e.g. starting with a splashscreen), but these kind of limitations also > exists on the other platforms. > > Note that this PR is blocked by > [JDK-8346433](https://bugs.openjdk.org/browse/JDK-8346433), > [JDK-8346195](https://bugs.openjdk.org/browse/JDK-8346195), > [JDK-8346378](https://bugs.openjdk.org/browse/JDK-8346378), > [JDK-8346383](https://bugs.openjdk.org/browse/JDK-8346383), > [JDK-8346388](https://bugs.openjdk.org/browse/JDK-8346388) and > [JDK-8346394](https://bugs.openjdk.org/browse/JDK-8346394), which must be > integrated before this one. src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp line 53: > 51: */ > 52: if (JVM_IsStaticallyLinked()) { > 53: hDLL = ::GetModuleHandle(NULL); So this returns a handle to the process instead ? I suppose this exists for apps that want the process, not for apps that can't get a handle to a DLL. I am not sure if this is always sufficiently equivalent to work for whatever the app needs it for .. I hope this doesn't create downstream problems that we need to fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22795#discussion_r1893187626
