131 lines
4.7 KiB
Text
131 lines
4.7 KiB
Text
|
|
NOTES FOR THE WINDOWS PLATFORMS
|
|
===============================
|
|
|
|
[Notes for Windows CE can be found in INSTALL.WCE]
|
|
|
|
Requirement details for native (Visual C++) builds
|
|
--------------------------------------------------
|
|
|
|
- You need Perl. We recommend ActiveState Perl, available from
|
|
http://www.activestate.com/ActivePerl.
|
|
You also need the perl module Text::Template, available on CPAN.
|
|
Please read README.PERL for more information.
|
|
|
|
- You need a C compiler. OpenSSL has been tested to build with these:
|
|
|
|
* Visual C++
|
|
|
|
- Netwide Assembler, a.k.a. NASM, available from http://www.nasm.us,
|
|
is required if you intend to utilize assembler modules. Note that NASM
|
|
is the only supported assembler. The Microsoft provided assembler is NOT
|
|
supported.
|
|
|
|
|
|
Visual C++ (native Windows)
|
|
---------------------------
|
|
|
|
Installation directories
|
|
|
|
The default installation directories are derived from environment
|
|
variables.
|
|
|
|
For VC-WIN32, the following defaults are use:
|
|
|
|
PREFIX: %ProgramFiles(86)%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramFiles(86)%\SSL
|
|
|
|
For VC-WIN32, the following defaults are use:
|
|
|
|
PREFIX: %ProgramW6432%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramW6432%\SSL
|
|
|
|
Should those environment variables not exist (on a pure Win32
|
|
installation for examples), these fallbacks are used:
|
|
|
|
PREFIX: %ProgramFiles%\OpenSSL
|
|
OPENSSLDIR: %CommonProgramFiles%\SSL
|
|
|
|
|
|
GNU C (Cygwin)
|
|
--------------
|
|
|
|
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.
|
|
|
|
To build OpenSSL using Cygwin, you need to:
|
|
|
|
* Install Cygwin (see http://cygwin.com/)
|
|
|
|
* Install Cygwin Perl and ensure it is in the path. Recall that
|
|
as least 5.10.0 is required.
|
|
|
|
* Run the Cygwin bash shell
|
|
|
|
Apart from that, follow the Unix instructions in INSTALL.
|
|
|
|
NOTE: "make test" and normal file operations may fail in directories
|
|
mounted as text (i.e. mount -t c:\somewhere /home) due to Cygwin
|
|
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)
|
|
------------------
|
|
|
|
* Compiler and shell environment installation:
|
|
|
|
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 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).
|
|
|
|
* It is also possible to cross-compile it on Linux by configuring
|
|
with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'.
|
|
Other possible cross compile prefixes include x86_64-w64-mingw32-
|
|
and i686-w64-mingw32-.
|
|
|
|
|
|
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.
|