Ever since I found symbolic links are available on Windows, I’ve used it in various places. To reduce the PATH entries, so it doesn’t overflow, to overcome program idiosyncrasies etc. In this post I will tell you what I did with some DLLs, so I could run different versions of a software.
Both the software are in the context of PowerBuilder, a development IDE from Sybase (Now SAP). PowerBuilder with a scripting language called ORCA. Each version of PowerBuilder comes with a version of a tool that implements OrcaScript. Most things you do inside PB IDE can be done through Orca script – for e.g., you can build, deploy entire workspaces or targets using Orca script. Yes, it’s typically used in automating build processes. Though PB comes with Orca Tool (called orcascr125.exe in PB 12.5), I had already used another tool PBOrca. I really like this tool, so I wanted to continue to use this tool. But, this is an older tool that may not work with/understand PB 12.5.
In a PBOrca script, to work with a particular version of PB, you use the Session Statement:
session begin pbOrc100.dll
The other use was when I did some beta testing with PowerBuilder 15 recently. To build and deploy our PB application, we use Powergen. This is a build tool developed by E.Crane computing for building complex PB applications. It resolves circular references in PB libraries and builds applications smoothly. Powergen apparently uses ORCA to interface with Powerbuilder.
Symbolic Links to the rescue
When I first tried using PBOrca to build code in PB 12.5, I wasn’t sure if it would work, since 12.5 wasn’t in the support list. I decided to try posing PB 12.5 dll as 10 dll with the help of, you guessed it, Symbolic Links. I created a symbolic link named pborc100.dll pointing to pborc125.dll. Bingo, I was able to connect to and build PB 12.5 code. Get it? The software thinks it’s still loading to PB 10.0 DLL (the link PBORC100.dll, which indirectly invoked PBORC125.dll!). You could do this magic to some directory renames as well. I mentioned about Repository pointing to 2 different versions in my other post.
(Though, in all fairness to PBOrca, it actually worked with PB 12.5 dlls fine, but didn’t try that initially. All I had to was change the dll name in session statement).
Next time Symbolic link came to the rescue, was when I wanted to test Powergen build process with PB 15. When I did my beta testing, I had scripts setup for me to switch from 10.2 to 12.5 (See here). I wanted to reuse these scripts, without much changes. Unfortunately, Powergen does not know, PB 15 exists yet. After some thinking, realize symbolic link could help me here. I just created a symbolic link for a PB dll used by Powergen. The symbolic link posed the PB 15 dll as a PB 12.5 dll. This worked!!! I was able to build a PB 15 version of the application using Powergen 8.5, which doesn’t naturally support PB 15 yet.
In both the above cases, posing one version of DLL as another worked only because, there wasn’t major changes to the DLLs themselves across the version. Otherwise, I would have gotten some compile or linker error.
Note: We have paid full license fee for Powergen upgrades. The hack I did was to make it work, was for test only. Please do not construe this as way to avoid licensed upgrades.