As I mentioned yesterday, my publisher wants me to revise Assembly Language Step By Step over the coming year, for release in early 2010. I had assumed for some time that they considered the book a dead issue, though judging by my royalty statements, it continues to sell. And that's a clue: When the market is bad, publishers get nervous about striking out in entirely new directions with new series and lots of new titles. A handful of books are what they call “evergreens,” because they sell all year, every year, for years and years and years. I think that a lot of evergreen titles are going to be freshened up and reissued in the next few years. The publisher considers my book an evergreen (it was first published, after all, in 1989, and has sold steadily ever since) and the acquisitions editor had done her homework. She wanted DOS to go. She wanted to ditch the CD bound into the book. She wanted more Linux coverage. And if possible, she wanted me to use Ubuntu as the flavor of Linux cited in the book.
I'm cool with all that. I had decided years ago that DOS would be missing from any future editions. I had assumed that I would include coverage of 32-bit Windows console apps, but I'm not welded to that notion, nor to any particular Linux distro. The book is not about Windows, nor about Linux. It needs an OS over which to run the example programs, but which OS is mostly immaterial, so long as it supports the Intel 32-bit flat model. The book is a “front door” introduction to what computers actually are, and how Intel-based machines function under the hood. It's about that waydeepdown place where the software meets the hardware. It is not about how to make API calls nor how to coordinate all the folderol that happens inside large-scale apps.
A lot of people misunderstand the book, and I get gripes all the time about how it “doesn't go far enough” and “doesn't teach the principles of software development.” That's not what it's for, and I don't have the page budget to write enough book to satisfy all my gripers. The format has worked across twenty years and three editions, and I'm sticking with it.
There's still a lot of work to do. Much of the coverage depends on DOS, DOS calls through INT21, and BIOS calls through INT13. All that has to go. I need to explain how the software interrupt mechanism itself works, and for that I'm going to defy the Unix Gods and explain how to use the Linux INT80 call gate. This is heresy, but the mantra that “INT80 calling conventions can change at any time” isn't sufficient reason to keep the secret. I've asked several people to show me an example—even a single example!—of when a Linux INT80 kernel call changed, but so far I've seen nothing. And even if some of the more arcane kernel calls are still evolving, I doubt that the very simple calls have changed at all in many years. Proper warning will be given, but I don't bow before that particular altar anymore.
Alas, if DOS goes, Rob Anderton's excellent NASMIDE programming environment has to go as well, and something else will need to be found to help people load, assemble, link, and run the examples. I've got John E. Davis' text-mode JED editor installed, and in a pinch it will do, but the holy grail for me would be running NASM under Eclipse. Eclipse is a sort of Erector set (ok, a Lego set) for creating platform-independent IDEs in Java. Almost everything beyond the very basics is a plug-in. You can get plug-ins for most modern languages and toolsets, and Eclipse can run anywhere that Java runs. (Of course, your tools must either be in Java or available on the host hardware.) Eclipse itself and nearly all available plug-ins are free and open-source. I've already got it running here on both XP and Ubuntu. All I need is a NASM-oriented assembly language plug-in.
The infuriating thing is that such a plug-in exists, but it comes with no installation documentation, and it does not install the way all other Eclipse plug-ins I've seen install. Eclipse has a clever system in which plug-ins are posted on the Web using a standard format, so that the Eclipse environment can fetch them down and install them automatically, given a URL. I've downloaded the plug-in file and have tried just about everything to get Eclipse to suck it in or even see it. So far, no luck. If you've ever gotten it to install and work, boy, I'd sure love to learn the secret.
I have to scope out some new example programs, write them, and then describe them, and make sure that DOS and segmented Real Mode retreat into a few pages of historical context. It's months of work, even if it becomes my major project (which it will) and knocks most of my lesser projects back into the closet (which it might.) I'm slurping at the firehose right now regarding Eclipse, and have a couple of books on order. It's going to be a long climb, but I've made such climbs before, and they're always good mental exercise. It'll give this book (which I considered a throwaway back in 1989!) another eight or ten years of life. The publisher has always treated me well, and the book paid off my mortgage. What's not to love?
