From: Richard Levitte Date: Thu, 12 May 2016 20:32:12 +0000 (+0200) Subject: Windows: Add CRYPT32.LIB to the libraries to link you app with X-Git-Tag: OpenSSL_1_1_0-pre6~831 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=531e9dcc243a967832fbe784dfc0d226422216b2;p=oweals%2Fopenssl.git Windows: Add CRYPT32.LIB to the libraries to link you app with Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/1063) --- diff --git a/NOTES.WIN b/NOTES.WIN index 1c10b758df..f2fb0876d1 100644 --- a/NOTES.WIN +++ b/NOTES.WIN @@ -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;