|  | T his is a work in progress. Thus it is entirely possible that you may read a paragraph written within the last day, while the very next paragraph was concieved more than a year ago. By using the version/timedate stamps, you can determine the reliability of any information. The older it is, the more likely it is that it is horribly wrong. "Know your enemy and thus yourself"-min 95

What is an OCI? --anonymous
An Object Class Interface. This is roughly the same thing as an API (Application Program Interface) but since this system uses Objects and not megalithic applications, the continuation of the usage of the term API into this project would have seemed, well...archaistic. --min /0.14 8/9/96

Why were you picking on Steve Jobs? --anonymous
"I come not to bury Caesar, but to praise him." I wasn't being mean to Jobs. No, not really. I like him. --min /0.13 8/6/96

Why is everyone hugging aliens? --b. cannon
Who knows why our alien masters have us do what we do? :-) --min /0.14 8/9/96

Why is all the text this horrible green? :-) --everyone, incl. Akintunde
Since 0.16 this is no longer an issue. --min /0.16 8/28/96 Because you're browsing in 256 or 16 color modes. It looks just fine in hi-color (thousands) or truecolor (millions) as God intended it. Seriously though, this is the most asked question and most common complaint about these pages. It really does look much better at the higher color depths it was designed in. However, for everyone's viewing pleasure you should be happy to know that all the group documentation is in black and white. Better? :-) --min /0.13 8/2/96

|  | ### When are you guys going to be done? --anonymous In a half year to a year after you give us a grant of 20 to 60 thousand US. The more resources we have, the more energies can be given over to the project. --min /0.13 8/2/96

|  | ### Is it free or not? --anonymous Stop reading old docs! :-) Yes. It is. Despite some wavering on the issue in the past, the aim of the Grail Millennium Project is to produce a free and open operating system. However, there are a few very serious problems with the completely free and user-supported OS model, the most damning of which is that commerical software developers by and large will not develop for a system that can not provide assurances of long-time market survivality-- behold Linus Torvold's Linux as a prime modern-day example of this. The best way to garner these assurances is typically to have an operating system that is a significant if not primary source of income for it's parent organization. Being that Grail Millennium is non-profit we have a slight problem here. What to do? Can one have a commerical non-profit organization? :-) Perhaps. Separate from the Grail Millennium Project an experimental brother organization is being conceptially formed whose object is to attempt to foster strategic commericial alliances, as well as bring in grant-money and other resources to help bolster the project and provide the stability developers need. Should it even be mentioned that a design goal of the project is to produce a system that will last well through the next millennium? Within these constraints there is little else that can be done in this area except to speak binding words that weave a circle round the free core and let the wolves of capitalism do what they may beyond. But enough of such talk. This is afterall a prototype for an ORG site. Such issues shall only be mused over within the private mailing list or donated commerical web-spaces. fini --min /0.00/0.03/0.13 8/2/96

|  | ### Who is the guy in the Logo? --anonymous Bill Cannon jr (of Clan McCannon). --min /0.13 8/2/96

|  | ### What hardware platforms is it for? --anonymous Grail is to be initially only available on the IBM-derived PC systems, though later on a version should show up on the Macintosh. While I nowadays exclusively use IBM PCs, it was not so always, and I'm still a strong Mac supporter. Porting from consoles to Grail is entirely expected it should be mentioned, though porting directly to them is not likely to happen anytime soon. Grail tries to be as friendly to consoles as is possible however to cut down on the effort and time involved for companies who port regularly.
Target Platforms | Target Processors
--- | ---
IBM PC Clones Apple Macintosh systems BeBox ESCOM Amiga | x86s (386, 486, Pentium, Pentium Pro, 5x86, 6x86, etc) Motorola 68020, 68030, 68040, 68060 PowerPCs (601, 603, 604, 620, etc) The Intel IA-64 (P8/PA-RISC) and P7 Merced
--min /0.00/0.04/0.13 8/2/96

