DL>
  > JdeBP> The problem is nothing to do with the respective operating systems,
  > JdeBP> and everything to do with the heap management in your C++ compiler's
  > JdeBP> runtime library.  Ironically, it seems that the converse of your
  > JdeBP> complaint is true :  the C++ compiler that you are using for OS/2
  > JdeBP> has more efficient heap management than the C++ compiler that you
  > JdeBP> are using for DOS+Windows 95.
  >
  > Just what exactly are you saying here?  It doesn't make any sense.  I'm us
  > the same compiler on both platforms (Watcom 10.0a), and I'm using statical
  > allocated memory, not dynamic.  As a result, it's only the variable being
  > placed on the heap, not the area of memory to which the pointer points.
  > [...]
  > Like I said above, I'm not using the heap.
  > [...]
  > I will stress it again.  The memory I was reading, I did not allocate.
  > However, I was not writing to it, [...]
DL>

  All of which are wrong, since they completely contradict the code that
  you posted.  Here is the code that you posted once again:

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>

  You _are_ using dynamically allocated memory (the calls to `malloc' are
  plain to see), and it _is_ access to heap memory wherein you say that
  you are encountering GPFs (you are writing to heap memory pointed to by
  `p3' in the call to `memcpy', and reading from the same memory in the
  call to `write').

  If you are confused, it is because you aren't reading my response in the
  context of the code that you _actually_posted_.

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