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/WinUI/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.
