Applications

os8088 ships two floppies. The first one boots; the second one is the software, and everything on this page comes off it. Eleven programs, in two folders, on a FAT12 volume any modern machine can also mount and write: eleven separate binaries totalling about 66KB, in a system whose whole kernel is 52,718 bytes.

None of them are built in. A program is a flat binary with a 32-byte header, assembled to run at offset zero and never relocated: the loader takes a claim off the heap, reads the file into it, zeroes the program's uninitialized data and far-calls its entry point with the segment registers pointing at the program's own segment. From there it lives exactly as the system's own windows do -- it gets a window, a dock tile, a row in the Task Manager, its own menus on the menu bar and, if it asks for one, a pre-emptively scheduled background task of its own. Closing it frees the region and every claim it made. Several can run at once, and more than one copy of the same one can.

Every image below is a screendump of the real system running in an emulator, captured by a script that double-clicks the program out of the Disk window, closes the Disk window behind it and then drives the program itself -- typing, clicking keys, drawing, dealing and serving. Nothing here is a mockup. The interface is black and white; where you see color, the program is using it.

The APPS folder

Eight programs and one data file. Two of them exist mainly to prove something about the system underneath -- and two of them are the largest pieces of software in the tree.

A full screen of white with a black menu bar across the top carrying File, Edit, Style, View and Help in white text. Below it a heading, Writing on an 8086, is drawn at double size in bold; under that a line of body text reads The editor styles bold and italic as you type, with the word bold in bold and the word italic slanted. A text caret sits on the empty line beneath. — **A distraction-free Markdown writer, ported from the Macintosh.** ArtfulType is ActionRetro's writing app for classic 68k Macs, rebuilt for the 8086. In Writer mode it takes the whole screen -- and that black bar across the top is not the system's menu bar, it is the program's own pixels, drawn and tracked by the program, with drop shadows, right-aligned shortcuts and the triple flash a Macintosh gives you when you pick an item. The document is ordinary Markdown in a 20KB gap buffer, and the styling is a way of drawing it rather than a second copy of it: styled lines hide their asterisks and hashes and come out of the program's own glyph engine -- bold by overstriking, italic by shearing, headings doubled to twice and three times size, links underlined with the URL hidden -- while the paragraph the caret is in stays raw, and closes up again when the caret leaves. On a 4.77MHz machine a keystroke has to cost almost nothing, so it costs one store into the gap, a relayout of one paragraph, and one blit per line that changed. Nothing on the typing path ever walks the whole document.

A full-screen FastTracker II style display. Top left, a blue TRACKER banner with BPM 125 and Spd 007; below it the module name Beverly Hills Cop and four channel meters showing green level bars. Top right, a list of twelve sample names and a row of buttons: About, Play, Pattern, Stop, Load and Fullscreen. The lower two thirds is a black pattern grid of blue note names in four columns, with one row highlighted in gray as the playing position. — **A four-channel Amiga MOD player, playing.** The pattern view a tracker is supposed to have: notes scrolling under a highlighted playing row, four channel meters moving, the sample list down the right-hand side. The work is split across two tasks that the kernel pre-empts against each other -- a background task keeps the sound card's ring of buffers fed while the foreground redraws a screen's worth of pattern text, and neither waits for the other. The module here is 116KB, which is larger than a segment can hold; it comes in through the one file call in the system that has no 64KB ceiling, advancing its destination by whole segments as it reads.

A near full-screen window titled Paint. A narrow tool palette down the left edge holds pencil, eraser, fill, rectangle, ellipse, selection, eyedropper and text tools above width and height boxes reading 448 and 280 and an Apply button. A large white canvas fills the rest, carrying a green zigzag stroke and a magenta rectangle drawn freehand. A row of sixteen color swatches runs along the bottom. — **A bitmap editor that sizes itself to the machine it finds.** Paint asks the kernel how much memory is actually free and then decides what it is allowed to be: the canvas, the undo image and the clipboard all come out of a single claim off the heap, and it gives up features one tier at a time on a smaller machine before finally putting up a notice window on one that cannot fund it at all. Its BMP and GIF codecs borrow those same buffers as scratch, which is the only reason a 16KB LZW dictionary fits anywhere. The swatch row is the one place the interface is in color on purpose; on a Hercules or CGA machine those sixteen entries reduce to black, white and a dither.

A window titled Fractal with a status line reading Mandelbrot, Zoom 0, 100 percent, Spectrum. Inside it the Mandelbrot set is rendered in full color: a black body surrounded by concentric bands of magenta, yellow, green and cyan against a blue field. — **The program that background tasks were built for.** A Mandelbrot explorer that renders in three progressive passes on a task of its own, so the rest of the desktop keeps running while it iterates. It is also where the hardest drawing problem in the system got solved: the window can be covered, uncovered, moved or resized while the worker is still going, and 320x170 pixels is far too much to keep a copy of. So it keeps a cache of the *first pass alone* -- one word per run of identical color, 4,000 bytes -- and replays that to put the picture back before telling the worker to carry on from where it was, rather than starting the whole render again.

