Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!ptsfa!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac Subject: Re: Should 64K ROMs be supported? Message-ID: <1506@hoptoad.uucp> Date: Wed, 17-Dec-86 19:00:25 EST Article-I.D.: hoptoad.1506 Posted: Wed Dec 17 19:00:25 1986 Date-Received: Thu, 18-Dec-86 05:11:59 EST References: <476@runx.OZ> <1490@hoptoad.uucp> <907@ur-tut.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Centram Systems, Berkeley Lines: 121 Sorry for the delay; news system problems. First, David, your proposed solution for getting to globals at the interrupt level without using writes into relative code space is incorrect. CurrentA5 gives the A5 of the *current application*. This strategy will fail very badly under Switcher, causing the globals of various other applicvations to be modified in undefined ways, and bringing the whole system to a lovely, gnarly, crunchy crash. I can see you've never written a socket listener or protocol handler. Care to make another stab at an answer? Second, I rather resent your tone. You keep trying to make it seem like I am some fiend bent on screwing millions of people out of their Macs. If more software manufacturers had an upgrade policy as rational as Apple's, then there would be no problem with cleaning up the OS. Yes, some old versions would break, and people would have to get the new versions. Big deal. This isn't screwing over the users; it's refusal by the maufacturers to upgrade every few months that screws over the users. Upgrades are a reality of software; nothing is perfectly bug free, and nothing is ever as good as it could be with another few weeks of hacking. (Apple could help this process along by instituting a third-party software upgrade system through registered Apple dealers.) What causes my resentment is that we at Centram have had to do a huge amount of compatibility hacking that serves no purpose but to make our software work with some arcane software or hardware product for the Mac. (A main source of our compatibility problems is that the late introduction of record locking forced a number of DB applications to depend on undocumented FS behavior; this has also prevented any reasonable network caching.) Fortunately, this phase ended shortly before release, we have almost no compatibility problems now. Do you think you're the only ones who suffer from the fact that so many Mac programs and peripherals are ill-behaved? Do you think a professional developer neccessarily has less comprehension of compatibility problems? I think this upgrade/"don't step on Bill Gates' toes" problem is receding into the past. Mac software used to be a gamble, on which one could barely squeeze through with luck. Manufacturers were unwilling to spend a pittance on upgrades for software that would have only a small margin of profit anyway. Now, in 1986, things are very different. Mac sales exploded with the Mac+, as I'm sure you know. Suddenly everyone and his brother wants to jump on the bandwagon. Apple is now in a position 180 degrees opposed to its earlier begging and pleading with developers to pleeeeeez write Mac software; now it can dictate terms. If the terms involved a general upgrade cycle to last over six months or a year, the devlopers would jump to get their software compatible first. Third, do you inform developers when their software has to be specially accomodated in the ROM? (We usually do this with TOPS compatibility problems.) It seems to me that if Apple did this, then the ill-behaved software could be wiped out in under a year. This would then free *Apple* to do some *serious* OS improvements, like adding multitasking on the 512K and Mac+, improving the speed of the Resource Manager, adding more user-selectable user interface operations, and so forth, instead of millions of patches to keep things running. Anyone who's stepped through the new ROMs knows that they're a nightmare of "where was I called from" and "minor hack to cope with incorrect calls". I can't imagine how the current software could possibly survive another revision cycle. Seriously, compare the rate of improvement of the Mac OS with, say, UNIX or VMS. Pretty sorry, isn't it? Fourth, it appears that I was correct about Apple overestimating the difficulty of re-implementing the Mac OS, since according to Computer Currents, the first Mac clone is through development. To stay ahead in a market of clones, Apple is going to have to clean up the OS so it will be able to move faster than the clone makers. Fifth, it might be interesting to examine why so many Mac applications are so poorly behaved, as compared to, say, UNIX applications. Obviously part of it is that Hertzfeld and Haeberli are no way up to Ritchie's standards (no insult there! Very few are!), and part of it is the lack of memory protection, but I think it strikes deeper than that. It is weird that in an OS so obviously influenced by Smalltalk, all the things that help make Smalltalk (and most OS's) reliable have been ignored. I am referring, of course, to data representation hiding. All through the Mac, the OS is presented not merely as a set of typed objects on which various operations can be performed, as in Smalltalk or UNIX, but as a set of data structures in process memory and ways of manipulating them. Example: NewMenu, NewDialog, and so forth should return *typed descriptors* referring to *internal* system data structures not meant to be touched by the application. Imagine if UNIX, instead of returning a descriptor on a file open, returned the system inode data structure for the file; not just a copy, but the real data structure, and it would be considered OK for the process to do whatever it wants with it. Reliability would plummet, security would be inconceivable, and it would be impossible to extend the file system (as with the FSS mechanism) because of program reliance on system data structures. Sound familiar? Programmers love to prove to themselves how clever they are. Given a choice between a clean, message/syscall-style way of accomplishing something, and a dirty, sly, tricky way that shows that the person really knows what he is doing, an awful lot of programmers will choose the latter. Leaving these back doors open, and even encouraging them by providing documentation on internal system data structures to the application programmer, is suicide. (Putting the data structures in an area of memory used by the application for its own bookkepping also decreases reliability, of course. A slightly incorrect program is much more likely to write incorrect data near where it is supposed to be writing it than it is to start writing to a random area. And this storing of system data structures in process memory makes it impossible to increase OS reliability by later adding memory protection.) If these problems with lack of data rep hiding in the OS are not clear, I will be happy to expand on them. But it should be plain that one significant reason for misbehavior of so many Mac applications is that the whole design of the Mac OS encourages applications to screw around with things that properly belong to the OS exclusively. I realize my tone here is not overly polite, but I really don't appreciate being accused of being out to screw everyone over, as you so delicately put it. It also doesn't help to have incorrect solutions presented in an overbearing and self-righteous manner. I am perfectly willing to have a calm and polite discussion of the subject, but you are going to have to drop your defensiveness and innuendos. To point out that the Mac OS has flaws is not a personal attack on David Gold, and to respond with indignation and insult is not likely to convince anyone I am wrong. -- Tim Maroney, Electronic Village Idiot {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)