kim@amdahl.uts.amdahl.com (Kim DeVaughn) (06/27/88)
In article <6585@jhunix.HCF.JHU.EDU>, ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) writes: > In article <8eXJ77752K1010c6iYg@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > >In article <6558@jhunix.HCF.JHU.EDU>, ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) writes: > :: I have experienced this problem too, but ONLY after I added > :: DMouse to my startup-sequence. I had assumed that DMouse is looking > :: for the Workbench disk, not ConMan. The problem does NOT occur if > :: I use PopCLI instead of DMouse. > : > :I would bet that you are using the "from" option on the newcli command > :with DMouse to startup something (shell, or whatever). > > Yes, I am using "from". HOWEVER, all of my system directories > are assigned to my hard drive, including "S:". My workbench disk > still gets a disk hit! Doesn't matter. I have *all* my system assigns to directories in vd0:, and had the same problem. Putting a "cd" (to what I consider my "home" dir in vd0:, as Matt suggested) cured the problem. As I understand it, what is happening is that when the program you're starting up in your "from" file tries to get a lock on it's initial current dir, it's getting a NULL. This means "the boot device" to some component of AmigaDOS, and since that currently means "df0:", it puts up a requester for that device. Note that the request can be satisfied by putting/having *any* formatted disk in df0:, including a blank one. Also, if you click on "cancel" a time or two, the requester will go away, and everything will proceed normally. I dunno whose "anomaly" this is, but I think it's really the fault of the compiler startup code (could be mistaken here), as it does not happen with PopCli-II, which was released using one of the older versions of Lattice. It does happen with DMouse (Manx v3.6), and something quite similar (if not exactly the same) happens with PopCli-III (newer version of Lattice). This was the reason I went back to the older PopCli-II, after all attempts to eliminate it failed with PopCli-III (though I didn't try the "cd" trick on it back then). A final note. PopCli-II initiated CLI's inhereted the path that existed when they were started. DMouse initiated CLI's do not, so you'll need to have a path command in your "from" file following the "cd" command to emulate what you got for free with PopCli. Seems like a step backwards to me (sigh). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/30/88)
>I'm curious as to why Matt chose not to use a CLI environment for >launching the command, as it would allow for inheritance of directory, >paths, stacksize, etc. Matt? > > -Bill Hawes Ahhh... Several reasons, the least of which is the incredible waste of memory having the CLI structure, stack, associated file locks, etc... But mainly, since there are a limited number of CLI's, I don't want drivers, handlers, and other non-interactive programs wasting them. -Matt
hawes@dino.ulowell.edu (Bill Hawes) (07/07/88)
I'm certainly in favor of minimizing the amount of memory used by software, one of the main reasons I choose to code in assembly language. On the other hand, since DMouse potentially replaces several other background-type goodies, Matt has already saved memory by combining the functionality. But if people are going to have to use PopCLI II to get the search path, wouldn't it be better to use a CLI for DMouse? The limit of 20 CLI's doesn't seem too severe -- the only time I've hit it is when purposely testing something for that failure mode, or when debugging a program that keeps hanging, so that it's easier to keep grabbing CLI's (using PopCLI II) rather than rebooting. -Bill