NOTES FOR THE WINDOWS PLATFORMS
===============================
- [Notes for Windows CE can be found in INSTALL.WCE]
-
Requirement details for native (Visual C++) builds
--------------------------------------------------
+ In addition to the requirements and instructions listed in INSTALL,
+ this are required as well:
+
- 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.
+ Please read NOTES.PERL for more information.
- You need a C compiler. OpenSSL has been tested to build with these:
PREFIX: %ProgramFiles%\OpenSSL
OPENSSLDIR: %CommonProgramFiles%\SSL
+ ALSO NOTE that those directories are usually write protected, even if
+ your account is in the Administrators group. To work around that,
+ start the command prompt by right-clicking on it and choosing "Run as
+ Administrator" before running 'nmake install'. The other solution
+ is, of course, to choose a different set of directories by using
+ --prefix and --openssldir when configuring.
GNU C (Cygwin)
--------------
recognize that binaries targeting Cygwin itself are not interchangeable
with "conventional" Windows binaries you generate with/for MinGW.
+
GNU C (MinGW/MSYS)
------------------
and i686-w64-mingw32-.
- "Classic" builds (Visual C++)
- ----------------
-
- [OpenSSL was classically built using a script called mk1mf. This is
- still available by configuring with --classic. The notes below are
- using this flag, and are tentative. Use with care.
-
- NOTE: this won't be available for long.]
-
- If you want to compile in the assembly language routines with Visual
- C++, then you will need the Netwide Assembler binary, nasmw.exe or nasm.exe, to
- be available on your %PATH%.
-
- Firstly you should run Configure and generate the Makefiles. If you don't want
- the assembly language files then add the "no-asm" option (without quotes) to
- the Configure lines below.
-
- For Win32:
-
- > perl Configure VC-WIN32 --classic --prefix=c:\some\openssl\dir
- > ms\do_nasm
-
- Note: replace the last line above with the following if not using the assembly
- language files:
-
- > ms\do_ms
-
- For Win64/x64:
-
- > perl Configure VC-WIN64A --classic --prefix=c:\some\openssl\dir
- > ms\do_win64a
-
- For Win64/IA64:
-
- > perl Configure VC-WIN64I --classic --prefix=c:\some\openssl\dir
- > ms\do_win64i
-
- Where the prefix argument specifies where OpenSSL will be installed to.
-
- Then from the VC++ environment at a prompt do the following. Note, your %PATH%
- and other environment variables should be set up for 32-bit or 64-bit
- development as appropriate.
-
- > nmake -f ms\ntdll.mak
-
- If all is well it should compile and you will have some DLLs and
- executables in out32dll. If you want to try the tests then do:
-
- > nmake -f ms\ntdll.mak test
-
- To install OpenSSL to the specified location do:
-
- > nmake -f ms\ntdll.mak install
-
- Tweaks:
-
- There are various changes you can make to the Windows compile
- environment. By default the library is not compiled with debugging
- symbols. If you add --debug to the Configure lines above then debugging symbols
- will be compiled in.
-
- By default in 1.1.0 OpenSSL will compile builtin ENGINES into separate shared
- libraries. 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
- into libcrypto32.dll instead.
-
- 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:
+ additionally link your application with 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;
projects / openssl.git / blobdiff