Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!tut.cis.ohio-state.edu!bgsuvax!denbeste
From: denbeste@bgsuvax.UUCP (William C. DenBesten)
Newsgroups: comp.sys.mac
Subject: Re: INIT User guidlines proposal
Message-ID: <5092@bgsuvax.UUCP>
Date: 31 Oct 89 15:17:14 GMT
References: <8910310233.AA09123@decwrl.dec.com>
Organization: Bowling Green State University B.G., Oh.
Lines: 47

From article <8910310233.AA09123@decwrl.dec.com>, by phil@vaxphw.dec.com (At 'MAC'simum efficiency!):
> It is very difficult 
> to turn off selectively some  INITS as each requires a different key to cause
> it not to load.  An INIT also doesn't give a user any 'warning' as to when to
> press the 'no load' key.

> An INIT, when it begins execution, should display a startup ICON using SHOWINIT
> or SHOWCINIT code (or any other compatible code segment) that has been floating 
> around the networks for a long time.

I think that the INIT 31 code should be modified to do this for us.
After all, the code would then only appear in one place and it would
be impossible to create an init that the user didn't know about, which
is a good thing in the light of viruses.  It should also patch out
InitGraf so that unfriendly inits don't erase other icons.

  [for each init...]
> It should display a 'successful' or  'question mark' ICON on startup.
> allow the SHIFT key to act as a 'slow motion'  startup, 
> 'pretzel' key is [...] show a 'NO LOAD/UNSUCCESSFUL'
> The OPTION key is used by INITs that require configuration.

Holding down various keys at just the appropiate time is a clumsy and
non-intuitive approach to handling inits.  I would like it better if
INIT 31 had a mechanism for selectively disabling inits and displaying
an x-ed out icon for the init.  Being able to communicate with the
init and tell it to go into a verbose mode would also be nice.  Then
we would need only one secret key to convice INIT 31 to ask us what we
want to do.  In this context, cdevs and rdevs should also count as inits.

> If all INITs followed these guidelines, eventually a user could very easily
> turn  INITs on or off as well as see which INITs loaded or didn't load.

I believe that convincing every INIT writer to follow a set of
guidelines would be difficult to impossible.  Fixing INIT 31 would be
a much simpler approach.

Actually, what I envision is mostly handled with 3rd party init
managers.  The problem is that INIT developers have to build in their
own tricks because they can not count on everyone having an init
manager.  Perhaps the time is right for apple to incorporate one into
the system.

Note: I have heavily chopped the parent article.  I apologize to the
author if I am now quoting out of context.
-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet