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…)
I so dearly want to comment ‘Waaaah!’ but I won’t, because that would be rude. It’s one thing to not like C (or COBOL, or Forth–I don’t care for SQL, or databases, at all), but to assert that programming in C is somehow dirty is, well, misplaced emotion. It’s a step away from the rational that I find odd and out of character for you. It veers perilously close to an exercise in Catholic Guilt ™ (patent pending).
Yes, it’s your space and you can write what you wish. I just think it’s a bit over the top to invest that much negative emotion in something like that.
Maybe I need to start hanging smilies over my rants. Ahh, me. Fielding a couple of C rants a year (and maybe not even that many) is one of my trademarks. I can’t let my people down.
Now, “dirty” is not the right word (and not a word I used) and what I’m recoiling from is not the language. It’s the culture. I find C culture profoundly disturbing. It’s combative and tribally creepy, and I have never seen anything like it associated with any other programming language. What other language has its own Obfuscated Code Contest? (And sheesh, like obfuscated C is hard? Put on an Obfuscated COBOL Contest and I’d be impressed.)
I find it appalling that unbounded hand-grenades like strcat() and strcpy() are still in clib after all these years. If creating reliable (and exploit-free) code was the goal, that stuff would have been tossed out ages ago, or at least exiled to a separate module under a legacysecurityholes.h header file. Yet whenever I’ve made the suggestion, C partisans act like I’m spitting on the flag.
It is to shudder.
Ok, rant over, and I apologize to those who might have been offended. The psychology of programming language adherence is a fascinating thing. I learn something new about it a couple of times a year.