A Grail Millennium Project

White Paper

History | Preface | TOC

This document is maintained by the author, Lewis A. Sellers, somewhere in the mountains of East Tennessee, the United States of America. It is an informal technical document for a works in progress project called Grail Millennium, or fully, The Minimal Operating System of Object Class Interfaces Holy Grail for the Millennium. In other words, for a new, easy to use, long-lived operating system.

Copyright Notice

This document and all material therein, unless otherwise stated, is Copyright © 1995,1996, Lewis A. Sellers. All Rights Reserved. Permission to distribute this document, in part or full, via electronic means (emailed, posted or archived) or printed copy are granted providing that no charges are involved, reasonable attempt is made to use the most current version, and all credits and copyright notices are retained.

Distribution Rights

All requests for other distribution rights, including incorporation in commercial products, such as books, magazine articles, CD-ROMs, and or computer programs should be made to the primary author Lewis Sellers.

Warranty and disclaimer

This document is provided as is without any express or implied warranties. This is a work-in-progress, and as such will contain outdated or as yet uncorrected or substanstiated assumptions. The author, maintainer and/or contributors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

WWW Home Sites

You can currently find home sites to this project at If you can not reach them, or they seem to be down, do a key word search on AltaVista, Lycos, or the Web Crawler search engines.

Contact Email

The primary author of Grail Millennium should be reachable at lsellers@usit.net.

Preface | TOC

OCI/Spec | DISTRIBUTED LONG-TERM MEMORY

DESIGNER

Lewis A. Sellers (aka Minimalist) lsellers@usit.net

CRITIQUED BY

DRAFT

TOC

(a0.50)

Table of Contents

Legal NoticesWho gets sued and why
HistoryChanges and who made them
PrefaceAbout this document and the people that make it

Overview

TOC

An Overview of the Non-local Virtual File Systems

BY | Lewis A. Sellers lsellers@usit.net

As stated in the main Filesystem Document, the file system used by Grail pertains to every device that contains files or that has an aperture through which they may be accessed. In general the Grail looks upon files the same way whether they exist on your system or someone else's and whether they are formatted for Grail or some other operating system.

Grail is currently bound with the device objects and device object reinterpreters to handle, in addition to itself, the DOS, WIN95 DOS and UNIX filesystem extensions and well as communications through the serial port (NULL-modem), hayes-protocol compliant modems, IPX Networks and TCP/IP ISDN and TCP/IP PPP dialups. Grail treats the differences between filesystems and communications protocols roughly the same.

Local

Non-local

Foreign File Systems

INTERFACING WITH NON-LOCAL FILESYSTEMS

When through a non-local filesystem interface you move through filespace, tokens are created on your systems representing the non-local systems observed in filespace.

Say for instance you visit ftp.cdrom.com (Walnut Creek Software) looking for new and exciting programs to download. Grail will create non-local/ if it has not done so already, then it will created non-local/ftp.cdrom.com/. Typically, since you have come in at the top level it will then create a folder for every subdirectory at their site and a token for every file, such as:

/non-local/ftp.cdrom.com/ ;folder

bin/ ;folder

pub/ ;folder

readme.txt ;token

While the concept of recreating non-local filesystems on your on system may sound a bit distressing at first, don't worry about it too much. All recreations occur in the virtual subroot non-local and all true files have only a token of their existence stored unless your software transfers them. This applies no matter what the source or the means of connection. When you are connected to computer systems that may not present a decernable filesystem (such as most current BBSes) then you must declare it's proper name to be used and all files are grouped into a single common folder. Take for instance, The Other World BBS, which ran under Major BBS software. The folder /non-local/The Other World BBS/ would be created and used.

See the section on NON-LOCAL FILESYSTEMS for more detail.

Well, ok. But I also heard file transfers were... unusal.

They are different to be sure. Not only are hard drives, floppies, CD-ROMs and Tape-drives part of the filesystem, but modems, ethernet cards, etc. All non-local files and folders are by default mirrored through tokens onto your filesystem. As to what that means, say you FTP to ftp.cdrom.com down into /pub/demos/songs and do a directory. Depending on how you have your system setup, Grail would probably create the folder path /ftp/ftp.cdrom.com/pub/demos/songs/ and fill it with token file bindings based on the directory information it got back. If you transfered a file from them the token would be replaced with the actual file.

Thus, there is typically no such thing as a disk cache under Grail, and you never have to fiddle with deciding where to put a file, etc. No download directories. It handles itself.

All transfered files have an extra attribute which in effect gives them a life span and makes them easy to purge enmass if you need more space. Unless you specifically increase a file/folders lifespan or make it permanent it will eventually disappear after a certain amount of time or if disk space drops too low. This attribute is called transience. The files are typically called virtual files.

There was some concern about using path-less BBS systems with Grail. In general, if you interface with a location such as a BBS that does not provide folder or directory path information, they use one common folder for all files. For instance, say you connect with the Otherworlds BBS. You might have a folder path created such as /bbs/OtherWorlds BBS/.

