In late May, I decided to sit down and finally learn C. This has been a goal of mine for some time, but in the past I hadn't gotten much further than trying a handful of exercises from K&R. This time I had a specific project in mind: Replicalc, a REPL-based calculator for Linux, MS-DOS, and Windows 3. This series is a short retrospective about the journey to the first Replicalc release, 0.1.0, which took a little over a month.
Lots of reasons!
I often keep a TI-83 calculator by my desk. I don't need a graphing calculator, but I like its REPL-based interface. I can type a whole equation with multiple operators, and evaluate it only when I press the Enter button. I'd love to be able to do this on my computer. There are a couple of options out there, but I'd rather develop my own. Can't be too hard, right?
So why support MS-DOS and Windows 3? I grew up with those operating systems, but was too young to be able to develop for them at the time. It's something I've always wanted to do, and it's still possible today even if the rest of the world has moved on. And thanks to Windows' backwards compatibility, it also allows me to target Windows 10 with little additional effort.
And why C? There aren't many other options when you want to target MS-DOS, and C is both well-supported and well-documented across the platforms I want to use. Also, Charles Petzold's book, Programming Windows 3.11, is primarily written for C, and will be useful when I eventually add a Windows GUI in the future.
The first thing I needed to do was figure out the most recent version of C that I would be able to use. C99 has some nice quality-of-life features, however, none of the MS-DOS compilers support it fully. That left C90.
Next, I needed compilers. My computer runs Fedora, which ships with GCC, so that's an easy choice. For MS-DOS, there are a few options. I went with Open Watcom since I already had some previous experience from Jim Hall's C programming tutorial.
For an IDE, I like to use Visual Studio Code. It has decent C support, including debugging. The debugger obviously doesn't support MS-DOS, but it would allow me to iron out most of the teething issues during the initial Linux build before porting to MS-DOS later.
Finally, I would need a way to test the code in DOS later on. I decided to use DOSBox rather than a VM. DOSBox is great for running games, but I heard it wasn't recommended for software. I decided to use it anyway because it would make it very easy to share and compile my source code inside the "guest". Otherwise I would need to set up SMB shares and configure networking for a VM. As it turns out, DOSBox did cause some issues during development (more on this later) but it still paid off in convenience.
Continued in Part 2.