On 6 Jan 01, at 8:59, Richard Levitte - VMS Whacker wrote:
> From: "Rob Neff" [EMAIL PROTECTED]>
>
> neff.ra> The following is copied from MS VC++ 6.0 online help:
>
> Thanks, that was very helpful!
>
To expand Rob's mail, this is a part of a document I wrote some time ago which discuss this
From: "Rob Neff" [EMAIL PROTECTED]
neff.ra #ifdef MYDLL_EXPORTS
neff.ra #define MYDLL_API __declspec(dllexport)
neff.ra #else
neff.ra #define MYDLL_API __declspec(dllimport)
neff.ra #endif
neff.ra
neff.ra extern MYDLL_API int nTestdll;
neff.ra
neff.ra MYDLL_API int fnTestdll(void);
That's
threads within the
same process must be synchronized...
- Original Message -
From: Toomas Kiisk [EMAIL PROTECTED]
To: OpenSSL Development [EMAIL PROTECTED]
Sent: Wednesday, January 03, 2001 4:37 AM
Subject: Re: Windows, DLLs and variables.
On Fri, 29 Dec 2000, Dr S N Henson wrote
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED]
levitte Why should an external application use OPENSSL_EXTERN for it's own
levitte DLL's? Or why should an external DLL use OPENSSL_EXTERN for it's own
levitte purposes? I see such use as a flaw in that applications or DLL.
levitte
From: Dr S N Henson [EMAIL PROTECTED]
drh An external DLL might use DECLARE_ASN1_FUNCTIONS() in its header file
drh and then drag in OPENSSL_EXTERN if it was added to the macro.
drh OPENSSL_EXTERN would then need that behaviour to work.
drh
drh If OPENSSL_EXTERN is considered illegal in
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
drh An external DLL might use DECLARE_ASN1_FUNCTIONS() in its header file
drh and then drag in OPENSSL_EXTERN if it was added to the macro.
drh OPENSSL_EXTERN would then need that behaviour to work.
drh
drh If
An issue has arisen with Windows DLLs and the new ASN1 code...
The new ASN1 code declares its ASN1 modules in terms of constant
structures called ASN1_ITEM. The i2d, d2i, free and new operations are
now declared as wrapper functions which call a high level ASN1_item_*()
function and include a
From: Dr S N Henson [EMAIL PROTECTED]
drh An issue has arisen with Windows DLLs and the new ASN1 code...
[...]
drh AFAICS this needs a "DATA" declaration in the DEF file *and* a custom
drh header declaration otherwise it doesn't work (linker errors or invalid
drh data).
drh
drh The header
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
drh An issue has arisen with Windows DLLs and the new ASN1 code...
[...]
drh AFAICS this needs a "DATA" declaration in the DEF file *and* a custom
drh header declaration otherwise it doesn't work (linker errors or
From: Dr S N Henson [EMAIL PROTECTED]
drh definitions for the Win32 case. Of course, what you say above means
drh that OPENSSL_EXTERN will have different values depending on if you're
drh building the DLL or using it. That's pretty easy to do if we use a
drh macro BUILD_SHLIB as a flag.
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
drh definitions for the Win32 case. Of course, what you say above means
drh that OPENSSL_EXTERN will have different values depending on if you're
drh building the DLL or using it. That's pretty easy to do if
From: Dr S N Henson [EMAIL PROTECTED]
drh Well the relevant functions and variables are declared with a macro:
drh
drh DECLARE_ASN1_FUNCTIONS(SOME_ASN1_THING)
Doesn't look too difficult. Replace "extern const" with
"OPENSSL_EXTERN const"...
drh this appears in some OpenSSL headers. It may
From what I remember, the MS style was for each library to have its own
XXX_IMPORT macro:
#ifndef BUILDING_XXX
#define XXX_IMPORT __declspec(dllimport)
#else
#define XXX_IMPORT __declspec(dllexport)
#endif
And only the XXX makefiles had -DBUILDING_XXX (or
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
drh Well the relevant functions and variables are declared with a macro:
drh
drh DECLARE_ASN1_FUNCTIONS(SOME_ASN1_THING)
Doesn't look too difficult. Replace "extern const" with
"OPENSSL_EXTERN const"...
From: Dr S N Henson [EMAIL PROTECTED]
drh What I'm not sure about is how this can work with an application that
drh wants to compile an additional external DLL which might effectively need
drh OPENSSL_EXTERN (via DECLARE_...) to mean two different things in
drh different places. That is import
drh compiling code that is going to be linked into the DLL you need to
drh precede the variable with:
drh
drh _declspec( dllexport )
drh
drh however when linking to these variables you need:
drh
drh _declspec( dllimport )
drh
drh So the declaration needs to be different
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
drh What I'm not sure about is how this can work with an application that
drh wants to compile an additional external DLL which might effectively need
drh OPENSSL_EXTERN (via DECLARE_...) to mean two different
17 matches
Mail list logo
