Figured couple of clarification notes are due:-)

> Added files: (Branch: OpenSSL_0_9_8-stable)
> openssl/ms do_win64a.bat do_win64i.bat
> Modified files: (Branch: OpenSSL_0_9_8-stable)
> openssl Configure e_os.h
> openssl/crypto cryptlib.c mem_dbg.c
> openssl/util mk1mf.pl
> openssl/util/pl VC-32.pl
>
> Log:
> To secure Win64 API I'm throwing in this minimalistic Win64 support.


What does "to secure API" mean? This means to explicitly assign Win64
config options affecting binary compatibility, options which will be
supported through 0.9.8 and most likely future releases.

What does "minimalistic" mean? It means that no assembler modules were
engaged yet and [most importantly] following:

> +if ($FLAVOR =~ /WIN64/)
> + {
> + # Note that we currently don't have /WX on Win64! There is a lot of
> + # warnings, but only of two types:
> + #
> + # C4344: conversion from '__int64' to 'int/long', possible loss of data
> + # C4267: conversion from 'size_t' to 'int/long', possible loss of data
> + #
> + # Amount of latter type is minimized by aliasing strlen to function of
> + # own desing and limiting its return value to 2GB-1 (see e_os.h). As
> + # per 0.9.8 release remaining warnings were explicitly examines and
> + # considered safe to ignore.
> + #
> + $cflags=' /MD /W3 /Ox /Gs0 /GF /Gy /nologo -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DOPENSSL_SYSNAME_WIN32 -DOPENSSL_SYSNAME_WINNT -DUNICODE -D_UNICODE';
> + $lflags="/nologo /subsystem:console /opt:ref";
> + }


What does "safe to ignore" mean? It means that given the context of
every warning, no loss of data is actually taking place. At least it's
believed not to:-) This is based on visual code audit and the fact that
toolkit is known to work on a number of other 64-bit platforms, which
are subject to "data loss" exactly as much as Win64, but which compilers
are not as picky/fastidious as Microsoft ones. It was even tempting to
disable above mentioned warnings with /wd4355 and /wd4267, but for now
I've chosen to drop /WX instead. The question is what do we do about
these warnings in long run. Well, purify API:-) Does it mean that API
will change? Most likely. However!!! Fortunately such changes won't
necessarily have to break backward binary compatibility. Or in other
words application programs compiled with "non-purified" headers don't
have to break when linked with "purified" .DLL at run-time. Naturally
not vice-versa. Current Win64-specific API limitations comprise [but not
necessarily limited to]: null-terminated strings may not be longer than
2G-1 bytes, longer strings are treated as zero-length; dynamically and
*internally* allocated chunks can't be larger than 2G-1 bytes; inability
to encrypt/decrypt chunks of data larger than 2G-1 bytes [it's possibly
to *hash* chunks of arbitrary size through]. Neither of these are
actually big deal and hardly encountered in real-life applications... A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org