-=*>})Jonathan de Boyne Pollard was nattering on to Daniel Lynes
   about Protected mode diffef on 10 Dec 96  08:49:02({<*=-

 JdBP> The problem is nothing to do with the respective operating systems,
 JdBP> and everything to do with the heap management in your C++ compiler's
 JdBP> runtime library.  Ironically, it seems that the converse of your
 JdBP> complaint is true :  the C++ compiler that you are using for OS/2 has
 JdBP> more efficient heap management than the C++ compiler that you are
 JdBP> using for DOS+Windows 95.
 
 Just what exactly are you saying here?  It doesn't make any sense.  I'm using
 the same compiler on both platforms (Watcom 10.0a), and I'm using statically
 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.

 JdBP> C++ runtime libraries usually organise the heap by allocating a
 JdBP> large chunk of address space from the operating system, and then
 
 Like I said above, I'm not using the heap.

 JdBP> But it won't cause a hardware page fault, because as far as the
 JdBP> operating system is concerned, you are writing to memory pages that
 JdBP> you legally allocated and have a perfect right to write to.  Never
	   
 I will stress it again.  The memory I was reading, I did not allocate.
 However, I was not writing to it, so I did not think there would have
 been a problem with a GPF.

 JdBP> Going back to your example above, either you have, coincidentally,
 JdBP> just happened to use a sequence of memory allocations and
 JdBP> deallocations that results in the space allocated from the runtime
 
 No.  I have tried to deallocate memory that I have allocated, plus memory
 that I have not allocated.

... No you cannot call 911! I'm downloading my mail!
--- Blue Wave/Max v2.12 OS/2 [NR]