Fix #if _MSC_VER clause in aes_locl.h
[openssl.git] / INSTALL.W32
index 78d289e16a5e8628a507a15924fccfdbff259963..a4b6700e2e26dd791c3c10f2cb81ac7b5661b83a 100644 (file)
@@ -3,6 +3,7 @@
  ----------------------------------
 
  [Instructions for building for Windows CE can be found in INSTALL.WCE]
+ [Instructions for building for Win64 can be found in INSTALL.W64]
 
  Heres a few comments about building OpenSSL in Windows environments.  Most
  of this is tested on Win32 but it may also work in Win 3.1 with some
        $ md c:\openssl\lib
        $ md c:\openssl\include
        $ md c:\openssl\include\openssl
-       $ copy /b inc32\*               c:\openssl\include\openssl
+       $ copy /b inc32\openssl\*       c:\openssl\include\openssl
        $ copy /b out32dll\ssleay32.lib c:\openssl\lib
        $ copy /b out32dll\libeay32.lib c:\openssl\lib
        $ copy /b out32dll\ssleay32.dll c:\openssl\bin
  (e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
  rely on CRYPTO_malloc_init() solving your problem, and you should
  consistently use the multithreaded library.
+
+ Linking your application
+ ------------------------
+
+ If you link with static OpenSSL libraries [those built with ms/nt.mak],
+ then you're expected to additionally link your application with
+ WSOCK32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
+ non-interactive service applications might feel concerned about linking
+ with 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.
+
+ If you link with OpenSSL .DLLs, then you're expected to include into
+ your application code small "shim" snippet, which provides glue between
+ OpenSSL BIO layer and your compiler run-time. Look up OPENSSL_Applink
+ reference page for further details.