Jeff Duntemann's Contrapositive Diary Rotating Header Image

programming

Idea: A GUI Vibe Coding Prompt Editor

Feb 20th, 2026
by Jeff Duntemann.
1 comment

I was poking around my substantial library of technical books earlier today, and in a far corner getting dusty was a copy of Java Studio By Example by Lynn Weaver and Leslie Robertson. It was published in 1998, and Java Studio (along with its creator, Sun Microsystems) are now extinct. But the gist of it was that you draw a sort of schematic diagram of a program’s logic on the screen. Then you use the Studio program to generate executable Java code.

I never got to play with Java Studio, but the idea fascinated me. After all, back in the second half of the ‘90s I was Editor in Chief of Visual Developer Magazine, focused on Visual Basic and Delphi and associated products. (I was sent the book by Sun as a review copy.) And flipping through the book, it hit me: How much bad code is produced by AIs like Claude simply because the developer doesn’t know how to construct a prompt that Claude will understand correctly? I’ve never tried vibe coding, but prompt engineering sounds to me like the critical link in application development’s complicated chain.

So how about a GUI editor that gently helps a user create prompts that will allow an AI to craft workable code?

Although I’m still a vibe-coding virgin, from my reading I would guess it would be a conversation with an AI, each programmer response to the AI being a more detailed clarification of the one before it. Maybe prompts like this:

  • Create a desktop Free Pascal application for Windows that accepts and validates data-entry fields describing an MP3 music collection, stored in and managed by a desktop SQL database.
  • Create data-entry fields for these data items: cut name, cut length, cut genre, album name, performer name, composer name(s), recording year.
  • Create validator procs for each data entry field according to field rules.
  • Create a 12-line table on the main form to display cuts, with clickable header sorting and a search dialog with pull-down menu lists of all fields.
  • Create database output reports summarizing cuts by name, albums by name, albums by performer, composers by name.
  • Create buttons for adding new cuts to the database, deleting cuts from the database, saving the database, and exiting the application.

I’m a programmer, so such prompts come easy to me. That might not be the case for people who have no programming experience. The AI would be capable of natural language and could craft a list of prompts from a back-and-forth chat that the user could see on the screen and clarify if necessary.

What would the AI do in response to user prompts? It would primarily ask for clarification of prompts, but would also build an application main window mockup and dialog mockups to one side of the AI vide coding conversation window. The user could drag mockup fields around in the mockup window, or simply say, “Center the table and put the buttons evenly spaced in a line below the table.” If the application uses database tables, the AI could create a window for each table to verify field nature, size, and validation rules.

The AI could put questions or suggestions in little hover balloons that would pop up if the user spoke a field name or hover the mouse over a field.

I’m not sure how an AI would be trained to design the application. The purpose of the vibe coding editor would be to help management or other non-technical users write prompts that are sufficiently clear and unambiguous for the AI to construct code embodying what what the user is trying to describe. It might all be done by one AI, or it might be done by two AIs: One to help the user create prompts, and another to build the app from those prompts.

That’s most of the idea as it came to me. Maybe somebody’s already done this. I don’t know. From a height, the idea is to raise the abstraction level high enough through user/AI conversation so that code could be generated from clarified user prompts rather than flowcharts or source code. If nothing like this has been created yet, trust me: It will happen, and soon.

Odd Lots

