potential corruption problem if user manages to inter-leave aligined
and misaligned requests [as well as some MSC-specific tweaks].

performing AES encryption in hardware, as well as one accessing
hardware RNG. As you surely imagine this engine access this
extended instruction set. Well, only AES for the moment, support
for RNG is to be added later on...
PR: 889
Submitted by: Michal Ludvig <michal@logix.cz>

Obtained from: http://www.logix.cz/michal/devel/padlock/

COFF and a.out targets [similar to ELF targets]. You might notice some
rudementary support for shared mingw builds under cygwin. It works (it
produces cryptoeay32.dll and ssleay32.dll with everything exported by
name), but it's primarily for testing/debugging purposes, at least for
now...

going out...

if we explicitly intruct the linker to set entry point, then we become
obliged to initialize run-time library. Instead we can pick name run-time
will call and such name is DllMain. Note that this applies to both
"native" Win32 environment and Cygwin:-)

static variable

http://cvs.openssl.org/chngview?cn=12493. Now all platform should
be operational, while SSE2 code pathes get engaged on ELF platforms
only.

is to have a placeholder to small routines, which can be written only
in assembler. In IA-32 case this includes processor capability
identification and access to Time-Stamp Counter. As discussed earlier
OPENSSL_ia32cap is introduced to control recently added SSE2 code
pathes (see docs/crypto/OPENSSL_ia32cap.pod). For the moment the
code is operational on ELF platforms only. I haven't checked it yet,
but I have all reasons to believe that Windows build should fail to
link too. I'll be looking into it shortly...

stop complaining about loss of precision, but explicit cast.

because "wrong" casts will either be optimized away or never performed.

libraries. Old .sl extension works just fine, but it .so which is default.

Win64 comes in two flavors, IA-64/Itanium and AMD64/Opteron. The
suggestion is to refer to former as WIN64I and latter - WIN64A