|  | ### How is it distributed? --anonymous This is an open free system, as you perhaps already know. Thus, it is just given away (within certain government and other restrictions). You may find it on-line at an ORG site hosting us, or other distribution areas. It could be you'd find it on a BBS or on CD-ROM. There's no telling. There are five packages, some of which are optional. #### P0 Processor-Specific Essential Core This package is rather small, but very important. It contains all the supervisor objects for a specific processor type. #### P1 Platform-Specfic Core-up/Installation and Platform Supervisor Objects In general each hardware platform will have one Core-up and one Installation program for it, ie one for the IBM PC-clones, one for the Power Macs, etc. In addition, the P1 package will include device objects to handle processor/platform specific hardware such as the CMOS Clock on the IBM PCs. For the P1 class are included a set of minimal tools such as editors, metaphors, and Platform-extra device objects. Terminal1 Metaphor The Editor Associative Editor Object Module Sniffer Text-only Visual Device Objects Keyboard Device Object Mouse Device Object The Grail Assembler Grail Script Object, docs #### P2 Device Objects Package This is a massive download if taken as one package. When encountered on CD-ROM the entire collection will probably be bundled up. When browsing across the internet typically you will look for the specific object for your specific piece of hardware. #### P3 Applications Package The CLI Metaphor, a windowed text interface The GLASS Metaphor, pretty 2d windowed GUI The NATURAL LANDSCAPE Metaphor, an emmersive 3D environment Digital Illustrator (by and for computer artists) An audio player and graphic display program for native and friendly formats such as JPEG, and PNG, TIFF, MPEG and Quicktime if the APPLE QTM code is available. An ascii, GrayText and RTF editor A standard/scientific calculator A clock alarm A freeware reader program that professionally displays text so that, among other things, Gutenburg etexts can easily be read. Displays ascii, gray and RTF. Includes a small selection of classic Gutenberg etexts (The Art of War and John Carter of Mars I through IV). Integrity program to do performance and load-failure tests on your system. Several freeware and mini-games by our own people as well as small demonstration programs by various companies that support and author under the Grail Millennium Project. #### P4 Software Developers Kit Technical e-Manuals, explaining all the basics you need to know to write code for the system. C (Ansi emulation and Grail Extensions) Libraries of example Source-code Lots of in-house Technical Manuals to fill up your drive space --min /0.00/0.06/0.13 8/2/96

|  | ### Is this system meant to replace mumble? --anonymous "If you can't say something nice about someone...." --unknown Not really. While it has strong leaning into the multimedia and entertainment fields, the expected areas of greatest market penetration are the areas of education and academic theoretical exploration. Well... in the beginning anyway. --min /0.13 8/2/96

|  | ### THE GRAIL MODEL Grail is for Entertainment and Educational purposes. It is not meant to be a server platform, run business software or be a secure anything. I don't believe in a one-world one-OS philosophy. To that end, it is imperative that Grail be able to gracefully kill itself off and switch to another OS at will, and visa versa. We have reverence for all UNIX clones and respect for OS/2 and MacOS and hope to develop gateways back and forth to them. Grail exalts power slightly above speed. Raw speed is not always the point. Grail tries to create a host of discrete functions that may be at some point supported by hardware, but if not, are supported in software. Where an operation or function is considered overhead (ie, something that probably won't be in some form of a loop) flexibility and power win out over speed. Where the function will probably be in tight loops, speed is everything and all our powers of coding are bent to optimization. For flexibility, Grail is highly modular, and supports OOPish objects. There are no .EXEs, .BINs, .COMs, .VBX, or .DLLs. There is only the object and it's functions, and that object may or may not be a task. See the section on the Grail Script for example code. --min /0.00/0.04/0.06

|  | ### Ok, What's the Environment Model like? Once upon a time there were up to three separate environment models for Grail (Black, Gray, and White). After a lot of long hard thought upon this, the concept has been essentially dropped. The amount of complexity it would added to the kernel and all the support code was, in the final analysis, deemed to be more trouble than it was worth. What was wanted was to be able to disable paging (and therefore not suffer the potentially crippling wrath of sequential TLB misses) and secondly prevent your applications performance to degrade or be choppy because of multitasking. Why not allow such? If we did go with the ability to do mode switches as such, more code would be required and thus the kernel would bloat and be less optimized. It was thought that, in the end, only democoders and a few hacker types would opt for these more primal modes. Separate segments are kept for the kernel, fs device object, and debugger at CPL0, and all the other applications at CPL3. The normal environment model uses a UNIX-like flat-memory paradigm with paging and interesting variants of virtual memory management along with both scheduled and preemptive fair-turn time-sliced multi-tasking. Besides the normal paged virtual memory strategies, Grail has a curious extension to this called a Godet, which essentially maps unused address space to specific files allowing you to address large files as if they were in memory (ie, no damn fiddling with fopen/fread, etc -- just access it). This model also boasts management of up to 110 simultaneous tasks (in the current intel build: properly you should ask the kernel how many it supports directly -- don't assume. Might go up or down from build to build, cpu to cpu.) As said, because of the paging U/S protection mechanism (along with standard CALLGATEs) it is more likely that your applications will survive a hit. --min/0.00