Nov 24th, 2025
by Jeff Duntemann.
3 comments
  • This (scary) item is the most significant I’ve seen recently: Microsoft is working on features that obsess with granting a Windows AI its own private workspace on your machine, plus access to your Documents, Downloads, Desktop, Videos, and Music folders. This will go nowhere good. Keep it in mind, and if MS asks for permission to enable this feature, weigh the consequences. MS admits the damned thing could install malware and have hallucinations. Huh. I won’t use a computer that thinks I‘m dead.
  • There’s a cool group on Facebook called Old Radio Garage. Lots of pictures of  tube-era radios, including a few on the bench being repaired, but not a lot of discussion.
  • Speaking of radio, I (finally) took a closer look at AccuRadio, which is a free music streaming service that offers bits’n’pieces of almost everything musical. It takes a little study to find your preferences, but I was amazed at the breadth of coverage. You have to create a free account to avoid most commercials and have access to some features, but I think it’s worth the benefits.
  • Google is evidently in the process of merging Android with ChromeOS into an OS called Aluminium. (No, I didn’t misspell that. It’s the British spelling.) The Aluminium OS will evidently have AI all over itself, inside and outside. Gosh, I just can’t wait to pass on it!
  • We have AA, AAA, C, and D batteries. Why not B batteries? Reader’s Digest has a short-form explanation. What they don’t emphasize is that B batteries providing high-ish DC voltage to portable tube radios never had a standard size, not that I’ve ever heard of. I bought a 45-volt battery when I was 12 or 13 for a tube radio I was building, and it was like a long 9V battery, with the same power connectors, just more cells stacked up inside the rectangular case. I later saw all sorts of “B” batteries (most of them dead) in many shapes and voltages. Given the broad range of radios that would use it, a standard size and voltage would be impossible, which in truth explains all that needs explaining.
  • Lazarus v4.4 is out. Built with Free Pascal 3.2.2. It’s a bugfix release, but hey, there’s no reason not be up to date. It’s worked great on my several Lazarus projects under Windows 11.
  • I used to call Free Pascal FreePascal, but that’s no longer how the product’s creators spell it. Free Pascal it is. Sooner or later I’ll update FreePascal from Square One to reflect that spelling.
  • And least but not last (ok. both least and last) Politico posted a gigantic, high-fat article about a crew called Stardust who want to make chemtrails real, in essence squirting air pollution back into the atmosphere to reflect sunlight and cool the planet. This is not a new idea, and not necessary, especially since Stardust refuses to say what the particulates they want to squirt into the atmosphere are made of. There is no climate crisis. Polluting the atmosphere with unknown crap is a scam. Don’t fall for it.

New Edition of FreePascal From Square One

May 7th, 2025
by Jeff Duntemann.
17 comments

[I released a new rev of the book as of 10-21-2025, and the link in this post now points to the new rev.]

Once I got The Everything Machine published on KDP this past March, I went back to a project I’ve tinkered with for almost 15 years: FreePascal from Square One, a 354-page PDF providing an introduction to programming, using the FreePascal FOSS compiler and the Lazarus IDE for editing and building. I need to mention here that the book does not go into Windows programming, OOP, software components, or the Lazarus GUI builder. I have a concept for a second book for those topics, and have written some of it, and borrowed a little from my portions of The Delphi 2 Explorer. No schedule yet, but I work on it when time permits.

FreePascal from Square One really is a free ebook. It’s a distillation of the four editions of my Pascal tutorial, Complete Turbo Pascal, which first appeared in 1985 and culminated in Borland Pascal 7 From Square One in 1993. I sold a lot of those books and made plenty of money, so I’m now giving it away, in hopes of drawing more people into the Pascal universe.

The book begins at the beginning of the beginning, and explains the ideas behind programming, drawing on metaphors from daily life, before jumping into coding. I’ve turned loose increasingly polished revisions on a regular basis since 2011 or so. This one has things none of the earlier revisions had: A new chapter on simple Pascal file I/O, and a clickable table of contents.

The TOC thing made me nuts for awhile. I tried to make it work using InDesign, but InDesign (my 2005-era copy, at least) can’t do it. I know it can be done—I have a couple of technical ebook PDFs with clickable TOCs—but needed to buy a high-end PDF editing tool to make it work. The product is PDF X-Change Pro from Tracker Software. It’s not free, but if you do any amount of work with PDFs, it’s essential. The Pro-level product comes with a 1,372-page manual—in PDF format, of course. It took me most of a day plowing through that monster manual to find out how to make clickable links in PDFs, but once I located that part, adding links to the TOC took me less than an hour.

It’s not tied to TOCs. You can define a clickable rectangle anywhere in a PDF, and specify what page that clickable rectangle will send you to. I drew rectangles all around the lines in the TOC, then right-clicked each rectangle and specified a destination page number for each line.

If you want the book, it’s right here. You’re welcome to share it around, post it on your site, or give it to anyone who might be find it useful. If you’re interested in FreePascal and Lazarus, here’s where to go to download them. They’re as close as you’ll get to Delphi in the free software universe, and it’s about the only programming environment that I use these days, unless I duck back into x64 assembly. Give it a try. It’s bogglingly good.

Odd Lots

Feb 9th, 2025
by Jeff Duntemann.
9 comments

Weekwander

Oct 5th, 2024
by Jeff Duntemann.
1 comment