You can of course, BTW, transfer not files, but streams of data through communications devices, if you so desire.

FOREIGN FILESYSTEM INTERPRETATION

Wanting to transfer all your precious data from some other operating system to Grail? That's not much of a problem. Grail's file system is pretty accomodating. If you missed it, filenames can be up to between 2 and 4 billion characters long under the Intel version of Grail. Yes, I said Billion, as in B. If you wanted to you could put the entire contents of The Bible as your filename. :) On 64-bit machines, it's even more, as if you really need it. The point is: don't worry about the conversion. You won't lose anything.

Grail can read from both the DOS and WIN95 filesystems as well as UNIX EFS. And hopefully, soon, even the Mac Filesystems (who's actual wide-spread use of a two fork filesystem helped in a small, but important way in the shaping of the Grail FS).

There are two ways to go about the translation. You can once and for move the file into Grail filespace, or you can have Grail pretend this other filesystem is its. If you're going to be using the file much, you might as well move it into Grail space. When accessing foreign filesystems even on your own computer, Grail creates a folder in the local/ folder with the name of this DOS or whatever file partition. It however creates local token files, as opposed to non-locals and thus does not take up to much extra space.

DOS

See WIN95.

WIN95

The main difference between the DOS and WIN95 filesystems is that WIN95 has added a somewhat ungainly cludge to add support of up to 255 odd characters for a filename. Grail supports DOS and WIN95 through the same interrpreter.

The translations are fairly staightforward. The main part of the file is stored in the data branch and all of it's attributes and its filename are placed into it's binding and associative branch. Names are translated directly as is so the filenamed "MYCAT.TXT" will remain "MYCAT.TXT" even though dot-extensions look pretty silly under Grail.

On that point, the interpreter will classify a program based on those extensions. File with a ".TXT" extension will be classed as Plaintext/ASCII. All ".COM", ".EXE",".DLL" and ".VBX" will be classed as objects/corrupt, by the way. All Images

Plaintext/ASCII files have their 10, 13 newline sequences stripped out and replaced with a simple unixy 13, which is also what Grail uses.

UNIX

***

Modem

IPX

Dailup PPP Internet Connect

ISDN Internet Connect

***tokens

1

application

high-level protocol

protocol

device object

Click here for Picture

**device object

__MODEM

__ETHERNET

__ISDN

**protocol level

**fs level

**

HOW DO I REFER TO FILES (or FOLDERS)?

As said, there is is the main root folder (top most heiarchy of the entire system) and the sub-root folders (top heirarchy on each filesystem device) and then finally the normal folders. All may contain files. To make interfacing with other filesystems easier, Grail has adopted a routing and referencing system similiar to UNIX and the URL (Uniform Resource Location) syntax. When referring to a file you must first declare it's general location: Is the file local or non-local?

To access local files you can use the prefix "local:" or no prefix at all. To access non-local files the prefix is "non-local:". When using

The root is always called ROOT. If you wish to refer to a file called test_file_1 in the ROOT, it would be:

/ROOT/test_file_1

Sub-roots have their own names which reside in the ROOT filespace along with all the system files and system folders. You refer to the file test_file_1 in the sub-root drive3 as:

/ROOT/Drive3/test_file1

And so on.

local (or file):

Forces a referal to local filespace. These files are typically fairly secure and safe.

non-local (or ftp):

Forces referal to a non-local filespace. The term is currently synonomous with ftp.

When through a non-local filesystem interface you move through filespace, tokens are created on your systems representing the non-local systems observed in filespace.

Say for instance you visit ftp.cdrom.com (Walnut Creek Software) looking for new and exciting programs to download. Grail will create non-local/ if it has not done so already, then it will created non-local/ftp.cdrom.com/. Typically, since you have come in at the top level it will then create a folder for every subdirectory at their site and a token for every file, such as:

/non-local/ftp.cdrom.com/ ;folder

bin/ ;folder

pub/ ;folder

readme.txt ;token

While the concept of recreating non-local filesystems on your on system may sound a bit distressing at first, don't worry about it too much. All recreations occur in the virtual subroot non-local and all true files have only a token of their existence stored unless your software transfers them. This applies no matter what the source or the means of connection. When you are connected to computer systems that may not present a decernable filesystem (such as most current BBSes) then you must declare it's proper name to be used and all files are grouped into a single common folder. Take for instance, The Other World BBS, which ran under Major BBS software. The folder /non-local/The Other World BBS/ would be created and used.

See the section on NON-LOCAL FILESYSTEMS for more detail.

TOC

About Modems

BY | Lewis A. Sellers lsellers@usit.net
The bound object class is __MODEM, with a hayes protocol object __HAYESPROTOCOL.

__MODEM_Aquisition

__MODEM_DeviceInformation

__MODEM_Status

__MODEM_SetupEnvironment

__MODEM_SetupDevice

__MODEM_Operation

**

win1 = __METAPHOR_TextWindow_Open

print __OBJECT_Function __METAPHOR, TextWindow_Print

if __MODEM_Aquisition >0

{

(memory, accesstime, transferrate) = __MODEM_Information 0

Print "Memory:\t",memory,"\n"

Print "Access Time:\t",accesstime,"\n"

Print "Transfer Rate:\t",transferrate,"\n"

(avg_memory, avg_accesstime, avg_transferrate) = __MODEM_Information 1

Print "Average Memory:\t",memory,"\n"

Print "Average Access Time:\t",accesstime,"\n"

Print "Average Transfer Rate:\t",transferrate,"\n"

}

__METAPHOR_TextWindow_Close win1

**

DEVICE_Aquisition

DEVICE_Device_Information

Returns information about the device, such as it's memory capacity, speed, etc.

Group 0: total memory, access time, transfer rate

Group 1: Average total memory, access time, transfer rate

Group 2: total memory, access time, transfer rate

Group 4: total transfer output, input

DEVICE_Status

Returns the current mode or operation status of the device.

DEVICE_Setup_Environment

Configures and maintains the data structures on the system for the device.

mode 0 device

mode 1 exterior-filesystem

mode 2 filesystem

DEVICE_Setup_Device

Talks to the device setting it up for various modes or operations.

stream

block

DEVICE_Operation

Performs the low-level read and/or write operations.

mode 0 ?

mode 1 read

mode 2 write

**

Creation

Places the interrupt handlers for COMs 1 through 4 into the Asynchronous Exception handler chain.

Destruction

Removes all COM handlers from the asynchronous Exception chain.

Structure of Com List:

flags

partial/complete

disabled/enabled

null/IRQ handler

number (COM1,etc)

type (serial,etc)

detection routines (cs:eip)

read routine (cs:eip)

write routine (cs:eip)

max speed

**

Get Bufferspace Info

USE: DX=0-3

RETURN: AL= 2^n size of buffer setting

Change Bufferspace

USE: DX=0-3

AL bytes allocated for buffer space as 2^AL

AL represents the buffer space as 2^AL (ie 1,2,4,8,16,32,64,etc).

This allows faster ANDing to pointer as it overflows. This space

is allocated for both incoming and outgoing. Ie, DX=0 AL=6 means than

64 bytes are allocated for outgoing to COM 0 and 64 outgoing for COM 0.

Flush Buffer

USE: DX=0-3

This sets the lastreadposition pointer to position.

Wait on Buffer Empty

USE: DX=0-3

ECX maximum polls to wait for.

Sits and waits till the out going and incoming buffers are empty.

Use before a flush.

Read Com Status

USE: DX=0-3

RETURN: ESI position incoming

ECX lastread incoming

EDI position outgoing

EDX lastread outgoing

_InitializeCommunications port,

USE: DX=0-3 communcations port

AL break (0/1)

BH parity (0-4)

0=no parity

1=odd parity

2=even parity

3=stick parity odd

4=stick parity even

BL stop bits (0/1)

CH data length 0-8

7=7 bits

8=8 bits

CL BPS rate

4=1200 baud

5=2400 baud

6=4800 baud

7=9600 baud

8=19200 baud

?=14400

?=28800

?33.6

Com Control

USE: DX=0-3

AL 0=read

1=write

if AL=1 BL=modem control register

RETURN: AH port status

AL modem status

BL modem control register

Read character from Com buffer

USE: DX=0-3

RETURNS: AL Character

AH status

flag c set if no data

Places the next character in the incoming buffer into AL (assuming there is data waiting.) and increases the lastreadposition pointer.

Write character to Com buffer

USE: DX=0-3

AL character

RETURNS: flag c set if buffer full

Readblock from Com buffer

USE: DX=0-3 com port selected

EDI pointer to buffer data is to be copied to.

ECX the maximum size of the destination buffer.

RETURNS: ECX no of bytes read from buffer.

Writeblock to Com buffer

USE: DX=0-3

ESI pointer to data to be written into outgoing buffer space

ECX size of data to be placed in buffer.

RETURNS: ECX count of btyes wrote

ESI pointer to last byte taken.

flag c is set on error (buffer full)

TABLE Port Status Bits

76543210

.......1 Data ready

......1. Overrun error

.....1.. Parity error

....1... Framing error

...1.... Break detected

..1..... Transmit holding register (THR) empty

.1...... Transmit shift register (TSR) empty

1....... Timeout

TABLE Modem Status Bits

76543210

.......1 Change in Clear to Send (CTS) status

......1. Change in Data Set Ready (DSR) status

.....1.. Trailing edge ring indicator

....1... Change in receive line signal

...1.... Clear to Send (CTS)

..1..... Data Set Ready (DSR)

.1...... Ring Indicator (RI)

1....... Recieve line signal detected

TABLE Modem Control Register Bits

76543210

.......1 Data Terminal Ready (DTR)

......1. Request to Send (RTS)

.....1.. Out1

....1... Out2

...1.... Loopback Test

111..... Reserved

TOC

Network Cards

BY | Lewis A. Sellers lsellers@usit.net

TOC

ISDN

BY | Lewis A. Sellers lsellers@usit.net