🚀 go-pugleaf

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