Windows: Add CRYPT32.LIB to the libraries to link you app with

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1063)
This commit is contained in:
Richard Levitte 2016-05-12 22:32:12 +02:00
parent 6385ffd12d
commit 531e9dcc24

View file

@ -105,18 +105,18 @@
This section applies to non-Cygwin builds.
If you link with static OpenSSL libraries then you're expected to
additionally link your application with WS2_32.LIB, ADVAPI32.LIB,
GDI32.LIB and USER32.LIB. Those developing non-interactive service
applications might feel concerned about linking with the latter two,
as they are justly associated with interactive desktop, which is not
available to service processes. The toolkit is designed to detect in
which context it's currently executed, GUI, console app or service,
and act accordingly, namely whether or not to actually make GUI calls.
Additionally those who wish to /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL
and actually keep them off service process should consider
implementing and exporting from .exe image in question own
_OPENSSL_isservice not relying on USER32.DLL.
E.g., on Windows Vista and later you could:
additionally link your application with WS2_32.LIB, GDI32.LIB,
ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those developing
non-interactive service applications might feel concerned about
linking with GDI32.LIB and USER32.LIB, as they are justly associated
with interactive desktop, which is not available to service
processes. The toolkit is designed to detect in which context it's
currently executed, GUI, console app or service, and act accordingly,
namely whether or not to actually make GUI calls. Additionally those
who wish to /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and
actually keep them off service process should consider implementing
and exporting from .exe image in question own _OPENSSL_isservice not
relying on USER32.DLL. E.g., on Windows Vista and later you could:
__declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)
{ DWORD sess;