|  | ### DOES IT MULTI-TASK? IS IT PRE-EMPTIVE? DOES IT THREAD? DOES IT SUPPORT MULTI-PROCESSORS? Essentially yes to all. Grail is an object-oriented operating system which attempts to functionally hide whether the object exists within a specific CPU area, etc. Each individually executing bit of code is called an _instance_ in Grail. Thus Grail does not by name support Tasks or Threads or Processes, but instances, active and passive. --min/0.00

Why not just use DOS, Windows®, OS/2® or Linux®?
DOS is 16-bit, dead and takes too long to develop for. It's been fun though. OS/2, I'm afraid to say this, but is a dead issue now as well, at least for the mass public. Even if they do inherently add Java in an fix several of it's previous shortcoming, it's name is now poision in the collective consciousness of the public. Rest in peace. Windows? You're kidding right? I'll be among the first to admit that the new Windows 95 design is a good step in the right direction, and for the most part rather like the setup. But it's as nightmarish to program for as an version of Unix. Speaking of which: Linux. Even though I like UNIX and strongly support it's continued existence as a dominate platform, it's just too bloody complicated to use for the mass consumer or the professional who doesn't have a compsci degree. If it takes my grandmother more than 10 minutes to start it up, it's history. So we have Grail. An OS specifically designed for power and ease of use for the professional and the consumer. --min/0.00/0.16 9/02/96

|  | ### WHAT GRAPHICS AND AUDIO CARDS DOES IT SUPPORT? This is a long detailed subject, for which you should probably obtain one of the in-house CORE technical documents specs if you are interested. There is a driver source-code template to be provided to all card manufacturers which works on the most basic (unaccelerated) cards. Ideally the OEM will modify the code to take supreme advantage of their cards so that it will run as efficiently as possible. In the situations where OEMs do not want to help theirselves in this way, we do accept volunteers to write the drivers. Generally the way this works is that we ask which team member wants to be responsible for coding a driver, and they are supplied (freely, permanently) with said hardware along with specifications and the email address of an engineer familiar with the cards design. However, for the absolute best in graphics/video device objects you might want to poke around Scitech a while after Grail is formally released into the wild as beta. If they happen to determine that Grail has long-term viability and write device objects for purchase by consumers and software publishing companies alike, they will be the best you can get. Because of the design of Grail, you only need a driver for your specific card on your machine. Writing of generic drivers that host a family of cards is intensely frowned upon by Grail. If, for example, you have a CL-GD5428 (a good basic accelerated graphics card by Cirrus Logic) you would have only a CL-GD5428 driver, not one for all the CL-GD542x's. This promotes writing code that is the absolute fastest and efficient as possible. --min/0.00/0.06

|  | ### WHAT IF I'M RUNNING UNDER OS/2 OR WIN3.x/95? If you're running under OS/2 or WIN95 do you have to erase then to run Grail? No. There is being designed a variant of the multi-OS bootup program that will allow you to switch between OSes without too much hassle. Grail is meant to be as co-operative to foreign OSes as possible. --min/0.00/0.06

|  | ### WHAT DOES IT LOOK LIKE? The Grail operating system has no set interface, neither CLI (Command Line Interface) nor GUI (Graphic User Interface). And it never shall. The design of the filesystem (FS) is such that all truly relevant information is stored either with the user's resource file or the associative of the file in question. A Metaphor is a program that takes this FS information, along with that of the currently running tasks, and paints a picture therein based. A Metaphor is merely a structured, guided, visual interpretation of the computer system. It can be anything. You can make it look like almost any other operating system (flat and lifeless) or a living breathing dynamic environment. There are in fact, two Metaphors that come with the release version of Grail. One is a standard (though nicely done) two-dimensional folder-based paradigm similiar to that seen on most every system currently available. There is also a three-dimensional Metaphor with a natural landscape motif. (See EOS2MOCK.JPG -- The Cyberdemon and Quake preview screenshot are courtesy of ID Software.) Any end-user with programming skills can thus custom design their own Metaphor (ie GUI) interface. --min/0.00/0.07

|  | ### I HEARD THE FILESYSTEM WAS A LITTLE DIFFERENT. CARE TO EXPLAIN? Well, the FS is a bit different true. Grail uses a two-branch file system, using folders with binding lists and files with associative and data branches. "Mm. what's that mean?", you ask. It means that, a little like the Macintosh systems, you can store information associated with a file in a different branch (fork) of that file. Think of a saddle bag, if that helps. One side of the bag holds the actual data or program of a file, the other side holds information about the file which may include it's name, the authors name, a graphic icon representing the file, some user preferences on how to use the file, it's x/y/z location on the screen, etc etc. Almost every bit of information relating to that file is stored in it's associative branch. Nice, neat and tidy. One of the first things people notice about this, is that the file's name itself is held in the associative branch just like any other information. And yes, this does mean that on the current Intel platforms filenames can be up to a little over 4 billion characters in length (or 2 billion if using Unicode). I don't want to hear anyone bitching about filename lengths being too short from now on, ok? =) --min/0.02

