RevMedia

As an Advanced Revelation user, you've watched that logon banner many, many times. And as a reader of this journal, you've probably wondered often about what's happening as those little dots march across the screen.

Through the good graces of Revelation Technologies and of Revmedia, I have the opportunity here to give you a bit of a peek behind the logon curtain. While constrained from detailing each tiny step of the process (there's much that goes on that's still secret stuff), I can offer the following overview. To keep things simple I'll provide an outline, and then add some commentary at the end. Let me just quickly note that the information here is unofficial, meaning that Revelation Technologies will emphatically not entertain any questions or problems that you might come up with arising out of this article. That said, here's the outline:

AREV.EXE

    If math chip else load emulator
    Initialise memory: 1/8 for descriptors (up to 64K),
    remainder for string space.
    Initialise descriptor table.
    Initialise EMM if present.
    Read REVBOOT file and extract RTP1.
    Call RTP1.

RTP1

    Initialise system variables.
    Install boot filing system.
    Open SYSOBJ "manually" (with BFS call).
    Load SYSOBJ code into program stack.
    Install RTP50 (MEMORY.RESIDENT); Initialise FILES and VOLUMES.
    If network version and if station id, check for too many users.
    Open SYSTEM manually.
    Get user name from command line else read monitor type and set to USER
    or COLOR.USER.
    Validate user; if fails three times, log out.
    Attach VOC and VERBS manually.
    Load secondary load code.
    Locate logon verb in VOC (user/account/LOGON); load into TCL buffer.
    Attach REVBOOT volume.
    Display network inactive message if neccesary.
    Attach INDEXING volume.
    Attach DOS volume.
    Install SYSCOLUMNS file type.
    Load command stack from LISTS
    Call RTP2.

RTP2

    If no help level, display auto help.
    Call INITIALIZE
       Load environment record.
       Load keysroke arrays.
       Initialize backdrop and status list.
    Attach TRANSACT volume.
    Restart pending transactions.
    Loop
       Call RTP18 (TCL) (exit only on OFF or TCL-1 RESET).
    Until logout
       Null @DATA, clear select lists, printer off, break key on
       Unlock all.
       Call INITIALIZE.
    Repeat

There is much to learn here. For starters, it's now clear that REVBOOT is nothing more than RTP1 followed with the "boot" filing system (i.e., the file type of the basic AREV system files). In most (all?) cases, that is RTP57. If you had a desire to use a non-linear hash file type for your system files, you could theoretically substitute your BFS for RTP57 in REVBOOT and recreate the SYSOBJ, SYSTEM, VOC and VERBS file in the new file type. (Let us know how that goes). More practically, this explains why REVBOOT is rebuilt when you bump; a new version of RTP57 (with network interface code) is put into REVBOOT.

Some of you might have gotten stuck after the 2.0 Upgrade when you suffered an infinite-loop load error upon trying to log on. This happened to folks who had placed a Quickdex on VOC, VERBS or SYSTEM. Now you can see why - the system attempts to access the files before it can get at the object code for the Quickdex routine (which is in VERBS). The solution is to put the indexing object code back into SYSOBJ, allow it to be loaded earlier, and live with the extra memory it requires.

The most interesting aspect, I think, is the behaviour of RTP2. If you're a program stack hacker, you can now see how the irreducible core of programs gets and stays on the program stack. It's first loaded directly out of SYSOBJ and secondary load. It's then protected by RTP2, which is (Tron-like) the "master controlling program" for the system. The lowest-level reset you can do (at TCL-1) flushes everything off the program stack back to RTP2, which catches the reset and processes it. If a program can get itself onto the program stack before RTP2 is called, it will stay there for the rest of the session.

(If you've paid close attention, you'll be asking why RTP1 doesn't appear on the program stack, as it should (and first, too.) Look carefully, though. RTP1 is loaded before the program stack is even initialised - in fact, that's its first duty - so it is handled differently and disappears as soon as it calls RTP2).

I'm afraid that there isn't enough information here for you to puzzle out what each marching dot means in the logon banner. The news is actually even worse than that. Not only is this just an outline, but it is, unfortunately, apt to change in the future. However the basic notion of what the logon sequence is all about is represented here, and will certainly not change in spirit, even if it does eventually change in details. I hope you find it as interesting as we do. Perhaps you can even find a practical application for it all - if so, do let us know!