[Indigo]<AltoSource>BRIEFINGBLURB.DM!2>BriefingBlurb.2

Most general-purpose computer systems have some sort of file system, and no two of them are exactly alike. Programmers tend to assimilate the assumptions of their local file system so completely that they forget that other systems do things differently. As a result, they sometimes get burned when they start programming under a different system. Let’s consider some of the implicit assumptions behind the Alto file system organization.

Alto disks are self-contained. Exception: there exist Altos with two disk drives that can be configured to spread the file system across both disks, as mentioned above. Each one has a single directory in which the visible names of the files are stored. Fine point: multiple directories are permitted, but most software can’t handle them. Names consist of a file name proper, optionally followed by a period and an extension. Actually, file names are terminated by a ``.’’ and may contain any number of embedded ``.’’s. Dividing the name into two parts with a single ``.’’ is purely a convention, though a widely-observed one. Certain conventional extensions exist, e.g., ``.mesa’’ for Mesa source programs. All of this is probably familiar to you from other systems.

Wrinkle #2: Because multiple versions are impractical, writing a "new version" of a file really means writing on top of the old one. Nearly everyone who isn’t accustomed to this (particularly PDP-10 hackers) gets burned by it at least once. (However, there is an important exception: Bravo maintains explicit backup files even when version numbers are disabled.)

Wrinkle #3: Alto files consist of pages. Each page carries with it the number of significant bytes it contains. Thus, in principle, a file need not be a sequence of full pages followed by a single partially full page. In fact, however, strange things will happen if you manage to construct a file in which any page (except the last one) is not full. Fortunately, it is hard to do so.

Wrinkle #4: Alto files always have a page at the front called a leader page, which holds various interesting and useful data about the file (e.g., when it was last written). For no good reason, the Alto file system prefers that the last page of the file contain less than 512 bytes of data. This means that a logically empty file actually takes two pages, one for the leader and one containing 0 significant bytes of data.

Wrinkle #5:The Alto disk architecture permits a representation for files that drastically reduces the possibility of a hardware or software error destroying the disk’s contents. The basic idea is that you must tell the disk not only the address of the sector you want to read/write, but also what you think that sector holds. This is implemented by dividing every sector into 3 parts: a header, a label, and a data field. Each field may be independently read, written, or compared with memory during a single pass over the sector. The Alto file system stuffs a unique identification of the disk block (consisting of a file serial number and the page number of the file) into the label field. Now, when the software goes to write a sector, it typically asks the hardware to compare the header and label fields against data in memory, and to abort the writing of the data field if the compare fails. This makes it pretty difficult, though not impossible, to write in the wrong place. The label field also contains links (disk addresses) to the predecessor and successor blocks of the file. It happens that if the compare logic of the disk microcode sees a particular pattern in a memory word, it omits the comparison on that word and instead overwrites the pattern with the data from the corresponding disk word. Thus, by cleverly arranging the memory "image" of a label field to be compared, the software can get the safety check on the block identification AND obtain the disk addresses of the neighboring blocks in the same operation. Cute, huh? More information about the disk system and how the software exploits it may be found in {1} and the "Disks and BFS" section of {8}.

You should also know about the Scavenger, a program that rebuilds the file structure (but not the file content) of an Alto disk. Despite the checks and balances of the file system, occasionally things get smashed or lost. When they do, running the Scavenger is the best first attempt to recover them (assuming that your hardware is functioning correctly; running the Scavenger won’t help much and could hurt if it is really your disk drive or Alto hardware that is busted). The Scavenger is available from the NetExec, so even if your disk is so messed up that you can’t boot it, help is available. You can read more about the Scavenger and what it can do in {10} and [13].

Lots of smart people have spent lots of time producing lots of nifty software for the Alto. Programs to manipulate directories, programs to format documents, programs to make pictures and illustrations, programs to transfer files, disks, and messages around, programs to help you write programs, programs to ... oops, you just ran out of disk space.

