Source Control Techniques 
 

Some Source Control Techniques

Binary compares - to verify identical executables

In 1984, my employer wanted improvements to a key piece of equipment, called the Mach One. They already had a very large green-bar printout of the source code, which was in assembler for the PDP-11 computer from Digital Equipment Corporation. The Mach One was a very customized PDP-11 computer, that controlled multiple video devices, in real-time with deterministic timing accuracy. I obtained the source code (on disk) from the manufacturer, and compiled the program until I was able to get an exact binary compare between the program I compiled, and the last version from the manufacturer.

Conditionals - for all changes to the source code

Once this base-line was achieved, I knew I indeed had the correct version of source code, and had set all the compiler settings correctly. From that point forward, I put all of my changes to the source code in conditionals. For every set of changes, I would use a new conditional (usually the minor version number). After I was done editing the code to make all the changes for a new version, I would compile the new version of the program with the conditional defined, and then disable the conditional, compile the program, and verify I still had an exact binary compare to the last version. I could also quickly search the source code for the conditional, and walk-through my changes to verify they were complete.

Conditionals - for merging separate versions of source code

In 1986, the manufacturer of the Mach One contracted with me to move improvements from the code used for systems in the USA, to the code used for systems in Europe. In this case they supplied me with two versions of the source code, that were from the same original source code, but had been split apart and maintained separately for some time. I compiled the two versions of the code and saved the executables. I wrote a lot of custom programs (in my text editor and also using Turbo Pascal) to automatically compare and merge the two sets of source code, using a single conditional to differentiate the differences. When I was done, I was able to compile the source with or without the conditional, and verify with binary compares that the merge was successful and exact. At that point, it was easy to search through the text, and move improvements from one version to the other.

Conditionals - for customizations of source code

In 1987, I started to support most of the existing Mach Ones worldwide (I supported about 40 systems). Using conditionals and binary compares in this way, I was able to supply improvements to my clients, even though I was unable to run the program at my development office (due to the lack of expensive video equipment). The original manufacturer of the Mach One maintained separate source code for each client, because each was usually slightly customized in some way. Since each client's source code had been maintained separately, I had to use my custom difference program to locate customizations, which I then moved into my (single) source code. Using conditionals I was able to keep all my clients on a single set of source code, even though there were customizations for each.

Source code analysis

In 1991 I started porting the Mach One from the customized PDP-11 computer to a PC. This was done in stages, and completed in 1993. I am still supporting these systems, and still use conditionals and binary compares in my Turbo Pascal source code the same as before. I use several function libraries from TurboPower in my program. I also use the Turbo Analyst program to do code analysis. The program is over 50K lines, is extremely reliable and robust, and runs continuously for weeks at a time.

Conditionals - for merging separate versions of source code

Between 1994 and 1996, I worked part-time on a very large pharmaceutical order-entry program written in Turbo Pascal. This large program used multiple EXEs, and consisted of well over 100 units. The make file compiled these units into about 80 different programs, some of which were used for database maintenance. One of my first jobs was to merge two versions of the program, so that improvements made to one version could be moved into the other version. Here again, I stored the 80 EXEs for each version, used custom programs to merge the source, and did binary compares to verify that the merge was exact.

Accurate analysis of source code used in multiple programs

With the order-entry system, I also used the Turbo Analyst program on the source code to find unused unit references, unused variables, and other things that could be improved. Since the Turbo Analyst program is made to parse a single program (just like the Turbo Pascal compiler), I couldn't use the information it created for just a single program. I had to run the Turbo Analyst on all 80 programs, saving the reports to disk files, and then use a custom Turbo Pascal program to merge the multiple reports. That way, if an item was flagged as unused in some programs, but was used in another program, I would be aware it was used. Only if the item was not used in all of the 80 programs could it be eliminated.

For a few years starting in 2010 I worked on expensive embedded equipment using Turbo Pascal and I again used techniques described above.  If you'd like a few more details see near the bottom of this APro page.


Return to the Communications page
Return to the home page for Breneman Labs

Show this image for email address

BRENEMAN LABS
Customer support is our top priority!
Contact information on home page
email: see the image to the left