Suggestion for OPENSSL_Applink [Was: Windows DLL naming inconsistency]
As discussed earlier it's virtually impossible to produce a compiler neutral OpenSSL binary distribution for Windows. Attempt to mix compiler environments or even different compiler flags results in application crashing at run-time. To address this problem a suggestion was made as depicted in http://marc.theaimsgroup.com/?l=openssl-devm=107569526410302w=2. Now even sample implementation is available at http://www.openssl.org/~appro/win32_applink.tar.gz. See 01README.txt for description and self-test instructions. Review and provide feedback. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
Three comments: * Do we really need to have the get_link_table function? I think we should be able to import just the link table itself Imagine that some table entry needs to be initialized with a non-constant, a variable which value needs to be simply copied... Having function feels just more flexible... * We can define the link table in a header file and have the user simply include the header file in only one place OR provide a #define prior to the #include to define the link table in only one place If there are no non-constant variables to be transfered:-) * The link table should contain a table format version number so that in case we need to grow the table in the future it will be possible to do so and produce the appropriate compatibility errors. Or have versioning information embedded into the name, e.g. get_link_table_v1. But one way or another the answer is absolutely! The code appearing in previous mail was just a dummy example. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
Andy Polyakov wrote:
Now let's imagine we pick Microsoft compiler. I'd suggest to perform an
MT build and link it dynamically with MSVCRT.DLL. Idea is to use MSVCRT
primarily for BIO and other strictly internal purposes (keep in mind
that MSCVRT.DLL can be redistributed). At the same time I'd sanitize
functions appearing in grep 'FILE \*' include/openssl/* and replace
calls to stdio with wrappers, which would treat FILE * as opaque
pointer. Idea is to link these wrappers to corresponding stdio functions
provided by compiler environment at run-time. How? We could require user
application to be linked with a module of own design, which exports a
symbol, and then we could refer to this symbol from DllMain in
libeay32.dll for the purposes of linking the wrappers with vendor stdio.
For example. Supplied code to be compiled and linked with user
application could look as following (this is just an example!):
static void *link_table[]={stdin,stout,stderr,fprintf,fread,fclose};
void ** __declspec(dllexport) get_link_table() { return link_table; }
While DllMain in libeay32.dll could:
h=GetModuleHandle(NULL);//.exe image used to create the calling process
proc=GetProcAddress(h,get_link_table);
if (proc==NULL) report_or_log_error_and_exit();
tbl=(*proc)(); // use tbl to feed the wrappers
It should be enough to simply add the supplied module to the target
project to make magic happen and work with any run-time environment or
flag combination. There is a minor problem with Borland, which insists
on different function name decoration and uses different .LIB format,
but it seems that it can be easily resolved with IMPLIB... Thoughts? A.
I like it! :-)
Three comments:
* Do we really need to have the get_link_table function? I think
we should be able to import just the link table itself
* We can define the link table in a header file and have the user
simply include the header file in only one place OR provide a
#define prior to the #include to define the link table in only one
place
* The link table should contain a table format version number so
that in case we need to grow the table in the future it will be
possible to do so and produce the appropriate compatibility errors.
- Jeff
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
As for with the BIO code I am not sure this is a possibility. Note
that once compiled and linked with MSVCRT, BIO would actually work fine
with any run-time environment, because it never exposes FILE * to the
application and sticks to private __iob, private to OpenSLL .DLL, in
cases when application uses incompatible stdio. The real problem is
grep 'FILE \*' include/openssl/*.
Bottom line. In order to make OpenSSL independent from Windows compiler
run-time, it's appears to be necessary to [at least!] eliminate FILE *
references from exposed API.
Here is alternative suggestion I've been pondering over.
What is this thread about? About making it possible to provide binary
toolkit distribution, which preferably can be used with a number of
compiler environments(*): Visual C, .NET, Borland, MinGW(?), Digital
Mars(?). If we manage to achieve the goal of building *unified* binary
distribution with a single compiler, there hardly is a reason for making
it work with every particular compiler.
(*) I leave DJGCC out because it doesn't support dynamic linking, and
Cygwin - because it's rather thick POSIX API emulation layer, thick
enough to deserve separate namespace.
Now let's imagine we pick Microsoft compiler. I'd suggest to perform an
MT build and link it dynamically with MSVCRT.DLL. Idea is to use MSVCRT
primarily for BIO and other strictly internal purposes (keep in mind
that MSCVRT.DLL can be redistributed). At the same time I'd sanitize
functions appearing in grep 'FILE \*' include/openssl/* and replace
calls to stdio with wrappers, which would treat FILE * as opaque
pointer. Idea is to link these wrappers to corresponding stdio functions
provided by compiler environment at run-time. How? We could require user
application to be linked with a module of own design, which exports a
symbol, and then we could refer to this symbol from DllMain in
libeay32.dll for the purposes of linking the wrappers with vendor stdio.
For example. Supplied code to be compiled and linked with user
application could look as following (this is just an example!):
static void *link_table[]={stdin,stout,stderr,fprintf,fread,fclose};
void ** __declspec(dllexport) get_link_table() { return link_table; }
While DllMain in libeay32.dll could:
h=GetModuleHandle(NULL);//.exe image used to create the calling process
proc=GetProcAddress(h,get_link_table);
if (proc==NULL) report_or_log_error_and_exit();
tbl=(*proc)(); // use tbl to feed the wrappers
It should be enough to simply add the supplied module to the target
project to make magic happen and work with any run-time environment or
flag combination. There is a minor problem with Borland, which insists
on different function name decoration and uses different .LIB format,
but it seems that it can be easily resolved with IMPLIB... Thoughts? A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
An easy way to figure out where the dependencies lie are to compare the data structure definitions in the CRT headers. As was pointed out earlier, data structure definitions are apparently not the only concern:-( If there are #ifdef's in the data structure definition then you know there is a guarranteed compatibility issue. In MSVCRT case structures are all the same in all combinations of MT and debug and it's multiple copies of global structures (in stdio case it's most notably __iob and __pioinfo arrays) which cause the trouble. For the reference, source code for MSVCRT is available in Microsoft Platform SDK under src/crt. As for with the BIO code I am not sure this is a possibility. Note that once compiled and linked with MSVCRT, BIO would actually work fine with any run-time environment, because it never exposes FILE * to the application and sticks to private __iob, private to OpenSLL .DLL, in cases when application uses incompatible stdio. The real problem is grep 'FILE \*' include/openssl/*. Bottom line. In order to make OpenSSL independent from Windows compiler run-time, it's appears to be necessary to [at least!] eliminate FILE * references from exposed API. We have the following variables which we want to express in the name of the dll: 1. run-time library [compiler x threading x debugging] Compilers: msvc 6.0 msvs .net msvs .net 2003 others? Given the variety of run-times getting rid of FILE * in API might appear as viable alternative, huh? Unless of course Microsoft and few others (e.g. Borland?) can *guarantee* internal consistency over different releases. Threading; linked to threaded run-time linked to non-threaded run-time I see no need for having non-threaded version (as there is no MT MSVCRT). MT build should siffice for all purposes. Debugging: linked to debugging run-time linked to non-threaded run-time For the sole reason to provide for common copy of global run-time variables (as mentioned above). This is *very* unfortunate sutiation in my personal opinion. 2. 32-bit vs 64-bit Is normally solved through search pathes. At least when it comes to installing a .DLL next to other system DLLs, you *have to* put 32- and 64-bit ones to *different* catalogs. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
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) But what does this naming convention on Unix means *exactly*? Is it actually a requirement that all .a archives or .so objects are prefixed with lib? No. Is it possible to link with a.a? Yes. With a.so? Yes. With a.whatever? Yes! As long as we explicitly name it by full patch. Why do we prepend the name with lib* then? For a sole reason to use it with -l flag at link-time, where it essentialy means prepend the name with lib and look for it *around*, right? This look around is the keyword... Now note that in Windows it is .lib extention which implies looking around, meaning that .lib extension in Windows is essentially equvalent to lib prefix in Unix. This is why you can't observe any Windows naming standard if you disregard extention. On Windows, there's the added complexity of using different run-time libraries depending on if you're using threads or not, Note that this applies exclusively to LIBC (which is a static library!). There is no MT-versions of USER32, KERNEL32 or even MSVCRT. if you built in debug mode or not Note that this applies exclusively to LIBC and MSVCRT, there're no debug counterpart of USER32, KERNEL32 or any other system run-time component needed to execute program compiled for debugging. In other words this MT and debugging naming convention exists exclusively in compiler driver's mind, cl.exe in Microsoft case, and applies exclusively to components tightly coupled to compiler run-time environment [such as LIBC and MSVCRT]. This is another reason why one can't observe any Windows library naming convention. 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. I'd say that we should rather strive for being more like USER32 or any other system component, i.e. being MT-safe and neutral to any particular compiler run-time environment. 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, ^??? It's impossible. You can't intermix 64- and 32-bit objects in same library nor in address space of any particular process. Well, the latter is possible from hardware point of view, but it requires kernel support and there is no any [as far as I know]. Naming convention for 32- vs. 64-bit objects is provided rather through search pathes [at both link- and run-time], than name of the object module per se. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
... this MT and debugging naming convention exists exclusively in compiler driver's mind, cl.exe in Microsoft case, and applies I naturally meant mind in quotes:-) 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, ^??? It's impossible. You can't intermix 64- and 32-bit objects in same library nor in address space of any particular process. Well, the latter is possible from hardware point of view, but it requires kernel support and there is no any [as far as I know]. To avoid possible confusion. You don't need kernel support to perform the switch itself, as it's performed totally in user-land. But(!) the kernel has to be aware of such possibility and act accordingly at next context switch (be it system call, page miss or something else). This is what is missing in kernel. Well, in Windows such switches are taking place in user-land, but they are allowed only in explicitly authorized code segments, most notably in 32-bit NTDLL.DLL, and never in user supplied code segments. In other words you *can* write a code in assembler and switch say from 32- to 64-bit instruction set, but the program will most likely crash shortly after that in a mysterious way. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
In message [EMAIL PROTECTED] on Mon, 26 Jan 2004 12:07:56 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro and other details I'm not aware of. I've heard appro suggestions of creating several variants of the OpenSSL libraries that appro would be used in parallell with the different MSVC libraries, and appro that's where a naming convention is becoming even more important. appro appro I'd say that we should rather strive for being more like USER32 or any appro other system component, i.e. being MT-safe and neutral to any particular appro compiler run-time environment. That would be great, so how does one do that? appro Added to this problem, we have the different register sizes on appro different CPUs (32-bit, 64-bit, and whatever will follow), which seems appro to be difficult to intermix in the same library, appro ^??? It's impossible. I wasn't ready to use such a terminal word. appro You can't intermix 64- and 32-bit objects in same library nor appro in address space of any particular process. Well, the latter appro is possible from hardware point of view, but it requires kernel appro support and there is no any [as far as I know]. Naming appro convention for 32- vs. 64-bit objects is provided rather appro through search pathes [at both link- and run-time], than name appro of the object module per se. Good point. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
Re: Windows DLL naming inconsistency
appro and other details I'm not aware of. I've heard appro suggestions of creating several variants of the OpenSSL libraries that appro would be used in parallell with the different MSVC libraries, and appro that's where a naming convention is becoming even more important. appro appro I'd say that we should rather strive for being more like USER32 or any appro other system component, i.e. being MT-safe and neutral to any particular appro compiler run-time environment. That would be great, so how does one do that? Note that I didn't say it would be trivial, nor that I know exactly how to actually do it:-) I merely said that having observed how system components [e.g. KERNEL32] are linked there seem to be a way to achieve this [noble] goal. Step in the direction would be to understand exactly *why* it's not possible to interchange /MD and /MDd versions. The conclusion might be hard to accept. As it might turn out that the only way is to break dependency from MSVCRT, but the catch is that it's MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h are relatively easy to replace (e.g. by linking with the static LIBC), but probably not stdio.h (linking it statically probably won't work as it most likely will interfere with another copy of stdio and one most likely will have to implement some ascetic replacement). A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
On Mon, Jan 26, 2004, Andy Polyakov wrote: appro and other details I'm not aware of. I've heard appro suggestions of creating several variants of the OpenSSL libraries that appro would be used in parallell with the different MSVC libraries, and appro that's where a naming convention is becoming even more important. appro appro I'd say that we should rather strive for being more like USER32 or any appro other system component, i.e. being MT-safe and neutral to any particular appro compiler run-time environment. That would be great, so how does one do that? Note that I didn't say it would be trivial, nor that I know exactly how to actually do it:-) I merely said that having observed how system components [e.g. KERNEL32] are linked there seem to be a way to achieve this [noble] goal. Step in the direction would be to understand exactly *why* it's not possible to interchange /MD and /MDd versions. The conclusion might be hard to accept. As it might turn out that the only way is to break dependency from MSVCRT, but the catch is that it's MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h are relatively easy to replace (e.g. by linking with the static LIBC), but probably not stdio.h (linking it statically probably won't work as it most likely will interfere with another copy of stdio and one most likely will have to implement some ascetic replacement). A. That I believe is the main problem: all the runtime library dependencies which directly or indirectly call incompatible library functions. There was an attempt to fix this back in SSLeay where the application called one function which passed pointers to the malloc routines but it never worked. I suspect the reason is that it didn't go far enough: it would have to also pass pointers to things like stdio functions too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
We have the following variables which we want to express in the name of the dll: 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-time 2. 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
Re: Windows DLL naming inconsistency
Andy Polyakov wrote: That would be great, so how does one do that? Note that I didn't say it would be trivial, nor that I know exactly how to actually do it:-) I merely said that having observed how system components [e.g. KERNEL32] are linked there seem to be a way to achieve this [noble] goal. Step in the direction would be to understand exactly *why* it's not possible to interchange /MD and /MDd versions. The conclusion might be hard to accept. As it might turn out that the only way is to break dependency from MSVCRT, but the catch is that it's MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h are relatively easy to replace (e.g. by linking with the static LIBC), but probably not stdio.h (linking it statically probably won't work as it most likely will interfere with another copy of stdio and one most likely will have to implement some ascetic replacement). A. What you do is not link to a run-time library and instead use the equivalent versions provided by the Windows kernel as defined in WinBase.h. For string functions you use: lstrcmp lstrcmpi lstrcpyn lstrcpy lstrcat lstrlen For file operations you use: _lopen _lcreat _lread _lwrite _hread _hwrite _lclose _llseek For memory allocation you use a combination of: GlobalAlloc LocalAlloc HeapAlloc TlsAlloc(thread local) depending on what is necessary. Basically, we would approach this by implementing our own run-time library which is in turn implemented in base OS functions. Then we would link the DLL without a run time library. Remember the dependency on the type of run time library is caused by passing of things like FILE pointers and Memory allocations across the application / library boundary. If you can ensure that there are no such crossings then you do not have a dependency. However, with the BIO code I am not sure this is a possibility. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Dr. Stephen Henson wrote: That I believe is the main problem: all the runtime library dependencies which directly or indirectly call incompatible library functions. There was an attempt to fix this back in SSLeay where the application called one function which passed pointers to the malloc routines but it never worked. I suspect the reason is that it didn't go far enough: it would have to also pass pointers to things like stdio functions too. The passing of the memory functions was good enough to allow you to move between debug and non-debug versions of the same library (compiler version and threading model.) It is not good enough to all total portability since there a many classes of run-time functions which have internal data structure dependencies depending on the compiler version and the threading model. The stdio functions are another example of these. An easy way to figure out where the dependencies lie are to compare the data structure definitions in the CRT headers. If there are #ifdef's in the data structure definition then you know there is a guarranteed compatibility issue. smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
That would be great, so how does one do that? Note that I didn't say it would be trivial, nor that I know exactly how to actually do it:-) I merely said that having observed how system components [e.g. KERNEL32] are linked there seem to be a way to achieve this [noble] goal. Step in the direction would be to understand exactly *why* it's not possible to interchange /MD and /MDd versions. The conclusion might be hard to accept. As it might turn out that the only way is to break dependency from MSVCRT, but the catch is that it's MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h are relatively easy to replace (e.g. by linking with the static LIBC), but probably not stdio.h (linking it statically probably won't work as it most likely will interfere with another copy of stdio and one most likely will have to implement some ascetic replacement). A. What you do is not link to a run-time library and instead use the equivalent versions provided by the Windows kernel as defined in WinBase.h. That's exactly what I was referring to when mentioned breaking dependancy from MSVCRT. For file operations you use: _lopen _lcreat I would object to this, as this interface is provided *only* for compatibility with 16-bit versions of Windows. Basically, we would approach this by implementing our own run-time library which is in turn implemented in base OS functions. That's why I wrote that it might be hard to accept, because it's really the last thing we want to do, implement own run-time environment, isn't it? But note that there *are* system DLL which are linked with MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free, while WS32_32.DLL imports fopen, fclose, fgets and some string functions... How does it work there? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
But note that there *are* system DLL which are linked with
MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free,
while WS32_32.DLL imports fopen, fclose, fgets and some string
functions...
Consider following dll.c snippet:
#include stdio.h
#ifdef ME_DLL
__declspec(dllexport)
foo() { printf (%p\n,stdin); }
#else
main () { foo (); printf (%p\n,stdin); }
#endif
Compile it as 'cl -DME_DLL dll.c /LD; cl dll.c dll.lib' [or in other
words link statically with LIBC] and run dll.exe... I get 10008038
00407038 meaning that dll.dll and dll.exe get *separate* copies of
__iob table!? Now compile as 'cl -DME_DLL dll.c /LD /MD; cl dll.c
dll.lib' [or in other words dll.dll is linked dynamically with
MSVCRT]... I now get 7803A690 00407038. Compile as 'cl -DME_DLL dll.c
/LD /MD; cl dll.c dll.lib /MD'... Finally(!) I get 7803A690 7803A690.
But compile as 'cl -DME_DLL dll.c /LD /MD; cl dll.c dll.lib /MDd'
[dll.dll is linked dynamically with MSVCRT.DLL and dll.exe - with
MSVCRTd.DLL]... I get 7803A690 10261828. That must be it! The reason
why it's impossible to interchange debug and non-debug versions.
How does it work there?
I suppose it works as long as no FILE pointer fopened in one module
(e.g. dll.exe in the above example) is passed down to another module
(dll.dll in the above example). Well, most things would probably work
fine (provided that structure layout is the same), but other things,
like fclose, fileno, fdopen might fail just miserably. If malloc/free
relies on some global variable (there is some kind of lock as far as I
can see), then free-ing a chunk allocated in another module can produce
unpredicted result too. 'dumpbin /imports libeay32.dll' also shows that
it imports _write,_read and _close, but not _open. File descriptor in
MSVCRT is an index in __iob table... What a mess... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Windows DLL naming inconsistency
Andy Polyakov wrote: That's why I wrote that it might be hard to accept, because it's really the last thing we want to do, implement own run-time environment, isn't it? But note that there *are* system DLL which are linked with MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free, while WS32_32.DLL imports fopen, fclose, fgets and some string functions... How does it work there? A. You can link to a C Run Time within a DLL as long as you are not sharing data structures with your caller. WS32_32.DLL can use fopen() because it does not accept FILE * from its callers. All of the use of fopen() is local to its own implementation. Threading issues if any are handled internally by ensuring that calls are not made outside of a mutex semaphore lock. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
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. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ 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]
Re: Windows DLL naming inconsistency
Why do you believe that stunnel represents the most widely used naming? There are widely deployed applications from IBM (ships as part of the Access IBM service) Time Warner's Road Runner The Kermit Project (Kermit 95) and many others who distribute ssleay32.dll and libeay32.dll. If anything I would argue that the naming convention needs to be modified to include the version number so as to prevent conflicts between 0.9.5, 0.9.6, 0.9.7, and 0.9.8 all of which have incompatible ABIs. Jeffrey Altman Martin Germann wrote: Hi, I noticed an inconsistency in the windows library names: When compiling OpenSSL on windows with gcc (MinGW), the resulting ssl library is called 'libssl32.dll'. Using MS Visual C++ (and Borland C++, i suppose), the resulting binary will be called 'ssleay32.dll'. This may cause a lot of confusion for users compiling OpenSSL on Win32. Therefore, I suggest to modify the targets for Visual C++ and Borland C++ to also build 'libssl32.dll', as this target name seems to be most widely used (e.g. stunnel). Regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows DLL naming inconsistency
Jeffrey Altman wrote: Why do you believe that stunnel represents the most widely used naming? I just thougt that gcc represents the most widely used naming. There are widely deployed applications from IBM (ships as part of the Access IBM service) Time Warner's Road Runner The Kermit Project (Kermit 95) and many others who distribute ssleay32.dll and libeay32.dll. OK, but what about modifying the gcc Makefile so that it builds ssleay32.dll and libeay32.dll? Regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Windows DLL naming inconsistency
Hi, I noticed an inconsistency in the windows library names: When compiling OpenSSL on windows with gcc (MinGW), the resulting ssl library is called 'libssl32.dll'. Using MS Visual C++ (and Borland C++, i suppose), the resulting binary will be called 'ssleay32.dll'. This may cause a lot of confusion for users compiling OpenSSL on Win32. Therefore, I suggest to modify the targets for Visual C++ and Borland C++ to also build 'libssl32.dll', as this target name seems to be most widely used (e.g. stunnel). Regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