A small window titled Recorder holding a black-on-white waveform display of a dense audio signal, a status line reading DEMO STAGED, 400 to 800 Hz, 08000 of 16000 bytes, IN colon SB, and a row of four buttons: REC, STOP, PLAY and DEMO. — **Sampled sound in and out, through whatever the machine has.** The Recorder captures and replays digitized audio over the same ring-of-buffers mechanism the MOD player uses, and it does not know or care which device is on the other end: a Sound Blaster's DMA channel where there is one, the PC speaker where there is not. The status line names the route it actually got. The waveform above is the built-in demo tone staged in memory, drawn one column per sample window.

A window titled Piano. The upper half is a five-line musical staff with a few colored note marks on it; below that a REPLAY and CLEAR button pair beside the word READY, a SONGS row offering TWINKLE, ODE and MARY, and a two-octave keyboard of black and white keys with the computer keys a, s, d, f, g, h, j, k, l and the row above lettered onto them. — **Two octaves, played with the mouse or the keyboard.** Every note the Piano plays is also written onto the staff above the keys, and the staff replays. It is the smallest thing in the system that exercises the sound path end to end, which is what makes it the useful one: on a machine with a sound card, the loadable sound driver moves the tone off the PC speaker and onto the card's FM chip without the Piano knowing anything has changed. Same program, same call, two entirely different pieces of hardware making the noise.

A window titled Note Pad on the desktop containing two typed lines: Note Pad is a package now, not a built-in, and It runs in its own segment, with a text caret after the last character. A single tile sits in the dock at the bottom left. — **The program that proved the loader was good enough.** Note Pad used to be part of the kernel. Moving it out onto the floppy reclaimed about 1.4KB of the kernel's segment, and it removed a limit rather than adding one: as a built-in it had a fixed pool for exactly two instances, and as a package it has no cap at all -- open six of them if you like. It word-wraps, tracks a caret, and opens and saves real files through the system's Open and Save dialog.

An almost empty desktop with one small window titled Hello, containing two centered lines of text: Hello from a dot o88 package. One tile sits in the dock at the bottom left. — **The whole interface, in 322 bytes.** A header, a window template, a paint procedure, and nothing else -- this is the smallest program the system can load, and it is on the disk as the floor of what a package costs. It is also the only program in the tree that deliberately ships *without* an icon, so that the generic application icon in the Disk window has something to prove itself on. Every other package embeds its own 16x16 bitmap in its header, and the file manager harvests those icons by reading the first sector of each file when it mounts the disk.

The GAMES folder

Three of them, and each one arrived by needing something the system could not yet do.

A large window titled Solitaire filled with green baize. Top left, a face-down stock with a blue lattice back; top right, four empty foundation piles marked with spade, heart, diamond and club outlines. Seven tableau columns below, each ending in a face-up card, the rest face down. — **Klondike, and the one program that drags the way the window manager does.** Picking up a card does not redraw anything: it draws a one-pixel inverted outline that erases itself before the drawing lock is released, so a hand of cards in flight costs a few inverted strips per timer tick and the table underneath is not touched until you let go -- exactly how the system drags its own windows, done with the calls a program is given. The faces are drawn from primitives, but the backs are *blitted*: that lattice is rendered once into a packed image, so every later card back is a single call instead of hundreds. On a black-and-white machine the red pips are drawn hollow rather than red, because red reduces to white and a filled pip would simply vanish into the card.

A tall window titled Arkanoid with a score of 10 at the left and LV1 at the right. Six rows of colored bricks in red, cyan, green, white and magenta fill the top, with one brick already missing, above a large black playfield and a white paddle near the bottom. — **A game loop that is a task.** A ball has to keep moving between keystrokes, so the game loop is the program's background task -- one frame per timer tick -- and everything the foreground does is set a word the loop reads. It is also where a genuinely awkward problem got solved: the PC BIOS gives a program key presses but never tells it when a key is *released*, so a held arrow has to be inferred from the keyboard's own auto-repeat, with a deadline long enough to outlast the half-second pause before repeat starts. Get that wrong and holding the paddle left stalls for half a second, which reads exactly like a broken keyboard.

A window titled Minesweeper showing a nine by nine grid of raised gray cells. A large region has been revealed as flat white squares carrying blue and green digit counts, and two red flags are planted at the top left and bottom right. A status strip above the board reads 8 and F equals FLAG. — **The first program the loader ever ran.** Still the plainest case, and still the one worth pointing at: 1,510 bytes on the floppy, a 9x9 board of 16-pixel cells, an icon embedded in its own header, and paint, key and click procedures the kernel calls exactly as it calls the system's own. The first click is always safe -- the mines are laid after you have chosen where to start -- and the digits are the only place in the entire interface, outside Paint's palette, where color is used to carry meaning rather than decoration.

Running them yourself

Download both images: boot the machine from os8088.img and give it apps.img as its second floppy. Double-click the Disk B icon on the desktop, open APPS or GAMES, and double-click a program. It will be on screen in about a second on an emulator, and rather less briskly on a real XT.

The software disk is an ordinary FAT12 volume, so you can also mount it on any modern machine and copy programs on and off it -- and since os8088 writes FAT12 as well as reads it, files you save from Paint or Note Pad come back off the same disk on your own computer. Writing one of your own is the packages page.