I’ve mentioned here that I’ve got a contract and have begun work on the third edition of my book Assembly Language Step By Step. The second edition was written almost exactly ten years ago, and I had mostly given up on the book as obsolete and out of print forever. My publisher most sensibly wants me to get rid of all the DOS material and rewrite the book entirely for Linux in general, and Ubuntu Linux for the sake of the screen shots. The second edition did address Linux assembly with NASM, but almost as an afterthought, having first taught the concepts of assembly using DOS as a tutorial platform.
So I got to work. And as I soon discovered, whew! A lot of things have changed in the last ten years. Ubuntu didn’t exist, and the notion of not having root at all would have been thought absurd in most Linux geek circles. But so it is, and I’ve had to become intimately familiar with sudo in all its forms and wrappers. Ten years ago, I just worked in root and was careful–if you were going to work in assembly, there was really no other way.
KDE was brand-new in 1999, and GNOME wasn’t even in general release. I worked in the console and mostly hated it, and when the book was done, I mostly forgot it. That’s easy enough to do across ten very busy years, and the console does not help you remember anything. One way to look at a GUI is as graphical short-term memory reminding you what options exist and what their parameters are, just in case you don’t use a command often enough for it to rise above the brain sludge in your head. Essentially all of the work I’ve done in Linux in the ensuing ten years has been in the GUI desktops, and it’s all been user stuff, largely to get a sense for how readily Linux (Ubuntu especially) might replace Windows. On the programming side I’ve played mostly with Gambas and Lazarus, which correspond (roughly) to VB and Delphi.
Faced with a console again, I remembered about four commands: ls, cd, pwd, and cat. I remembered that ./ specifies the working directory. I knew that there was a way to add the working directory to the search path, but I had to look it up. Fainter still were memories of console control codes: ESC [2J…or was it ESC [1J…or ESC [1H? More looking up. More printing of Web pages, more sitting in my big chair, drinking from an increasingly familiar firehose. Eight years or so ago, I got ncurses installed on the Xeon under Red Hat and figured out how to call it from NASM. Alas, I cannot find any least traces of my playing-around code, and so I have to learn it all over again, and re-create the nascent example programs I had written against the possibility that I might revise the book someday. Someday didn’t come until I was certain that it never would. Then…wham!
Someday is here.
I’m not adding material to the end of the book, except a chapter section on how to call ncurses. The first three chapters won’t change much either. (Foobidity!) Mostly I’m rewriting the initial steps in actual coding, and the distressing thing is that my elaborate memory-mapped text output library, which taught so much of basic assembly so well, simply won’t work in protected mode. So I need to look at what will demonstrate the same principles and not talk to video memory. A CPUID utility suggests itself, so I’ve connected the CPUID instruction to the firehose.
And I’m writing C code again. God help us, I feel like I want to wash my hands every fifteen lines–but that’s just the nature of the job. Like I’ve said many times, when you work outside your preferences you broaden your horizons. This doesn’t mean you shouldn’t bring soap. (At least I’ve got the firehose…)
Forty years ago, we watched three human beings travel to the Moon. Well, they got there, and took a spin or two around it, and then came home. They didn’t land, but that’s ok. (Gravity wells are a bitch.) We didn’t appreciate at the time what a feat it was, and would not in fact understand the bittersweet truth for many years thereafter: We had a window; it opened, and it closed. It may not open again—but while it was open, we took it.
