BackGround
SoftDomain, as a Sun partner, engaged in a project to port a massive application written in C and C++ from HP/UX 10.20 to Solaris 2.6. A sale worth several million dollars hinged on it. Some 10 teams with a total staff of about 150 people develop the application. It supports the ever-changing business of the largest telecommunication company and thus, adds new features with every scheduled quarterly release. Needless to say, it is crucial a system to its owner. Besides the expected complexities of porting a large and fluid application an unexpected technical challenge was encountered: the Standard Template Library (STL) used by the HP C++ compiler is totally incompatible with the one in Sun Workshop C++ 5.0 compiler!
The Scramble
Houston, we have a problem! We were now faced with 2.8 million lines of code in C++ that used heavily the STL. Our first obvious options were daunting. The first one was to rewrite all the usages of the STL in a way that would be compatible with Sun’s Workshop C++ compiler. This implied labor costs not anticipated by any party involved in the project and it significantly increased the risk of introducing bugs to the ported product. By all measures, this was an extreme option.
The second option was to find another STL that would be compatible with HP’s. We tried going back to Sun Workshop 4.2 compiler. This uses an older version of RogueWave STL. It did not work. After working hand in hand with Sun’s support team, an early release of Sun Workshop 6.0 was given to us to try. Things improved somewhat, yet the differences were still major. After this we knew there was little that Sun could do for us.
Our second and only option was to procure a 3rd party STL somehow. We approached RogueWave and got an updated version of their STL for the Workshop 5.0 compiler
This was a promising attempt given that RogueWave’s product is integrated into the previous version of Workshop. Again there were major incompatibilities and time was running.
Writing a new STL was out of the question. The hierarchical dependencies between classes make it quite a complex task. But we were not quite ready to give up. Instead we studied the STL of our close partner, SCO. How did it work?
The Solution
Light at the end of the tunnel. The STL used by SCO is a direct descendant of the now defunct Unix System Laboratory (USL). This AT&T; spin-off attempted to unify the different versions of Unix in existence in the early 90s. One of the Unix versions that USL tried to bring under the System V Release 4 version (SVR4) was HP/UX. However, this never happened, but to our surprise, HP and their C++ offering adopted the STL library developed by USL. Ironically, Sun adopted the SVR4 kernel.
We immediately negotiated with SCO to obtain source license for their STL and quickly ported it to Solaris and Sun Workshop 5.0.
The Result
With our brand new SUN Workshop STL based on SCO’s original product we undertook the bulk of the port. Our team of programmers ported the system application by application, recompiling and testing with our STL
As we ported a number of other incompatibilities were detected and resolved. They were limited, for the most part, to normal implementation differences, where border cases were exposed given the different implementations
SoftDomain’s STL proved to be a sound technical solution. It substantially simplified the project and made it a success.
The porting project has come to an end. However, the large applications like the one ported live on (in a Solaris system, for now…).