We all know that you can’t have your cake and eat it too. With a small disk, you can’t even have it, most of the time. Most people are amazed to learn that an Alto disk will hold over 4800 pages (actually, 4872 pages, a little under 2.5 MBytes)—they rarely see one with more than a few hundred available. You will quickly discover that Alto programmers spend a significant fraction of their day switching disk packs or running FTP. Some do both. Of course, users of shared Dorado partitions have to use FTP or its equivalent quite a bit as well, but for different reasons. There’s no real cure for this disease, but by being aware of what is costly in space, you can make the pain less acute. Let’s see where the space goes by ``building a disk’’ from scratch, so to speak.

Naturally, there are a few things that you just can’t live without. You must have an Operating System, an Executive, and a number of files that go along with them. You also need the basic file system machinery (the directory and the disk descriptor so you can allocate disk space). You also should have Swatee and probably Swat, though the latter isn’t really essential. There are also a number of small files that the OS and the Executive expect to find around—don’t try to get rid of them, they will just come right back. Even so, a disk with just the OS, Executive, Swatee, Swat, and friends still has about 3900 pages free.

Next come the facilities you nearly always want: FTP and Bravo. FTP can always be obtained from the NetExec, but that takes a while and you use it frequently, so most people keep it around on the disk. It consumes about 180 pages. For wizards and hackers, there is a version of FTP hiding inside SYS.BOOT, and one can put together a small kludge that transfers control to it. This way you can have FTP without giving up the full 180 pages it normally needs. Bravo is a good deal larger, weighing in at about 650 pages by the time you count all its related files and a font or two. With FTP and Bravo, your disk is now down to around 3000 free pages.

At this point, things begin to diverge, depending on your plans for the disk. As an example, let’s consider a Non-Programmer’s Disk. This is a disk designed mostly for producing memos and documents and contains lots of files appropriate for these tasks. When you get it, it has about 1600 free pages—a comfortable amount, but quite a drop from 3000. Where did those pages go? Well, first there are the forms—files containing templates for things you commonly produce, like memos, letters, etc. The standard bunch only consumes about 40 pages—cheap. Then come the fonts ... and disk space starts to disappear. Screen fonts (so that Bravo can display things) occupy about 100 pages, and you should probably retain the standard bunch (on a Non-Programmer’s disk, at least). The real space hogs are subsystems you rarely use. Chat takes 130 pages, and unless you spend a great deal of time talking to Maxc (in which case you probably don’t care about Alto disk space), you might as well get it from the NetExec when you need it. Markup and PressEdit occupy another 210 pages, Draw takes 150 more. Unless you use these facilities regularly, you are wasting 300 pages. Neptune takes up some more, unless you feel that you can get by with the standard Executive file system commands. There is also an Executive command "FileStat" that will tell you how big files are. Finally, a Non-Programmer’s disk also has BravoBug and some sample documents and illustrations, which together occupy about 100 pages. They are pure fat—you almost never use them, and can retrieve them from appropriate servers when necessary.

Perhaps this tirade on disk space seems superfluous—after all, a Non-Programmer’s disk does have over 1600 free pages even with all this junk. True, but other disks are rarely so empty. Things get particularly tight on Mesa disks, so it is useful to know just what can be deleted and what can’t. The preceding discussion gives you an introduction, but Mesa programmers have been known to go out much further on the limb in their quest for breathing space (e.g., deleting Swat, SYS.ERRORS, and related files that are only needed when the Alto is trying to tell you about a weird error condition). The moral is: know what’s on your disk and why it’s there. Delete *$, Scratch*, and *.scratch occasionally—it’s amazing what you find lying around.

Users of Dolphins and Dorados don’t have to worry quite so intently about disk space, since their local disks are much bigger. In fact, it turns out that their local disks are so big that the Alto OS cannot address the entire disk! Hence, when a Dolphin or Dorado is emulating an Alto, its local disk is split up into separate worlds called partitions. Dolphins disks hold two partitions, while Dorado disks hold five; and each partition is 22,736 Alto pages in length (Oh boy, space to burn! Or so it seems for a while...). What partition you are currently accessing is determined by the contents of some registers that the disk microcode uses. There is a command called ``partition’’ in the Executive and the NetExec that allows you to change the current partition.

