From 05fc0bae8661aaca9b4c11071c1bd7bf06d1b90f Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Thu, 12 May 2016 22:34:17 +0200 Subject: [PATCH] Windows: Add CRYPT32.LIB to the libraries to link your app with Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/1064) --- INSTALL.W32 | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/INSTALL.W32 b/INSTALL.W32 index 80e538273e..bd10187c32 100644 --- a/INSTALL.W32 +++ b/INSTALL.W32 @@ -300,17 +300,17 @@ If you link with static OpenSSL libraries [those built with ms/nt.mak], 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: + 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; -- 2.25.1