Karig

 

Top • Entries • FAQ • Features • Screenshots • Downloads • Links

Search (using Google):  Web Karig

 

27 November 2003

What I want, part 2

In Part One, I discussed my two main inspirations for Karig — Chuck Moore's colorForth and the ideas of Jef Raskin, the designer of the Canon Cat. In Part Two, I finally get around to discussing the internals and the user interface I have planned for Karig.

Internals

Internally, Karig will look a bit like colorForth:

  • Compilation on demand. Only some of the code in Karig, such as the compiler and the task switcher, will be ready-to-run machine code. Most of the code will be what I call precode — pre-parsed source code, stored not as text but as an array of integers for fast compilation. This means that the compiler not only turns source code into programs; it also replaces the code I'd have to write to relocate pre-compiled programs before running them. (To relocate a program is to load the program at whatever address is found to be available, and also to alter the program to ensure that it will run at that address.)

  • No memory protection. I decided that I wanted to be able to do things in Karig that a "real" OS would not let you do — experiment with the I/O ports and the hardware, test privileged instructions to see how they work, or fiddle with parts of Karig itself, such as the task switcher or the memory manager.

  • Single-user. Karig will not support multiple users on the same machine.

  • Cooperative multitasking. Cooperative multitasking is simpler to implement and debug than pre-emptive multitasking. The programmer also knows that his thread will not be interrupted until he yields control to the system.

  • Dual-stack architecture. Forth and colorForth both require two stacks per thread; so will the Karig version of colorForth.

  • Word dictionary. Karig, like colorForth, will store machine code in high memory, and the names of and pointers to machine-code routines in a dictionary, which is always in memory. The compiler relies on the dictionary to find routines so that it can generate CALLs to those routines.

  • Single-load. The Karig kernel, compiler, precode, and user documents will all be stored in a single fixed-size file, which the Karig boot code will load into memory, all at once. This eliminates the need for most operations involving disk hardware. (This file is essentially a dump of most of high memory to disk.)

I also want Karig to have a few features not in colorForth:

  • Hard-disk storage. ColorForth uses floppies and only floppies to store data. I want Karig to use the hard disk. Specifically, I want Karig to load its data from a fixed-size file on a FAT32 or NTFS partition ("KARIG.PRT" in the root directory), memorize the sectors where the file is stored, and write changes back to those sectors.

  • Automatic saves. Karig should write changes back to the hard disk automatically; the user should not be required to issue a "save" command. Karig would be able to tell what parts of memory have changed by keeping a page table and running a thread to examine the table for entries in which the "dirty bit" is set.

  • Memory log. Some OS designers use linked lists to implement memory management. Karig will allocate chunks of memory as "entries" in a "log." Each new entry is always allocated at the end of the log. When it comes time to free memory, this will usually create a hole in the log, a chunk of unused space. Karig will run a thread to examine the log for holes; if it finds more than a small amount of memory consumed by holes, it will repack the log, moving the unused space to the end of the log so that the memory can be reused.

    Programs will be able to access objects using direct pointers. However, each object will have an ID, which a program must use to get the pointer to the object. The program must get a fresh pointer to the object not only when accessing the object for the first time, but also after yielding to the system. (Whenever a program calls YIELD, the system stops the current thread and finds another one to run. The thread the system runs could be the one that looks for holes in the log and gets rid of them by moving objects around. If the object being used is one of the objects being moved, then the pointer is useless, and the program must get an updated one.)

User interface

Karig's user interface will adopt some of Jef Raskin's ideas:

  • Quasimodes. I am considering a number of quasimodes for Karig, each implemented by holding down a special key and typing in the first few letters of the name of a command or an object. I want a COMMAND key for running commands in the word dictionary directly. I want a CHARACTER key for entering non-ASCII characters. I want a STYLE key to alter the fonts and formatting of text. I also want FIND keys to implement incremental search.

  • One set of commands. All commands and styles would be available at all times regardless of what the user is doing.

  • Universal undo. Documents will be stored as lists of changes, not simply as the data making up the document. The system would have to recreate the document on the fly from this list of changes. However, this setup would make undoing and redoing changes very easy, even after the document is left untouched for months.

  • "Calculate" command. A traditional calculator program is clunky. It's an awkward way to do calculations. It would be better if you could enter the calculation in your text and hit a key to replace the calculation with the result.

  • No files. Actually Karig will load one huge file into memory at startup. This one file will contain all of the user's documents, fonts, pictures, and other data. This means that the user never has to "open" a document; all he has to do is scroll to it or search for it, because it's already in memory.

    Karig will also avoid directories, in the sense of folders that seem to contain documents (which implies that a document can be in only one folder). Instead, Karig will use "sequences" — arrays of object IDs. An object ID can be stored in any number of sequences. This gives the user much greater flexibility in organizing his documents.

  • Incremental search. Searches would work like this: You hold down one of two keys (one key to search forward, one to search backward), and you type in the first few characters of whatever you're looking for. The characters you type can be return characters or document-break characters in addition to letters and punctuation. As you type each letter, the display moves to the first occurrence of all the characters you've typed so far. This is incremental search. It is much faster and much more convenient than using a dialog box to begin a search.

  • Dedicated keys for critical commands. The UNDO and FIND commands are important enough that they deserve their own keys. I'm thinking of using the two Alt keys as the FIND keys, and the Caps Lock key as the UNDO key (Shift+Caps Lock would redo).

I also have other user-interface ideas that I found on the Net or came up with on my own:

  • Windowless screen. The Karig user interface will not use movable, resizable windows. Instead, Karig will use a static screen layout. One large document pane will take up the bulk of the screen; this is where all editing is done. On the side, however, will be three little "windows" for displaying details from up to three other documents at once. This setup means less code than if I had to write and debug code for creating and managing real windows, yet it still allows you to view two or more documents side by side.

  • Cursor is always in the center row. The cursor never moves up or down. If you press the cursor-up key, the screen actually moves down one line to put the cursor into the previous row. This means that there is no distinction between moving the cursor and scrolling — another simplification.

  • Text is auto-selected. When you start typing, the current selection is not replaced. Instead, the text you type is added to the current selection. You can then change the formatting of the text you just typed without going back to select it first. For example, you can cancel the current selection, then begin typing a few words (which become the new selection), hit a CAPS key, and make all of the text you just typed uppercase.

  • Themable projects. It would be nice to be able to change the display of each project with fonts and bitmaps, so that you can distinguish them visually without having to stop and read the screen. For example, the to-do list, the calendar, and the address book would each have its own distinct look — although the screen would still have the same layout in all three (one large editing pane, three small viewing panes).

Conclusion

So as you can see, Karig will be quite different from other hobbyist OSes. Some people will question the wisdom of some of my decisions, but remember that Karig is a toy OS. I don't foresee myself making a server OS out of Karig or even offering Karig as a platform on which to do serious work. Maybe one day I'll get bored with Karig and start work on a real OS, but until then, Karig is simply my hobby.

Check the index for other entries.