I spent a week in Chicago (or started out there) to gather with old friends, some from grade school, some from high school, and one (my friend and Best Man Art) from Kindergarten. I rented a smallish car (a 2024 Corolla Cross, which I had not heard of before) and Art and I forged west to the town of Galerna, in northern Illinois on the Mississippi River. My old friend Rich (whom I met in third grade, as best I recall) has a place there. For three days we drank wine and ate cheeseburgers, played whiffle golf around Rich’s substantial house, watched the stars from his front porch, and laughed our asses off over old stories of school, The Fox Patrol in Boy Scouts, college parties, the Resurrection Hospital dish room, where most of us worked at one time or another, and much else. Rich took us all (there were six present) on a pontoon boat tour of Galena Lake near his house.

I’ve read in many places that bonding with friends is one of the best ways to keep your brain cells alive and functional, and now that we were all in our 70s, I took great comfort in that. Rich has been holding these gatherings for almost 20 years, and (especially in the last 10 or 12 years) the group has shrunk from 15 or more down to seven or eight, of which a couple couldn’t make it this year. Each time one of the group passes on, we plant a tree on the slopes of the hill near Rich’s house in their honor.

After we returned from Galena, I visited with my father’s youngest cousin Mary Ellen, and her daughter Mary Kate. They’ve been friends for a very long time, and both helped me piece together the Duntemann family tree back in the ‘90s. We laughed and remembered old times, like the freshman ROTC Military Ball that I was required to attend, and did, with my cousin Mary Kate on my arm. She was a beautiful girl (still is, in my eyes) and I hope it wasn’t a sin that I quietly neglected to tell anybody that she was my cousin, including all my nerdy friends who attended the ball alone.

Honor is good. I honor all my friends, alive or dead, as I will as long as I’m here in God’s beautiful and extravagant creation—and maybe beyond.

֎

The day I flew back from Chicago (October 2nd) was our 48th wedding anniversary, and Carol and I celebrated and had a nice dinner out together. Again, friendship underlies our relationship, and has always done so, across our 48 years as spouses and 55 years as best friends. Friendship, as I’ve said many times here and elsewhere, is the cornerstone of the human spirit, the anchor to which all other positive forces that act upon relationships are anchored. Marriage works—if you work at it, as Carol and have always done and will always do.

֎

Some time back I was threading my way through parts of the Scottsdale-Thunderbird shopping plaza where I don’t often go, and saw that the restaurant Casa Greeka was evidently closed. My guess is that COVID did them in, as it did in so much else. Their theme was Mexican-Greek fusion. I never ate there, but I did wonder what people of Greek heritage thought of the name. The proper name would (perhaps; I’m not Greek) be Casa Greco.

But it got me thinking about food fusion for a bit. How about this: A restaurant specializing in Irish-Hawaiian fusion, called Lovely Houlihan’s. Don’t fret if you don’t get the joke. It’s for old people.

֎

Yes, it’s true: I’m finally closing in on the last bits of my new novel, The Everything Machine. It’s the cornerstone Drumlins story, and will reveal (most of) the mystery behind the thingmakers and the alien minds that created them. If you must genre-tag the novel, I call it a Space Western, with a side order of airships and a whiff of Dieselpunk. Should come in between 120,000 and 125,000 words, which is 25,000 words shorter than The Cunning Blood. After I get that published, I’m going to work on nonfiction for a bit, starting perhaps with a Square One introduction to Windows programming with Lazarus/FreePascal, drawing on my parts of The Delphi 2 Explorer. I already have 7,000 words on that book, which I set aside in 2021 when I began The Everything Machine. There’s a lot to cover, especially for a beginner audience, and I don’t know how long it will be. I won’t know (as usual) until I finish it. Wish me luck.

Lazarus 3.0 Has Arrived!

Dec 22nd, 2023
by Jeff Duntemann.
5 comments

For all you Pascal programmers among my readers: Lazarus 3.0 is out, and available for free download. Here’s the announcement. I’ve already installed it on Win10 and will install it on Linux when time becomes available. (I’m still struggling to write the trademark Jeff Duntemann mayhem-filled action climax of my current WIP: The Everything Machine, the first full-length drumlins novel.)

Delphi now costs over $1000. If I’m going to teach Pascal, I can’t use Delphi, love it though I may–and do. Lazarus is pretty much Delphi’s peer, though it doesn’t…quite…have the third-party component aftermarket that Delphi has. Doesn’t matter. The fundamental principles of OOP and event-driven programming are the same.

