> jaltman> And since you are not simply changing the linkage, but
> jaltman> instead replacing functions by macros, when the OpenSSL DLLs
> jaltman> are replaced all applications need to be recompiled from
> jaltman> scratch, not just relinked.
>
> Hmm... Well, perhaps we should make sure this version create those
> stubs, but have them scream "Please recompile your program, the
> function sk_GENERAL_NAME_num will disappear in the next version" in
> addition to doing their job (unless it's preferable to have them
> abort(), that might be a humongous amount of messages...). That's an
> option I can see as a possibility as an interim. But I still think
> (of course, the rest of the team will have their say on this) that
> those stubs should disappear in due time (if nothing else, *before*
> OpenSSL 1.0).
I would prefer that things be left as they are rather than have the
libraries output data to stdout/stderr OR call abort(). Libraries
should not call abort() unless things get really desperate.
> jaltman> In my situation, I could test the version number of the DLL
> jaltman> if it were added to the DLL resources. I can do this because
> jaltman> I don't link my executables to the .LIB files. Instead I
> jaltman> compile and load the DLLs at run time with LoadLibrary() and
> jaltman> GetProcAddress(). So if entry points are missing I can
> jaltman> detect them at runtime. BUT I attempt to write my code in
> jaltman> such a way that it is compatible with multiple releases.
>
> And I know other places that prefer to create non-DLL libraries,
> basically because I've said to everyone that has asked that before
> version 1.0, anything goes (although we've been pretty good at
> backward compatibiltiy so far :-)).
The problem with using static libs is that 0.8MB of code must get
linked into each component of the system. That wastes a lot more
space than the stub routines. Perhaps generation (or usage) of the
stub routines could be a compile time option.
> jaltman> ------
> jaltman>
> jaltman> Another problem:
> jaltman>
> jaltman> RAND_status()
> jaltman>
> jaltman> takes over a minute to return the first time it is called within a
> jaltman> process on Win2000.
>
> A quick guess: RAND_poll.c in rand_win.c, especially the part that
> walks processes/threads/modules... Do you have the possibility to
> come up with timing data?
What my code does is call RAND_status() to determine whether or not
random data needs to be computed. Does RAND_status() no longer simply
provide a test, but instead performs entropy gathering?
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]
