Manual multithreading and multitasking
Today, we expect our computers to do many things simultaneously through multitasking (running multiple processes on a single operating system) and multithreading (running multiple processes, or threads of execution, in a program). But early PC operating systems such as CP/M and MS-DOS were built to do just one thing at a time.
Brilliant programmers with specialized knowledge could hack alternatives, but it was a messy and painful experience. C programmers, for example, might turn to setjump and longjump to implement threads, which was a recipe for a long weekend of debugging accompanied by at least three pots of coffee.
Multithreading still isn't easy, but development tools and operating systems have streamlined the process. Since the introduction of Windows 2000, for example, developers have been able to use overlapped I/O to enable an auto-scaling multithreading platform, points out Dan Rosanova, principal consultant at Nova Enterprise Systems. That works "much better than the old 'start <i>x</i> threads to do <i>y</i>,'" he notes.
Honorable mention:
Writing Terminate-and-Stay-Resident (TSR) routines, an early and very popular hack toward multitasking, on MS-DOS. "One system call -- a specific group of register settings left in place when you invoked Interrupt 21h -- had the effect of returning control to DOS but leaving your code in allocated heap space," remembers Mark W. Schumann, software developer at Critical Results, who got started in college making things work on a DEC PDP-11.
"If you also redirected, for example, Interrupt 9 -- keyboard handler -- to point at your own code, which then chained back to the original interrupt vector, your code would be executed just before normal handling of the keystroke," continues Schumann. "That's how you wrote 'pop-up' programs back in the day. You had to be careful about file-system operations because DOS itself wasn't re-entrant, and you had to make your code extra-fast so it wouldn't mask the next interrupt."
Self-modifying code
In the 1960s, when memory was measured in "K" (1,024 bytes), programmers did anything to stuff 10 pounds of code into a five-pound bag of computing power. One example was writing programs that altered their own instructions while they were running. For instance, one of my programming friends fit a 7K print driver into 5K by shifting (assembly language) execution one bit to the right. Some of these solutions were breathlessly elegant, but they were a maintenance nightmare.
There were several variations on this theme. One programmer recalled using the contents of one register as data in another register. Another technique was to write stack modifying code as a shortcut around language-generated limitations.
Related item
In dire circumstances, you might need to patch a program while it was still running. This might involve flipping the switches on the computer's front panel (yes, we had those) to modify instructions or data.
Or you might connect to an important daemon -- say a print spooler -- hand-assemble code that you would place in some unused section of memory, and then patch a jump instruction in the active region of the program to branch to your new code. If you made a mistake, boom!
Plus, you had to remember to make the same change again in the source code and recompile it, or else you'd end up doing the same thing again the next time the system was rebooted, which could be months later, after you forgot what you'd done.