|  | ### HOW DO WE REFERENCE FILES THEN, IF FILENAME IS EXTRANEOUS INFORMATION? Good question. It didn't start out this way, but in an order to have extremely long filenames I moved them to the associative branch. In order to reference a file I created the ideal of using unique 32-bit reference ids for files (or folders). You would reference a file using a string of these 32-bit refIDs denoting the folders, subfolders and then the file you were talking about. It was about this time a few months ago that I got my first true internet account... and lo and behold I encounter the concepts of URLs and the DNS. From that point on everything meshed and became very clear. So yes, Grail in effect now uses a DNS/URL similar file naming system. All files use a string of refIDs, which you can lookup through folder and filenames through the __FS_FileLookup function much like a DNS lookup. A DNS is composed of 4 8-bit numbers, though, I might mention and does not reference actual files, while each element in the Grail FS is 32-bits currently. The bitwidth of the refID is usually the same as the architecture of the machine it is running on, I might mention. You can set the default to other though. For example, most Intels currently have 32-bit pointers and a 32-bit filesystem. With the bigger hard drives and DVDs coming out though, you might have 64-bit refIDs. Grail's FS and kernel are designed with the idea in mind that at some point it may run on 32-bit, 64-bit, 128-bit, 256-bit, etc systems or devices. --min/0.02/0.06

|  | ### WELL, OK. BUT I HEARD FILE TRANSFERS WRE... UNUSUAL. 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/. (Yes, spaces are valid in filenames under Grail.) You can of course, BTW, transfer not files, but streams of data through communications devices, if you so desire. --min/0.02

|  | ### IS IT TRUE IT INHERENTLY SUPPORTS INDIVIDUAL OR MASS FILE COMPRESSION? Yes. As part of the file system itself on-the-fly decompression is supported. Though we are developing our own code to do such, hopefully Stac Technologies will, if Grail starts to pick up momentum, develop their own routines for you to use. Anyway, you can select the policy of a file to prefer compression (even a specific compression type). For some files, compression would not substantially help and would infact slow things down. For others, such as say a Window BMP file, setting the compression policy would definately help. You will read the file just as normal, and the FS will automatically decompress as needed. Grail also inherently supports archives through the FS hyper device object. While you can wonder through the highly-compressed archives just like any other folder, you can not use them. Under the Natural Landscape Metaphor they look like they are encased in ice. :) Dearchiving pretty much takes care of itself. Because of the time such a function requires however, you'd usually create a separate running active instance... um, a thread :) and monitor it, providing semaphore and messaging information back to the user. --min/0.02

|  | ### HMM. IT DOESN'T SEEM PARTICULARLY SECURE FROM WHAT I'VE HEARD. And there's no particular reason it should be. This operating system is designed to be used primarily at home, or as a common site-interface (helpful directions in malls, etc). It will support multiple persons to use it, but not at the same time as you might with a server. Nevertheless, it is possible to doubly or even triply encrypt files, via the operating system and define passcode/voice protected personnel accounts with restricted file/folder aged-based* or group access. =) In short, you can set it up so that you and the kids (or you and your parents) can use the same computer without trashing each others programs and files. Or keep or diary without the threat of it being read. Or play DOOM without the fear of your little brother erasing your save games. Etc. Yep. When in Supervisor Mode, you can setup an account for your kids, entering their dates of birth, and then allow access to files based on age. If you set DOOM II for age 13, and your 12 year old son has his birthday, it will automagically grant him access without you having to tell it to. :) This also makes a market for automatic birthday-card programs, I would think, as well as gradual birds-and-the-bees type information to be show to your kids. --min/0.02

|  | ### COOL, BUT ARE YOU HIRING? The Grail Project is not exactly a non-profit organization, but neither is it a for-profit, all-the-profit, screw-everyone-else-out-of-their-profit organization. At the moment the Grail Team is merely a loose confederation of like minded persons helping to build upon the basic structure of the kernel and prepare for it's coming. If you enjoy putting together FAQs through writings and illustrations/renderings, designing device drivers, and helping build an operating system you're welcome go to the group section and try to join up. :) --min/0.02

