Embedding extra DLLs into .exe *and finding* them again

[tarmes]

Hi,

For the last 2 days I've been trying to "recompile" a script which had a bug that needed fixing. When I say "recompile" I really mean that I wish to turn it back into a single self contained .exe - that's how it came.

I've tried with three different tools - PerlApp, Perl2Exe and PAR::Packer.

In each case I am able to generate the .exe, but I'm always missing the DLLs that I need for SSL communication (libeay32.dll and ssleay32.dll). The original app had these contained in the .exe, and this worked seamlessly, so I'd like to do the same thing.

With each of the above tools I *can* successfully embed the two DLLs in to the .exe, and I'm sure that they're being extracted when the DLL starts, however they still can't be found when the exe is run.

I feel like I'm missing a step. The DLLs are embedded, and extracted to a temp folder, but there's nothing to tell the app to look in that folder when searching for DLLs. The original app could do this, so I'm clearly missing a step somewhere :(

Can anybode help me on this? I'd like to use either Perl2exe or PAR::Packer - PerlApp's too expensive.

Thanks,

Tim

P.S. Yes, I've searched - a lot.

[cdarke]

Is this failing at link time (the linker is usually called silently by the compiler), process load-time, or run-time?

If link-time, then the .lib files might be needed. These should be generated when the DLLs are compiled.

If at process load-time or run-time then you more than likely need to check the PATH environment variable %PATH%. Alternatively it could be a manifest problem if you are really unlucky. It depends on exactly how it is failing.

[tarmes]

Hi,

Thank you for responding.

The failure is at run time. If the DLLs are in the same folder as the exe then it works perfectly. If they're not, then the application fails with an error message stating that it can't find the DLLs (even though they're embedded in the exe).

The original exe didn't have this issue. The embedded DLLs were extracted somewhere then located by Windows when needed.

Would setting the PATH variable from within the application work? I did try playing with this idea, but I got the impression that the exe tried to locate the DLLs before the code got started, and that setting PATH was happening too late. Maybe I was doing something wrong?

The source code doesn't currently modify PATH so I assume that this wasn't necessary for the original "compile"?

I'm actually new to Perl as a language. If there's an example somewhere of setting the PATH variable to point to the location of the extracted exes when using either PAR or Perl2exe then I'd be grateful.

Tim

[Anonymous Monk]

You might start by reading your perl compiler docs they should tell you where files are extracted to and how to access them. I ASSUME that you're using the DLLs due to a requirement by a module you're using. If so you could place a BEGIN{} block at the top of the script to ensure your PATH changes are done before the modules are used. Modifying the path variable should be as easy as $ENV{'PATH'} .= ';C:\Path\to\directory'; Note I'm including the preceding semi-colon in my path string - and the .= appends my string to the end of the existing PATH value. But I'm just flying from the seat of my pants here. Check the wonderfully useful perldoc website and search for %ENV for how to access/modify environment variables.

[Marshall]

Sorry, but I am doubting this DLLs (even though they're embedded in the exe) part. How did you determine that this embedding occurred correctly?

On ActiveState, I manually installed this SSL stuff and wound up putting the .DLL's into a bunch of places so that PerlApp could find them. C:\Perl\bin, Windows, \Windows\system. I remember this being a mess. I have libeay32.dll in C:\Perl\bin and both of these DLL's in the normal Windows places for the other DLL's.

Sounds like you don't have these DLL's in the .exe otherwise they would be found and used even to the exclusion of any .DLL's in the .exe directory.

by definition any "standalone .exe" will run without any .DLL's on the target machine at all!

[Anonymous Monk]

I've tried with three different tools

Why not show exactly what you tried in the form of a small self-contained example?

To is how i tried (you'll need Listdlls).

pp -e " use Crypt::SSLeay; print $Crypt::SSLeay::VERSION,$/ ; my @ldd 
+= qw[ Listdlls.exe  ]; print for qx!@ldd $$!; "


----------------------------------------------------------------------
+--------
a.exe pid: 1164
Command line: a

  Base        Size      Version            Path
  0x00400000  0x12000   0.00.0000.0000  ...\cache-da39a3ee5e6b4b0d3255
+bfef95601890afd80709\a.exe
  0x018b0000  0xfe000   0.09.0008.0011  C:\WINDOWS\System32\libeay32.d
+ll
  0x019c0000  0x33000   0.09.0008.0011  C:\WINDOWS\System32\ssleay32.d
+ll

now adding the shared libraries

pp -l libeay32.dll -l ssleay32.dll -e " use Crypt::SSLeay; print $Cryp
+t::SSLeay::VERSION,$/ ; my @ldd = qw[ Listdlls.exe  ]; print for qx!@
+ldd $$!; "

----------------------------------------------------------------------
+--------
a.exe pid: 1136
Command line: a

  Base        Size      Version            Path
  0x00400000  0x12000   0.00.0000.0000  ...\cache-da39a3ee5e6b4b0d3255
+bfef95601890afd80709\a.exe
  0x018b0000  0xfe000   0.09.0008.0011  ...\cache-da39a3ee5e6b4b0d3255
+bfef95601890afd80709\libeay32.dll
  0x019c0000  0x33000   0.09.0008.0011  ...\cache-da39a3ee5e6b4b0d3255
+bfef95601890afd80709\ssleay32.dll

if you unzip a.exe, you'll find

2006-09-28 15:04:00 .....      1073152       487750  shlib\MSWin32-x86
+-multi-thread\libeay32.dll
2006-09-28 15:04:14 .....       200704        93031  shlib\MSWin32-x86
+-multi-thread\ssleay32.dll
------------------- ----- ------------ ------------  -----------------
+-------