sirius@recondo.UUCP (Mike Stilson) (06/17/89)
From: shadow@pawl.rpi.edu (Deven T. Corzine) >In article <1380@rivm05.UUCP> ccemdd@rivm.UUCP (Marco Dedecker) writes: >>In article <0903.AA0903@recondo>, sirius@recondo.UUCP (Mike Stilson) writes: >Check in the 1.3 Includes & Autodocs RKM under SumKickData() and a >couple others in the Autodocs for the exec.library. It gives enough >information that you should be able to create resident modules. (As >opposed to using the *Capture vectors) It gave most of the information, but there were a couple things I was doing wrong (based on assumptions) because there were no specifics mentioned. >>Try checking out the program called 'guardian', or the bootblock from >>the system Z viruskiller, they stay resident using the KickTagPtr. > >(i.e. resident modules) Kinda sorry when you have to look at viri to see how to do something.. isn't it? I finally found some (albeit, C ) source showing it.. a program called 'AddMemForever' that came through the net a while ago... >>Using the KickTagPtr is probably what you want for your utility. > >It's cleaner than the *Capture vectors, and multiple applications can >use it in peaceful coexistence... That's the main reason I want to use it. >>About the WarmCapture, it is never called !! (probably reserved for >>use in future releases, or whatever) > >This is strange, I have heard elsewhere also that WarmCapture is never >called. VERY strange, but true. > Yet, the Exec code *does* have a call for the WarmCapture >vector. Immediately after CoolCapture is called, InitCode() is called >to initialize all the resident modules, immediately followed by a >check (for non-zero, as with the other *Capture vectors) and a call >for WarmCapture. What follows is clearing all registers and an >endless loop, calling Debug(). (and getting ExecBase again) So, the >code IS there. The bootstrap resident structure has a pri of -60.. it's supposed to be the last one executed. It terminates its running with a JMP (A5). It never returns, so.. anything that 'should' occur after that executes, won't. WarmCapture is handled immediately after the call to InitCode() (it's the next instruction, actually..) But since the jump to the boot routine never returns, it never gets to that section of code... doesn't exactly make sense to me, but that's the way it is. My guess is that AmigaDOS is stopping WarmCapture from being run. I see several possibilitie. One, when the resident module for DOS executes, it does not return. This seems unlikely, as it would keep subsequent resident modules in the chain from initializing. However, AmigaDOS harbors some serious brain-damage, so I wouldn't put it past it. Two, AmigaDOS changes the WarmCapture vector to point to a RemTask(0L) call. (The initial startup code becomes task "exec.library" when multitasking is initialized.) This seems most likely, as it will prevent Debug() from running next, dumping the machine into ROM-Wack. Three, AmigaDOS could RemTask(FindTask("exec.library")), but that seems cumbersome and rather dangerous. So, odds are that the reason WarmCapture is never call is that AmigaDOS preempts it to keep the machine from falling into ROM-Wack. This is, as I said, something of a guess, extrapolated from what knowledge and information I DO have onhand, but it is an educated guess. Any CATS-type folks care to comment? (or confirm or deny?) >This is all I can do for you, since I haven't had time to check this >place out myself. That's about all I can do. Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K. -- Mike 'Sirius' Stilson - Sirius Software UUCP: sirius@recondo.UUCP BITNET: sirius%recondo@uunet.UU.NET MA-BELL: (412) 793-1242 or (412) 793-5765 USNail: 1312 Universal Rd. Penn Hills, PA 15235-3936
jesup@cbmvax.UUCP (Randell Jesup) (06/29/89)
In article <0935.AA0935@recondo> sirius@recondo.UUCP (Mike Stilson) writes: >>>About the WarmCapture, it is never called !! (probably reserved for >>>use in future releases, or whatever) ... >My guess is that AmigaDOS is stopping WarmCapture from being run. I >see several possibilitie. One, when the resident module for DOS >executes, it does not return. This seems unlikely, as it would keep >subsequent resident modules in the chain from initializing. However, >AmigaDOS harbors some serious brain-damage, so I wouldn't put it past >it. [ a couple other ideas] Well, AmigaDOS does stop warmcapture from being called, by starting the initial CLI process, then doing a RemTask(0) from the DOS resident init code (running on exec's initial task). Don't count on this, folks: it may change in 1.4. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
shadow@pawl.rpi.edu (Deven T. Corzine) (06/29/89)
In article <7165@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <0935.AA0935@recondo> sirius@recondo.UUCP (Mike Stilson) writes: >>My guess is that AmigaDOS is stopping WarmCapture from being run. I >>see several possibilitie. One, when the resident module for DOS >>executes, it does not return. This seems unlikely, as it would keep >>subsequent resident modules in the chain from initializing. >>However, AmigaDOS harbors some serious brain-damage, so I wouldn't >>put it past it. [I was the actual author of the above paragraph; it had been misquoted] > Well, AmigaDOS does stop warmcapture from being called, by >starting the initial CLI process, then doing a RemTask(0) from the >DOS resident init code (running on exec's initial task). Now, doesn't this seem a bit nasty to you? What if, somehow, AmigaDOS is NOT the last module initialized? Is there any way to be sure of this? Hmm... > Don't count on this, folks: it may change in 1.4. That's fine... If you're going to stop WarmCapture from running anyhow, forcing WarmCapture to point to a call to RemTask(0L) would be a cleaner method, would it not? Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.