The latest two versions of OpenSSL I’ve released only support Windows XP SP2, Windows Server 2003 SP1 and newer.
The affected OpenSSL versions are:
0.9.8 q, 0.9.8 r, 1.0.0 c and 1.0.0 d.
Technical Background:
The mentioned libraries statically link against a version of msvcrt.lib which include references to EncodePointer/DecodePointer and _except_handler4_common. EncodePointer and DecodePointer are only available with the aforementioned OS versions. The CRT exception handler 4 has been introduced with newer versions of msvcrt.dll too (XP iirc).
Since mid 2010 I used a different approach in building the libraries, instead of my old-fashined mingw gcc 3.4.5 build chain Salvor came up with the idea to use VC++ with special adjustments as posted in his comment here.
Typically DLLs created with VC newer than 6 have dependencies to the corresponding runtime libraries (the well-known msvcrt##.dll). Using his approach removed this dependencies. My initial tests with XP, 2003, Vista and Win 7 didn’t show any problems, Dependency Walker had not shown problems too. But as it turns out now Salvor didn’t take the changed feature set of msvcrt.dll into account. And I didn’t do either.
I spend a large amount of time within the past two weeks to test all available build chains possible, including VC 2008 and 2010 together with masm and nasm, mingw with gcc 3.4.5 up to gcc 4.5.2 and today even the Windows Device Driver Kit 7.1 together with PSDK 2003 and SDK for Win 7 and .NET 4. Using the DDK was an interesting approach to circumvent the mentioned problems (Thanks to Mladen Turk for his interesting post titled Fighting the MSVCRT.DLL hell), but fails with the exception handler 4 too.
I am aware of the stubs published at StackOverflow regarding this issue with Encode/DecodePointer, but believe me that’s nothing we want in productive code.
Currently the only two working alternatives are:
As we switched away from gcc 3.4.5 for several reasons (size and performance of the created libraries) I would prefer using VC++ 6.0. The OpenSSL build chain for gcc 4 is broken like the BCB chain is for years now. I cannot afford spending so much time on fixing the perl scripts with every OpenSSL release. Currently I publish four sets of files with every OpenSSL release (0.9.8.x for x32 and x64, 1.0.0.x for x32 and x64) and create 2 additional ones for internal FIPS 140 tests. Together with testing the libraries and the preps needed for publishing this became a lot of work compared to the past years.
Why don’t you just use other precompiled binaries?
I know what you’re talking about. The precompiled libraries other vendors like Shining Light publish do require the MS VC runtime dlls. We want to give the Indy the possibility to ship OpenSSL without any VCRT dlls. Afaik the newer VCRT requires that you include the official MSI packages. This has many drawbacks.
What do you need to do now?
Please check if you use any of the above mentioned Indy OpenSSL libraries in a productive environment together with an OS older than the supported ones. If that may be true I would suggest updating your release information, platform requirements or inform your users / customers where needed.
This is only required if you use our libraries (as published on the Fulgan mirror).
Note the reverting back to an older version of OpenSSL is not an option due to well-known security issues as published on the OpenSSL site or US CERT.
What can you do to help?
I would like to ask for a donation of a single copy license of MS VC++ 6 or MS Visual Studio 6 (English). This would help tremendously with the effort to keep the old OSs like Win 2000 supported way beyond what MS does on it’s own. We have a bunch of licenses, tools and compilers available here at the office but nothing that old as the ancient VC 6 ![;)]()
So, if anybody is willing to help the Indy team (and me) drop a mail to winkelsdorf [at] gmail [dot] com.
Thanks to Jason Smith for bringing up this issue to the Indy team at the Atozed Newsgroup!
Cheers,
Arvid
[Edit2]
Removed my rant about those DelphiFeeds Off-Topic Voters ![;)]()
[/Edit2]
![]()
![]()
