mp1u+@andrew.cmu.edu (Michael Portuesi) (04/16/88)
[look! a message that's not cross-posted to comp.sys.amiga!]
I just downloaded a copy of REZ from a BBS system last night, and I have some
questions about its use.
I have been using the old Resident command from the 1.2 Gamma distribution to
make a bunch of BCPL commands resident (copy, rename, delete, etc). I find
that with these commands resident and with ConMan running, I get nearly all of
the functionality of the Dillon/Drew shell for less memory (unix-like syntax is
not important to me, and I can live without the superior scripting
capabilities). Anyway, Resident allows you to replace the default CLI with a
CLI-Resident that somehow "knows" about these resident commands and uses them
without having to search the disk.
I tried out REZ, and installed the big blob of commands I normally make
resident. They installed fine, but I was shocked to find that I still had to
have my Workbench disk in the drive so that the CLI could search for the
resident commands! For me, the whole purpose of having commands resident was
so that I wouldn't have to have the Workbench available to the system at all
times (I have 1.5M and one disk drive).
I understand that REZ works by stealing the LoadSeg() and UnLoadSeg() vectors
in AmigaDOS. In this case, it is understandable that the CLI is still
searching for commands on its path since the resident stuff is happening at
such a low level. But is there a way to make REZzed commands less dependent on
the Workbench disk, or should I continue to use the 1.2 Gamma Resident and wait
for the one that's supposed to come with 1.3?
If this message is not "techy" enough for comp.sys.amiga.tech, please let me
know by email. I would like to get a better feel for what is appropriate for
this group.
--M
Michael Portuesi / Carnegie Mellon University
ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas
"Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"kim@amdahl.uts.amdahl.com (Kim DeVaughn) (04/16/88)
In article <UWNbguy00V4M0Bk15-@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > > I tried out REZ, and installed the big blob of commands I normally make > resident. They installed fine, but I was shocked to find that I still had to > have my Workbench disk in the drive so that the CLI could search for the > resident commands! Hmmmmm ... I've been using REZ for awhile, but haven't noticed this since the commands that I tell REZ to rez are sitting in vd0: (REZ is still "on trial" with me, so I haven't changed my environment around to take full advantage of it yet). Anyway, let me make a SWAG at your problem ... When you issue the command "rez foo" (or "rez -a foo"), REZ only adds the command to it's list of things you want to be made resident (in this case, "foo"). It doesn't actually load them at this point, but waits until the first time you actually issue the command (foo) to work it's magic. Hence, the *first* time you *use* one of the commands in your "blob", REZ checks it's list and sees that although the command is on the rez-list, it hasn't been loaded yet, and allows the path search to proceed. Assuming the command was found, it gets loaded (and executed), but is only *now* actually resident. Subsequent invocations for that particular command won't result in such a search, and will use the resident copy (dunno, if this is true if the code isn't sharable, and another copy of the code is already running). There is another command-line option for REZ ... -l, as I recall ... that causes the command(s) to also be loaded *now*. (I haven't used -l yet, but I think that's correct.) So try something like "rez -l glop1 glop2 ...", and see if that doesn't takes care of things. If not, then I must not understand your problem. BTW, you really ought to blow-off all that BCPL junk, and start using the ARP equivalents. Backwardly compatible, smaller, faster, and also provide additional functionality! Strangely enough, the hueristics Jim is using to guess at what "type" of code a command is (for informational purposes only), still think the ARP commands are from BCPL; other assembly language programs get flagged as Lattice 4.0 (as do several programs compiled with Manx ... :-) ). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
mp1u+@andrew.cmu.edu (Michael Portuesi) (04/18/88)
Excerpts from: 16-Apr-88 Re: REZ questions. Kim DeVaughn@amdahl.uts. (2471) > Hmmmmm ... I've been using REZ for awhile, but haven't noticed this since > the commands that I tell REZ to rez are sitting in vd0: (REZ is still > "on trial" with me, so I haven't changed my environment around to take > full advantage of it yet). If you are going to keep the commands in vd0: why bother having REZ around in the first place? I realize you are merely evaulating REZ, but it seems pointless to have two copies of a program around in memory so that you can only execute one of them. If that were the solution I were looking for, I would simply copy a batch of commands to ram:c and say "path add ram:c". > When you issue the command "rez foo" (or "rez -a foo"), REZ only adds the > There is another command-line option for REZ ... -l, as I recall ... that > causes the command(s) to also be loaded *now*. (I haven't used -l yet, but > I think that's correct.) So try something like "rez -l glop1 glop2 ...", > and see if that doesn't takes care of things. If not, then I must not > understand your problem. Using -l was the very first thing I tried. Remember, my goal is to not require the Workbench disk in my only disk drive during normal use. > BTW, you really ought to blow-off all that BCPL junk, and start using > the ARP equivalents. Backwardly compatible, smaller, faster, and also > provide additional functionality! If REZ had worked the way I had expected it to, I would be more than happy to blow off the BCPL junk and go with ARP. But right now the 1.2 Gamma Resident is the only thing that does what I want, and it only works reliably with BCPL programs. Are there any other suggestions? Does anybody know about the other "resident" options (especially the one that's supposed to come with 1.3)? --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"