John_M@spectrix.UUCP (John Macdonald) (12/14/87)
The following request may be for something that is already being done
at Apple. I hope it is.
I would like to see an Init Manager. It should be able to run a
dialogue that I will call the Init Chooser. The Init Chooser would
present a list of available inits on the screen. There would be a
check box beside each init to indicate whether the init is currently
selected. Clicking the box would reverse the state. The position
in the list would specify the order that the inits will be run.
Dragging an init would allow you to change the order. You could
open inits from places other than the system folder. This interface
would be useful in two places (at least).
There would be a cdev using the Init Chooser that would allow you to
choose and order the set of INIT's that are normally run when you
start up. Current usage is to run every init in the system folder
in alphabetical order, which requires renaming and hiding in folders
to control their usage.
In addition, a Init Chooser could be used as a single method of
dynamically modifying the default init list. The current usage is
to have some combination of (shift, caps lock, option, and command)
alter inits. Some inits ignore all such combinations. Some inits
put up a yes/no dialogue box if their special keyset is pressed.
Some inits cancel themselves if their special keyset is pressed.
There is no co-ordination of which ones use shift, which use
command-shift, which use caps lock, etc. You have to look up in the
manual for each init you have and hope that there aren't too many
that overlap too much. Some inits do not affect the screen at all
when they run - you can't tell when one finishes and the next starts.
If two inits both disable themselves if the shift key is pressed,
but you only want to disable one of them, you have to be good at
guessing when to hold the shift key down.
What I would like is for one key combination to cause the Init
Chooser to be run before ANY init is run. It would be used to
specify the entire set of inits (and their order) for this startup.
No guessing, no conflict between which inits you want to disable.
Simple inits (10 lines of code) could be written without worrying
about techniques for disabling, etc. that would be far more work
to write than the actual init itself. (I would expect that this
is a fairly straight-forward addition - after all, currently there
is a piece of code that finds all inits, sorts them into alphabetical
order, and then runs each one in turn. This same code could instead
check for the shift key and then either use the default set or invoke
the Init Chooser to be the temporary set.)
In addition (and now we are getting to an area where I am not so clear
on what is needed), there should be an analysis done on why some inits
must be run before other inits. Whenever a specific cause is found,
there could be some control flags added to inits to show how it uses
objects that are causes of potential conflicts. (I SAID I was vague
on what is needed.) I would guess that in most cases, one init needs
something that is provided, or modified, by another init.
It might be useful to have a control fields in an init that could
specify reuirements of the form:
this init must be run before init FOOBAR
this init must be run after init FOOBAR
this init should not be run unless init FOOBAR is also run
this init generates system resource FOOBAR
this init modifies the appearance of system resource FOOBAR
this init uses system resource FOOBAR
While inits could check for some of these things themselves, they
can't check for inits that run later that modify resources underneath
them. (e.g. an init that checked what type of screen controller was
present to determine how much memory to allocate for graphics operations
would have problems if a later init turned on the 32-bit-plane
4096 x 4096 x 4096 3-D I-Want-It display that was sitting uninitialized
in Nubus slot 7 :-)
It is useful to provide this information. The Init Chooser could
do things like check all required predecessors when you check an init.
It could maintain required ordering as you move inits. (e.g. you move
an init to the head of the list, and the inits which must be run before
it are then moved ahead of it.)
--
--------- .signature eater food ---------
John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
internet:Sorry. We're in range, but we're in no domain.
Disc-claimer: (noun) any hack's source directoryhallett@lear.steinmetz (Jeff A. Hallett) (12/15/87)
In article <338@spectrix.UUCP> jmm@spectrix.UUCP (John Macdonald) writes: >The following request may be for something that is already being done >at Apple. I hope it is. > >I would like to see an Init Manager. It should be able to run a >dialogue that I will call the Init Chooser. [...Various comments about such a Manager...] Raise Shields! Lock Phasers! FIRE! This is exactly what we DO NOT want. It is this "let's install this, and that..." garbage that has made DA's and Fonts such a complete pain and what makes Suitcase so wonderful. INIT's are great in that to activate them, you put them in the System Folder. To deactivate them, you take them out. It is that simple. To do anything else would be a level of abstration and complication where none is needed. This is the way DA's and Fonts should've been in the first place, but Suitcase fixes it. To change the order, change the name; they are executed alphabetically. To paraphrase a quote: "Ineet Managers?? We don't need no steenking Ineet Managers." Cease Fire! Evasive Maneuvers! I apologize if this seems unnecessarily harsh, but it is something that I (and probably quite a few others) feel strongly about. Jeff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The needs of the few outweigh the needs of the many" -- Kirk (STIII) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/15/87)
In article <338@spectrix.UUCP> jmm@spectrix.UUCP (John Macdonald) writes: >I would like to see an Init Manager. It should be able to run a >dialogue that I will call the Init Chooser. > [ much deleted, read it, it is interesting.] I certainly hope Apple does _not_ waste any time writing this. What a horrible idea! 1.) You don't need it to mark an INIT as not to be run. If you don't want an INIT to run the next time you boot, drag it out of the system folder! 2.) You not only don't need it to sequence INITs, but that isn't the right way to solve the problem. The right solution is: Get that buggy software fixed, and you already have a workaround that works while you are waiting. If one INIT must be run before the other, one of the two is buggy. Write a nasty note to the tech support people at each company, and until they fix it, rename one of them (INITs are run in alphabetical order.) 3.) The proposed design doesn't help when you are booting from a disk with a collection of incompatible INITs. You may have trouble booting your machine because of an INIT conflict. An INIT Manager that runs after the system is up won't help here. Most INITs have the feature that if you hold down some combination of the chift, control and option keys while the machine is booting, the INIT will just return without doing anything. These shift-sequences are clearly documented in the manuals. (If you do not have access to the manual, ask yourself "why?". Some people get software from friends and forget that they didn't pay for it. The lack of a manual on your bookshelf when you need it is a good reminder. (Other people have site licenses and site administrators who aren't doing the whole job.)) Now I have shown that an INIT manager is unnecessary because it does nothing that you can't already do. But it is not just unnecessary, it is a positively bad idea. It is a bad idea because it increases the complexity of the user interface. The more things like Font/DA Movers we have, the less that a niave user can just do in the Finder, the more confusing and hard to use the Macintosh becomes. If there already is a good simple way of doing something, it just confuses people to give them another way. The Macintosh achieved its current popularity in large part because of its ease of use. I want the Macintosh to continue to be a success. Let's keep it easy. If the user can do something just be moving around a few files, then let's let him. That way he is using techniques he already knows well, and doesn't have to remember how to use a program he uses rarely (and face it, an INIT Chooser would not get used very often.) --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
chow@batcomputer.tn.cornell.edu (Christopher Chow) (12/15/87)
In article <22163@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <338@spectrix.UUCP> jmm@spectrix.UUCP (John Macdonald) writes: ::I would like to see an Init Manager. It should be able to run a ::dialogue that I will call the Init Chooser. :: [ much deleted, read it, it is interesting.] : :I certainly hope Apple does _not_ waste any time writing this. What a horrible :idea! : :1.) You don't need it to mark an INIT as not to be run. : :If you don't want an INIT to run the next time you boot, drag it out of the :system folder! If you happen to be trying to figure what combinations of inits are crashing your system then dragging things in and out of the system folder is a slow way of doing things. Plus, suppose you're hard disk has a init which causes you Mac to crash on boot. If you had an INIT manager type package then you can simply tell the offending INIT not to load. Currently, you're stuck unless you can boot off another device. : :2.) You not only don't need it to sequence INITs, but that isn't the :right way to solve the problem. The right solution is: Get that buggy :software fixed, and you already have a workaround that works while you :are waiting. Agreed. But in real-life that could be a problem. :3.) The proposed design doesn't help when you are booting from a disk :with a collection of incompatible INITs. : :You may have trouble booting your machine because of an INIT conflict. :An INIT Manager that runs after the system is up won't help here. :Most INITs have the feature that if you hold down some combination of :the chift, control and option keys while the machine is booting, the :INIT will just return without doing anything. These shift-sequences :are clearly documented in the manuals. Yeah, but what happens when you have a series of inits which won't load if the shift key is down and you're only trying to prevent one of them from loading. Do you think you can predict correctly when to hold and release the shift key :-)? :It is a bad idea because it increases the complexity of the user :interface. The more things like Font/DA Movers we have, the less that :a niave user can just do in the Finder, the more confusing and hard to :use the Macintosh becomes. If there already is a good simple way of :doing something, it just confuses people to give them another way. The :Macintosh achieved its current popularity in large part because of its :ease of use. I want the Macintosh to continue to be a success. Let's :keep it easy. If the user can do something just be moving around a few :files, then let's let him. That way he is using techniques he :already knows well, and doesn't have to remember how to use a program he uses Yeah, but short cuts are useful to people who need them. The Mac interface is already populated with various short cuts. People can be free to ignore any short cut they don't want to use. Its this type of minimialistic thinking which lead Apple not to even identify in its docs of the Mac II the "programmer's switch". Of course, I'm biased in this issue, since I suggested something similar about two months ago entitled "Init 31 should be rewritten" :-) Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699, USPS: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
chow@batcomputer.tn.cornell.edu (Christopher Chow) (12/15/87)
In article <8203@steinmetz.steinmetz.UUCP> lear!hallett@steinmetz.UUCP (Jeffrey A. Hallett) writes: :In article <338@spectrix.UUCP: jmm@spectrix.UUCP (John Macdonald) writes: ::I would like to see an Init Manager. It should be able to run a ::dialogue that I will call the Init Chooser. :[...Various comments about such a Manager...] : :This is exactly what we DO NOT want. It is this "let's install this, :and that..." garbage that has made DA's and Fonts such a complete pain :and what makes Suitcase so wonderful. : :INIT's are great in that to activate them, you put them in the System :Folder. To deactivate them, you take them out. It is that simple. :To do anything else would be a level of abstration and complication :where none is needed. This is the way DA's and Fonts should've been :in the first place, but Suitcase fixes it. : Well, you've missed a *big* point. The wonderful thing about Suitecase is that you can: 1. Place resources (fonts, da's, snd's) in different files, i.e., not the system file. 2. You get control over your system, in that you can activate and deactiate fonts, da's, and sounds as you wish by opening and closing files. With inits since the advent of INIT31 you've got (1), but only if you put it in the System Folder, and you don't have (2). Currently, the only way to get control over property (2) is to reboot. Rebooting takes a long time and is nowhere elegant. Or is it that you don't care at all about property (2)? Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699, USPS: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
simon@alberta.UUCP (Simon Tortike) (12/15/87)
I have heard there is a beast that will do part of the proposed Init Manager's
work: something called ASK- another INIT? INITs seem to cause weird things to
happen to Falcon running on a Mac// with the colour monitor and 8-bit
video card, even when in the monochrome mode. The fellow in our local
software shop said they had this program called ASK which would ask one
whether the listed INITs should be installed.
-------------------
W. Simon Tortike
Dept Min, Met & UUCP: {ubc-vision,ihnp4,mnetor}!alberta!simon
Petroleum Engg BITNET: stortike@ualtavm
Univ. of Alberta AGT: (403) 432-3338
Edmonton, AB
Canada T6G 2G6hallett@lear.steinmetz (Jeff A. Hallett) (12/15/87)
In article <3185@batcomputer.tn.cornell.edu> chow@tcgould.tn.cornell.edu (Christopher Chow) writes: >: [My Own Message] >Well, you've missed a *big* point. The wonderful thing about Suitecase is >that you can: > >1. Place resources (fonts, da's, snd's) in different files, i.e., not the > system file. > >2. You get control over your system, in that you can activate and deactiate > fonts, da's, and sounds as you wish by opening and closing files. > >With inits since the advent of INIT31 you've got (1), but only if you put >it in the System Folder, and you don't have (2). Currently, the only way >to get control over property (2) is to reboot. Rebooting takes a long time >and is nowhere elegant. > >Or is it that you don't care at all about property (2)? I don't believe I have missed anything. (2) is basically N/A with respect to INIT's. Define INIT: A routine or property that the user wishes loaded AT BOOT TIME for the duration of his/her session. INITs that are not meant to be active throughout the whole session should be provided with a toggle key stroke. The fact that they do not is no indication that Apple needs to write another inane manager; it is a cue to INIT writers that they need to go the extra yard. If anything, I feel that YOU have missed the point. The whole point of having Suitcase is not to activate or deactivate anything. It is to increase the flexibility of your system by allowing the user to set up "configurations" that can be swapped easily depending on the task to be accomplished. There is no point in "deactivating" a font - there is a point in being able to swap one set of fonts for another. The same holds for DA's. INIT's are not this application specific (or at least, none of the ones I've seen are - SmartQuotes is an exception, but that is run-time toggle-able). Jeffrey A. Hallett (ARPANET: hallett@ge-crd.arpa Software Technology Program UUCP: desdemona!hallett@steinmetz.uucp) General Electric Corporate Research and Development ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The needs of the few outweigh the needs of the many" -- Kirk (STIII) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: I do not guarantee the validity of the content, meaning, or nature of anything in this message as my own sanity may be in doubt. My employer doesn't either and probably won't admit they employ me if called. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
moriarty@tc.fluke.COM (Jeff Meyer) (12/16/87)
Well, guess what? Such a bugger exists (to a point). I downloaded a little
INIT off of a local BBS the other night called " Aask.INIT" -- note the
space and Aa at the beginning, so that it will be executed first at boot-up.
It works in the following manner -- if you boot up with the space bar held
down, a screen showing all the INIT files in your System Folder appears.
You then can (literarly) cross them off, either temporarily (this boot-up
only) or permanently (Aask.INIT changes the INIT's file type from "INIT" to
"xNIT"), and those INITs will not be loaded. And, of course, you can switch
particular INITs back on at this point, too.
It's from those wonderful people over at CE software, and I'll post it to
comp.mac.binaries first chance I get.
"Oh dear... well, if you
don't get her to a very
powerful Shaman right
away -- she'll die."
"We got an Elder God in the
van. Will he do?"
Moriarty, aka Jeff Meyer
INTERNET: moriarty@tc.fluke.COM
Manual UUCP: {uw-beaver, sun, allegra, hplsla, lbl-csam}!fluke!moriarty
CREDO: You gotta be Cruel to be Kind...
<*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>rmh@apple.UUCP (Rick Holzgrafe) (12/17/87)
Writing proper INITs seems to be one of the blacker of the variously-colored
magics needed to program a Mac. (I'm writing my first INIT myself at
the moment - it's coming along, but slowly.)
I agree with Mr. Oster (et al) that an Init Manager is unnecessary. (See
disclaimer below - I don't get to make these decisions for Apple, I'm
just giving you my opinion.) The only real difficulty in using the Finder
as your "Init Manager" is when something bombs so bad you can't boot.
So here's some simple advice from one whose own INIT does this to him
regularly: keep a bootable floppy handy. Put NOTHING on it or in it that
didn't come on the released system disk, and NEVER change its contents.
All it has to do for you is boot, launch the Finder, and let you access
the volume with the bad INITs.
Here at Apple, I have three hard disks and uncountable floppies lying around
my desk in various states of organization. The first time my development
system wouldn't boot, it took me quite a while to locate a floppy that
would. Now that floppy is sacred, and I keep several copies!
==========================================================================
Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh
Communications Software Engineer | AppleLink HOLZGRAFE1 (I don't look often)
Apple Computer, Inc. | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 27-Y | not necessarily represent those of my
Cupertino, CA 95014 | employer, Apple Computer Inc."raylau@dasys1.UUCP (Raymond Lau) (12/17/87)
Maybe we don't need an INIT manager, but one thing that'll help out is some
routine which will put up a box at loading time if a certain key combo is held
down and allow the user to reequest that a certain INIT not be loaded.
This would be great for finding buggy INITs...saves the trouble of breaking
out floppies bec. the INIT crashes when booting from the HD, etc.
Someone mentioned that an INIT manager would be impossible/useless bec. it
would be loaded after INITs... recall that INITs are loaded by Apple's
INIT 31. We as users can assume that Apple's 31 is relatively bug free.
It has also been mentioned that many INITs incl. shift sequences to abort
loading. That's nice, but not all do! And you can't decide which you don't
want loaded as many use the same sequence (shift).
--
Raymond Lau GEnie: RayLau
100-04 70 Ave. CIS: 76174,2617
Forest Hills, NY 11375-5133 Delphi: RaymondLau
United States of America MacNET: RayLau
uucp: raylau@dasys1.UUCP (..{phri,cucard,bc-cis,mstan}!dasys1!raylau})
John_M@spectrix.UUCP (John Macdonald) (12/19/87)
In <338@spectrix.UUCP>, I made a long posting asking for a way of
controlling inits, both the order that they were run, and which
ones would be run at all; with these alternatives being specified
either for permanent effect, or for a single boot only. Judging
from the number and intensity of the responses, this is an important
matter.
A number of responses refer to Aask, an Init which provides much
of this capability, being developed by CE Software, with an early
version already available on various bulletin boards. I will
certainly look into this, but I think that this is something that
is important enough for Apple to do - putting it into the System
itself (a new variant of INIT 31). I will return to this point
later.
It has been pointed out that you can disable INITs by moving them
out of the System folder, and that you can control their order by
renaming them. This is considered to be so simple that providing
any other mechanism makes it difficult for naive users to understand
what is happening. I agree with this only partially. It is very
easy for a naive user to add a new INIT to their system file to
try it out and to remove if he doesn't like it. This simplicity
should not be interfered with. It is not easy for a naive user
to install the latest system/finder/multifinder from Apple, have
it crash on startup, and then figure out which INIT is not compatible
with the new system. It is not easy for a naive user to determine
which INIT is causing a conflict with a new INIT that he is trying
to install. (It is not even very easy for a naive user to determine
what other INITs he has that might be conflicting. He can easily not
notice an init sitting in the middle of a bunch of device drivers.
He can forget that something is an init) It is not easy for some
naive users to rename a file that they didn't create. (They are
justified too, some programs stop working if you rename them.)
There was also some mention of the confusion that might result if
it were possible to have inits that were not in the system folder.
Considering the large number and variety of different files that
MUST be in the system folder, I don't fully agree. This is one
of the things that I especially like about Suitcase - it adds files
to the system usage class that can be collected in a folder under
the system folder. (I would like to see blessed sub folders, so
that you can have device drivers in one, inits in another, DA's
and their control files in another, etc.) (Suitcase also brings
back the day where a "usable" system file could be copied to a
floppy. If you haven't got Suitcase, look into it. disclaimer:
I just a happy customer.)
If trying to determine what init causes a crash means that you
must reboot from floppy, move various inits in/out of your system
folder and retry and see if it crashes again, then it will take
a very long time (especially if you have many INITs).
Forexample, if I know that one of ten INITs causes a problem, I
would toss them all into a sub-folder, pull them back out two
or three at a time and reboot. If it crashes, I reboot from
floppy and toss two of them back. If it succeeds, I pull two
or three more. If the proposed init manager existed, I would
simply reboot once, check all the INITs for loading, and check
the single-step box. The manager would run the inits, one at a
time, telling me which one it was about to run as it went.
When it crashed, I would know which one (probably) caused the
trouble - next time I would uncheck that candidate and try to
load it all. Thus, in two passes, I would find and eliminate
a single INIT that crashed with that system. (Of course, it
would take longer to determine one that crashed after it started
or a combination that crashed together, but this type of problem
would still be easier to resolve with an init manager control.)
Note that a naive user would probably be able to use the second
method as efficiently as an expert user, it is simple. However,
with the current setup, he would likely run add them one at a time
and require more reboots, or even worse, remove them one at a time,
and have more crash and reboot from floppy sequences, taking much
longer. A naive user is also less likely than an expert developer
type user to be able to guess which init is the most likely to
have caused the problem, or which had definitely started running
before the crash.
To not reduce the current simplicity, I had expected (but not
stated in my posting) that new inits could still be added by
putting them into the system folder - I hadn't determined any
specific rule about how they would fit into the ordering.
I don't trust that all of the current and future init writers
will provide a mechanism that will allow boot-time choice of
inits - they already don't. (If I depress shift-whatever and boot,
I get some inits that don't install themselves, some that put
up a box asking if I want them or not, and some that install
themselves regardless. I might also get finder instead of multi-
finder, and some other Apple internal devices might change their
behaviour.) An Apple-provided machanism would ensure that init
writers don't have to do the 'right' thing - a 'righter' mechanism
than they could possibly provide would already be there.
A number of followups made the assuption (or outright statement)
that inits that must be run in a specific order are "buggy". I
think that this assumption may be already wrong, and is certainly
likely to be wrong in the future. The Macintosh has already shown
that it is dangerous for a program to make assumptions about the
environment it is running in. What is a fixed piece of hardware
on todays Mac may turn out to be one of the possible pieces of
hardware available on next years Mac, and may be dynamically
simulated to any of them (without rebooting after a switch) on
some other Mac. (The specific example I am thinking of here is
screen size - we now have large, small and simulated (Stepping
Out) screens (I don't know whether Stepping Out allows the screen
size to change dynamically, but certainly the monitor cdev on a
Mac II allows the "screen" to change shape without rebooting.))
One of the means available for simulated hardware changes is inits.
(There is a shareware or public domain init called Big Screen which
simulates a large screen. I don't know if Stepping Out is also
an init.) This same principle of not making assumptions about
the underlying universe lead to the addition of the SysEnvirons
trap. Anything that might change in the future should be determined
through software, even if it is fixed on all current hardware.
If an init provides a new or dramatically changed appearance to
the "machine" it might affect the way other inits should operate.
Imagine an init which creates a "spooling" process which watches
all serial ports for some sort of request (perhaps the Mac is
being used to provide LaserWriter access to a number of lesser
machines). It would determine from the system how many serial
ports there were on the system, so that it doesn't just blindly
assume that will always be limited to two. Now imagine a second
init, which interacts with the Ethernet board. It sets up a process
to handle requests to act as if it were a serial port. It even tells
the system that it is acting like a serial port and the system adds
it to its list. Unless it runs first, the "spooler" init will
not notice it, and not be able to watch this "serial port". I
don't think that there is anything that either init writer could
do to make them work together if the inits are run out of sequence
(at least not if the init writers did not know of each others work
while they were writing their init). While this specific example is
flawed (I expect that these things would be better off as device
drivers instead of inits, although they still may have problems
getting amicably started up), I think that the principle holds.
I am sure that there could be inits that could benefit from each
other if run in the proper order, and be perfectly useful on their
own, but which could only work together sensibly if run in a certain
order. This is what I hoped would be addressed with the extensions
- some way hohaving init that will work into the future with other
inits that change the basis of the machine out from under them. Given
some method of specifying what system resources an init asked about and
used, and what resources it modified the appearance of, the computer
could do a lot of the work of ordering inits automatically. That would
certainly be the least taxing demand on the naive user of all!
One final comment. One response said:
::Most INITs have the feature that if you hold down some combination of
::the chift, control and option keys while the machine is booting, the
::INIT will just return without doing anything. These shift-sequences
::are clearly documented in the manuals.
The "shift key disables 5 inits I want as well as the one I don't"
and the "the bad init doesn't allow for disabling" problems I mentioned
above make the manual-documented sequence not particularily useful.
In addition, I have started to regard looking something up in the manual
as a subtle hint that the user-interface may be lacking. Having to look
something up in the manual of every init you have is a strong signal that
the user-interface is lacking. (The fact that looking it up doesn't help
even more so.)
I have been lead more and more toward this opinion by the Macintosh.
(Before the Mac, I memorized manuals without complaint; I was not an
easy convert to this contrary view. I strongly believed that any
serious program obviously would require a manual, and would require
studying the manual before one could become proficient at using such
a program.)
As an example, I tell most of our users that they should not use Microsoft
Word, but should use MacWrite. The learning required for Word is too great,
most of our users do not do enough word processing to EVER become proficient
with Word, and its non-standard interface is too much of a barrier for casual
use. We do have some Word experts, anyone who has a need for the advanced
capabilities of Word can still get them - by going to an expert. With
MacWrite (soon to be WriteNow, I expect), they are already expert enough
to do most common word processing tasks without assistance.
I apologize for the length of this posting. I hope I am explaining more
than I am burying with the length.
--
John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
UUCP: {utecfb,ontmoh,spectrix} !bml!jmm
(formerly of Spectrix, still using their computer for news)
Now working for Brown Manufacturing, Ltd. (soon to have their own feed)John_M@spectrix.UUCP (John Macdonald) (12/19/87)
In <338@spectrix.UUCP>, I made a long posting asking for a way of
controlling inits, both the order that they were run, and which
ones would be run at all; with these alternatives being specified
either for permanent effect, or for a single boot only. Judging
from the number and intensity of the responses, this is an important
matter.
A number of responses refer to Aask, an Init which provides much
of this capability, being developed by CE Software, with an early
version already available on various bulletin boards. I will
certainly look into this, but I think that this is something that
is important enough for Apple to do - putting it into the System
itself (a new variant of INIT 31). I will return to this point
later.
It has been pointed out that you can disable INITs by moving them
out of the System folder, and that you can control their order by
renaming them. This is considered to be so simple that providing
any other mechanism makes it difficult for naive users to understand
what is happening. I agree with this only partially. It is very
easy for a naive user to add a new INIT to their system file to
try it out and to remove if he doesn't like it. This simplicity
should not be interfered with. It is not easy for a naive user
to install the latest system/finder/multifinder from Apple, have
it crash on startup, and then figure out which INIT is not compatible
with the new system. It is not easy for a naive user to determine
which INIT is causing a conflict with a new INIT that he is trying
to install. (It is not even very easy for a naive user to determine
what other INITs he has that might be conflicting. He can easily not
notice an init sitting in the middle of a bunch of device drivers.
He can forget that something is an init) It is not easy for some
naive users to rename a file that they didn't create. (They are
justified too, some programs stop working if you rename them.)
There was also some mention of the confusion that might result if
it were possible to have inits that were not in the system folder.
Considering the large number and variety of different files that
MUST be in the system folder, I don't fully agree. This is one
of the things that I especially like about Suitcase - it adds files
to the system usage class that can be collected in a folder under
the system folder. (I would like to see blessed sub folders, so
that you can have device drivers in one, inits in another, DA's
and their control files in another, etc.) (Suitcase also brings
back the day where a "usable" system file could be copied to a
floppy. If you haven't got Suitcase, look into it. disclaimer:
I just a happy customer.)
If trying to determine what init causes a crash means that you
must reboot from floppy, move various inits in/out of your system
folder and retry and see if it crashes again, then it will take
a very long time (especially if you have many INITs).
Forexample, if I know that one of ten INITs causes a problem, I
would toss them all into a sub-folder, pull them back out two
or three at a time and reboot. If it crashes, I reboot from
floppy and toss two of them back. If it succeeds, I pull two
or three more. If the proposed init manager existed, I would
simply reboot once, check all the INITs for loading, and check
the single-step box. The manager would run the inits, one at a
time, telling me which one it was about to run as it went.
When it crashed, I would know which one (probably) caused the
trouble - next time I would uncheck that candidate and try to
load it all. Thus, in two passes, I would find and eliminate
a single INIT that crashed with that system. (Of course, it
would take longer to determine one that crashed after it started
or a combination that crashed together, but this type of problem
would still be easier to resolve with an init manager control.)
Note that a naive user would probably be able to use the second
method as efficiently as an expert user, it is simple. However,
with the current setup, he would likely run add them one at a time
and require more reboots, or even worse, remove them one at a time,
and have more crash and reboot from floppy sequences, taking much
longer. A naive user is also less likely than an expert developer
type user to be able to guess which init is the most likely to
have caused the problem, or which had definitely started running
before the crash.
To not reduce the current simplicity, I had expected (but not
stated in my posting) that new inits could still be added by
putting them into the system folder - I hadn't determined any
specific rule about how they would fit into the ordering.
I don't trust that all of the current and future init writers
will provide a mechanism that will allow boot-time choice of
inits - they already don't. (If I depress shift-whatever and boot,
I get some inits that don't install themselves, some that put
up a box asking if I want them or not, and some that install
themselves regardless. I might also get finder instead of multi-
finder, and some other Apple internal devices might change their
behaviour.) An Apple-provided machanism would ensure that init
writers don't have to do the 'right' thing - a 'righter' mechanism
than they could possibly provide would already be there.
A number of followups made the assuption (or outright statement)
that inits that must be run in a specific order are "buggy". I
think that this assumption may be already wrong, and is certainly
likely to be wrong in the future. The Macintosh has already shown
that it is dangerous for a program to make assumptions about the
environment it is running in. What is a fixed piece of hardware
on todays Mac may turn out to be one of the possible pieces of
hardware available on next years Mac, and may be dynamically
simulated to any of them (without rebooting after a switch) on
some other Mac. (The specific example I am thinking of here is
screen size - we now have large, small and simulated (Stepping
Out) screens (I don't know whether Stepping Out allows the screen
size to change dynamically, but certainly the monitor cdev on a
Mac II allows the "screen" to change shape without rebooting.))
One of the means available for simulated hardware changes is inits.
(There is a shareware or public domain init called Big Screen which
simulates a large screen. I don't know if Stepping Out is also
an init.) This same principle of not making assumptions about
the underlying universe lead to the addition of the SysEnvirons
trap. Anything that might change in the future should be determined
through software, even if it is fixed on all current hardware.
If an init provides a new or dramatically changed appearance to
the "machine" it might affect the way other inits should operate.
Imagine an init which creates a "spooling" process which watches
all serial ports for some sort of request (perhaps the Mac is
being used to provide LaserWriter access to a number of lesser
machines). It would determine from the system how many serial
ports there were on the system, so that it doesn't just blindly
assume that will always be limited to two. Now imagine a second
init, which interacts with the Ethernet board. It sets up a process
to handle requests to act as if it were a serial port. It even tells
the system that it is acting like a serial port and the system adds
it to its list. Unless it runs first, the "spooler" init will
not notice it, and not be able to watch this "serial port". I
don't think that there is anything that either init writer could
do to make them work together if the inits are run out of sequence
(at least not if the init writers did not know of each others work
while they were writing their init). While this specific example is
flawed (I expect that these things would be better off as device
drivers instead of inits, although they still may have problems
getting amicably started up), I think that the principle holds.
I am sure that there could be inits that could benefit from each
other if run in the proper order, and be perfectly useful on their
own, but which could only work together sensibly if run in a certain
order. This is what I hoped would be addressed with the extensions
- some way of having init that will work into the future with other
inits that change the basis of the machine out from under them. Given
some method of specifying what system resources an init asked about and
used, and what resources it modified the appearance of, the computer
could do a lot of the work of ordering inits automatically. That would
certainly be the least taxing demand on the naive user of all!
One final comment. One response said:
::Most INITs have the feature that if you hold down some combination of
::the chift, control and option keys while the machine is booting, the
::INIT will just return without doing anything. These shift-sequences
::are clearly documented in the manuals.
The "shift key disables 5 inits I want as well as the one I don't"
and the "the bad init doesn't allow for disabling" problems I mentioned
above make the manual-documented sequence not particularily useful.
In addition, I have started to regard looking something up in the manual
as a subtle hint that the user-interface may be lacking. Having to look
something up in the manual of every init you have is a strong signal that
the user-interface is lacking. (The fact that looking it up doesn't help
even more so.)
I have been lead more and more toward this opinion by the Macintosh.
(Before the Mac, I memorized manuals without complaint; I was not an
easy convert to this contrary view. I strongly believed that any
serious program obviously would require a manual, and would require
studying the manual before one could become proficient at using such
a program.)
As an example, I tell most of our users that they should not use Microsoft
Word, but should use MacWrite. The learning required for Word is too great,
most of our users do not do enough word processing to EVER become proficient
with Word, and its non-standard interface is too much of a barrier for casual
use. We do have some Word experts, anyone who has a need for the advanced
capabilities of Word can still get them - by going to an expert. With
MacWrite (soon to be WriteNow, I expect), they are already expert enough
to do most common word processing tasks without assistance.
I apologize for the length of this posting. I hope I am explaining more
than I am burying with the length.
--
John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
UUCP: {utecfb,ontmoh,spectrix} !bml!jmm
(formerly of Spectrix, still using their computer for news)
Now working for Brown Manufacturing, Ltd. (soon to have their own feed)