For newcomers: Lazarus is a superb IDE and drag-‘n-drop GUI builder conceived as a Delphi competitor, though open-source and thus free of charge. It uses FreePascal 3.2.2 as its compiler. FreePascal understands Delphi’s additions to the Pascal programming language, and will also compile ancient Turbo Pascal programs. FreePascal is part of the Lazarus package and is installed when you install Lazarus. I have fragments of a book on Lazarus that I will return to at some point. But if you know Delphi, well, there’s not a lot more to learn. You’ll feel right at home.

Go get it. I’ve done a lot of work in Lazarus. It’s mature. It works. It can create wonderful GUI apps. And it’s free. What more do you want?

No More Assembly Required

Feb 22nd, 2023
by Jeff Duntemann.
14 comments

In other words: It’s done. Well, at least the hardest part (for me) is done: Yesterday I uploaded the last odd bits of x64 Assembly Language Step by Step, Fourth Edition to the publisher’s cloud. Now comes the work that I don’t have to do: copy edits, tech edits, layout, proofing. I will have some odds and ends to deal with down the road a ways, like looking at the proofs, building the listings archive, and rewriting my assembly book web page to reflect the new edition.

The publisher hired the estimable David Stafford to do tech edits, which is quite an honor. I’ve known David since the early PC Techniques days, and that guy knows his stuff with a capital-K. If there are booboos, bugs, or dryer lint in that thing, he’ll spot it. (Dryer lint we may leave for the production service.)

I’ve been working on this project since mid-April 2022. This is the fourth edition of the book from John WIley, and the fifth edition overall. The very first edition came from Scott, Foresman at the end of 1989, and was part of a short-lived assembly language series that I acquired and edited for them on contract back in the very late ‘80s. Its original title was Assembly Language from Square One. We were just getting out of second gear in 1990 when Scott Foresman was sold to Harper Collins. Toward the end of 1990, Harper Collins put the Scott Foresman trade book line out of print. I got the rights back in 1991.

I turned around and took the book to John Wiley, who bought it on the spot. I rewrote and expanded the book, which appeared from Wiley in 1992. The title had to change when I took it to Wiley to avoid mixups on retail channel returns, so the book became Assembly Language Step-by-Step. That’s not a bad title, in fact, since the whole point of the book was to do a methodical, patient introduction for people just getting started in computing. The 1992 edition was all-DOS, as you might imagine. In 1999 Wiley asked me to do an update that included both DOS and 32-bit Linux. I retained nearly all of what had been in the first Wiley edition, and added another 200 pages for 32-bit concepts and Linux. It was published in 2000.

That book sold extremely well for its nine-year life. In 2008 Wiley asked me for a new edition devoted entirely to Linux. DOS was almost extinct by then, so it was a good move. With only one tail to wag I was able to go into a great deal more detail about Linux and 32-bit protected-mode programming generally. It was a big job that took me seven or eight months, but the book appeared in 2009, at 610 pages.

As the teens drew toward the 20s and 64-bit Intel/AMD CPUs went mainstream, I enquired about a 64-bit edition every so often. In each case, my acquisitions editor basically said, “Don’t call us. We’ll call you.” So I stopped asking, and the 2009 edition kept on selling.

The call came in early April 2022. My old acquisitions editor had retired, and the new one was very much on board with an x64 rewrite. He asked me how long it would take. By then I was 69, and asked, How about a year? He said, Sure.

And that’s almost what it took, whew.

I don’t exactly when we’ll have books. Summer, I’m guessing; maybe late summer. It’s hard to know in this business. I’ve already been asked if I’m ever going to do a 128-bit version. Well, we need 128-bit CPUs first, and in truth I don’t see them on the horizon. We needed 64 bits for the address space way more than the register width. Since the AVX-512 math subsystem on nearly all modern Intel/AMD CPUs already has 512-bit registers, we don’t need the register width, and since 264 is 1.84 x 1019, we’ve already got all the address space we will ever need.  Without 128-bit Intel/AMD CPUs, my guess is that the fourth edition of the book will be the last, and it could well be around long after I go on to other realms.

If I’m going to do any large-scale programming tutorials going forward, it’ll be about the Lazarus IDE and GUI builder. But at least for the coming year, if I write anything at all I’m going to write SF.

But I think you knew that.

A libc Mystery

Nov 25th, 2022
by Jeff Duntemann.
19 comments

As most of you know by now, I’m hard at work on the x64 edition of my assembly book, to be called X64 Assembly Language Step By Step. I’m working on the chapter where I discuss calling functions in libc from assembly language. The 2009 edition of the book was pure 32-bit x86. Parameters were passed to libc functions mostly by pushing them on the stack, which required cleaning up the stack after each call, etc.

