A DOS program with a graphical UI for controlling timber drying kilns

It is funny how coincidences affect your whole career. I was in my first year of my microprocessor design education and I was learning myself Turbo Pascal 2.0 for CP/M on the side, when a friend of my uncle landed me a summer job at Norsk Data. I learned a lot about mainframe computers during those summer months, and I got to wet my feet in languages like Fortran, COBOL. and PLANC. PLANC had many similarities to Pascal, and I really enjoyed toying around with it.

In 1986, my uncle asked if I wanted to have a go at porting a timber drying kiln program on a DEC Rainbow 100 (CP/M) to an IBM PC (DOS). Naturally, I said yes. It was not very difficult to make the port from UCSD Pascal to Turbo Pascal 3.0, although it was still a very rudimentary program with very little UI and ReadLn inputs. In 1987, Turbo Pascal 4.0 arrived with a proper IDE!

I continued to make improvements to the DOS program, such as meticulously crafting an interrupt driven serial port unit, improved input, DOS specifics, etc.

Digression: Over the years I’ve told myself that it was the Black Monday stock market crash in October ’87 that ate all the HW jobs and made me switch from designing microprocessors to writing software,

However, at that point in time, I was already enrolled for the second year of the computer science education programme (having skipped the first year) – so I guess I was hooked on software earlier.

I probably assumed it was a lot cheaper to fix faults in software programs than in hardware microcode… Yeah, right!

OOP – Mind blown

The project remained a pet project while I completed my third year, and in May 1989, Turbo Pascal 5.5 arrived with something they called object oriented programming.

I was by now a fan of structured programming and was not overly sold on the new concept. The code I wrote was still mostly structured. I fiddled with the OOP concept and started wrapping some structures and code in objects. I still hadn’t grasped the concepts of polymorphism and abstraction, so my “OOP” code was mostly about code organisation.

After about 6 months, the penny dropped, big time! Oh Emm Gee, did it ever drop!

I realized that to encapsulate objects in such a way that they were identical on the outside, but different on the inside, I could hide the implementation details and have the objects that were compatible and interchangable when seen from the code that would use them!

After that, EVERYTHING started looking like objects.

I had made a “window” system for the text mode CRT, but then I got an idea. What if I could use OOP to do the same in Graphics mode? I already wrote some graphics code to present a line chart in graphics mode. Sure – I could more or less hide all the Gfx details from the core logic, and voila – I had something that looked a lot better than text mode.

A few years back – uh – 13 years is a few, isn’t it – I checked if I still could get the code to run – and in a DOSBox, I was able to run the app in it’s demo mode and capture it 🙂

With permission from Alfsen og Gunderson, here is the actual source code: https://github.com/LarsFosdal/DOSTimberDryingKiln

Alfsen og Gunderson

The final exams were in June 1990, and I was suddenly in the job market. The company my uncle worked for, Alfsen og Gunderson (AG) – an engineering company – wanted me to take on a two year engagement, with the purpose of refining the kiln control program. They also said that if they were satisfied, they would offer me a permanent position.

Naturally, I accepted – and in July 1990, I started with the improvements on what up until then had been a on-the-side-of-studies project.

After about 15 months, in the autumn of 1991 – I had a feature complete, graphical UI, configurable number of kilns and tunnels, multi PLC, multi printer, multi resolution Timber Drying Kiln control program, installed at multiple locations around Norway, bearing the name P4 for Program 4. P3 was the previous text version. P2 the first port and P1 the original DEC program.

I had also written a control program for a 20 meter long fishing trawl fixation stretch bench. You dip the “knitted” net in a liquid rubber-like solution, and put it under high tension, close a lid over it, and heat it up for the solution to dry and hold all the knots in the net in position. The control program defined the heat, tension and time parameters.

When I went to ReFa (Redskapsfabrikken) in Finnsnes in Northern Norway to install the fixation control program and make the final adjustments, I discovered that I had forgotten to copy a newly written unit onto my diskettes, and the program would not compile. I spent the night rewriting the unit from scratch and that ended up being the final version of that unit.

Black Monday

But – Black Monday and the slump in the economy did impact the business of AG. They had shrunk from 150 employees in 1990 to 50-some in the autumn of 1991, and they had been bought by ABB (Asea Brown Boveri). So, I got the sad message that due to the dire financial situitation, they were unable to uphold their promise of a permanent position and I was given notice two months before Xmas 1991 that I only had employment out the year. Bummer!

Anyways, I stumbled upon an ad for a job where they wanted someone to port a Turbo Pascal DOS application to Turbo Pascal for Windows. I applied, got the job, so I went directly from AG to Falcon Information Services.

Strictly speaking, I was not qualified, as I had never done any Windows programming, but as I said during the interview, I like learning new things – so I got the job. But – that is a story for another time.

I did do some consulting for AG until early 1993. When they in the late ’90s were replacing my program with an off-the-shelf solution for control programs, one of my former colleagues at AG said they had not realized the amount of thought and work that had gone into my programs until then. I have to say, that acknowledgement felt good.

Other fun features of P4

All the text in the application, such as help texts and prompts, is kept in a .mes file which is verified for link integrity and “compiled” into a binary file. I like to think of that as my version of HyperText cards – as well as fairly forward looking with regards to translation and modification of the texts, without need for changing the application code.

In addition, every lead and prompt text also is in the .mes file and hence it is trivial to write a translated version of the .mes file and copy that into place to run the UI in a different language.

Although I was working largely alone on this project, it was an incredible learning journey. Studying hardware manuals, I wrote native “drivers” for EGA, VGA and Hercules video cards. I found out how to create and load custom fonts and created text render routines, light-weight windowing and menu routines, rule based input methods with character set filters, max/min values, list selection, etc.

I wrote an interrupt driven serial port “driver” for talking to the PLCs, and added an OOP layer on top that eliminated the differences in the actual protocols used to talk to each PLC.

I learned about chart rendering and printing and figured out how to draw on world coordinates in a virtual drawingboard and then map the physical coordinates of the output bitmaps (needle printers FTW) back to the world coordinates, so it was basically the same code that rendered the charts on screen and to the printer.

There is nothing quite as efficient as learning by doing. At times, it will be hard, but the more you experiment, learn and master – the easier it gets to evolve your skills. Study the books, the manuals, the articles, the source code, and write testable code – and – try to include references to the source of inspiration and documentation in your source code.

Keep Calm and Keep Coding