Browse Source

Clarify NOTES.WIN.

Reviewed-by: Richard Levitte <levitte@openssl.org>
master
Andy Polyakov 7 years ago
committed by Richard Levitte
parent
commit
ad839325e1
1 changed files with 43 additions and 37 deletions
  1. +43
    -37
      NOTES.WIN

+ 43
- 37
NOTES.WIN View File

@ -28,17 +28,14 @@
Cygwin implements a Posix/Unix runtime system (cygwin1.dll) on top of the
Windows subsystem and provides a bash shell and GNU tools environment.
Consequently, a make of OpenSSL with Cygwin is virtually identical to the
Unix procedure. It is also possible to create Windows binaries that only
use the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using
MinGW. MinGW can be used in the Cygwin development environment or in a
standalone setup as described in the following section.
Unix procedure.
To build OpenSSL using Cygwin, you need to:
* Install Cygwin (see http://cygwin.com/)
* Install Perl and ensure it is in the path. Both Cygwin perl
(5.6.1-2 or newer) and ActivePerl work.
* Install Cygwin Perl and ensure it is in the path. Recall that
as least 5.10.0 is required.
* Run the Cygwin bash shell
@ -49,6 +46,12 @@
stripping of carriage returns. To avoid this ensure that a binary
mount is used, e.g. mount -b c:\somewhere /home.
It is also possible to create "conventional" Windows binaries that use
the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using MinGW
development add-on for Cygwin. MinGW is supported even as a standalone
setup as described in the following section. In the context you should
recognize that binaries targeting Cygwin itself are not interchangeable
with "conventional" Windows binaries you generate with/for MinGW.
GNU C (MinGW/MSYS)
-------------
@ -57,7 +60,9 @@
MinGW and MSYS are available from http://www.mingw.org/, both are
required. Run the installers and do whatever magic they say it takes
to start MSYS bash shell with GNU tools on its PATH.
to start MSYS bash shell with GNU tools and matching Perl on its PATH.
"Matching Perl" refers to chosen "shell environment", i.e. if built
under MSYS, then Perl compiled for MSYS is highly recommended.
Alternativelly, one can use MSYS2 from http://msys2.github.io/,
which includes MingW (32-bit and 64-bit).
@ -68,36 +73,6 @@
and i686-w64-mingw32-.
Linking your application
------------------------
If you link with static OpenSSL libraries 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:
__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
OpenSSL BIO layer and your compiler run-time. See the OPENSSL_Applink
manual page for further details.
"Classic" builds (Visual C++)
----------------
@ -166,3 +141,34 @@
You can also build a static version of the library using the Makefile
ms\nt.mak
Linking your application
------------------------
This section applies to non-Cygwin builds.
If you link with static OpenSSL libraries 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:
__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
OpenSSL BIO layer and your compiler run-time. See the OPENSSL_Applink
manual page for further details.

Loading…
Cancel
Save