Submitted by: Paul Green <Paul.Green@stratus.com>
Reviewed by: steve

Improved PRNG seeding for VOS.

e_os2.h, this should fix WIN32 compilation issues and hopefully avoid
conflicts with other headers which may workaround ssize_t in different ways.

ignored.

in legacy code). I'd rather just remove it along with legacy interface,
but it's probably not as appropriate as I'd like. Reimplement the macro.

PR: 1312
Submitted by: Oliver Tappe <zooey@hirschkaefer.de>
Reviewed by: Ulf Moeller

PR: 1247

static variable

PR: 499

PR: 780
Submitted by: Verdon Walker <VWalker@novell.com>
Reviewed by: Richard Levitte

against DJGPP, and much more restricted than previous definitions.

of OPENSSL_NO_FP_API on existence of OPENSSL_SYS_MSDOS to e_os2.h.

PR: 227

Correct misspelled VXWORKS macros.
Add VXWORKS identifying macros to e_os2.h.
Add required inclusions and mappings for VxWorks in e_os.h.
A few small modifications to make OpenSSL build and work on VxWorks.
PR: 253, except for the  change that was handled in an earlier
         commit, and a request for easy build of just parts of OpenSSL.

PR: 62

Submitted by Compaq.

Contributed by "Brian Havard" <brianh@kheldar.apana.org.au>

mistake.

redefined variables.

Fix OPENSSL_IMPLEMENT_GLOBAL.

Allow Win32 to use EXPORT_VAR_AS_FN in mkdef.pl

make update.

Under VC++ _DLL is set to indicate that the application
will be linked against the DLL runtime library. It is
automatically set when /MD is used.

As a result OpenSSL shouldn't use _DLL to determine if
it should set OPENSSL_OPT_WINDLL because this will
cause linkage conflicts with static builds which do
include the /MD compiler switch.

for Windows compilations if DLL linkage is required or not.

functions on platform were that's the best way to handle exporting
global variables in shared libraries.  To enable this functionality,
one must configure with "EXPORT_VAR_AS_FN" or defined the C macro
"OPENSSL_EXPORT_VAR_AS_FUNCTION" in crypto/opensslconf.h (the latter
is normally done by Configure or something similar).

To implement a global variable, use the macro OPENSSL_IMPLEMENT_GLOBAL
in the source file (foo.c) like this:

	OPENSSL_IMPLEMENT_GLOBAL(int,foo)=1;
	OPENSSL_IMPLEMENT_GLOBAL(double,bar);

To declare a global variable, use the macros OPENSSL_DECLARE_GLOBAL
and OPENSSL_GLOBAL_REF in the header file (foo.h) like this:

	OPENSSL_DECLARE_GLOBAL(int,foo);
	#define foo OPENSSL_GLOBAL_REF(foo)
	OPENSSL_DECLARE_GLOBAL(double,bar);
	#define bar OPENSSL_GLOBAL_REF(bar)

The #defines are very important, and therefore so is including the
header file everywere where the defined globals are used.

The macro OPENSSL_EXPORT_VAR_AS_FUNCTION also affects the definition
of ASN.1 items, but that structure is a bt different.

The largest change is in util/mkdef.pl which has been enhanced with
better and easier to understand logic to choose which symbols should
go into the Windows .def files as well as a number of fixes and code
cleanup (among others, algorithm keywords are now sorted
lexicographically to avoid constant rewrites).

The reason is that some parts are only included when certain other
include files have been included.

Also, it seems that the rest of the OpenSSL code assumes that all
kinds of M$ Windows are MSDOS as well...

sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.

I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.

default value OPENSSL_IMPORT.  Explain the use of all those macros.

"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order.  Thusly fixed.

Allow configuring the name of that header file.