1. run-time library [compiler x threading x debugging]
Compilers:
cygwin versions
msvc 6.0
msvs .net
msvs .net 2003
others? Threading;
linked to threaded run-time
linked to non-threaded run-time Debugging:
linked to debugging run-time
linked to non-threaded run-time2. 32-bit vs 64-bit 3. openssl version 4. with or without kerberos or some other openssl feature?
and we need to do all of this in 8.3 notation. This is not going to be pretty.
Assuming we allocate one character to represent compilers in a table; one character to
represent threading and debugging and 32/64-ness; two characters for openssl version;
this leaves four characters for a descriptive name.
The primary motivation for this in my mind is that too many companies are beginning to install OpenSSL binaries into the System Path on Windows (or worse the \Windows\System32 directory).
This causes other apps to break.
Now, we could avoid all of this by simply requiring software vendors to follow IBM's rules for redistribution of run time dependent components. You must redistribute the components using
application specific naming conventions in order to avoid conflicts with other applications
which might rely on different versions of the same component.
This last item is probably the easiest to implement.
Jeffrey Altman
Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Sun, 25 Jan 2004 11:02:06 -0500, Jeffrey Altman <[EMAIL PROTECTED]> said:
jaltman> I think there are two very different markets. One is the jaltman> cygwin (unix on windows) environments which expect things to jaltman> be named the way they are on Unix/Linux. The other is the jaltman> native windows environment which expects naming to be as it jaltman> has been on Windows. I think both need to be supported jaltman> therefore there should not be a name collision.
I entirely agree with the idea of following the standard set in the environment you work in. However, if we look at the file name without the extension, I'm only aware of a naming standard on Unix (libraries start with "lib") and VMS (it's a little bit more complex, and includes things like a prefix for the utility or language the library is connected to, and usually includes the word "SHR" for shareable libraries, although I see a lot of variety still...). I'm not aware of any naming convention for Windows libraries, and haven't been able to get a straight answer when I ask (and if you look at the variants of LIBC that comes with MSVC, you see a bit of variety there as well).
On Windows, there's the added complexity of using different run-time libraries depending on if you're using threads or not, if you built in debug mode or not, and other details I'm not aware of. I've heard suggestions of creating several variants of the OpenSSL libraries that would be used in parallell with the different MSVC libraries, and that's where a naming convention is becoming even more important.
Added to this problem, we have the different register sizes on different CPUs (32-bit, 64-bit, and whatever will follow), which seems to be difficult to intermix in the same library, and thereby requires another bit of information that may need to be included in library file names, and as far as I understand, no-one has yet come up with a commonly accepted standard.
I would love it if someone could point out a standard for each operating system family (Unix, Windows, VMS, ...) and if we could figure out a way to adhere to that in a meaningful way.
Thoughts? Opinions? Wishes to strangle me for sturring this up :-)?
----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details.
smime.p7s
Description: S/MIME Cryptographic Signature
