Migrating a 32-bit Eclipse RCP to 64-bit
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.
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
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.