[Feature Request] Provide EXE launcher for Windows

[skissane]

Is your feature request related to a problem? Please describe.
Many desire Ghidra would be installable via Microsoft's WinGet package manager.
Previously, this was requested in #5084 – which was closed as "Won't support". @ryanmkurtz gave the following explanation:

We have received requests to support several different package managers and installers for various platforms, and our stance has always been that we do not want to get bogged down in platform-specific package management and distribution. Perhaps this will change one day, in which case I will reopen this ticket.

An understandable stance. However, it isn't actually necessary for the Ghidra developers to maintain the WinGet packaging, that can be maintained externally in the microsoft/winget-pkgs repository. There is an open issue requesting Ghidra to be added to that repo – microsoft/winget-pkgs#111394 – and someone submitted a PR to do so – microsoft/winget-pkgs#119124

However, that PR ended up being closed, because currently Microsoft WinGet has the policy that they don't allow "Script-based installers" including batch files in packages. Although Ghidra doesn't actually have an installer, it is just a ZIP file (which apparently is okay because other WinGet package are also just ZIP files), the fact that the launcher is a batch file ghidraRun.bat is being interpreted by the WinGet administrators as contravening this policy. (I don't think batch files are banned completely, so long as they are not the main application entry point.)

If an EXE launcher equivalent to ghidraRun.bat was provided, that would unblock the ability to package Ghidra in WinGet.

I note #7223 was recently closed as "Won't support" as well – asking for an "executable launcher that can be pinned on task bar and startmenu". Maybe you are going to close this as "Won't support" as well, but it has a different motivation, and getting any particular taskbar/start menu behaviour is out of its scope.

Another argument for converting Windows batch files to C++ is that Windows batch is a really horrible language, with lots of footguns and gotchas (a lot worse than Unix shell scripts), and you already have a number of C++ components in your project so adding another one would not be out of place. (One could also use plain C instead of C++, but since you've got more C++ code than C, I assume you'd prefer C++ over C.)

This issue is not asking to convert the launch shell scripts used on Linux and macOS to C++, this issue is just asking it for Windows. Of course, you could decide to do that as well; or you might decide not to. There are legitimate arguments for both options.

Describe the solution you'd like
Some options:

1. Just translate the logic of ghidraRun.bat and launch.bat into C++ – converting any of the other batch files is likely unnecessary – and have it still spawn javaw.exe as a subprocess
2. Rather than spawn javaw.exe as a subprocess, host the JVM in-process using JNI
3. Use the Java native packaging tool jpackage included JDK 16 and higher, which can build a Java app into a Windows EXE (and also an MSI installer, deb/rpm packages for Linux, and pkg/dmg for macOS)
4. There are various "batch to EXE" compilers out there. I don't think this is a good option because none of them appear to be high quality, well-supported or to have a large and active community, and I don't think you'd want such a tool as a build-time dependency

I personally think (1) is likely the simplest option, at least in the short-term. (2) would be better but more involved. (3) won't allow replicating the existing custom logic of launch.bat, which is likely to pose an issue.

I realise this might not be a development priority for you. If someone external did the work and submitted it as a PR, would you be willing to accept it? (If you are going to say ahead of time you aren't willing to accept such a PR, there would be limited point in someone going to the effort of creating it.)

Describe alternatives you've considered

1. People just accept Ghidra won't be available via WinGet
2. Someone convinces the WinGet administrators at Microsoft to change their policy (or the interpretation of it)
3. Someone maintains a fork of Ghidra adding this feature and packages it via WinGet. (Sceptical anyone is going to step forward to take on that significant responsibility.)