Better way to build tests. Taken from OpenSSL-1_0_1-stable

[openssl.git] / INSTALL.W32

diff --git a/INSTALL.W32 b/INSTALL.W32
index 849544bf17d3f02fc889bde9b1b070c6051695bf..a0886b3d77499e9757e50b6952e61f5613ebd7cf 100644 (file)
--- a/INSTALL.W32
+++ b/INSTALL.W32
@@ -41,7 +41,7 @@
  C++, then you will need already mentioned Netwide Assembler binary,
  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
 
@@ -81,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.
@@ -103,7 +100,6 @@
  ms\nt.mak
 
 
-
  Borland C++ builder 5
  ---------------------
 
@@ -301,7 +297,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