Evaluation of cross-platform installer builders

Friday, April 24, 2009 | Posted by

On stackoverflow, there's a question regarding the comparison of cross-platform installer builders. This answer is apparently the result of a very thorough evaluation and paints a very favorable picture of install4j.

Finding a memory leak with JProfiler (old)

Thursday, April 23, 2009 | Posted by

There is a newer version of this screen cast.

This version is outdated with respect to the heap walker, but it also shows useful features outside of the heap walker.

Object counts in dynamic memory views and the heap walker

Wednesday, April 22, 2009 | Posted by

Often the question comes up why there are larger object counts in the dynamic memory views than in the heap walker. The simple explanation is that the dynamic memory views show all objects on the heap - even those that are unreferenced, while the heap walker only shows objects that are strongly referenced.

Here, for example, in the "All objects" view, a particular class has an object count of 6741:

In the heap walker, the object count is only 6282:

The difference comes from objects that are not referenced anymore, but that are still on the heap because the garbage collector has not collected them yet. Clicking on the "Run GC" button in JProfiler might collect some, but not all of them, since the garbage collector does not do full collections in modern JVMs. However, when you take a heap snapshot, a full collection is done internally, so you only look at objects that you can actually do something about.

Ideally, we would exclude unreferenced objects from the dynamic memory views too, but this information requires an expensive calculation that can only be performed when taking a heap snapshot.
  Since the release of Vista, code signing has been of growing interest for our users, mainly because a signed installer or launcher produces nicer and less UAC dialogs when it wants to elevate its privileges.

install4j provides a signing hook for all generated windows executables. On step 5 of the Windows Media Wizard, you can specify any external tool with the executable files as parameter. The signing tool will be called with the working directory set to the project file parent directory so you can specify keys and certificates relatively. You can use the $EXECTUABLE variable to refer to the launcher or installer and an $OUTFILE variable if the tool you use requires different in and out files.

I will explain below what tools you can use to sign your executables, but first, you would need a Microsoft Authenticode Certificate from a certificate authority like Thawte:


In their order process, they will generate a private key (PVK) file and a certificate request. After Thawte verified your identify, they will provide you a SPC file that contains your certificate. There are a bunch of other certificate authorities, most notably verisign where the process is quite similar.

Code signing on Windows

On Windows, you can quite easily use Microsoft's tools like signcode or signtool which are contained in the freely available Platform and .Net SDKs. You can find the documentation in the MSDN:


Below is a good summary of how to use signtool:


It also explains how to convert different file formats that other certificate authorities might issue.

Code signing on other platforms with Mono's signcode

It is also possible to sign executables on other platforms. The $INSTALL4J_HOME/resource/signcode.exe executable is a mono executable modified by ej-technologies to support signing of 64-bit executables. This executable can only be executed if mono is installed. Mono is available for a number of platforms and can be downloaded free of charge.
The tool has the same syntax as the one from Microsoft. A typical entry would be mono /opt/install4j/resource/signcode.exe -spc mycert.spc -v mykey.pvk -vp password -t http://timestamp.verisign.com/scripts/timstamp.dll $EXECUTABLE
Some SPC files cannot be read directly by this tool. If this is the case for your certificate, you can export all CER files from the SPC file and generate a new SPC file with the cert2spc tool included with mono. You have to add the CER files in the order of the certificate chain (your own certificate is the last one on the command line).
Code signing on other platforms with openssl and osslsigncode
If you want to avoid installing mono or have problems with your SPC file, you can also use a different tool called osslsigncode in conjunction with openssl. Here is a download with a patch for signing PE32+ (Windows x64) executables. A short ./configure && make should be sufficient when you have curl and openssl installed.
This tool requires the private key in a different form, though. First, you would have to convert your PVK file to a PEM file with this tool on Windows. A typical command line would be simply pvk -in mykey.pvk -out mykey.pem. The upcoming openssl 1.0 will also be able to do this conversion.
The PEM file is still encrypted, but osslsigncode needs an unencrypted DER file. You might want to generate this DER file directly before your build process and delete it afterwards to avoid having your private key hanging around unencrypted longer than necessary. The conversion to a DER file is done with openssl rsa -passin pass:XXXXX -outform der -in mykey.pem -out mykey.der.
A typcial command line in install4j would then be osslsigncode -spc mycert.spc -key mykey.der -t http://timestamp.verisign.com/scripts/timstamp.dll -in $EXECUTABLE -out $OUTFILE. Remember that the spc and key files can be specified relatively to your install4j project file.
Update: As of install4j 5.1, code signing is implemented directly and the above mentioned tools are no longer required.


Tuesday, April 21, 2009 | Posted by

In this blog we'll show you tips and tricks around JProfiler and install4j. Comments and questions are always welcome. Enjoy!