X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=INSTALL.W32;h=bd10187c32244fb4b3d0773eaea550b0825d0a19;hp=76beee31822f9d057f0af5b96ded720d144881cd;hb=3984ef0b72831da8b3ece4745cac4f8575b19098;hpb=3189772e07dafe359f84ada71001515127bc396d

diff --git a/INSTALL.W32 b/INSTALL.W32
index 76beee3182..bd10187c32 100644
--- a/INSTALL.W32
+++ b/INSTALL.W32
@@ -25,11 +25,11 @@
   * Borland C
   * GNU C (Cygwin or MinGW)
 
-- even though optional for non-gcc builds, Netwide Assembler, a.k.a.
-  NASM, available from http://sourceforge.net/projects/nasm is
-  recommended.
+- Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/
+  is required if you intend to utilize assembler modules. Note that NASM
+  is now the only supported assembler.
 
- If you are compiling from a tarball or a CVS snapshot then the Win32 files
+ If you are compiling from a tarball or a Git snapshot then the Win32 files
  may well be not up to date. This may mean that some "tweaking" is required to
  get it all to work. See the trouble shooting section later on for if (when?)
  it goes wrong.
@@ -39,11 +39,11 @@
 
  If you want to compile in the assembly language routines with Visual
  C++, then you will need already mentioned Netwide Assembler binary,
- nasmw.exe, to be available on your %PATH%.
+ nasmw.exe or nasm.exe, to be available on your %PATH%.
 
- Firstly you should run Configure:
+ Firstly you should run Configure with platform VC-WIN32:
 
- > perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
+ > perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
 
  Where the prefix argument specifies where OpenSSL will be installed to.
 
@@ -56,6 +56,7 @@
 
  - If you don't want to use the assembly language files at all then run:
 
+   > perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
    > ms\do_ms
 
  If you get errors about things not having numbers assigned then check the
@@ -80,16 +81,13 @@
 
  There are various changes you can make to the Win32 compile
  environment. By default the library is not compiled with debugging
- symbols. If you add 'debug' to the mk1mf.pl lines in the do_* batch
- file then debugging symbols will be 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.
+ symbols. If you use the platform debug-VC-WIN32 instead of VC-WIN32
+ then debugging symbols will be compiled in.
 
-
- By default in 0.9.8 OpenSSL will compile builtin ENGINES into the
- libeay32.dll shared library. If you specify the "no-static-engine"
+ By default in 1.0.0 OpenSSL will compile builtin ENGINES into the
+ separate shared librariesy. If you specify the "enable-static-engine"
  option on the command line to Configure the shared library build
- (ms\ntdll.mak) will compile the engines as separate DLLs.
+ (ms\ntdll.mak) will compile the engines into libeay32.dll instead.
 
  The default Win32 environment is to leave out any Windows NT specific
  features.
@@ -102,7 +100,6 @@
  ms\nt.mak
 
 
-
  Borland C++ builder 5
  ---------------------
 
@@ -188,6 +185,15 @@
    required. Run the installers and do whatever magic they say it takes
    to start MSYS bash shell with GNU tools on its PATH.
 
+   N.B. Since source tar-ball can contain symbolic links, it's essential
+   that you use accompanying MSYS tar to unpack the source. It will
+   either handle them in one way or another or fail to extract them,
+   which does the trick too. Latter means that you may safely ignore all
+   "cannot create symlink" messages, as they will be "re-created" at
+   configure stage by copying corresponding files. Alternative programs
+   were observed to create empty files instead, which results in build
+   failure.
+
  * Compile OpenSSL:
 
    $ ./config
@@ -251,7 +257,7 @@
 
  then ms\do_XXX should not give a warning any more. However the numbers that
  get assigned by this technique may not match those that eventually get
- assigned in the CVS tree: so anything linked against this version of the
+ assigned in the Git tree: so anything linked against this version of the
  library may need to be recompiled.
 
  If you get errors about unresolved symbols there are several possible
@@ -294,13 +300,24 @@
 
  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.
+ 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;
+	    if (ProcessIdToSessionId(GetCurrentProcessId(),&sess))
+	        return sess==0;
+	    return FALSE;
+	}
 
  If you link with OpenSSL .DLLs, then you're expected to include into
  your application code small "shim" snippet, which provides glue between