Calling conventions in x64 are radically different. The first six parameters to any function are passed in registers. (More than six and you have to start pushing them on the stack.) The first parameter goes in RDI, the second in RSI, the third in RDX, and so on. When a function returns a single value, that value is passed back in RAX. This allows a lot more to be done without fooling with the stack.

Below is a short example program that makes four calls to libc functions: Two calls to puts(), a call to time, and a call to ctime. Here’s the makefile for the program:

showtime: showtime.o
        gcc showtime.o -o showtime -no-pie
showtime.o: showtime.asm 
        nasm -f elf64 -g -F dwarf showtime.asm -l showtime.lst

I’ve used this makefile for other example programs that call libc functions, and they all work. So take a look:

section .data
        timemsg db    "The timestamp is: ",0
        timebuf db    28,0   ; not useed yet
        time1   dq    0      ; time_t stored here.

section .bss

section .text

extern  time
extern  ctime
extern  puts
global  main

main:
        push rbp            ; Prolog    
        mov rbp,rsp

        mov rdi,timemsg     ; Put address of message in rdi
        call puts           ; call libc function puts
               
        xor rax,rax         ; Zero rax
        call time           ; time returns time_t value in rax        
        mov [time1],rax     ; Save time_t value to var time1
        
        mov rdi,time1       ; Copy pointer to time_t value to rdi
        call ctime          ; Returns ptr to the date string in rax

        mov rdi,rax         ; Copy pointer to string into rdi
        call puts           ; Print ctime's output string
        
        mov rsp,rbp         ; Epilog
        pop rbp
        
        ret                 ; Return from main()

Not much to it. There are four sections, not counting the prolog and epilog: The program prints an intro message using puts, then fetches the current time in time_t format, then uses ctime to convert the time_t value to the canonical human-readable format, and finally displays the date string. All done.

So what’s the problem? When the program hits the second puts call, it hangs, and I have to hit ctrl-z to break out of it. That’s peculiar enough, given how many times I’ve successfully used puts, time, and ctime in short examples.

The program assembles and links without problems, using the makefile shown above the program itself. I’ve traced it in a debugger, and all the parameters passed into the functions and their return values are as they should be. Even in a debugger, when the code calls the second instance of puts, it hangs.

Ok. Now here’s the really weird part: If you comment out one of the two puts calls (it doesn’t matter which one) the program doesn’t hang. One of the lines of text isn’t displayed but the calls to time and ctime work normally.

I’ve googled the crap out of this problem and haven’t come up with anything useful. My guess is that there’s some stack shenanigans somewhere, but all the register values look fine in the debugger, and the pointer passed back in rax by ctime does indeed point to the canonical null-terminated text string. The prolog creates the stack frame, and the epilog destroys it. My code doesn’t push anything between the prolog and epilog. All it does is make four calls into libc. It can successfully make three calls into libc…but not four.

Do you have to clean up the stack somehow after a plain vanilla x64 call into libc? That seems unlikely. And if so, why doesn’t the problem happen when the other three calls take place?

Hello, wall. Anybody got any suggestions?

SASM Crashes on “Section” in a Comment

Aug 28th, 2022
by Jeff Duntemann.
4 comments

As most of you know, I’m grinding along on the fourth edition of my book Assembly Language Step By Step, updated to cover x64. I’m using the SASM IDE for the example code because it provides seamless visual debugging using a front-end to gdb. Back in 2009 I created the third edition, and incorporated the Insight debugger front end for visual debugging. A month or so after the book appeared, Insight vanished from the Linux world. I tried a lot of debuggers and editors before I discovered SASM. It’s treated me very well.

Until today.

Now, I’ve been programming since 1970, in a lot of languages, on a lot of platforms, and I’ve made a lot of mistakes. Finding those mistakes is what debugging is about. Today, I was working on a short example program for the book. When I finished it, I clicked the Build button. It built as it should. I needed to single-step it to verify something about local labels, but when I clicked the debug button, SASM crashed. As Shakespeare would have put it, SASM died and gave no sign. The whole IDE just vanished. I tried it again. Same thing. I rebooted Linux. Same thing.

Puzzled doesn’t quite capture it. I loaded another example program from the book. It built and debugged without any trouble. I loaded example after example, and they all worked perfectly. Then I copied the source from the malfunctioning example into a file called crashtest.asm, and began cutting things out of it. I got it down to a start label and a SYSCALL to the exit function. Still blew SASM away.

