Well, we can't support PAR because currently it's kind of a stop-gap
solution used by those who don't want to or cannot buy perlapp/perl2exe
(like me). If you must use PAR then there is nothing stopping you from
using the PAR options to include bitmaps and other files inside the PAR
file. When your program is executed these will be extracted and will be
available in the temporary directory used by PAR (which I believe can be
found in @INC). You can then do something like this:
my $resource = Win32::GUI::LoadResource("some.file") || do
{open(FILE,"<","some.file");binmode(FILE);join('',<FILE>)};
Which should revert to a disk copy if LoadResource fails to find the
resource. Alternatively you can use this to auto-generate perl hex code
for files and stick the files right into your script:
open(DATA,"<","test.bmp");
my $data;
sysread(DATA,$data,(stat(DATA))[7]);
close(DATA);
my $output = '$VAR = "';
for(my $i = 0; $i < length($data); $i++) {
$output .= sprintf('\x%02x',ord(substr($data,$i,1)));
if($i % 80 == 0) { $output .= "\".\n \"" };
}
$output .= "\";\n";
print $output;
I now have confirmations from people that both Perl2Exe and PerlApp work
OK with LoadResource and the additions to the LoadImage routine (meaning
EXE is checked first when loading bitmap, cursor and icon files). PAR
will need to mature a bit (i.e. dump the whole extracted bundle thing
and use an in-exe resource like the other perl exe makers do) before it
will really make the grade for me, I'm afraid. By the way, I'm not
making PAR exempt from the use of this new functionality on purpose,
it's just that PAR cannot possibly work with it yet.
Steve
> -----Original Message-----
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]
> Sent: 19 February 2004 17:57
> To: Stephen Pick
> Cc: Jez White; Win32-GUI
> Subject: Re: [perl-win32-gui-users] Shipping resources with your exe
>
>
> It would probably be sufficient to support PAR. Even if ActiveState
> gave you the free copy, it isn't likely they'd give it to
> everyone, so
> everyone is more likely to use PAR, in the long term (once
> it's growing
> pains are over). Of course, if AS does supply you a free
> copy, I have
> no objections to your support of it, along with PAR.
>
> Looking at the global issue, I wonder if it might not be possible to
> create a DLL containing all the resources for a particular Win32::GUI
> program, and then, whether the program is running via
> perl.exe, or via
> PAR, or even Perl2Exe or PerlApp, that somehow that one DLL would be
> referenced for all the resource needs of the program.
>
>
> On approximately 2/19/2004 2:02 AM, came the following characters from
> the keyboard of Stephen Pick:
>
> > 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.)
> >
> > Steve
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> >
> [mailto:[EMAIL PROTECTED] 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?
> >
> > jez.
> >
> >
> >
> > ----- Original Message -----
> > From: Steve Pick <mailto:[EMAIL PROTECTED]>
> > To: Jez White <mailto:[EMAIL PROTECTED]> ;
> Win32-GUI
> > <mailto:perl-win32-gui-users@lists.sourceforge.net>
> > 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.
> >
> > Steve
> >
> > ----- Original Message -----
> > From: Jez White <mailto:[EMAIL PROTECTED]>
> > To: Win32-GUI
> > <mailto:perl-win32-gui-users@lists.sourceforge.net>
> > Sent: Wednesday, February 18, 2004 6:34 PM
> > Subject: [perl-win32-gui-users] Shipping
> resources with your exe
> >
> > Hi,
> >
> > 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:
> >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/W
inUI/WindowsUserInterface/Resources.asp
>
> 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?
>
> Cheers,
>
> jez.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
