leipold@eplrx7.uucp (Walt Leipold) (01/17/90)
We've developed a product called the 'MacbRISC', a Unix computer on a NuBus card (features: 40/50/60-MHz Clipper RISC processor, 8/16/32 Mbytes RAM, built-in Ethernet, 2 SCSI controllers, 2 serial ports, MMU-controlled mapping of RAM to NuBus, etc). Although the MacbRISC is a completely independent co-computer, it *does* share the Mac's power supply. Unfortunately, the Unix filesystem doesn't like to be unexpectedly powered down, so we want to discourage the MacbRISC user from shutting down his Mac (and thus his MacbRISC board) while the MacbRISC's Unix is running. To do that, I've written an INIT to install a shutdown task which checks on the Unix status; if Unix is up, a dialog box will ask the user if he'd rather do a Restart instead of a Shutdown. The problem: Since my shutdown task must use dialogs and other resources from its INIT file in the System folder, I've installed it to run before sdUnMount time. However, IM V doesn't tell me how a shutdown task can determine whether it was invoked via a "Shutdown" or a "Restart" from Finder/Multifinder (right now, the stupid dialog appears for every Restart as well as every Shutdown). I suppose I can patch the Shutdown trap and work my magic before any Shutdown tasks are run, but the mere existence of the Shutdown Manager makes me reluctant to reinvent the (possibly incompatible) wheel. So, does anybody out there have any idea how my shutdown task can determine what kind of shutdown/restart it was called during? ----- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) ---- -- The UUCP Mailer
urlichs@smurf.ira.uka.de (01/18/90)
In comp.sys.mac.programmer leipold@eplrx7.UUCP (Walt Leipold) writes:
<
< The problem: Since my shutdown task must use dialogs and other resources
< from its INIT file in the System folder, I've installed it to run before
< sdUnMount time. However, IM V doesn't tell me how a shutdown task can
< determine whether it was invoked via a "Shutdown" or a "Restart" from
< Finder/Multifinder (right now, the stupid dialog appears for every Restart
< as well as every Shutdown).
<
Install something with sdOnUnmount to load the resources, stash their handles
somewhere, and another procedure with sdOnPowerOff to execute the code.
However, see below...
< I suppose I can patch the Shutdown trap and work my magic before any
< Shutdown tasks are run, but the mere existence of the Shutdown Manager
< makes me reluctant to reinvent the (possibly incompatible) wheel. So,
< does anybody out there have any idea how my shutdown task can determine
< what kind of shutdown/restart it was called during?
<
Patch Shutdown.
I do it. Apple does it (Apple Internet Router). So why shouldn't you?
If you want to offer the user any "Continue" button, you _have_ to patch
Shutdown. (Continue with the trap by jumping to the original address, or just
return without calling the original trap to cancel. Since you might not be the
only guy who got that idea, do the actual shutting down from within a normally
installed routine.)
Programs that don't patch _Shutdown and then expect to be able to continue
anyway by calling _ExitToShell are creating big problems. (Example: TOPS.)
Related question: IM V says that first the drivers are closed (more exactly,
they are send a GoodByeKiss or whatever), then volumes are unmounted. Since
volumes are accessed through drivers, this does strike me as slightly
illogical... Anyone know more about this?
--
Matthias Urlichschaffee@reed.UUCP (Alex Chaffee) (01/20/90)
In article <1409@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs) writes: <In comp.sys.mac.programmer leipold@eplrx7.UUCP (Walt Leipold) writes: << However, IM V doesn't tell me how a shutdown task can << determine whether it was invoked via a "Shutdown" or a "Restart" from <>< Finder/Multifinder (right now, the stupid dialog appears for every Restart <>< as well as every Shutdown). <>< <>Install something with sdOnUnmount to load the resources, stash their handles ,>somewhere, and another procedure with sdOnPowerOff to execute the code. <>However, see below... <> <>< I suppose I can patch the Shutdown trap and work my magic before any <>< Shutdown tasks are run, but the mere existence of the Shutdown Manager <>< makes me reluctant to reinvent the (possibly incompatible) wheel. So, <>< does anybody out there have any idea how my shutdown task can determine <>< what kind of shutdown/restart it was called during? <>< <>Patch Shutdown. I'm not intimately familiar with the Shutdown manager, but I have patched a few traps in my time. I offer the following suggestion: Patch Shutdown, but since you're worried about compatibility, just have that patch set a flag somewhere that your real shutdown routine can see it. Then proceed legally and cleanly to _Shutdown... Presumably, your sdUnmount (or sdPowerOff) routine will get called at the right time, look at the flag, and if it's been set, put up the dialog box. Does anyone see a problem with this? Or is it redundant? "So we stole a painting. So we turned a policeman into a toilet. Worse things happen every day in El Salvador." - Grant Morrison, Doom Patrol #29 -- Alex Chaffee chaffee@reed.UUCP Reed College, Portland OR 97202 ____________________
d88-jwa@nada.kth.se (Jon Watte) (01/23/90)
In article <13905@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >I'm not intimately familiar with the Shutdown manager, but I have patched a >few traps in my time. I offer the following suggestion: Patch Shutdown, >but since you're worried about compatibility, just have that patch set a >flag somewhere that your real shutdown routine can see it. Then proceed >legally and cleanly to _Shutdown... Presumably, your sdUnmount (or >sdPowerOff) routine will get called at the right time, look at the flag, and >if it's been set, put up the dialog box. Does anyone see a problem with >this? Or is it redundant? Well, the problem was that if your shutdown manager task puts up the dialog, there's no way to get OUT of the shutdown sequence... Presumably, though, it's safe to tail-patch _Shutdown, since I have very grave doubts any buggy core routines will call this, and thus Apple patch it to fix a bug :-) Patch _Shutdown Put up your dialog If cancel - well, return (with an error ? or ExitToShell() ?) If not - well, JMP away to the address you got when you patched Or is there still a better way ? On the subject of trap patching; I'd like to write an INIT and FKEY combination that lets me switch keyboard layout without going into the chooser (or is there one already ?) I thought about my INIT patching _KeyTrans, and changing the pointer on the stack to a KCHR I've loaded into memory. Anyone see a problem with this, except that I'll have to lock the KCHR down constantly (since _KeyTrans is presumably called at interrupt time) ? h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
moyman@ecn.purdue.edu (01/15/91)
Someone out there must have done this before! I have an INIT that installs code
to be run at shutdown. The question is how do I get the resources it needs to
hand around until then??
Interesting observation: All of the constants (#define's ...their values) from
the INIT remain intact while the globals from the INIT are accessable but their
values are scrod!! This doesn't make sense to my feeble mind.
Lets take the example of an 'STR ' resource named "String #1" (with the "System
Heap" bit set...nothing else).
I could do:
strHdl = GetNamedResource('STR ', "\pString #1");
DetachResource(strHdl);
HLock(strHdl);
Doing a "GetString" at shutdown finds nothing... The value of strHdl is scrod
at shutdown so how can I (or the GetString call) do a "LoadResource" to get it
back in memory?? To tell you the truth I am not real sure what I am trying to
do... Keep the resource in memory till shutdown or just keep the resource in
the system heap till shutdown...or what. Am I the only one who has tried to do
this?? or is it just not posible to do!! (which I can't believe)
Mike Moya
Engineering Computer Network
Purdue University