DR>
  > JdeBP>   You cannot have it both ways in two consecutive sentences.
DR>

  I said this, and in your reply you *still* try to have it both ways in
  two consecutive sentences, viz. :

DR>
  > The 2Gig size was chosen because thats the biggest file you can
  > have anyway under OS/2 so the mapping of a single large file in a
  > process could always be done [...]. That leaves plenty for the
  > operating system and user code to map into.
DR>

  Mapping a 2Gb file into a 2Gb address space *doesn't* leave "plenty" for
  the O/S and user code/data.

  Choose one or the other.  You cannot have both.

  The people who are looking at filesizes well into the gigabytes,
  *must* use partial mapping on a 32-bit architecture (i.e. "today's
  hardware" from my original message) anyway, and thus lose the benefits
  because application-level buffer management is still required.  So
  memory mapping isn't actually a solution to their problem at all.

DR>
  >                                             On the other issue,
  > [partial mapping] yes it does simplify things.
DR>

  Buffer management has to be done for partial file mapping, which
  leaves the resultant code no simpler.  Think about how access to a
  record that is not currently within the "window" must have to be
  implemented at application level.

  And if we restrict ourselves to only mapping whole files, we are back
  to my point of two messages ago, where files are being restricted to a
  "reasonable" size.  In which case, any limit is arbitrary, and *all*
  are no use to the high end folks, as they cannot use memory mapping at
  all for their files because they exceed the maximum size of the 32-bit
  address space.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 2.01wb