How do you reel in those big fish we’ve just been talking about? With FTP. After Bravo, FTP is probably the most heavily used Alto subsystem, so it is well worth your while to learn something about its facilities. However, the documentation in [13] is sufficiently old that you should read the relevant section of {10} instead. We’ll touch on the high points here.

Full-blown FTP (there are half-blown versions) operates three windows on the Alto display, of which two are interesting. The so-called ``user’’ window is where you conduct your file transactions with another machine, often (but not necessarily) a file server. The ``Telnet’’ window provides you with a stripped-down version of Chat, and is handy when you want to do something that just isn’t covered by the file transfer protocol. Most of the time, however, the user window is all you ever look at (or through). There are commands to establish and destroy connections, to retrieve, store, delete, and rename files, and to interrogate directory contents and storage resources.

Much of the flexibility of FTP is derived from its command line processor, which, in conjunction with the Executive’s file name completion and *-expansion, provides considerable flexibility and power. With flexibility comes the ability to screw yourself with ease, so FTP implements a few checks that prevent you from doing stupid things, at least without confirmation. You should read about the /A and /> switches remembering that, unless you can afford to maintain multiple versions, once you write on an Alto file, it’s gone.

In the outside world, document production systems are usually de-coupled from text editors. One normally takes the text one wants to include in a document, wraps it in mysterious commands understood by a document processor, feeds it to that processor, and puzzles over the resulting jumble of characters on the page. In short, one programs in the document processor’s language using conventional programming tools—an editor, a compiler, and sometimes even a debugger. Programmers tend to think this is neat; after all, one can do anything with a sufficiently powerful programming language. (Remember, Turing machines supply a sufficiently powerful programming language too.) However, document processors of this sort frequently define bizarre and semantically complex languages, and one soon discovers that all of the time goes into the edit/compile/debug cycle, not careful prose composition.

Bravo is a modest step away from the programming paradigm for document production. A single program provides the usual editing functions and a reasonable collection of formatting tools. You can’t program it as you would a document ``compiler’’, but you can get very tolerable results in far less time. The secret is in the philosophy: what you see on the screen is what you get on paper. You use the editing and formatting commands to produce on the screen the page layout you want. Then, you tell Bravo to ship it to a printer server and presto! You have a hardcopy version of what you saw on the screen. Sounds simple, right?

Of course, it isn’t quite that easy in practice. There are dozens of subtle points having to do with fonts, margins, tabs, headings, and on and on. Bravo is a success because most of these issues are resolved more or less by fiat—someone has prepared a collection of configuration parameters (in user.cm) and a set of forms (on a Non-Programmer’s disk and the MAXC <Forms> directory) that accommodate 99% of the document production you have to do. Most of the configuration options aren’t even documented, so it is hard to get enough rope to hang yourself. If you feel suicidal, there are always wizards about who can answer your every question about Bravo esoterica. The net effect is that you spend much more time composing and much less time compiling.

No one believes Bravo is the ideal solution; indeed, it has a lot of shortcomings that become evident as you begin to push on it. Nevertheless, it is a sufficiently large step forward that you will wonder how you tolerated the old way of doing things. (If this isn’t obvious to you after reading [12] and [13], wait until you’ve used it for a few weeks.) You will also find that the availability of multiple fonts, paragraphing, automatic indentation, and other formatting facilities inside the text editor leads you to make prettier programs as well. It just isn’t that much more work to create and maintain attractive source text, and a simple set of formatting conventions can be a more potent program documentation aid than comments (see [11] for some examples). There are some operational annoyances with using Bravo formatting, however. The only program which can interpret Bravo formatting information and produce corresponding hardcopy is Bravo itself, and it can only do so on one file at a time and rather slowly. Empress is much faster, but can only handle pre-formatted Press files or simple text (e.g., a sequence of ASCII characters). There is a Hardcopy subsystem that takes a list of files and feeds them one-by-one to Bravo for hardcopying (it uses a Bravo macro [13] to eliminate manual intervention), but this is a kludge at best. Therefore, some people feel that Bravo formatting is just too much trouble and instead do it ``by hand’’. They are a small minority.

Like all text editors, Bravo breaks once in a while. There is nothing quite like the sinking feeling you get when a large number of your precious keystrokes gurgle away down the drain. When they do, you probably have an instinctive response (conditioned by previous editors you have used) to run the editor again to find out what state your file is in. Resist this impulse at all costs—it is the worst thing you can do.

