From:	Charles_Boatwright AT cisnc DOT canon DOT com (Boatwright, Charles)
Subject:	RE: Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
17 Sep 1997 11:31:44 -0700 :
Message-ID:	<5F404EEF30B3CF11B76B00000000000182E5BC.cygnus.gnu-win32@cisncdc>
Mime-Version:	1.0
To:	"'David MAUGIS'" <david DOT maugis AT sonovision-itep DOT fr>
Cc:	"'gnu-win32 AT cygnus DOT com'" <gnu-win32 AT cygnus DOT com>

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:david DOT maugis AT sonovision-itep DOT fr]
> Sent: 	Friday, September 12, 1997 2:13 PM
> To: 	kroening AT hit DOT handshake DOT de; Boatwright, Charles
> Cc: 	gnu-win32 AT cygnus DOT com
> 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
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -