Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!indetech!vsi1!zorch!mykes From: mykes@zorch.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.misc Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <1991Jan18.061539.14527@zorch.SF-Bay.ORG> Date: 18 Jan 91 06:15:39 GMT References: <7511@sugar.hackercorp.com> Organization: SF-Bay Public-Access Unix Lines: 99 In article burley@geech.ai.mit.edu (Craig Burley) writes: >In article mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > In article <7511@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > > I can start up a _bunch_ of apps on a 2 meg Mac (I just have to be > > selective about what I launch). > > Whereas I can start up a bunch of applications in my 1.5M Amiga and could > care less what they are. > > Yeah - GNU Emacs works like a charm, and ADPro can handle some > _really_ large images in 1.5M. And AmigaVision runs alongside both of > those, just fine. Where did you say that beachfront property was, > Peter? > >Um, this seems stupid, pardon my english -- has ANYBODY gotten GNU Emacs to > run under Mac OS? I've got an 8MB SE/30, let me know!! You can find a version of GNU that runs on the Mac on many BBS systems... > >Meanwhile, the debate over image size is fascinating. On the Mac, the >problem is that an application must establish when it is started up how >much memory is to be set aside for it. Aside from temporary allocations >that can't be maintained and still task switch (as used by the Finder >when doing a floppy disk-to-disk copy so each disk need be inserted only >once during the copy), I don't think there's any way for a running app >to reliably say "hey, I need another .5MB after all, to deal with this >new file the user is opening". > >By "reliable" I don't mean "works even if you don't have the RAM [virtual >memory on applicable systems]" -- I mean "works if you have .5MB >contiguous memory available, even if it isn't contiguous with the application's >original image". I think the Mac OS does allow an application to extend >itself, however, if it has unallocated space beyond it, which would indeed >result in order-of-invocation requirements for users who intended to use >one of several simultaneously available applications in a manner that caused >it to have to extend itself (presumably by just opening lots of files or >inputting lots of data). I do recall seeing responses to complaints like >"my Mac says not enough memory, but the About Finder menu shows plenty of >memory, what's the deal?" saying things like "Quit all your applications, >start X up first, then start Y, then start Z, then reopen all your files, >and that will defragment the memory space". > >So my question is, does AmigaOS not require applications to live as >single, contiguous, preallocated chunks in memory? If this is the case, >then indeed the Amiga's memory management seems superior for this >situation. Order of application invocation would not be nearly as important >(or at all important) as it is on the Mac. Of course, sloppily coded >applications that fragment memory, or really bizarre usage of well-coded >applications, could still result in situations where a request for more >memory failed due to more than enough memory being overly fragmented. But >on the Mac, that situation is, I believe, fairly easy for an ordinary user >to encounter while using solid applications. > The AmigaOS supports "scatter" loading of executables which allows an application to NOT bet a single contiguous chunk. This is particulary valuable because of the fragmentation that can occur (parts of programs can load into whatever fragments are available). Memory fragmentation does not really become a problem until you get into low memory situations, which for me (a power user) is practically never. >The Mac OS doesn't make any gains as far as I've been able to analyze in >requiring monolithic application memory images -- it appears to be due to >the original approach of one application at a time (which I call "Unifinder"). >Too many apps, plus the OS interface and mechanisms, made this assumption >for Multifinder to change it. A big win for system 7, virtual memory (on >systems that support it), will allow Mac users to increase the declared >amount of memory each app needs without actually taking up that much RAM, >unless they really need it. I don't think system 7 does away with the >monolithic address space per app, however; I might be wrong. In any case, >this is another example of how the Mac OS' history (and requirements for >backwards compatibility) as a non-multitasking system has crippled its >a dvances somewhat. > virtual memory should be interesting on the Mac. When you click on a window to bring it to the front, you are going to have to SWAP lots of code in and out just to refresh all those applications' windows. On a machine that already has a hard time being fast at refreshing the screen, it is not going to be better, even if you have a 1 Gigahertz 68090 (one of these days!). >Note that Microsoft Excel required special code in Multifinder until a >fairly recent release (I think Apple recently removed this special code >due to this release) that allowed an application to indicate that not >only did it need to reserve MB, but it needed to have live at a >particular place in memory. I don't know whether this meant users had >to invoke Excel first to make sure it got its desired absolute addresses >or Multifinder simply avoided loading any other apps into that area of >memory if Excel was hanging around (which, I think, it could detect due >to the Mac's informative file system). Also, Excel was limited to 1MB >up until this (or a nearby) version. >-- > >James Craig Burley, Software Craftsperson burley@ai.mit.edu