Re-9: libeay32.dll error with standalone

[Jim Bufalini]

Hey Matthias,

I've put this one back on-list also so other developers and RunRev will be
aware...

> with your stack i get the error also.
> That´s the path:
> 
> C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program
> Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\ATI
> Technologies\ATI.ACE\Core-Static;C:\Acer\Empowering
> Technology\eDataSecurity\;C:\Acer\Empowering
> Technology\eDataSecurity\x86;C:\Acer\Empowering
> Technology\eDataSecurity\x64;C:\Program Files\Paradigma
> Software\VComponents_Win_VC;C:\Program
> Files\QuickTime\QTSystem\;C:\Program Files\Common Files\DivX
> Shared\;C:\Program Files\IDM Computer Solutions\UltraEdit\
> 
> (Btw: I was wrong with the 32bit path, it´s ...eDataSecurity\i386 not
> ...eDataSecurity\x86. But this does not matter.)
> 
> If i remove C:\Acer\Empowering Technology\eDataSecurity\x64 from path
> or just rename the folder x64 in explorer or just delete the
> libeay32.dll in the x64 folder, then the standalone runs without that
> error.
> 
> Tried here now on my son´s Acer notebook (hope he will not get to know
> that i played with his machine ;-) ) and also on some customer
> machines.
> 
> Runrev confirmed that Revolution/standalones look along the path at
> startup for some files, even if they are not needed. That should be no
> problem normally. But in my case a "wrong" path setting (created by the
> installer of eDataSecurity) lets the standalone find a wrong
> libeay32.dll. And that causes that problem.(If there is no libeay32.dll
> along the path and if the libeay32.dll is not needed, there is no error
> message). But if there is a wrong libeay32.dll  and although it is not
> needed, there is the error message.
> 
> Btw.: The bigger %path% is, the longer it takes for the standalone to
> startup. So if there is no libeay32.dll in any of that folders in
> %path% the standalone checks all that folders for it (and again
> regardless if the file is needed or not).

Good sleuthing work. :-) I would think this is deserving of a RQCC that says
that a standalone shouldn't search for libeay32.dll unless SSL & Encryption
is included in the Standalone Settings. Feel like filing one? ;-)

It's obvious now to me why I don't ever experience the issue and you have. I
have apps that do use SSL. The options for this is that you put the SSL libs
in the same directory as the EXE like RunRev does for the IDE (you will
notice both ssleay32.dll and libeay32.dll are always in the same directory
as Revolution.exe and not where you would expect them to be, which is in the
Externals directory). BTW, if you try to move these to the Externals
directory of your own app, you will find you can't, no matter what you do
with setting the externals, etc. Encryption just won't work.

Or, what I do is have my installer put rev's versions of these files into
the \Windows\System32 directory. Since the System32 directory is almost
always the first or second directory in a Window's path. This guarantees
that a rev standalone will find "its own" version of the SSL libs and
quickly.

Since, obviously, I've installed my own apps on my own machines, then
standalones that don't use SSL, but which you say searches anyway, always
found the correct SSL libs. And, when I renamed them all, since you say it
searches, but if it doesn't need SSL (like the test app I sent you), it
doesn't complain. :-/

Where the issue comes in is if a developer is distributing an app that does
not use SSL and does not include SSL & Encryption in their Standalone
Settings and therefore does not put Rev's version of these libs in the path.
However, if this standalone is going to search anyway, there is a high
likelihood that it will find these libs on "some" users' machines, because
many apps install them. And, evidently, some versions of these libs can
cause a standalone to have errors.

So bottom line is, a standalone shouldn't be searching for these, without
the developers knowledge. And, for now, if anyone is distributing a Windows'
app, they need to put the ssleay32.dll early in the path to "block" the
standalone from possibly finding someone else's version of it. Otherwise,
they will get reports of errors that they won't have a clue about what is
causing the errors on some machines and not others, because it doesn't show
up in their IDE or on their test machines.

It also means RunRev should be compatible with and include the latest
versions of these third-party DLLs with their releases or installing a Rev
app could interfere with other apps on a user's machine. 

Aloha from Hawaii,

Jim Bufalini