Re: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v14]

2022-10-06 Thread Julian Waters
> Please review a small patch for dumping the failure reason when the MSVCRT > libraries or the Java Virtual Machine fails to load on Windows, which can > provide invaluable insight when debugging related launcher issues. > > See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull R

Re: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v14]

2022-10-09 Thread David Holmes
On Thu, 6 Oct 2022 12:45:08 GMT, Julian Waters wrote: >> Please review a small patch for dumping the failure reason when the MSVCRT >> libraries or the Java Virtual Machine fails to load on Windows, which can >> provide invaluable insight when debugging related launcher issues. >> >> See https

Re: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v14]

2022-10-10 Thread Julian Waters
On Mon, 10 Oct 2022 04:35:12 GMT, David Holmes wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 16 additional >> commits

Re: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v14]

2022-10-10 Thread David Holmes
On Mon, 10 Oct 2022 11:58:33 GMT, Julian Waters wrote: >> src/java.base/windows/native/libjli/java_md.h line 48: >> >>> 46: */ >>> 47: >>> 48: void reportWithLastWindowsError(const char* message, ...); >> >> Why does this need to be exported in the header file? Are you expecting >> other cod

Re: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v14]

2022-10-11 Thread Roger Riggs
On Tue, 11 Oct 2022 01:38:52 GMT, David Holmes wrote: >> I left that in there since it would possibly be a useful utility to have for >> other JLI code that might need to work with Windows errors in the future > > In that case shouldn't the `JLI_xxx` naming scheme be retained? $0.02, leave it f