Jeff Duntemann's Contrapositive Diary Rotating Header Image

programming

INC Whew

Well. A few minutes ago I found myself staring at the last line of the last page of the last chapter of Assembly Language Step By Step, Third Edition. I’m sure it’s a feeling a little like that described by some of my friends who took their time getting through college, and one morning at the end of a term found themselves thinking, “Hey! I have enough credit hours now! I can graduate!”

It took so long that I wasn’t quite ready when I realized that it was finally over.

I celebrated by playing the MP3 of David Buskin‘s “Flying Child” and singing along. Loudly. That felt so good that I played Dean Friedman‘s “Ariel” and sang along louder still. Rather than make myself a little too nuts by singing Danny Hutton‘s manic cover of “Funny How Love Can Be” I poured myself a Diet Green River and ate too many Cape Cod Robust Russet potato chips before collapsing in my comfy chair.

Ten minutes later, Carol got back from Crystal Lake after a two-day sojourn wrapping up our trip and (not coincidentally) leaving me free to work here in Des Plaines. That was a piece of timing, but Carol’s good like that. We understand one another in a quantum-entanglement sort of way that is the very best part of loving a woman for forty years.

In truth, I’m not quite finished. Chapter 12 is still first draft and needs a polish pass. I have to write a new introduction and bibliography, and add two pages to the instruction reference. After that, of course, comes proofs and so on, but it’s starting to look like I’ll have real books sometime this fall, probably by November and perhaps as early as October. It ran a little long (187,000 words instead of 175,000) but not long enough to fuss about. It soaked up almost all of my creative time and energy since last December. I learned a lot doing it, and as often as I found myself feeling ragged and annoyed at the scale or the pace of the project, I’m still glad I did it. The book has been in print now for 21 years across three editions (the first from a now-defunct publisher under another title) and could well be in print for another ten or fifteen. It paid off my mortgage. In fact, it’s made me more money than all my other paid writing projects put together, in all of the 35 years that I’ve been writing for money. It’s gotten to be kind of an institution around here, and I’ll rewrite it again if I have to.

But not this week. Please.

Cranky Insight

I haven’t posted for eight days, and people are starting to send me notes asking if I’m all right. I am, though I’m not sleeping well and don’t have my usual energy. Whatever time and oomph I haven’t had to devote to family issues here I’ve been pouring into the book. I’m now 161,000 words in, of about 180,000 total, so the end really is in sight–but seeing the end isn’t enough. I still have to grind through the material.

I will take an opportunity to gripe a little, this time about the Insight GUI shipped for and with the gdb debugger. Insight isn’t perfect, and parts of it are excellent–especially compared to the molasses marathon of using naked gdb in a console, God help us–but a good deal of it is simply awful. I chose Insight as the example debugging tool for my third edition, in part because it’s technically a component of gdb and not an add-on. However, it comes closer to the truth to say that after I interviewed Linux debuggers for use with C-free assembly code, Insight was the last man standing. Most debuggers assume that they’ll be dealing with clib and C source code, and don’t know how to load a C-free executable, even if contains valid STABS or DWARF debug info. At least Insight allows assembly language source debugging in a window.

As grateful as I am for it, certain things about Insight make me nuts. Good example: The Memory view. This is an ordinary hexdump-style memory display, with only two means of navigation. You can scroll the dump up or down for 16 bytes by clicking the arrows, or you can type in a new address in an entry field. And I mean type–the GUI does not recognize paste from the clipboard. If you want to fill the field with a new address, the keyboard is all you get. Worse, moving up- or down-memory by clicking the arrow buttons takes one to three seconds to refresh the window. (This is not an exaggeration. I timed it.) An operation like that, on a 2.8 GHz machine, should be instantaneous. How about buttons to take us to the address currently in ESP or EIP? Or sheesh, maybe implement paste from the clipboard to the address entry field!

I’m tempted to blame it on the fact that Insight is written in Tcl/Tk, but I’ve actually used Tcl/Tk and I don’t think it’s inherently that slow. The only guess I would hazard is that because working in naked gdb is horrendously ponderous but still nearly universal in the Linux world, the guys who wrote Insight didn’t know any better, and thought that their results were transcendently wonderful. Not true. One click is often (if not always) worth twenty or more frantic keystrokes. To me, that’s a win. You command-line people should get out more.

Odd Lots

  • The rest of Bichonicon was uneventful enough (and I was tired enough) that I decided it wasn’t worth a whole ‘nother entry. Aero won a ribbon on Saturday, but did not win points. Carol and I ate too much fast food. We came home. End of story.
  • I did briefly run into St. Louis native Nancy Frier, granddaughter of the man who founded Alox Manufacturing Company, maker of shoelances, kites, marbles, military radar corner reflectors, and lots of other odd bits. She had visited a marble factory in West Virginia and showed me a video of glass marbles being made on a machine very similar to the one Alox had used. It’s a great video, and when she uploads it to YouTube I’ll post a link here.
  • And I found two bottles of Diet Green River. The trick is to look in small local grocery stores or local chains, like Garden Fresh Markets or Shop and Save. Have not yet checked the local Butera, but it’s on my list.
  • A reader chided me that “All your damn dogs look alike. Post more pictures of Carol.” He’s right about the dogs, I guess, but I have posted quite a few pictures of Carol in my photo gallery. In fact, here’s an almost 40-year run of the two of us together.
  • From the Words I Didn’t Know (or at least understand) Until Yesterday Department: “Kukla” is Russian for “doll.” The eponymous little guy on the seminal Kukla, Fran, and Ollie kids’ show had been built as a doll for a friend by puppeteer Burr Tillstrom, who liked the doll so much that Tillstrom kept him, and made him the star of the show.
  • From the Words I Didn’t Know Until Yesterday (And Didn’t Think Were Necessary) Department: A merkin is a wig for women’s genitalia; basically, a pubic toupee. Sheesh. English has a word for everything.
  • Here is A Brief, Incomplete, and Mostly Wrong History of Programming Languages. I think it’s truer than people will admit, especially the Pascal entry. Thanks to Bruce Baker for the link.
  • Blandishments: Salt-free mustard and ketchup.
  • A guy scraped Twitter data for the phrase “just landed in” and mapped the air travel data, hoping to create a new tool for epidemiology. Germs like jet aircraft for various reasons, and this is the first genuine use for the Twitter system that I’ve ever heard of.
  • I follow Icecap as part of my ongoing climate research, and it’s interesting for another reason: It consists of a navigation column and three narrow content columns. I’ve never seen another blog with a layout quite like this, and I like it. Narrow is better than wide, especially for small print. Scanability (given that I don’t read every entry) is high.
  • Finally, some images speak for themselves. This is one of them. (Thanks to Baron Waste for the link.)

Ncurses! Firehosed Again!

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…)

Coming -Clean About Eclipse

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.

Going Into Eclipse

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?