Jeff Duntemann's ContraPositive Diary

I got the NASM plug-in installed into Eclipse yesterday, after a tip from Bishop Sam'l Bassett of the Old Catholic Church, who had spotted a forum comment that I hadn't. (The real skill in using the Internet is crafting your search terms.) Eclipse has a plug-in cache, and sometimes you have to empty the cache to get it to refresh its list of plug-ins. I intuit that this function is usually served by exiting and restarting Eclipse, but in my case that wasn't enough.

I got the cache cleared by rebooting the system, and suddenly, there was the plug-in. The forum comment in question also mentioned that you can start Eclipse with the -clean command-line parameter, and Eclipse will start "clean" with an empty plug-in cache. I didn't have to do this, but it's worth knowing.

Otherwise, I had done all the right things. Eclipse doesn't really "install" plug-ins in the sense that we install things in Windows. Unzipping a plug-in archive under the Eclipse plugins directory is all that installation requires, assuming that the archive contains all of a plug-in's necessary elements.

There's still work to be done in configuring Eclipse to develop with NASM (setting paths for the assembler and gcc, and a bunch of other things) but that's straightforward and should be done long since by tonight. I'm going up to SoftPro Books in Denver tomorrow with Jim Strickland, and we'll see what they might have that could be useful getting up to speed with Eclipse. A quick scan of pertinent titles on Amazon indicates that most books are about developing Java apps with Eclipse, but some discussion of the IDE in general terms would be very useful about now.

I have a gripe about Ubuntu that I might as well air at this point. The folders in which you unpack Eclipse plug-ins are owned by root, and unless you're running as root you can't unpack files into those folders. Fair enough. I had hoped that Ubuntu and Gnome would have evolved sufficiently since I last did this sort of thing to just pop up a sudo dialog when the user (and we're all users on this bus; Ubuntu does not really have a root account in the strict sense of the word) attempts to do something that violates permissions. But no; it throws up a fairly useless message and glares at you. To get the job done you have to bring up a terminal or the graphical command line dialog and run "gksudo nautilus" to run Nautilus as root. Installer systems like apt-get don't throw tantrums like that on you; when they need permission to install files in folders owned by root they just ask for your password. Nautilus needs to do that.

After all, I'm the Visual Developer Magazine guy, and I have a fetish: Command lines should never be compulsory. Never. It's 2008. We're supposedly all OS grown-ups now. Fundamental things like file management should be 100% point-and-click.

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?