Windows heaps and Cygwin heap

[Ryan Johnson]

On 13/05/2011 4:36 AM, Corinna Vinschen wrote:
> I'm going to squeeze my rambling in between this thread since
> it's related.  I just changed the subject.
>
> On Apr 19 14:16, Ryan Johnson wrote:
>> Regardless of file mapping behavior, though, I don't see right off
>> how to make this problem go away. Nothing stops thread stacks or
>> heaps from causing problems with other dlls, and they seem to move
>> around even when they could have stayed put.
> I noticed this as well on W7 32 bit.  Even the process default heap
> (what's now called heap 0) is moved around wildly.
>
> There are noticable differences to Windows XP.  On XP, the address
> ranges from 0x10000 to 0x230000 are neither heaps, nor is any part of
> them shareable.
>
> More importantly, the heaps on XP are not so versatile.  In contrast to
> W7, if I start the same application multiple times, the heaps are always
> in the same spot.  Apparently some Windows DLLs create their own heaps.
> The more Windows DLL are loaded in a process, the more heaps I see.  On
> XP, all of them are always in the same place.  On W7 the heap addresses
> are plain erratic.
>
> Short break for the commercials:  We can safely make the assumption that
> the differences have been introduced with Windows Vista.  So, if I said
> W7 it's actually NT 6.x, in contrast to the older NT 5.x kernels.  Ok,
> back to the show.
This is true, but I get the impression that W7, x64 in particular, 
"refines" the behavior in ways that make it even more hostile to fork 
than Vista. I could be wrong, tho.

I'll try out the patch on my machine, since I seem to have an especially 
hostile environment for fork for some reason (it sure made testing my 
fork patches much easier than I would have liked...)

However, I've only seen failure to allocate the cygheap kill fork once 
or twice ever. It's statically-linked dlls that nearly always cause the 
problems.

Ryan