Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!mailrus!caen.engin.umich.edu!billkatt From: billkatt@caen.engin.umich.edu (Steve Bollinger) Newsgroups: comp.sys.mac.programmer Subject: Re: FullWrite Professional -- Six Years Later Keywords: frustration really about OS Message-ID: <3fb43579.129dc@blue.engin.umich.edu> Date: 16 Nov 88 17:49:00 GMT References: <17069@agate.BERKELEY.EDU> Reply-To: billkatt@blue.UUCP (Steve Bollinger) Organization: caen Lines: 102 In article <17069@agate.BERKELEY.EDU> 128a-3aj@e260-3a.berkeley.edu (Jonathan Dubman) writes: >Chuq von Rospach writes: (and I agree with most of his posting) >>Apple: here's a suggestion. Create a new bit for an application that tells >>Multifinder to load it at the top of memory so that things like PrintMonitor >>can load high and application can load low and never the twain shall meet, we >>hope!" > >I can't believe it, these Mac Programmers, particularly the OS people, are >still in the dark ages! High and low memory? Sounds like the Apple II, for >chrissake. "We hope!" You shouldn't have to HOPE about anything. And the >last thing we need is more kludgy bits in each application. These OS >programmers don't have VISION- they're stuck in a certain primitive mode of >thought- a 1982 Apple II mode of thought. No VISION? Sure, you forget that most of the Mac System has lasted for 4 years, including a transition from singletask to multi-tasking. ALL THIS WITHOUT REQUIRING PROGRAMS TO BE SO MUCH AS RECOMPILED! You're right, no vision here. > >>argh! ... [Hint: if you set all the programs you use in sequence to have the >>same memory requirement you may not be able to run them together, but >>they'll load when PrintMonitor is active... PrintMonitor is loaded in >>after where the layout program used to be so memory is fragmented and there's >>no room for FullWrite. > > ?!!! > >Except for I/O addresses, there should be no fixed locations in the OS. All >memory should be allocated through a memory manager which returns something >in your memory which could be anywhere in the 32-bit address space of the >microprocessor, and you should NOT DEPEND ON ANYTHING MORE. Applications >should not be monolithic in memory usage, they should be segmented. > The 68000 only has a 24-bit addess space, for starters. >THIS IS THE WAY EVERYONE ELSE DOES IT, ignoring implementation details. Unix >does it this way. The Amiga does it this way, and NOTHING EVER CONFLICTS >WITH ANYTHING ELSE! On my Amiga, I worry about one number: Free memory left. >I can load as many things as I have memory for and run them all at once and >each one thinks it owns the machine. Pre-emptive multitasking and >common-sensible memory management. Segmented self-relocating code. No fixed >addresses. Order of loading applications makes zero difference. "Background >printing is great!" Of course. That's like saying round wheels are great. >There should be NO OTHER KIND of printing. Printing is not one of the strong point of the Amiga. Less than a year ago a friend of mine was looking for a Amiga word processor with PostScript output so he could email it to me and I would print it on a LaserWriter. The most interesting part was when he asked me how many Mac word processors do PostScript output. I said offhand, 'All of them', and he was amazed. Yes, all of them, and every draw program and every spreadsheet and every quick hack written in 1984 WITHOUT SO MUCH AS RECOMPILATION. I wouldn't give up my PostScript output for background printing. What good is a LaserWriter if only a few word processors (and nothing else) print to it? > >I heard from some people at Microsoft that Excel had to be "significantly >rewritten" to use more than 1 megabyte. That's like saying a piano needs to >be redesigned to play music more than a minute long. The application should >use as much memory as it finds! What can I say? Microsoft seems to have their own attitude. Oh well, one bad apple doesn't spoil the whole bunch. > >Maybe this belongs in mac.programmer. But that is precisely the problem. > >USERS SHOULD NOT HAVE TO WORRY ABOUT ALL THIS! > >I feel sorry for Apple's current employees who are faced with the tremendous >intertia of a large installed base of screwed-up software. But I really >empathize with the users who have to worry about this baloney when they really >just want to get work done. > >Apple, what are your plans for the OS? The time to abandon this precambrian >MS-DOS style memory manager and OS-scheme is NOW. > I resent you saying that. Nothing manages memory as bad as MS-DOS, not even the Mac. The Mac was one of the first OS's to have relocateable blocks of memory (without an MMU). Apple started re-writing the Memory manager more than a year ago to fix these problems you mention. Currently, the only fault of the memory manager is that is does not tag memory blocks with an incidication of the Application that owns them. Because of this, it is impossible to ask for blocks of general RAM because if an application bombs Multifinder cannot tell which blocks to free and which ones are still owned. Considering the Memory Manager was written in 1984, it is amazing that this is the only major fault. And soon (probably system 7), this will be fixed and you will set the memory allotment to an application to just enough to run its base routines. And when the application needs more space (i.e. for a spreadsheet), it will get blocks from shared heap space. >Jonathan Dubman >UC Berkeley Math/CS student +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+