rouaix@inria.UUCP (Francois Rouaix) (09/02/88)
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) *
ewiles@netxcom.UUCP (Edwin Wiles) (09/08/88)
In article <1101@inria.UUCP> rouaix@inria.UUCP (Francois Rouaix) writes: > 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 Woooonnnnddeerrrfullll! Now there's a way to attach viri to the boot code that won't even break the boot! *Just* what we need! :-( -- ...!hadron\ "Who?... Me?... WHAT opinions?!?" | Edwin Wiles ...!sundc\ Schedule: (n.) An ever changing | NetExpress Comm., Inc. ...!pyrdc\ nightmare. | 1953 Gallows Rd. Suite 300 ...!uunet!netxcom!ewiles | Vienna, VA 22180
andy@cbmvax.UUCP (Andy Finkel) (09/09/88)
In article <1101@inria.UUCP> rouaix@inria.UUCP (Francois Rouaix) writes: > >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 true >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 ? I wouldn't depend on the pointer just happening to appear in the same place. Sure, it might tend to, but its not something I'd want to put into my code. > - is this feasible ? sort of; But I'm probably going to change the structure of the resident list for 1.4. It's private right now, only the standard C-A commands are supposed to know how to walk it (yeah, I know how likely/true that is :-) ). I want to add a checksum for each thing on the list (at the least). The programs loaded are generally scatter loaded. The method used by RAD for recoverability works much better if everything is in one memory chunk. This approach would work best if we were building a bunch of commands into the Shell. And you'd have to fix it so the shell loaded into a memory chunk. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dmose@agora.UUCP (Dan Mosedale) (09/17/88)
In article <4692@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <1101@inria.UUCP> rouaix@inria.UUCP (Francois Rouaix) writes: >>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. >> - is this feasible ? > >sort of; But I'm probably going to change the structure of the resident >list for 1.4. It's private right now, only the standard C-A ... >-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. Yes, please! It would be fantastic (and very memory efficient) to be able to make a programming environment with the compiler/linker in recoverable resident lists. It would make things memory efficient, and much quicker to recoup after a crash. \\ "These opinions may in some way represent those of my employer... // \\ but I seriously doubt it." // \\ // Dan Mosedale dmose@agora.UUCP \\ // \\/ ...tektronix!tessi!agora!dmose \//