Most of what was left was comments. I did a ctrl-X to cut the comment header onto the clipboard. Save, build, debug–and it worked perfectly.No crash, no errors, no problemo.

Soooooooo…….something in a comment header crashed the IDE? That would be a new one. So I dropped the comment header back into the file from the clipboard and started cutting out lines, one by one. I narrowed it down to one comment line, properly begun with a semicolon and containing no weird characters. The line that crashed SASM was this:

;         .bss sections.

I cut out the spaces and the period. No change. I cut out “.bss”. No change. I was left with the word “sections.” On a hunch, I lopped off the “s”. No change. Then I lopped off the “n”. Suddenly, it all worked.

SASM was crashing on a comment containing the word “section.” I verified by deleting the line entirely and typing it in again. Crash!

I stared at the damned thing for a long time. I loaded a couple of my other examples, and dropped the offending comment header into them. No problems. Twenty minutes later, I noticed something: In crashtest.asm, the fragment of comment header text was below the three section markers:

section.bss
section.data
section.text

; section

Now, in my other examples, the ones that didn’t crash, the comment header was above the three section markers. So I went back to crashtest.asm, and moved the comment header to the very beginning of the file, above the section markers. Suddenly everything worked. No crashes.

WTF? I assembled the offending crashtest binary from the command line without trouble. I loaded it into gdb from the command line and messed with it. No trouble.

I wrote this entry not for answers so much as to provide a report that other SASM users can find in search engines. There are things about SASM that aren’t ideal. Sure. But I’ve never seen it crash before. I’ll see if I can send the crashtest.asm to the people who created SASM. I’m sure it’s just a bug. But it’s the weirdest damfool bug I’ve uncovered in a whole lot of years!

In Pursuit of x64

May 31st, 2022
by Jeff Duntemann.
10 comments

You may be wondering where I am, given that I haven’t posted a Contra entry for over a month. I didn’t want May to conclude with zero entries posted, so I figured I’d take a break here and get you up to speed.

Here’s the deal: My publisher has asked for a Fourth Edition of Assembly Language Step-By-Step. It’s been thirteen years since the Third Edition came out, so it’s well past time. The idea here is to bring the book up to date on the x64 architecture. In fact, so that no one will mistake what’s going on, the title of the new edition will be x64 Assembly Language Step-By-Step, Fourth Edition. Whether they keep the “x” in lowercase remains to be seen.

So I’m off and editing, writing new code and checking every code snippet in a SASM sandbox, and making sure that I don’t forget and talk about EAX and other 32-bits-and-down entities without good reason. (There are good reasons. Even AH and AL are still with us and used for certain things.) Make no mistake: This is going to be a lot of work. The Third Edition is 600 pages long, which isn’t the longest book I’ve ever written (that honor belongs to Borland Pascal 7 From Square One, at 810 pages) but it’s right up there.

My great fear has been the possibility of needing to add a lot of new material that would make the book even longer, but in truth, that won’t be a huge problem. Here’s why: Some things that I spent a lot of pages on can be cut way back. Good example: In 32-bit Linux, system calls are made through the INT 80H call gate. In the Third Edition I went into considerable detail about how software interrupts work in a general sense. Now, x64 Linux uses a new x64 instruction, SYSCALL, to make calls into the OS. I’m not completely sure, but I don’t think it’s possible to use software interrupts at all in userspace programming anymore. I do have to explain SYSCALL, but there’s just not as much there there, and it won’t take nearly as many words and diagrams.

Oh, and of course, segments are pretty much a thing of the past. Segment management (such that it is) belongs to the OS now, and for userspace programming, at least, you can forget about them. I’m leaving a little description of the old segment/offset memory model for historical context, but not nearly as much as in previous editions.

I also dumped the Game of Big Bux, which doesn’t pull its weight in the explanation department, and isn’t nearly as funny now as it was in 1990. But have faith: The Martians are still with us.

My guess is that from a page count standpoint, it will pretty much be a wash.

It’s going to take me awhile. I don’t know how long, in truth. Especially since I am going to try to keep my fiction output from drying up completely. The book will slow me down, but (for a change) the publisher is not in a huge hurry and I think they’ll give me the time I need. I have 56,000 words down on The Everything Machine, and don’t intend to put it on ice for months and months. I’m not sure how well that’s going to work. We’ll see.

← Earlier Posts