Updated to openssl-1.0.0c

1 files changed, 21 insertions, 1 deletions

diff --git a/openssl/INSTALL.W32 b/openssl/INSTALL.W32
index 77441f1ef..d23c4baf6 100644
--- a/openssl/INSTALL.W32
+++ b/openssl/INSTALL.W32
@@ -185,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
@@ -297,7 +306,18 @@
  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.
+ 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