RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

[Alexander Matveev]

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ExtractIconEx() WinAPI to extract icons from executables, as it doesn't rely on GetLastError() to deliver error information to the caller. GetLastError() is not reliable in managed code.

How user should figure out what `installer.exe` suppose to do? Should user just take it from another JDK which works? It does not look like a solution to this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675947409