Path: utzoo!yunexus!unicus!yunexus!spectrix!John_M From: John_M@spectrix.UUCP (John Macdonald) Newsgroups: comp.sys.mac Subject: Re: Init Manager, please Summary: init ordering requirements are not neccessarily bugs Message-ID:Date: 19 Dec 87 06:08:16 GMT Article-I.D.: spectrix.I46 Posted: Sat Dec 19 01:08:16 1987 References: <338@spectrix.UUCP> <3184@batcomputer.tn.cornell.edu> <22163@ucbvax.BERKELEY.EDU> <977@pembina.UUCP> <8216@steinmetz.steinmetz.UUCP> <8203@steinmetz.steinmetz.UUCP> <3185@batcomputer.tn.cornell.edu> <7028@apple.UUCP> <2250@dasys1.UUCP> <2491@fluke.COM> Reply-To: jmm@spectrix.UUCP (John Macdonald) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 185 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)