Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Here is a summary of what I've discovered if you want to make Launch4j "work" on Vista, without throwing warning messages.
(1) "customProcName" leave as false (the default). This is a shame as I used to like setting this option. Our software accessed the internet, and this would allow the client's firewall to see OurProg.exe trying to access the Internet and not javaw.exe. The reason you have to switch this off, is that Launch4j creates a temporary copy of javaw.exe (named OurProg.exe) in the Program Files directory (Java subdirectory). Under Vista you need administration rights to do this, so every time the software is run you will user will be shown a warning message. And if you haven't digitally signed the .exe then the message is something unpleasent along the lines of "Unauthorized software trying to access your computer" ...
(2) "dontWrapJar" should be set to true (not the default), otherwise you won't be able to digitally sign your code. Again this is a shame, as it leaves the .jar sitting there and easily accessed. When wrapped, most people don't think to open the .exe looking for classes. If you try to wrap and then sign the file it corrupts it.
Some other things to consider:
- Add a vista manifest file to your launch4j .exe (this allows you to request Vista security level, and can stop some of the warning messages, and prevent virtualization of your Program Files dir). I do this as a post step using mt.exe
- Sign your launch4j .exe file, I do this as a post step using signtool. I'm still not sure if you need to sign the JRE .dlls and .exes if you distribute a bundled JRE.
- Don't store any user settings in Program Files ... this will cause warning messages.
- If you use an installer program (eg inno setup), don't let the user run the software automatically on installation. The set up script requires Administration access, and then if you launch the software it will initialize it as an Admin user. In future every time it is run it will require Admin access.
These are just some of my findings. They are not 100% accurate, but should give you some help if your users start complaining about Vista issues!. The new Vista security model (UAC) is the main cause of the problems.
Grzegorz , if you feel like making changes:
(1) being able to specify the Vista manifest file to be included as a resource would be great (NB: This is backward compatible, so my launch4j .exe with manifests still work on 98, 2000, XP etc). Not a big issue though, as I am using mt.exe through an ant task. Others might want it though.
(2) A new solution to "customProcName" would be great that doesn't involve the Program Files directory (but from previous posts I see you've already considered this)
(3) A way of wrapping the Jar and signing it!!! Also probably not something you can fix.
(1) is probably doable. (2) is solvable; JNI/Invocation API is the way to go with this. I think I'm going to take this ball and run with it... I really want to be able to update L4j to create Linux and *BSD (and perhaps, in the future, Solaris and MacOS) executables, and JNI is the way to do it. In fact, today I have done a couple native Linux launchers using JNI. I can see no reason *not* do modify L4j to use JNI.
Whoops. JNI solves (1). There are third-party tools that would solve (2).
If you set your manifest to this...
HighestAvaliable then make the customProcessName work. That privilege must be an administrator privilege only. So without this setting my process is javaw.exe...but once I add this manifest to the EXE it then is back to what it was before. Definitely need to add this to Launch4j!
1)Do you need to be using launch4j 3.0.0 for this? Or can it work with an older one (we're still using 2.1.4)
2)Where does this manifest go in? Could you provide a config using the SimpleApp.xml provided in the demo?
I added the manifest support (you can get it from CVS), so at least you won't have to add it after building the launcher/wrapper.
I don't have Vista yet so if someone could confirm this...
1) customProcessName should work when the level is set to requireAdministrator, I'm not sure about highestAvailable when the account is not an administrator. The real solution to this would be JNI.
2) If you'd like to sign the executable or the jar file "dontWrapJar" should be set to true. I don't think you can sign the exe without corrupting the jar and a signed jar should be considered broken after adding the executable header (though on the other hand the jar structure does not change).
The manifest is specified with <manifest> tag at the same level as <icon>, sample file is available from CVS.
One note: the XP styles still require a separate, standalone manifest and customProcessName=true.
Thanks for all the info guys,
....... <manifest>file</manifest> just like the icon.
But when I built my project, I got an error message saying "config doesn't support the nested "manifest" element."
I set it like below:
You need the CVS version of Launch4j in order for this to work, then configure it like this:
Reply to 6 # 2: Might be able to use this to sign wrapped jar