Recently, I was faced with the task of implementing some small enhancements for an Eclipse RCP application I implemented quite a few years ago. There were a couple of challenges:

  • It was a 32-bit Windows application (Galileo-based).
  • I still had a development Eclipse with all necessary plugins…
    • also 32-bit
    • some plugins used originally are not to be found on current update sites anymore
  • There is basically a single potential user — with a 64-bit machine like me.

For obvious reasons, I did not want to set up a completely new development environment from scratch. I still have a 13 year old notebook running a 32-bit Windows which I could have used for running the original Eclipse, but it is so slow that programming would have been a real pain — also I wanted an updated 64-bit version of the RCP application. Upgrading the entire application to current versions was out of the question.

What was needed was getting the old application to run on 64-bit machine and getting the development Eclipse to run on a 64-bit machine with minimal effort. With some playing around this was simpler than feared. There were only a handful of architecture-specific plugin(fragment)s.

  • org.eclipse.equinox.launcher.win32.win32.x86
  • org.eclipse.swt.win32.win32.x86
  • org.eclipse.core.filesystem.win32.x86
  • org.eclipse.core.net.win32.x86
  • org.eclipse.core.resources.win32.x86
  • org.eclipse.equinox.security.win32.x86

It turned out that replacing the 32-bit executable with the 64-bit one, finding and adding the x86_64-variants of the above plugins to the plugins folder and updating the corresponding entries in the config.ini (configuration folder) or bundles.info (org.eclipse.equinox.simpleconfigurator in configuration) was sufficient. With these minimal modifications, I had the old development environment running on my current 64-bit machine.

Building the 64-bit RCP was no problem after that. Again replacing 32-bit dependencies by 64-bit ones was enough.

a single 32- and 64-bit deliverable

Then I wondered, whether it was possible to have a single deliverable for both 32-bit and 64-bit Windows. As I said, for my development environment I simply added the 64-bit jars to the plugins folder (without removing the 32-bit ones) without any negative effects. Again, it was surprisingly simple. The executable looks for a corresponding “launcher” ini (e.g. eclipse.exe looks for eclipse.ini, myrcp.exe looks for myrcp.ini and so on), so you can have an eclipse64bit.exe next to a eclipse32bit.exe with the corresponding ini files.

All you have to do now is point them to their corresponding configuration. By default there is a configuration folder next to the plugins folder. Instead of having only one, you create a config32 and a config64 folder (read: have a standard configuration built, copy it and adapt the architecture dependent entries) and add

-configuration
config32

to the eclipse32bit.ini (and an analogous pointer to the 64-bin-ini). The -configration option points the launcher to, as you might guess, the configuration. If you have made sure all the needed architecture-dependent plugin fragments are located in the plugins folder, you now can deliver a single RCP-zip which can be run in both a 32- and 64-bit environment.