Punch card programming...

The second of our “reanimation” projects has reached a significant milestone. We ran the whole new system on the real hardware last week, and it mostly works. This is a big step for us and the client as the project has been quite complex in terms of how the development has been done.

As I said, our secret Industrial Control Client has had us working on a program that compiles in Visual C++ 6 on an XP VM. The result then runs on embedded hardware that is expensive and large and only available if you travel to the building where it lives. The nearest to ’testable code’ that we can get, without being on site is something that links correctly… To test the code, or even to make sure that it actually runs, we need one of the client’s staff members to travel to the site. This has been a challenging and slow moving project. It makes me appreciate how far our industry has come and how different it must have been working with punch cards. I’m so used to test-driven development and fast feedback cycles from code change to test, that getting into the groove for this work was hard for me. Initial changes made me very anxious; “what if this first change didn’t work as expected? Will the results of testing invalidate all of these other assumptions that I’m making here and does it mean that everything will need to be reworked once we get some results back from the site in a week or so?” In the end I had to just channel my inner Space Marine and “know no fear”…

We managed to get to a useful point with the work with very few site visits required. One, initially to ensure that my first changes resulted in something that still actually ran on the destination hardware, and then two more visits to test the code changes in big blocks of functionality.

The code changes required a very much slimmed down version of The Server Framework code so that the VS2022 code that runs on the Windows-based hardware could be compiled for the custom hardware. Taking C++17 code back to the C++ standard implemented by Visual C++ 6 in 1998 was interesting. Making sure that we needed only the bare minimum Server Framework code was complex. We’re used to using all or nothing of the framework; and splitting things out is made more complex by the fact that lots of seemingly simple pieces of framework code rely on some complicated concepts underneath the covers to provide debugging support and whatever.

I had some muscle memory issues with coding in Visual C++ 6 directly, and so much of the editing was done in Visual Studio 2022 with just the building being done in VC6. Luckily, the system can be mostly built on Windows 11 with VC6 and then test built in the VM once it builds OK in native form.

An interesting project. We’re now at phase 2 where we’ll add some slightly more complex threading code which will pull in more of the framework and will require a few more site visits.