From: Stephen P. <Ste...@uc...> - 2004-02-19 10:24:53
|
I didnt mean to suggest we start modifying the perl exe :) That would be = crazy. =20 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. =20 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. =20 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.) =20 Steve =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]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).=20 =20 How easy would it to be load other binary objects in from the exe? For = example, having other image formats or storable created objects. =20 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? =20 jez. =20 =20 ----- Original Message -----=20 From: Steve Pick <mailto:st...@ba...> =20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 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). =20 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: =20 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) =20 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. =20 Steve ----- Original Message -----=20 From: Jez White <mailto:je...@je...> =20 To: Win32-GUI <mailto:per...@li...> =20 Sent: Wednesday, February 18, 2004 6:34 PM Subject: [perl-win32-gui-users] Shipping resources with your exe Hi, =20 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:=20 =20 http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/= WinUI/WindowsUserInterface/Resources.asp =20 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?=20 =20 Cheers, =20 jez. |
From: Stephen P. <Ste...@uc...> - 2004-02-19 10:35:49
|
Hi peter, =20 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: =20 Running perl: Loading image 0 - current EXE: C:\Perl\bin\perl.exe =20 Running PAR packed exe (ouch...): Loading image 0 - current EXE: = C:\DOCUME~1\id909774\LOCALS~1\Temp\par_priv.1732.tmp\par.exe =20 Running perl2exe packed exe: Loading image 0 - current EXE: = C:\junk\Win32-GUI-0.0.665\samples\toolbar.exe =20 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! =20 Steve =20 -----Original Message----- From: Straub, Peter (Peter) [mailto:pet...@op...] 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. Cheers, Peter -----Original Message----- From: per...@li... = [mailto:per...@li...]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. =20 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. =20 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. =20 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.) =20 Steve =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]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).=20 =20 How easy would it to be load other binary objects in from the exe? For = example, having other image formats or storable created objects. =20 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? =20 jez. =20 =20 ----- Original Message -----=20 From: Steve <mailto:st...@ba...> Pick=20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 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). =20 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: =20 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) =20 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. =20 Steve ----- Original Message -----=20 From: Jez White <mailto:je...@je...> =20 To: Win32-GUI <mailto:per...@li...> =20 Sent: Wednesday, February 18, 2004 6:34 PM Subject: [perl-win32-gui-users] Shipping resources with your exe Hi, =20 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:=20 =20 http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/= WinUI/WindowsUserInterface/Resources.asp =20 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?=20 =20 Cheers, =20 jez. |
From: Straub, P. (Peter) <pet...@op...> - 2004-02-19 10:32:02
|
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. Cheers, Peter -----Original Message----- From: per...@li... = [mailto:per...@li...]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. =20 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. =20 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. =20 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.) =20 Steve =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]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).=20 =20 How easy would it to be load other binary objects in from the exe? For = example, having other image formats or storable created objects. =20 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? =20 jez. =20 =20 ----- Original Message -----=20 From: Steve Pick <mailto:st...@ba...> =20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 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). =20 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: =20 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) =20 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. =20 Steve ----- Original Message -----=20 From: Jez White <mailto:je...@je...> =20 To: Win32-GUI <mailto:per...@li...> =20 Sent: Wednesday, February 18, 2004 6:34 PM Subject: [perl-win32-gui-users] Shipping resources with your exe Hi, =20 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:=20 =20 http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/= WinUI/WindowsUserInterface/Resources.asp =20 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?=20 =20 Cheers, =20 jez. |
From: Stephen P. <Ste...@uc...> - 2004-02-20 10:40:22
|
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 =3D 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 =3D '$VAR =3D "'; for(my $i =3D 0; $i < length($data); $i++) { $output .=3D sprintf('\x%02x',ord(substr($data,$i,1))); if($i % 80 =3D=3D 0) { $output .=3D "\".\n \"" }; } $output .=3D "\";\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:pe...@ne...] > 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 >=20 >=20 > It would probably be sufficient to support PAR. Even if ActiveState=20 > gave you the free copy, it isn't likely they'd give it to=20 > everyone, so=20 > everyone is more likely to use PAR, in the long term (once=20 > it's growing=20 > pains are over). Of course, if AS does supply you a free=20 > copy, I have=20 > no objections to your support of it, along with PAR. >=20 > Looking at the global issue, I wonder if it might not be possible to=20 > create a DLL containing all the resources for a particular Win32::GUI=20 > program, and then, whether the program is running via=20 > perl.exe, or via=20 > PAR, or even Perl2Exe or PerlApp, that somehow that one DLL would be=20 > referenced for all the resource needs of the program. >=20 >=20 > On approximately 2/19/2004 2:02 AM, came the following characters from > the keyboard of Stephen Pick: >=20 > > I didnt mean to suggest we start modifying the perl exe :)=20 > That would be=20 > > crazy. > > =20 > > I meant that microsoft provides certain functions that let you add,=20 > > remove and update resources in an executable, you just have=20 > to pass the=20 > > handle to the module who's executable file needs to have=20 > its resources=20 > > played with. There are ways of finding what this handle is for the=20 > > current running thread (although I'm not sure what they are=20 > right now),=20 > > but I'm not sure what file it would pick up as the current running=20 > > thread when running under perl.exe -- it may pick up=20 > GUI.dll, or it may=20 > > pick up perl.exe. So while, say, an UpdateResource call may=20 > work in the=20 > > real executable it will probably cause unexpected results=20 > when running=20 > > under perl.exe. > > =20 > > Another problem that I've yet to test is to do with the=20 > various pl ->=20 > > exe converters out there. I'm not sure of PerlApp (the=20 > best, but $400,=20 > > so sod that...) or Perl2Exe (also costly) but PAR=20 > executables are simply=20 > > a depacker that unpacks a perl interpreter and appropriate=20 > packages to a=20 > > temporary directory then runs that perl interpreter to execute your=20 > > program. It's a good chance that UpdateResource commands (and even=20 > > LoadBitmap et al) would not pick up the exe file that you actually=20 > > executed when searching for resources, but would actually=20 > pick up the=20 > > perl interpreter or GUI.dll that had been packed into the=20 > PAR executable. > > =20 > > As a developer of Win32::GUI I'm sure ActiveState would be=20 > very happy to=20 > > give me a free copy of the Perl Dev Kit to aid in my work!=20 > (yeah, right.) > > =20 > > Steve > > =20 > >=20 > > -----Original Message----- > > From: per...@li... > > =20 > [mailto:per...@li...]On Behalf > > Of Jez White > > Sent: 19 February 2004 09:46 > > To: Steve Pick; Win32-GUI > > Subject: Re: [perl-win32-gui-users] Shipping resources=20 > with your exe > >=20 > > I agree with your analysis - I especially like the idea=20 > of bitmaps, > > Icons and cursors to check for resources first, and=20 > then to look at > > the file system (would solve the problem of running in=20 > "dev" mode > > with the perl command line, or running the exe direct). > > =20 > > How easy would it to be load other binary objects in=20 > from the exe? > > For example, having other image formats or storable=20 > created objects. > > =20 > > As for adding resources - I can see the benefits of=20 > having a native > > solution, but it would create massive scope to mess=20 > around with the > > perl exe:) Perhaps the first step is to point to=20 > ResHacker, with a > > step by step guide on how to use it? > > =20 > > jez. > > =20 > > =20 > >=20 > > ----- Original Message ----- > > From: Steve Pick <mailto:st...@ba...> > > To: Jez White <mailto:je...@je...> ;=20 > Win32-GUI > > <mailto:per...@li...> > > Sent: Wednesday, February 18, 2004 10:40 PM > > Subject: Re: [perl-win32-gui-users] Shipping=20 > resources with your exe > >=20 > > I'd find this functionality kinda handy. Loading=20 > resources from > > the exe is very simple, and it would not be too difficult to > > extend the Win32::GUI::Bitmap, Icon, etc. objects=20 > to accept an > > additional argument that indicates that the=20 > 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). > > =20 > > What is less trivial is getting the resources in=20 > there in the > > first place. While ResHacker lets you do it, it'd=20 > 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: > > =20 > > 1. Add this update/add/delete functionality into=20 > Win32::GUI so > > that applications can fiddle with their own=20 > resources. This may > > be an exceptionally bad idea (what exe file will it=20 > think it's > > using when running straight from Perl? We dont want=20 > it messing > > with perl.exe's resources) > > =20 > > 2. Create a small tool that is distributed with=20 > Win32::GUI to > > pack resources into the exe. I doubt we can re-dist=20 > ResHacker > > with win32::gui and it'd be nice if there was this=20 > functionality > > provided. The Win32::GUI::Bitmap, Icon and Cursor=20 > objects could > > then be modified to first check for a resource=20 > identified by the > > given filename in the current running exe, and if=20 > it's not found > > attempt to use the given filename to load an=20 > external file. This > > seems the best mode of operation to me. > > =20 > > Steve > >=20 > > ----- Original Message ----- > > From: Jez White <mailto:je...@je...> > > To: Win32-GUI > > <mailto:per...@li...> > > Sent: Wednesday, February 18, 2004 6:34 PM > > Subject: [perl-win32-gui-users] Shipping=20 > resources with your exe > >=20 > > Hi, > > =20 > > One the problems I have when I ship my exe is=20 > ensuring that > > all the resources (bitmaps, cursors and config files) > > are valid when my app starts up. Typically,=20 > just including > > them in a sub directory can cause problems=20 > since the user > > could delete or alter them. The ideal solution=20 > would be to > > package the resources into the exe and extract them at > > runtime. See: > > =20 > > =20 http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/= W inUI/WindowsUserInterface/Resources.asp > =20 > 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? > =20 > Cheers, > =20 > jez. --=20 Glenn -- http://nevcal.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
From: Glenn L. <pe...@ne...> - 2004-02-19 18:08:36
|
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: per...@li... > [mailto:per...@li...]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? > > jez. > > > > ----- Original Message ----- > From: Steve Pick <mailto:st...@ba...> > To: Jez White <mailto:je...@je...> ; Win32-GUI > <mailto:per...@li...> > 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:je...@je...> > To: Win32-GUI > <mailto:per...@li...> > 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. |