Remove inadvertently commited test binaries
[openssl.git] / INSTALL.W32
index d23c4baf625e783bda70830629d019cb835b66a9..bd10187c32244fb4b3d0773eaea550b0825d0a19 100644 (file)
@@ -29,7 +29,7 @@
   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.
 
  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
 
  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. 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:
+ 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;