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 Content-Type: text/plain To: "'David MAUGIS'" Cc: "'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".