128a-3aj@e260-3a.berkeley.edu (Jonathan Dubman) (11/16/88)
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. >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. 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. 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! 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. Jonathan Dubman UC Berkeley Math/CS student
grg@berlin.acss.umn.edu (George Gonzalez) (11/16/88)
The reason that Mac applications can't be moved once started isn't Apple's fault. It's because all applications depend on absolute addressing. Once an application has started up, its stack will be full of absolute addresses: return addresses from procedure calls, dynamic links to vars in other procs, VAr parameter addresses, pointers (absolute). All these addresses are pure machine addresses. The application, its stack, and its heap *can't* be moved because of all these references into the code, stack and heap. I don't know anything about the Amiga. But I'd like to know how they could move a running application. I suspect they can't either, and have similar memory fragmentation problems.
billkatt@caen.engin.umich.edu (Steve Bollinger) (11/17/88)
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) | +---------------------------------------------------------------------------+
spector@vx2.NYU.EDU (David HM Spector) (11/17/88)
[GrumbleGrumble]
Now that's being more than just a little unfair! Applications that
are location dependant are NOT APPLE'S FAULT! Apple has said from the
very beginning (read IMI-V and the TechNotes, esp. TN's 2, 25, 44,
117, 156 and 212) that program(er)s should not depend upon programs
being loaded into any spcific area of memory, not depend on memory
being [128|256|512|1M|etc|etc], the screen being any fixed size, and a
bunch o'other things.
Most Macintosh applications that are ___WELL_WRITTEN___ have no
problems running under any current, future *OR PREVIOUS* (with the
exception of HFS calls) version of the Macintosh OS.
Microsoft found out what happens when you don't follow programming
guidelines - your software breaks. I think Apple DID do the Macintosh
community a disservice by letting Microsoft get away with the Excel
problems for so long -- and even making MultiFinder "Microsoft aware".
Apple has a lot of work to do on the Macintosh OS, and they are doing
a LOT to make sure that Applications work well in future incarnation
of the OS... All developers have to do is follow the guidelines. Its
really a lot harder to write a broken program on a Mac than it is to
write a working one....
If you want to flame something, flame companies that write and release
broken software.
_DHMS
-------------------------------------------------------------------------------
David HM Spector New York University
Senior Systems Programmer Stern School of Business
ARPAnet: SPECTOR@GBA.NYU.EDU Academic Computing Center
USEnet:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
HamRadio: N2BCA MCIMail: DSpector New York, New York 10006
AppleLink: D1161 CompuServe: 71260,1410 (212) 285-6080
"Capital punishment is our society's recognition of the sanctity of human life"
- Senator Orrin Hatchdorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (11/18/88)
In article <17069@agate.BERKELEY.EDU> 128a-3aj@e260-3a.berkeley.edu (Jonathan Dubman) writes: >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. I would hardly call the Mac's memory manager "Dark Ages". And if I remember my Computer Arch. books, all computers have high memory, low memory. The problem that the poster is talking about referes to memory fragmentation problems. Solutions to this problem can be to load things at different end of Heap space and have the heap grow towards the middle. This has the effect of only effecting at most half of the heap for any recompactions, less memory to move, fast performance. Kludgy bits in each application. Bit's are to be used to indicate information about things, if we use them to indicate attributes of a process then that's what they should be for. Also the basic arch. of the Apple ][ is 1979 or so, it hasn't changed that much, by 1982 it was pretty well established. Your suggestion that the Macintosh design has a lot to do with the Apple II is completely unfounded. >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. Why stop at I/O addresses?? Facts of the matter are that most all computer systems have some hard coded addresses for the OS. I don't think making a memory manager call for each one is the best solution, but it's one. Why not make a data stucture availible that describes all of the OS values, ect... There are several options. Making a memory manager call for each OS data value might be considered a no-vision Apple II design decision. Macintosh applications are segmented! What more do I need to say. The 68000 has 24-bit addressing, get your facts straight. {However after reading your article I can see you have a problem with this} >THIS IS THE WAY EVERYONE ELSE DOES IT, ignoring implementation details. Unix Who the heck is everyone. I don't think the IBM PC does this. Unisys computer {2nd largest computer manufacturer in the world doesn't do it this way on all of their systems.} Ignoring implementations details. WAKE UP. What we're talking about is "IMPLEMENTATION DETAILS", I don't think you can ignore them. The facts of the matter are this statment is stupid. I'm sure most everyone reading this message can think of a computer that doesn't do it this way. Again avoid broad generalities, you might be wrong. >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. Do I really need to say anyting about the Amiga's OS. Sure it's got some strong points. But it's printing isn't one of them. And as far as the order of loading of applications, not too many Mac Programs worrry about loading in order. The Amiga folks are lucky they don't have MS doing any software for them, otherwise they might have the same problems. Also the Amiga's not the end all in OS's, the OS is buggy, and any application can take over the machine and start stepping on other Application's memory space {so can the Mac}, this is a big problem for micro computers, and will be until HW memory management becomes a reality to the general public. >I heard from some people at Microsoft that Excel had to be "significantly >rewritten" to use more than 1 megabyte. How many version of the Amiga OS are there?? "I heard from some people that the Amiga OS had to be "significantly rewritten" to be any good!" Not everyone always plays by the rules, and software evolves. I also heard that Unix has been rewritten, MS-Dos has been written. What's the big deal! >USERS SHOULD NOT HAVE TO WORRY ABOUT ALL THIS! Users don't. However on the Amiga they do! I've tried changing printers and getting some applications to work. This is not something to be attempted by the faint of heart!! >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. 98-99% of all software on the Macintosh works fine. You're picking on one popular package from over 3000 packages. Hardly a large installed base of screwed-up software. BTW: Has Amiga World finally broken the 100 page limit? I've always enjoyed reading that pamplet! >Apple, what are your plans for the OS? The time to abandon this precambrian >MS-DOS style memory manager and OS-scheme is NOW. Name one part of the Macintosh design that ressembles MS-Dos. Haven't you read about Apple's plans. They published all of their plans for the next 3 OS released perhaps what you need is more research. >Jonathan Dubman >UC Berkeley Math/CS student Stick to math John, you're no CS student! -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
sho@pur-phy (Sho Kuwamoto) (11/20/88)
In article <5857@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: > [after flaming an opionionated Amigaphile] > Name one part of the Macintosh design that ressembles MS-Dos. Haven't you >read about Apple's plans. They published all of their plans for the next >3 OS released perhaps what you need is more research. I remember reading this, but I've forgotten what theire plans were, and I've also forgotten where I read this to begin with. Could someone please fill me in on Apple's plans? What would be even more nice would be juicy rumors about what they *haven't* announced yet.... -Sho