Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ucla-cs!ucla-se!watson!weiss From: weiss@watson.seas.ucla.edu (Michael Weiss) Newsgroups: comp.sys.mac.system Subject: Re: New replacement for INITs Keywords: INIT extensions System 7 Message-ID: <2733@lee.SEAS.UCLA.EDU> Date: 12 May 91 08:22:56 GMT References: <2729@lee.SEAS.UCLA.EDU> <1991May12.032859.8612@swbatl.sbc.com> Sender: news@SEAS.UCLA.EDU Distribution: comp Organization: SEASnet, University of California, Los Angeles Lines: 73 In article <1991May12.032859.8612@swbatl.sbc.com> george@swbatl.sbc.com (George Nincehelser 5-6544) writes: >I like things the way they are for the most part. I would hate to have all >those little programs running around...I prefer that they hide in the system >as I generally consider them to be system level functions. SuperClock would be a system level function, I agree, but Bad Disk? That's really a program all to itself that would call upon the FinderEvent of a failed disk operation (there IS one of those, isn't there???). >For example, several people seem to be advocates for screen-blanking apps >instead of system extensions. Here are the problems I have with that: > >1) Installation: Startup apps take more user effort to install than > extensions. (i.e. You have to know about the startup > sub-folder in the system folder) And with System 6, you had to know to put the INITs in the System Folder. In any case, you only need to drag it into the folder and restart. One interesting thought, though, is that we will need a startup application picker, like INITPicker (maybe INITPicker 3.1 can add this feature), so as to be able to turn the auto startup of these programs on and off at will. >2) Control: It makes sense to have a screen-blanker control in the control > panel. An app could have some trouble doing this...it could be > done, I'm sure, but I bet it would complicate installation. Ahh, but there IS no control panel per se anymore. It's an...APPLICATION! OTOH, if it were its own self-contained program, it would have its own pulldown menus, and so would actually be EASIER to modify. >3) Other Naughty Apps: What happens when those ill-programmed apps that are > still around refuse to give time to background processes? If we > had a pre-emptive OS, I'd feel differently. I think we're gonna see those programs disappear VERY soon, since a big part of the IAC in System 7 is gonna need "sharing" programs. >4) Why?: I feel the extension conflict issue is often blown out of proportion. > I myself have run into very few conflicts, and I usually run between > 10 and 20 at a time. Why? I've got two reasons. First, while the extension conflicts are not all THAT common, I've run across several (I have tried nearly every PD/Shareware INIT in existance), and this would cut down severely the number of such conflicts. In my eye, even ONE is too many, and there should be no reason for ANY application conflicts, as they won't step on each other's toes. My second reason is that it makes it much easier to have the feature only when you want it. Say, for example, that the only place you ever use QuicKeys is in MSWord (bad example, but it's 1am...what do you expect?). Before going into MSWord, you could start up QuicKeys, and then after leaving MSWord (to free up memory), you quit QuicKeys. You couldn't do something like that in System 6 without restarting the machine. As another example, if you know that one of these little programs actually DOES conflict with an application, you could quickly and easily turn it off before starting the program, and then restarting it after leaving the offended application. Furthermore, an extension could be written to automatically startup one of these little programs when you start a particular application, and quit it when you quit the application. Or, the reverse could be done. I see much more flexibility, if nothing else. >I understand why apps could be nice, but I (usually a user) like things just >the way they are. Why start botching things up just because some programmer >types think their way is much better? Would it really benefit the average >user? Well, you see the above scenarios. What do YOU think? WOULD it benefit the average user? Maybe not, but then again most users are not INIT fanatics, either. I doubt that it would HURT the average user. -- \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | / - Michael Weiss weiss@watson.seas.ucla.edu | School of Engineering and - - izzydp5@oac.ucla.edu | Applied Science, UCLA - / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \