Hi peter,
I just tried the free version of it and it doesnt do what PAR does. I added a little line to LoadImage in GUI.xs to see what it thought it's current exe was. The results:
Running perl:
Loading image 0 - current EXE: C:\Perl\bin\perl.exe
Running PAR packed exe (ouch...):
Loading image 0 - current EXE: C:\DOCUME~1\id909774\LOCALS~1\Temp\par_priv.1732.tmp\par.exe
Running perl2exe packed exe:
Loading image 0 - current EXE: C:\junk\Win32-GUI-0.0.665\samples\toolbar.exe
Nice. So if you want this functionality you're gonna have to use a decent pl -> exe packer. I'll get onto the code and a CVS commit soon!
-----Original Message-----
From: Straub, Peter (Peter) [mailto:peter.straub@optimay.com]
Sent: 19 February 2004 10:26
To: Stephen Pick; Jez White; Win32-GUI
Subject: RE: [perl-win32-gui-users] Shipping resources with your exe

I have been using perl2exe for quite some time and I'm quite sure that it does the trick in the way that you describe for PAR.
-----Original Message-----
From: perl-win32-gui-users-admin@lists.sourceforge.net [mailto:perl-win32-gui-users-admin@lists.sourceforge.net]On Behalf Of Stephen Pick
Sent: Thursday, 19 February, 2004 11:02
To: Jez White; Win32-GUI
Subject: RE: [perl-win32-gui-users] Shipping resources with your exe

I didnt mean to suggest we start modifying the perl exe :) That would be crazy.
I meant that microsoft provides certain functions that let you add, remove and update resources in an executable, you just have to pass the handle to the module who's executable file needs to have its resources played with. There are ways of finding what this handle is for the current running thread (although I'm not sure what they are right now), but I'm not sure what file it would pick up as the current running thread when running under perl.exe -- it may pick up GUI.dll, or it may pick up perl.exe. So while, say, an UpdateResource call may work in the real executable it will probably cause unexpected results when running under perl.exe.
Another problem that I've yet to test is to do with the various pl -> exe converters out there. I'm not sure of PerlApp (the best, but $400, so sod that...) or Perl2Exe (also costly) but PAR executables are simply a depacker that unpacks a perl interpreter and appropriate packages to a temporary directory then runs that perl interpreter to execute your program. It's a good chance that UpdateResource commands (and even LoadBitmap et al) would not pick up the exe file that you actually executed when searching for resources, but would actually pick up the perl interpreter or GUI.dll that had been packed into the PAR executable.
As a developer of Win32::GUI I'm sure ActiveState would be very happy to give me a free copy of the Perl Dev Kit to aid in my work! (yeah, right.)
-----Original Message-----
From: perl-win32-gui-users-admin@lists.sourceforge.net [mailto:perl-win32-gui-users-admin@lists.sourceforge.net]On Behalf Of Jez White
Sent: 19 February 2004 09:46
To: Steve Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe

I agree with your analysis - I especially like the idea of bitmaps, Icons and cursors to check for resources first, and then to look at the file system (would solve the problem of running in "dev" mode with the perl command line, or running the exe direct).
How easy would it to be load other binary objects in from the exe? For example, having other image formats or storable created objects.
As for adding resources - I can see the benefits of having a native solution, but it would create massive scope to mess around with the perl exe:) Perhaps the first step is to point to ResHacker, with a step by step guide on how to use it?
----- Original Message -----
From: Steve Pick
To: Jez White ; Win32-GUI
Sent: Wednesday, February 18, 2004 10:40 PM
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe

I'd find this functionality kinda handy. Loading resources from the exe is very simple, and it would not be too difficult to extend the Win32::GUI::Bitmap, Icon, etc. objects to accept an additional argument that indicates that the resource should be loaded from the exe rather than from a real file on disk (in fact, it would actually be a trivial matter to do this).
What is less trivial is getting the resources in there in the first place. While ResHacker lets you do it, it'd be nice to see a Win32::GUI native way of doing it. Microsoft provides functions for adding, deleting and replacing resources in executable files and I propose we either:
1. Add this update/add/delete functionality into Win32::GUI so that applications can fiddle with their own resources. This may be an exceptionally bad idea (what exe file will it think it's using when running straight from Perl? We dont want it messing with perl.exe's resources)
2. Create a small tool that is distributed with Win32::GUI to pack resources into the exe. I doubt we can re-dist ResHacker with win32::gui and it'd be nice if there was this functionality provided. The Win32::GUI::Bitmap, Icon and Cursor objects could then be modified to first check for a resource identified by the given filename in the current running exe, and if it's not found attempt to use the given filename to load an external file. This seems the best mode of operation to me.
----- Original Message -----
From: Jez White
Sent: Wednesday, February 18, 2004 6:34 PM
Subject: [perl-win32-gui-users] Shipping resources with your exe

One the problems I have when I ship my exe is ensuring that all the resources (bitmaps, cursors and config files) are valid when my app starts up. Typically, just including them in a sub directory can cause problems since the user could delete or alter them. The ideal solution would be to package the resources into the exe and extract them at runtime. See:
Adding the resources to the exe is quite straightforward (with reshacker) but I'm not sure how easy it would be to implement these function calls (or even it is possible), would anyone find this kind of functionality useful?