Bravo has a ``replay’’ mechanism, meaning that it records all of its actions in a file and is capable of replaying an editing session (yes, even one involving multiple files) from the beginning. However, all replay information is thrown away when Bravo initializes unless you tell it that you wish to replay the immediately preceding session. If Bravo crashes on you, by diving into Swat or displaying "bootlights", your best bet is to re-boot your Alto, use FTP to obtain BravoBug (unless, of course, you already have it), refresh your memory about how replays work [13], then run BravoBug. Bravo/r is not an acceptable substitute, despite a popular rumor to that effect! More details are available in [13]. The essential notion is that you must not run Bravo in the usual way, or you will forfeit your opportunity to do a replay.

For years BCPL was the only implementation language for the Alto. Naturally, a nice cozy environment for BCPL programs (and programmers) gradually developed, and the cognoscenti could guess how subsystems would behave in unusual cases because they knew that the programs operated in this environment. Then, along came Mesa and the end of innocence. Mesa programs either have to mimic the behavior of the BCPL environment in situations where they supply overlapping function, or risk being branded ``incompatible’’.

Okay, so that’s a bit melodramatic. Nevertheless, Mesa is faced with the problem of adapting to an environment that it finds less than ideal. As subsystems coded in Mesa begin to emerge, subtle incompatibilities appear (e.g., Mesa’s inability, at present, to support version-numbered files). Mesa’s more modern approach to memory management (implicit segment swapping instead of explicit overlays) has the disadvantage of consuming considerably more disk space, largely because it has become much easier to ignore the constraints imposed by the Alto’s small primary memory.

Smalltalk is both a programming language and a programming environment, developed by the Learning Research Group with lots of help from other folks in CSL and SSL. The system has always been intended to serve as both a powerful language for use by experienced programmers and an easy language to be learned by children; some of the work of LRG has been aimed at testing out these systems with kids.

But Smalltalk is more than just a language design—it is a highly interactive, integrated system which tries to merge together many functions that are often viewed as separate subsystems: writing programs, editing text, drawing, real time animation, generation of music, and more. This view meshes well with the notion of a small, single-user personal computer (the ``Dynabook’’). Currently, a large project is under way to publish the details of Smalltalk 80, and to make it available at a very low level to outside manufacturers of small computers, in the hope of getting it out into the world by that route.

We rely very heavily on an electronic mail system. Since people spend much of the day at their Altos, notices posted on a central bulletin board are not likely to be seen rapidly. Accordingly, most announcements are broadcast (to expansive distribution lists) using our electronic mail system. If you don’t check your messages once a day or so, you will soon find yourself out-of-touch (and saddled with a mailbox full of obsolete junk mail). And conversely, if you don’t make moves to get on the right distribution lists early, you may miss lots of interesting mail. This business of using the message system for rapid distribution of announcements can get out of hand. One occasionally receives notices of the form: ``meeting X will start in 2 minutes—all interested parties should attend’’.

We also use the electronic mail system as a way of recording the progress of working groups and projects. Minutes of meetings, design documents, and related materials often pass as messages among group members. A file in which a copy of each such message is retained becomes a valuable archive of the project history and is quite painless to maintain. Many individuals keep archival files of their messages as well.

Our replacement for MSG is an Alto-based message system named Laurel; Laurel is the message composing and examining program, while Grapevine is the distributed transport mechanism, a collection of server machines that conspire to deliver mail. Because Laurel stores mail locally on the Alto disk and requires a moderate amount of disk space (about 500 pages), most users find it necessary to dedicate a disk on which they process all their mail. If you like to read your mail frequently and you don’t have a double-disk system, you find yourself switching disks a lot. The latest version of Laurel (Laurel 6) has lots of fun new bells and whistles that are worth getting to know: check out the modeless editor, thought by many to be the greatest thing since sliced bread, and try ``Run’’ning some ``.laurel’’ programs in the bottom window. Now that Laurel 6 is around, you can get the facilities of Chat, Ftp, and the Alto Executive all without leaving the Laurel cocoon.