REVMEDIA FKB Articles - AREV, OI, REV G, jREV, JCDC, LIVEWATER,ADVANCED REVELATION, OPENINSIGHT, REVELATION G

RevMedia FKB

Document	V2I6A8
Title	Advanced Revelation Initialisation Sequence (Overview) by Mike Pope
Keywords	AREV.EXE RTP1 RTP2 REVBOOT SYSOBJ RTP50 MEMORY.RESIDENT INITIALIZATION RTP18 RTP57 SYSTEM VOC COLOR.USER VERBS INDEXING DOS SYSCOLUMNS LISTS @DATA EMM
Text	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! (Volume 2 Issue 6 Pages 6 7)

[revmedia/copyrigh.htm]

Page last modified: 08/02/03