Chapter 4: The Right to Assemble The Process of Making Assembly Language Programs

Nude with Bruises and Other Perplexities

Years ago (back in the 1960s-had to be!) I recall reading about a comely female artist who produced her oil paintings by the intriguing process of rolling naked on a tarp splattered with multicolored oil paint, and then throwing herself against a canvas taped to the studio wall. (I can see the headline now: "NUDE WITH BRUISES" FETCHES RECORD PRICE AT NY AUCTION...)

I've seen people write programs this way. The old GWBASIC language that was included free with every copy of DOS worked like that. So does Perl, its counterpart in the Linux universe: You roll in an intoxicating collection of wild and powerful program statements, and then smear them around on the screen until something works. And something invariably does work, no matter how little thought goes into the program's design. GWBASIC and Perl are like that. They pay a cost in program performance to make it easy to create safe code that doesn't require a lot of forethought or design work. The programs that result, while workable in that they don't crash the machine, can take seven seconds to paint a screen, or 20 minutes to sort a database with 150 check records in it.

You can't paint "Nude with Bruises" in assembly language. Trust me.

Sweet Blindness: The Software Components Conundrum

But there are other perfectly proper programming paradigms that won't work with assembly language, either. One is commonly used with my own beloved Delphi: Decide what you want to do, sketch out a design based on a reasonable amount of forethought, and then go hunting through a veritable Sears Catalog of software component products looking for canned code that will do more or less what you need. In fact, you design your program to cater to the quirks and limitations of the software components that you have, can find, or can afford to buy.

The goal here is, in some respects, to do as little programming as possible. You attempt to wire together a collection of black boxes that will get the job done, while spending as little time as possible at it. Delphi works this way, as does its evil twin, Visual Basic, along with most of the high-level Java products including JBuilder and Visual Café. The software components have various names (VCL, ActiveX, Java Beans) but they are conceptually alike in one important way: They hide what they do internally so that you don't have to spend a lot of time understanding them.

This sounds like something I frown on, but people who know me will understand that it's been a major portion of my professional life: I founded and edited Visual Developer Magazine, which focused on only these products and this way of developing software. When I write code these days, that's how I do it. (In Delphi.)

I do it because I've made the conscious decision not to understand all of what's going on in my software. For me it's a time thing: Sure, I'm interested in what's going on inside, but if I spent all the time it took to understand it at a very deep level, I'd never finish writing the software. I do have a life, and not all of it is bashing code.

Remember what I said in the introduction to this book: You learn assembly language to understand how things work. Like all forms of education, you trade time and disciplined energy for knowledge. I've made the conscious decision (and you probably will too) that the time and energy required to learn Windows (or Linux X11) programming at the assembly level costs more than the knowledge is worth.

This wasn't true with DOS, which in truth most people don't use anymore. Nor is it true for Linux, where a deep knowledge of the operating system and how it works is extremely valuable. In this book I'm largely treating DOS as training wheels for Linux, where I'm convinced that most of the serious assembly work in the near future is going to happen. Learn DOS and 16-bit flat model (which is the old "Tiny" or "COM file" model) and you will slide into Linux like a hot knife into butter.

I started this chapter this way as a warning: You can't write assembly language programs by trial and error, nor can you do it by letting other people do your thinking for you. It is a complicated and tricky process compared to GWBASIC or Perl or such we-do-it-all-for-you environments as Delphi and Visual Basic. You have to pay attention. You have to read the sheet music. And most of all, you have to practice.