> Jeffrey Altman <[EMAIL PROTECTED]> writes:
>
> >Quoting from Peter Gutmann's paper when he describes the use of the ToolHelp
> >library:
> >
> > "Since even a moderately loaded system can contain over 500 heap
> > objects and 50 modules, we need to limit the duration of the poll
> > to a second or two, which is enough to get information on several
> > hundred objects without halting the calling program for an
> > unacceptable amount of time ..."
> Note that that's for Win16 on a 386/486, where the poll really will
> freeze the system. For Win95 et al this isn't an issue, both
> because it won't stop every other process and because systems
> running '95 have to be a little bit faster than a '386.
Peter:
you are coming into the discussion a bit late. The reason for
implementing a limit on the reading of the HEAPLIST32 chain members is
because if you do not provide a limit the reading of the chain can
take minutes. It is no more acceptable to freeze an application for 3
minutes than it is to freeze the entire system. I was testing this on
a 350 MHz Pentium II running Win2000. A process that contains
several megs of code and data in memory takes too long. Plus the
amount of random data in each additional HEAPLIST32 structure is
minimal.
> BTW (as a comment on a later thread) you could save yourselves a lot
> of effort by just pulling the necessary code out of cryptlib (it's
> available under the GPL, BSD license, or whatever else you want),
> since there are a number of further bugs in Windows which you
> haven't run into yet but probably will in the future (look for the
> long text block comments in rndwin32.c :-).
Thanks. I will look at this.
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
