Re: 0.9.6 incompatible with 0.9.5a on Win32

[Richard Levitte - VMS Whacker]

From: Jeffrey Altman <[EMAIL PROTECTED]>

jaltman> > jaltman> The problem has to do with linkage.  Attempts to substitute
jaltman> > jaltman> the 0.9.6 DLLs for 0.9.5a DLLs will fail due to missing
jaltman> > jaltman> functions:
jaltman> > 
jaltman> > Is there a way, with DLL's, to say that if a program is linked with a
jaltman> > previous version, it must be relinked?  For example, under OpenVMS I
jaltman> > can assign a shared library a major and a minor number, and also say
jaltman> > what condition make a new shared library valid for use with programs
jaltman> > that were linked with a previous version (usually, a shared library
jaltman> > can be used with programs that were linked with a version with the
jaltman> > same major and a lesser or equal minor).
jaltman> 
jaltman> > I'm of the opinion that if that functionality is missing, it's a flaw
jaltman> > in the operating system.
jaltman> 
jaltman> What you are describing has nothing to do with the current problem.

On the contrary, it has everything to do with it.  It's a tool to tell
the operating system what shared library version is compatible with
what, and to tell the user he or she must relink (and possibly
recompile) if the new version is not compatible with the one the
program was linked with.  Basically what you get told with the errors
you get, but a little bit more user-friendly, and with the added hint
that the developers know what they're doing.

jaltman> > And what would that stub do?  Tell you that you need to
jaltman> > recompile/relink and do an abort()?
jaltman> 
jaltman> The stub function would simply be
jaltman> 
jaltman>    int sk_GENERAL_NAME_num(STACK * st)
jaltman>    {
jaltman>       return(SKM_sk_num(GENERAL_NAME, (st)));
jaltman>    }

Which is exactly what the functions that existed before did, no more,
no less.  This is exactly what we found undesirable.

jaltman> Since you are not changing the functionality there is no
jaltman> reason for you to be breaking the linkage by removing an
jaltman> entry point.

Except that we would end up building them automatically, get a library
that is substantially (and needlessly so) larger (it was noticable!)
and possible with duplicate implementations (in theory, we had good
enough control for that not to happen, but it's better to be safe).

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).

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 :-)).

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?

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]