[openssl-commits] [openssl] OpenSSL_1_0_2-stable update

Richard Levitte levitte at openssl.org
Mon May 16 15:48:11 UTC 2016


The branch OpenSSL_1_0_2-stable has been updated
       via  05fc0bae8661aaca9b4c11071c1bd7bf06d1b90f (commit)
      from  688c10544d2ba32428830d0634e91233c20920c1 (commit)


- Log -----------------------------------------------------------------
commit 05fc0bae8661aaca9b4c11071c1bd7bf06d1b90f
Author: Richard Levitte <levitte at openssl.org>
Date:   Thu May 12 22:34:17 2016 +0200

    Windows: Add CRYPT32.LIB to the libraries to link your app with
    
    Reviewed-by: Matt Caswell <matt at openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/1064)

-----------------------------------------------------------------------

Summary of changes:
 INSTALL.W32 | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/INSTALL.W32 b/INSTALL.W32
index 80e5382..bd10187 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;


More information about the openssl-commits mailing list