DL>
  >  int main( int argc, char **argv )
  >  {
  >   .
  >   .
  >   .
  >   p=( char * )malloc( 239 ) ;
  >   p2=( char * )malloc( 72 ) ;
  >   .
  >   .
  >   .
  >   p3=( char * )malloc( 239 ) ;
  >   /*
  >    * The next line and the following one are GPF enabled (in Win95),
  >    * but not in OS/2.
  >    */
  >    memcpy( p3, p+extraBits, 239 ) ;
  >    write( handle, p3, 239 ) ;
  >    .
  >    .
  >    .
  >  }
DL>

  The problem is nothing to do with the respective operating systems, and
  everything to do with the heap management in your C++ compiler's runtime
  library.  Ironically, it seems that the converse of your complaint is
  true :  the C++ compiler that you are using for OS/2 has more efficient
  heap management than the C++ compiler that you are using for DOS+Windows
  95.

  C++ runtime libraries usually organise the heap by allocating a large
  chunk of address space from the operating system, and then suballocating
  from within that space as necessary to fullfill malloc() requests.  This
  reduces the number of times that the system API is called, reduces the
  number of times that user->kernel->user ring transitions occur, reduces
  the number of allocated pages (by allowing multiple allocated regions of
  memory to reside on the same page) and makes heap management faster.

  Borland C++ for OS/2, for example, allocates the heap from OS/2 using
  DosAllocMem in units of 4Mb, and uses a doubly-linked list of variable
  length blocks to perform housekeeping and suballocation.

  This does mean, however, that the hardware memory protection, which
  operates with a granularity of 4Kb, won't necessarily always
  prevent an application from writing beyond the end of an area of memory
  allocated via malloc().  The memory protection operates, as does the
  system API used to create the heap, in terms of pages.  The heap as a
  whole is protected (you cannot write to memory outside the heap), and an
  intelligent runtime library will use DosSetMem to protect you from
  accidentally writing to pages of the heap that haven't been suballicated
  from yet.

  But the memory returned from malloc() will often point into the middle
  of a page, and may have either used or free areas both before and after
  it.  Overwriting those areas will cause heap corruption (you will at the
  least be screwing up the heap manager's housekeeping information), and a
  good debugging memory management package will usually catch this at some
  point later in your program.

  But it won't cause a hardware page fault, because as far as the
  operating system is concerned, you are writing to memory pages that you
  legally allocated and have a perfect right to write to.  Never mind that
  the runtime only allocated a *part* of the page to you.  The operating
  system and the page management hardware only know about whole pages.
  Never mind that it was the runtime library, and not your application,
  that allocated those pages.  As far as the operating system is
  concerned, the two are indistinguishable.  Your application allocated
  pages, and is writing to them.  No problem.

  Going back to your example above, either you have, coincidentally, just
  happened to use a sequence of memory allocations and deallocations that
  results in the space allocated from the runtime for `p3' ending on a
  page boundary before an un-committed heap page (this is exceedingly
  unlikely, but possible), or the heap management in your DOS+Windows 95
  C++ runtime calls the system API to allocate individual lumps of memory,
  and isn't very efficient.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01