It’s not uncommon for a locomotive or airplane to be in use for 30 years or more. Last year, a Boeing 747 used by GE Aviation was retired after 50 years of active service and the Dutch Railways still have trains in service that were introduced in 1986. However, they rarely remain exactly the way they were built. Over the years, they have been routinely modified and updated. But what does that mean for their software, and in particular, for the compilers originally used to create that software? Can those compilers still be used in a software development environment that has changed radically over the years and will keep doing so?
There are several reasons why it’s not straightforward to switch to a new compiler when updating legacy software. For example because of dependencies on the compiler’s behavior in the build and test procedures, or because of the existing procedures that are reviewed and approved for safety critical applications. But does that equally apply to the development environment in which the original compiler ran? One of our customers recently asked us about moving a legacy compiler to an updated operating system, mainly because the company was currently running the compiler on an outdated and no longer supported Windows® XP computer. From now on, it wanted to run the compiler in a Windows 10 environment. Indeed, it was already testing the idea and the compiler seemed to be running fine under Windows 10.
But what the company wanted to ascertain was “how can we know for sure that the compiler is running correctly?” Turning to the original vendor of the compiler didn’t help, because although they were still around, they were not willing to extend any guarantee to an operating system that the compiler was never tested on.
SuperTest to the rescue
There are two ways SuperTest can help if you’re in this situation. Firstly, you can use SuperTest to validate your legacy compiler on the new operating system. This will tell you about the quality of the compiler when it is running on the new system, and as we’ve explained in previous blogs, it is always good to know the shortcomings of the compiler you’re working with.
But what you really need to be sure of is whether the compiler generates exactly the same code when running under the two operating systems. So the second thing you can do is run the compiler through SuperTest on both operating systems, and then compare the assembly or object code generated (ignoring any date-related watermarks). If the assembly/object code is identical, you have reliable evidence that the compiler’s behavior is independent of the OS, because SuperTest’s comprehensive range of tests will have put the compiler through its paces on both systems.
Plan for the future
Going back to our customer’s question, you might well now be saying to yourself: “Wait a minute, does that mean Solid Sands still supports SuperTest on Windows XP?” No we don’t. But SuperTest and its tools are mostly distributed as source code, and if you need to get it running on legacy systems, we will help you and get it to work. SuperTest’s self-checking nature makes it easy to check that, if it runs, it runs correctly.
Better still, plan for the future so you never have to face the problem. If you are currently working on a product with an expected service life-time of 30 years or more, get SuperTest today, pass your compiler through it, and collect a reference set of generated assembly files. Then in 10 or 20 years time, when you want to switch to the latest and greatest operating system, install Python on the new machine (because it’s all that SuperTest needs today) and run SuperTest again. Future-proofing your compiler has never been so easy.
Windows is a registered trademark of Microsoft Corporation.
Subscribe to our monthly blog!