Subject: RE: Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
From: [email-masked] (Boatwright, Charles)

17 Sep 1997 11:31:44 -0700
Message-ID: <5F404EEF30B3CF11B76B00000000000182E5BC.cygnus.gnu-win32@cisncdc>
Mime-Version: 1.0
Content-Type: text/plain
To: "'David MAUGIS'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

David,

Not that it matters, however I was comparing the NT global 
alloc to a debug process global alloc.  You point is well taken,
I *should* have dug through my lab books to find the data on
global vs virtual cross NT vs 95.  It was an interesting test, but 
in the end somewhat uncontrolled (someone with inside info
to the kernel group at M$ told me memory allocation performace
can only be measured with +/- 10% accuracy).

FWIW   my $0.02

> ----------
> From: 	David MAUGIS[SMTP:[email-masked]]
> Sent: 	Friday, September 12, 1997 2:13 PM
> To: 	[email-masked]; Boatwright, Charles
> Cc: 	[email-masked]
> Subject: 	Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
> 
>      
> I think GlobalAlloc is slower because, basicaly, when you allocate
> uninitialized
> memory (i.e. non zeroized ) you call a low level function :
> VirtualAlloc
> VirtualAlloc doesnt allocate any memory at first but only reserves
> address 
> space. When you access this address space, the memory is then
> allocated.
> 
> I suppose that if you try to allocate zeroized memory, GlobalAlloc has
> to map 
> all memory at once ...
> 
> 
	__SNIP SNIP__
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".