Authoritative collection of all of my articles
Over the last few days, there has been this… debate over at Twitter sparked by a claim that you cannot be a good programmer without knowing C. You obviously can be one, but there is some nuance in what “knowing” C is truly about. Here is my take on the matter. Let me repeat this first: of course you can be a perfectly good programmer without knowing C. Knowing a language doesn’t make or break a programmer, and there are great programmers out there that don’t touch C.
A blog on operating systems, programming languages, testing, build systems, my own software projects and even personal productivity. Specifics include FreeBSD, Linux, Rust, Bazel and EndBASIC.
The recent deep dive into the IDEs of the DOS times 30 years ago made me reminisce of DJGPP, a distribution of the GNU development tools for DOS.
I remember using DJGPP back in the 1990s before I had been exposed to Linux and feeling that it was a strange beast. Compared to the Microsoft C Compiler and Turbo C++, the tooling was bloated and alien to DOS, and the resulting binaries were huge. But DJGPP provided a complete development environment for free, which I got from a monthly magazine, and I could even look at its source code if I wished. You can’t imagine what a big deal that was at the time.
But even if I could look under the cover, I never did. I never really understood why was DJGPP so strange, slow, and huge, or why it even existed. Until now. As I’m in the mood of looking back, I’ve spent the last couple of months figuring out what the foundations of this software were and how it actually worked. Part of this research has resulted in the previous two posts on DOS memory management. And part of this research is this article. Let’s take a look!
In “From 0 to 1 MB in DOS”, I presented an overview of all the ways in which DOS and its applications tried to maximize the use of the 1 MB address space inherited from the 8086—even after the 80286 introduced support for 16 MB of memory and the 80386 opened the gates to 4 GB.
I know I promised that this follow-up article would be about DJGPP, but before getting into that review, I realized I had to take another detour to cover three more topics. Namely: unreal mode, which I intentionally ignored to not derail the post; LOADALL, which I didn’t know about until you readers mentioned it; and DOS extenders, which I was planning to describe in the DJGPP article but they are a better fit for this one.
So… strap your seat belts on and dive right in for another tour through the ancient techniques that DOS had to pull off to peek into the memory address space above the first MB. And get your hands ready because we’ll go over assembly code for a step-by-step jump into unreal mode.
It is hard to believe but we are already one month into 2024. January has flown by for me and I haven’t done a good job at keeping up with news sites… but I have been reading them on and off and I have collected a small set of interesting articles.
To everyone new around here, hello and thanks for subscribing! For some context, what follows is my manual selection of cool articles, videos, and projects I stumbled upon during this time period. However, this is not just a dump of links: each link is accompanied by a short commentary to justifies why I thought the material was interesting, why it is relevant to this publication and, more importantly, an attempt to nudge you into reading the source.
Let’s get to it.
Since the last article on the text-based IDEs of old, I’ve been meaning to write about the GCC port to DOS, namely DJGPP. As I worked on the draft for that topic, I realized that there is a ton of ground to cover to set the stage so I took most of the content on memory management out and wrote this separate post.
This article is a deep dive on how DOS had to pull out tricks to maximize the use of the very limited 1 MB address space of the 8086. Those tricks could exist because of the features later introduced by the 80286 and the 80386, but these were just clutches to paper over the fact that DOS could not leverage the real improvements provided by protected mode.
This detour is long but I hope you’ll enjoy it as much as I enjoyed researching the topic. I’ll walk you through the changes in the x86 architecture over time, starting with the 8086 and ending in the 80386, and how DOS kept up along the way. I’ll conclude with a peek into DOS’ own MEM and MemMaker utilities. I must omit details to keep the text manageable in size though, so please excuse the lack of detail in some areas; just follow the links to external documentation to learn more.
December draws to a close as does 2023, which means it’s time for yet another monthly links recap. For context to everyone new around here, what follows is my manual curation of cool articles, videos, and projects I stumbled upon during this time period. But this is not just a dump of links: each link is accompanied by a short commentary that justifies why I thought the material was interesting, why it is relevant to this publication and, more importantly, an attempt to nudge you into reading it.
I grew up learning to program in the late 1980s / early 1990s. Back then, I did not fully comprehend what I was doing and why the tools I used were impressive given the constraints of the hardware we had. Having gained more knowledge throughout the years, it is now really fun to pick up DOSBox to re-experience those programs and compare them with our current state of affairs.
This time around, I want to look at the pure text-based IDEs that we had in that era before Windows eclipsed the PC industry. I want to do this because those IDEs had little to envy from the IDEs of today—yet it feels as if we went through a dark era where we lost most of those features for years and they are only resurfacing now.
If anything, stay for a nostalgic ride back in time and a little rant on “bloat”. But, more importantly, read on to gain perspective on what existed before so that you can evaluate future feature launches more critically.
Just a bit over 2 months ago, on October 5th, 2023, Jordi Mon Companys interviewed me about Bazel for an episode in the Software Engineering Daily podcast. The episode finally came out on December 18th, 2023, so here is your announcement to stop by and listen to it! Cover image (and link) to the Bazel interview in Software Engineering Daily. If you don’t have time to listen to the whole 45 minutes, or if you want to get a sense of what you will get out of it, here is a recap of everything we touched on.
The computers of yesteryear had this little feature known as blinking LED lights 🔆. They also had this other feature called noisy disks 💾 and loud fans . Uh wait. Features? Why “features” and not “annoyances”?! 🧵👇 Front panel of a common PC case in the late 1990s. My Pentium MMX 166 was hosted in one of these. You see, these bright lights and loud noises acted as canaries 🐦 in a performance mine.
It’s more likely than you think! In a surprising twist of events, Microsoft is exploring the addition of a command-line (CLI) text editor to Windows. If you ask me, not having a CLI text editor on Windows is mind-boggling: you can access a Windows machine via SSH these days, so not having an editor that works in the console is a big handicap for remote system administration. So, should Windows bundle a CLI text editor?