Happy Hacking Life
For the past two installments, I wrote about the technical aspects of the MS-DOS communication environment, Program of the Air. The biggest factor was that by using generative AI, I was able to decipher the source code in a short amount of time. In reality, it contained enough information for an entire book, so it was a bit of a stretch to cover it in just two articles.
While writing, there was something that kept bothering me. That is, what exactly was so fun about it? To borrow the words of my friend Emi Tamaki, it might be called a 'Happy Hacking Life'.
Making things with what was on hand
The Air Virtual Machine (AirVM) was built by stacking layers: from very low-level parts that directly controlled computer hardware, to middle layers that wrapped them, to mechanisms like virtual memory and page swapping using EMS memory, and finally, at the top, a bytecode virtual machine based on 1970s Pascal P-code. By using this layered structure, I was able to provide compatibility not only with the PC-9801 but also with the 'DOS/V' that was emerging for the IBM PC at the time. I originally thought of virtualization because there was a request to port the communication language 'CUE' to Mac and Unix.
The Air C Compiler had completely different technical requirements. I incorporated the object-oriented concepts that were emerging at the time into the C language, and introduced features and control syntax to make it easier to write application behavior for real-time interactions such as keyboard input, timers, and communication-based I/O. In addition, I strengthened string processing, provided native-level support for regular expressions, and prepared a mechanism that allowed native calls to access the OS and the machine itself to be called transparently from virtual code.
Thinking about it, whether it was these virtual machines or the compilers, it could be said that they were the results of a gritty, patchwork-like practice—what I call 'bricolage' in this series. This included knowledge from computer science textbooks, insights from emerging operating systems like MINIX, ideas obtained through PC communications, the structures of other software, and even deciphering code by disassembling the output of Microsoft C.
The world was supposed to be a better place
The motivation was clear: besides saving on phone bills, there was also a UI/UX requirement to deconstruct the then-common VT100 terminal emulator and transform the experience of using PC communications into something completely different.
I wanted to make it possible for people who weren't familiar with computers to communicate freely, and to create communication software that could be used by anyone, from children to the elderly, regardless of age or gender. I believe there was a wish or hope that by doing so, the world would become a better place.
When I was making air craft, a user gave me this request: since they could only use one hand, could I make it so that operations could be completed with just one hand? Another person told me that since it was difficult for them to distinguish colors, they would prefer it if I didn't use green for text. I hadn't even thought of it, but I realized that many different people were using it, and that a little bit of ingenuity could improve their lives. This was around the time when barrier-free design was just starting. As an indoor person myself, I felt that a better communication environment could change my life. At the same time, I felt that it might make the world a little bit better.
I was building a custom bike
This program on MS-DOS worked by directly controlling the OS and hardware to extend their functions. I was treating the entire computer as my own.
This is similar to tinkering with old motorcycles. You don't just change the tires, handlebars, or muffler; you fine-tune the carburetor settings, change the number of sprocket teeth, or stiffen the suspension to suit your riding style. You can see everything inside, and if you have the tools, you can reach it. You could say that I was able to share what I had disassembled and rebuilt to my own liking with many people.
Programmers who could manipulate computers at will were called hackers.
As an aside, this word would later take on a completely different face. The other day, at the recommendation of an old friend, I bought Bruce Sterling's 'The Hacker Crackdown'. It's the book on the cover photo, but I haven't read it yet. It is a non-fiction work that follows the aftermath of how, around the same time I was peering inside the PC-9801, the same word began to be used alongside warrants on the other side of the ocean. I'll talk about that in another installment.
However, it wasn't that I was free
I tried to write that back then I could access all functions without restrictions and that I was free, but I hesitated because it seemed to contradict my previous article. That couldn't be the case.
640 kilobytes. The 8086 segment boundary. Floppy disks were still in active use. A pseudo-single-tasking OS. Almost everything I wrote in the previous two installments was a record of the battle against constraints.
It wasn't that I was free. The constraints were visible. They were within reach. That's why I could fight them. I think that's all there was to it.
In the third installment, I wrote that I created a programming language because phone bills were too expensive. It's the same thing. If there hadn't been any constraints, I probably wouldn't have created anything.
A car that won't let you open the hood
The operating systems of today's PCs, Macs, and smartphones are extremely sophisticated, allowing anyone to create apps of a certain level. Hardware has also evolved, with processing power and memory over 10,000 times greater than in the past.
However, constraints haven't disappeared; they've just been moved to places you can't see or touch. If the MS-DOS environment was like building a custom motorcycle, then the software development and user experience for today's smartphones, Macs, and PCs is like switching to a Lexus. Except, they won't let you open the hood. That's how it seems to me. The experience is well-crafted, but no matter who makes it, it ends up looking much the same.
What once spread out before us was a vast ocean where everything was handmade, and with no materials available, we programmed fueled only by passion. We had to start by building the boat itself just to figure out how to set sail. In a sense, it was like the resolve to row out alone into a blue ocean. You never knew what might happen.
However, I don't intend to end this by saying 'the old days were better.' If the location of the constraints has simply shifted, then there must be constraints invisible to me, and an ocean beyond them, right in front of a twenty-year-old today. Even with generative AI, I believe the ocean hasn't disappeared; its location has just changed.
And then, generative AI
It was that generative AI that deciphered the 35-year-old source code in the two previous installments of this article. It is the very tool that allows you to create something similar quite quickly. I am writing about the days when I fought against constraints, aided by the very tool that dissolves them.
Yet, for me personally, that experience of interacting with people through my own body and senses, and practicing what I learned like bricolage to create things, has become a precious asset in my life. Perhaps that is why I am still able to continue creating software today. It was a very happy experience and practice.
Happy Hacking Life. Emi Tamaki, who coined this phrase, is someone who researches the very sensations of the human body. I feel as though I have been living out those words myself.