Path: utzoo!utgpu!water!watmath!clyde!ima!bbn!lawrence
From: lawrence@bbn.COM (Gabriel Lawrence)
Newsgroups: comp.sys.mac
Subject: Re: Multifinder woes. DA's
Message-ID: <5904@ccv.bbn.COM>
Date: 8 Jan 88 17:24:19 GMT
References: <7965@j.ms.uky.edu> <411@ut-emx.UUCP> <7122@apple.UUCP> <937@usfvax2.UUCP> <1948@elrond.CalComp.COM> <2388@Shasta.STANFORD.EDU>
Reply-To: lawrence@BBN.COM (Gabriel Lawrence)
Organization: Bolt, Baranek and Newman Inc., Cambridge MA
Lines: 42

kaufman@Shasta.stanford.edu (Marc Kaufman) writes:
>anson@elrond.UUCP (Ed Anson) writes:
>
>.>I have this same suggestion for 'SIZE' resources; it should be possible to
>.>put a SIZE resource in a document, which would override the SIZE in the
>.>application (which would be used as a default)...
>
>>  I second the motion.  This problem (together with the lack of print 
>>  spooling) is the main reason I find myself flipping back and forth between
>>  Finder and MF...
>
>I have a similar problem, but from the other side.  I am writing a print
>driver that wants to build a pixel image of the page in the MAC, then send
>it to the device.  I think it is unfriendly to ask applications to include
>an additional 1 or 2 Megabytes in the SIZE resource, just so I can lay
>out the page (high resolution pages, in color).  Since the MAC is nominally
>a "single user" machine, why not allow an application to request a non-
>contiguous memory allocation.  I know that there are potential fragmentation
>problems, but we are probably not launching arbitrary user tasks while this
>extra memory is in use, and in any event the process can request just what
>it needs -- which is more efficient than guessing at 'SIZE' time.

Hmmm... Either I'm missing something or Microsoft et al didn't read their
MultiFinder-friendly technical documentation very thoroughly.  The 
documentation plainly states that an application should pre-allocate space,
via the SIZE resource, enough room for the application to perform comfortably
in.  Space for sizable documents or tasks requiring additional memory (such
as pre-print imaging) can be allocated by use of any one of the new memory
manager temporary allocation procedure calls.  Call me silly but I assumed
that the new temporary memory allocation calls were written specifically
for the purpose of keeping the SIZE resource requirements reasonable.  It
would also seem to me that if applications handled this mechanism correctly,
it would obviate the need for documents to carry around their own SIZE
resource.   An application could easily open a document, determine it's size
and then allocate additional memory before reading the data into memory.
Please, if I'm incorrect, someone kindly enlighten me.

=Gabriel Lawrence=
=BBN Communications=

USENET: ...!harvard!bbn!ccv!lawrence
INTERNET: lawrence@BBN.COM