X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;ds=sidebyside;f=INSTALL.W32;h=3dd7832f4eae0f498352966073e44ff4a13f729a;hb=c5c4246319b27ad7a9516ed772af5d8e6cb08e70;hp=f18f2496779cb2ad1bc501b13e6edc4733d75c38;hpb=e32ea818764f076bd75ae2c33b6319e8027141e8;p=oweals%2Fopenssl.git

diff --git a/INSTALL.W32 b/INSTALL.W32
index f18f249677..3dd7832f4e 100644
--- a/INSTALL.W32
+++ b/INSTALL.W32
@@ -49,7 +49,9 @@
 
  Firstly you should run Configure:
 
- > perl Configure VC-WIN32
+ > perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
+
+Where the prefix argument specifies where OpenSSL will be installed to.
 
  Next you need to build the Makefiles and optionally the assembly language
  files:
@@ -77,8 +79,12 @@
  If all is well it should compile and you will have some DLLs and executables
  in out32dll. If you want to try the tests then do:
  
- > cd out32dll
- > ..\ms\test
+ > nmake -f ms\ntdll.mak test
+
+
+To install OpenSSL to the specified location do:
+
+> nmake -f ms\ntdll.mak install
 
  Tweaks:
 
@@ -88,6 +94,12 @@
  compiled in. Note that mk1mf.pl expects the platform to be the last argument
  on the command line, so 'debug' must appear before that, as all other options.
 
+
+ By default in 0.9.8 OpenSSL will compile builtin ENGINES into the libeay32.dll
+ shared library. If you specify the "no-static-engine" option on the command
+ line to Configure the shared library build (ms\ntdll.mak) will compile the
+ engines as separate DLLs.
+
  The default Win32 environment is to leave out any Windows NT specific
  features.
 
@@ -98,6 +110,8 @@
  You can also build a static version of the library using the Makefile
  ms\nt.mak
 
+
+
  Borland C++ builder 5
  ---------------------
 
@@ -287,3 +301,21 @@
  (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.