|  | ### I'M CONFUSED WITH THE FILE AND OBJECT NAMES There is some confusion related to the proper usage of file and object names. In general you can use any character at all in either ASCII (8-bit) or UNICODE (16-bit), however there a few special characters that can not be part of a name, but are considered control characters. They are: NULL, ";", ":", "/" and NEWLINE. NULL is character code 0. It represents the end of a character stream. A colon, ":", represents the division between either a title and a subtitle or between an object name and it's instance name. For example this is a title/subtile name "STAR WARS:A New Hope". And this is a class/instance name "__METAPHOR:The Natural Landscape". A semi-colon ";" usually represents the series number. For instance "X-men:Trading cards;7" might represent the 7th in the series of X-Men trading card pictures. It is also used for extra attributes such as revision or fragmentation numbers, in that order. The right slash "/" prefixed to a name section indicates a folder, thus it's also called a folder mark. For example "public/readme_please", pointer to the readme_please document in the folder public. Using a folder mark without a name before it indicates that you wish to start with the NULL or ROOT folder. --min/0.02

|  | ### I CAN RUN 32-BIT PROGRAMS NATIVELY ON 64-BIT MACHINES? SERIOUSLY? Another issue that is bringing about confusion, especially locally. This is a complicated issue. Read the CORE documents and the Grail Assembler document. Anyway, it is true that theoretically, say for instance, you can write 32-bit GRAIL programs for the PowerPC 601 and then, latter on, buy a PowerPC 620, upgrade to the 64-bit kernel of GRAIL and run your programs without change. How is this possible? GRAIL automatically promotes your pointers to 64-bits, silly. :) If you study the Object Module Format, you'll notice that all pointer and pointer-related items are kept track of in a list in the object's file. Changing the size of all pointers in the data section is simple enough. Doing so for the code sections is a little harder, but feasible. This works only within the same architecture (x86 or PowerPC, etc) and will work both ways, both up to higher pointer-widths and down to lower. It will not work for device objects. It will also not work on a lower class machine if your code was compiled on a newer machine using instructions not available on the lower. You can of course flag your object's processor architecture as locked, which results in an error instead of a translation. This is a viable option for those who wish to produce specific customized code for each 32-bit, 64-bit, 128-bit, 256-bit, etc version of a processor. --min/0.02

|  | ### HEY, YOU SEEM TO HAVE ABANDONDED ASCII CONTROL SEQUENCES! You caught me. :) When I started college, I routinely used hard-copy terminals. I would log in on what was essentially a printer, and do my editing and compiling with the results being printed on this printer device instead of having a CRT screen. I also had a part time job once where we used punched-cards and 8 inch floppies. :) So, if it seems that I have abandoned this heritage with Grail's design, it's not because of ignorance of the standards or general avarice towards. It's simply because they are no longer needed, except for communications with printers, terminals or special devices. You can use them, it is only that GRAIL does not reserve them anymore. --min/0.03

|  | ### IS THERE A DOWNLOADABLE VERSION OF THIS FAQ? There sure is! The newest version is 0.05 - GRAILFAQ.ZIP Remember that this and all other documents available from this page are in Rich Text Format. They are also all compressed with PKZIP. --dustin/0.05 Glad someone's keeping all this up to date. :-) From this point on, only the basic essential information will be keep on this home page. If you need more, but non-technical, information on who's doing what and why, then either read the What's New page, or Dustin's GRAIL FAQ. It does have more info in it than is on this page. --min/0.06

HEY, EVERYTHING ON THE PAGE THIS CHANGED!
It happens. There was a major overhaul at 0.06 and there will be others. Expect several changes everytime the revision number does. --min/0.06/0.16 8/28/96

WHAT YOU SAID DOESN'T MAKE SENSE!
Entirely possible. You must remember that this is an on-going project. You may read a paragraph I wrote just yesterday, and the next one was written half a year ago. Obviously, there may be many unintentional discreptancies until all the project is in beta's and documents are brought up to date. --min/0.06/0.16 8/28/96

NEED TO ASK A QUESTION?
S omething bugging you about Grail Millennium? As us about it. If we have the time maybe the answer will appear on this page in a day or two. #### Your Name? (optional): Your E-mail address? (optional): Your question?: ###

Problems with the HTML or JavaScript? Email webmaster.
Comments? Email founder Lewis Sellers.
Copyright © 1996, Lewis Sellers. All Rights Reserved.

Q: CGI?
A: CGI n.(obsolete) Common Gateway Interface. Use environmentally safe Netscape JavaScript.

Grail Millennium Foundation