>> Could you please test the other suggested bn_lcl.h modification? While
>> you're on it...

>
> I cannot actually test it... I can compile and users may test.
> I don't have a win64 machine.


How is it tested? Implicitly by an application being inter-operable with
another? Meaning that only only part of algorithms is tested...

> And I don't know how exactly I can check for speed...


Same as on unix: openssl speed .

> I can send you binaries to test if you like.


I managed to produce them myself with
mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine,
modified bn_lcl.h gives ~2x improvement. All tests pass except for the
last Whirlpool test. It's a compiler bug, because if I drop optimization
level to -O1 when compiling wp_block.c, the test passes.

>> >> Also. As NT is natively UNICODE, and there are no non-NT Win64
>> >> implementations(*), there is no reason to favor legacy ANSI interfaces.
>> >> Could you verify that it compiles and works with -DUNICODE -D_UNICODE
>> >> added to config line?
>> >

>>

> Except one modification I had to do, updated in the patch.


Strangely enough the code in question is not compiled in VC-* build...
Basically there is no need for GetModuleHandle("avdapi32") and
consequent GetProcAddress calls, because the functions in question are
present on all WinNT *and* Win9x. On latter they do nothing, but they
are present, so that application won't suffer from startup errors if you
link them explicitly.

>> Quoting util/VC-32.pl: "As per 0.9.8 release remaining warnings were
>> explicitly examined and considered safe to ignore." It naturally does
>> not necessarily apply to HEAD, but there is awareness of the problem.

>
> Well... I don't run this script


I was just trying to say that the question was posed and looked into. A.


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org