>> 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 <alg>.

> 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                           [EMAIL PROTECTED]

Reply via email to