After getting Delphi 2007 to run on Windows 10 and seeing some of my earlier Delphi programming again, I was intrigued to try if I couldn’t get Turbo Pascal 7 working too. This was the development environment that I first started programming with in school in 2000. Of course, Windows 10 on an x64 machine has no way of running 16 bit DOS applications, so I needed a different solution.
Installing on hardware: fail
I do in fact own the full set of Borland Pascal 7 installation floppy disks as well as the manuals. Of course, I can’t install the software from them anymore, as I don’t have a floppy drive. Also, I doubt, they would even be readable anymore. But I made a backup of the disks’ contents and kept it was as a ZIP file.
I also still have my 1GHz Pentium III powered laptop running Windows ME from 2001. I remember fondly many a night spent sitting on that laptop working on some Turbo Pascal project I had given myself.
Unfortunately, the installer would not work as it was complaining about “insufficient memory”. This is funny as the 256 MB of RAM my laptop has were substantially more than computers had when Turbo Pascal 7 was released.
Maybe the problem wasn’t that there was too little memory, but rather too much of it. For instance, there is an integer overflow error in the Borland Database Engine causing it to report insufficient disk space when it encounters free space close to a multiple of 2GB.
So next, I tried setting up a virtual machine in Hyper-V. This would allow me to tweak the amount of memory the installer was seeing.
While in college I had free access to Virtual PC 2004 and so ended up with one virtual machine for each version of Windows I had owned up to that point. Unfortunately, all of the machines running Windows 9x/ME would fail to boot in Hyper-V. The earliest version to run was Windows XP.
Unfortunately, Windows XP demanded I activate before I was able to even log in. But without an opportunity to install drivers for the virtual network adaptor, it wasn’t able to get an internet connection and for some reason the phone activation failed as well.
I was, however, able to boot Windows into safe mode with command prompt, allowing me to execute the following command to “rearm” the activation and buy me some more time to get the registration issues sorted out, because of course, this was a licensed version of Windows.
After I did that and could log on normally, I still had trouble with getting a network connection between host and VM. So in order to get the Turbo Pascal installer onto the VM, I had to copy it to the VM’s virtual hard drive (VHD). Luckily, Windows 10 makes it really easy to work with VHD files: double-clicking mounts them as a drive and you can copy any files you want onto them just like with a real disk.
Now I had all the pieces on the VM and was ready to install. However, no matter how much or how little memory I assigned to the VM, the installer’s unzip component would always complain about it being insufficient. I considered writing a replacement for the unzip.exe which would not have this limitation. But it didn’t come to that, as I remembered having an installed version of Turbo Pascal 7 on a VM that I had cloned from the PC I used when I first started programming. I copied it to this VM, and boom there I was looking at white and yellow text on blue background: the Turbo Pascal IDE.
A few more steps
What you see above is part of the source code to TaRech, an RPN-based calculator that I wrote as my first project while learning Turbo Pascal.
Compilation, however, failed, because some essential components were still missing: object files for the graphics components (EGAVGA and the fonts used by my application). I found a solution in an old physics textbook on Google books. This command line uses the binobj.exe utility from Turbo Pascal’s bin folder to convert bgi and chr files into obj files:
binobj ..\BGI\egavga.bgi ..\OBJ\egavga.obj EGAVGADriverProc
The next problem was that once compiled my program failed to run, crashing during startup with error 200: division by zero. I learned that one of the central pieces of code, the unit crt, has a bug that causes this error when running on very fast computers (i.e. clock speeds greater than 200MHz). Luckily, that article pointed me to a fix published by c’t, a German PC magazine, in an issue of theirs from 1997. That code is still available from their FTP server.
With all these issues sorted out, I was finally able to see my application running again.; including what at the time seemed like fancy transitions; Unfortunately, the timing in the virtualized environment is off and they were now running substantially slower.
TaRech (named after “Taschen-Rechner”, the German word for calculator) supports basic arithmetic as well as trig and other functions. You can choose a fixed number of decimal places or switch to scientific notation. The boxes on the right show the contents of the calculator’s four registers.
It took me a few hours, but eventually I was really happy to see code and program again which I had been really proud of at the time. That code is available on GitHub.
Looking back at it now, 15 years later, I am a bit ashamed of the quality of that code, however: there are no useful comments, almost all all variables have global scope, values for positioning elements on screen are hard-coded, identifiers have terrible names and I apparently couldn’t make up my mind whether to choose English or German.
But no matter whether I look at code I wrote 15 years ago or code I wrote 15 months ago, it’s all terrible. I think this is a good sign, as it means that I keep improving and honing my skills.