Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!mcvax!inria!rouaix
From: rouaix@inria.UUCP (Francois Rouaix)
Newsgroups: comp.sys.amiga.tech
Subject: 1.3, resident, re-boot
Keywords: Want to get this resident list back
Message-ID: <1101@inria.UUCP>
Date: 2 Sep 88 14:35:26 GMT
Article-I.D.: inria.1101
Organization: Co.
Lines: 48


I just received my omega 1.3, and I was looking for a good way to
configure it.
We had vd0:, now we have RAD:. Ok, great, and I may reboot from RAD:.
BUT it seems more logical now to use Resident for the most commonly 
called commands, instead of putting them in vd0: or RAD:.
The problem we have now is : how can I have a lightning-fast reboot, with
my fine-tuned configuration. I don't wont to reload the code of my
commands at every boot.
IDEA: let's have "something" rebuild this Resident List during reboot.
Why I think it is feasible:
	1)If I understood the Resident command, there should be somewhere
in the memory a GLOBAL list of command names and associated SegLists (with
maybe some problem as described below). I deduce here that it is possible
to find a pointer to these informations somewhere in the dos.library data.
The point here is that the location for this pointer is ALWAYS the same
in a given memory configuration. Am I wrong ?
	2)We have something named ROMTags, that allow us to execute some
code during the boot process, although it is not really documented :-).
So we may write some code that will be executed by the strap module
(you know, those rt_Inits), and this code will try to rebuild our Resident
list, that is in fact modify the memory-allocation list, so the code won't be
trashed by other applications.

Now for the problem with our commands SegLists:
	- clearly, the code hunks must be in the SegList.
	- how about the data hunks ? (remember we may have shareable read-only
		data at least). I think that we don't have their address,
		because of load-time relocation resolution. We loose.
		But it's always feasible to have only code hunks, isn'it ?
		It may even be possible to patch existing commands if needed.

SO, if you followed me, you must ;-) know the answers to my questions:

	- is this feasible ?
	- is CBM going to write it ? if not, I'm willing to give a try,
	but I *need* some precise explanations on ROMtags, especially 
	how the memory-list is modified with respect to those endSkip and 
	other pointers.
	I promise I won't use this for writing new viruses ;-).
	(If it's worth to anybody at CATS, I have 1.3 omega officially, with
		non-disclosure agreement signed)

Hope it is sound...
-- 
*- Francois Rouaix                 //       When the going gets tough,       *
*- rouaix@inria.inria.fr         \X/           the guru goes meditating...   *
*- SYSOP of Sgt. Flam's Lonely Amigas Club. (33) (1) 39-55-84-59 (Videotext) *