Alan Stewart wrote:
On 5 Jul 2004 at 17:08, Dean Arnold wrote:
Glenn Linderman wrote:
On approximately 7/5/2004 3:50 PM, came the following characters from the keyboard of Dean Arnold:
After building a standalone of a fairly large DBI+Tk app (resulting .exe is 5.7 MBytes), the first execution is pretty lengthy. Is there anyway to open a splash screen for that initial load ? I realize you need Perl plus some GUI modules loaded before PAR could even try to run a BEGIN script, but is there any way to order the unpacking so the modules needed for a simple splashscreen get unpacked first, then display the splash while the remaining unpack/compile operations proceed ?
Maybe splash screen, a common enough operation, should be a PAR feature?
Either with a new switch, or if a file named splash.bmp or splash.jpg or something exists (PAR implementers can figure the details), then it is displayed mid-screen ASAP, while the rest of the unpacking proceeds.
Yeah, that was my thought. Actually, I'm thinking it needs to be platform specific code compiled into the C stuff, and the supplied splash is just a GIF/PNG/JPG image (to keep it simple). That way there's no need to wait for core Perl to get unpacked.
Q: is PAR/pp generating an executable ZIP ? If so, does that library have a splash screen capability ? (I vaguely recall that WinZIP or one of those tools had such a feature for creating executable ZIPs)
It's not an executable zip. In fact, it doesn't use anybody's library. In the case of pp without the -d option, there are four "layers" to an .exe:
1. A thin C frontend (static.c) that creates the temp dir and unpacks perl5x.dll and the internal .exe.
2. A thin frontend (main.c) on the internal .exe that sets up a Perl interpreter using the perl5x.dll and starts the Perl frontend appended to the end of it.
3. The Perl frontend (par.pl) that unpacks and maps all the modules and your script from the .par file appended behind it, and then runs your script.
4. The .par file itself.
That's a simplified view. From pp with the -d option, you get only 2 thru 4, using the installed perl5x.dll, and par.pl also creates the temp dir.
If you wanted a C generated splash before all the unpacking starts, main.c might be where it would go. The problem is: main.c starts the Perl interpreter and then has no way of knowing when the unpacking finishes and your script starts running.
If you put the splash code in par.pl where it knows what happens when, par.pl would have to include all the module baggage to support it. That might not be so bad if it is going to be a Tk app anyway, but adds a huge overhead if it, for example, Gtk or Windows native widget app.
Alan Stewart
Thanks for the brief code summary, it'll definitely help me navigate.
If I follow your processing sequence, the best (or at least quickest and most general solution) might be to add an option to include startup native executables in the PAR bundle that PAR can start via fork() or some such, then maybe capture the executable name in $ENV associated with its PID. Then when the primary application finally gets loaded and fired up, the app can check $ENV for the startup(s) and kill them if desired.
Likewise (getting back to my earlier issue w/ trying to read() included files, could PAR generate a $ENV value that points to the temp directory where it keeps its storage ? (I think thats how perl2exe did it).
As for the relative merits of splash screens, I can assure the readers that on my system (2.4GHz P4, WinXP, 512Meg), the bootup time for my app - especially for the first execution - can be disconcertingly long. It wouldn't be so bad if the mouse cursor would stay in the "busy" state the entire time, but it seems to switch back to normal fairly quickly. (I hate to think how it will behave on my 1GHz laptop, tho based on the amount of disk accesses I see, it may actually be an I/O bound problem).
And one other thought: is there any open request for stripping comments and POD from included modules ? After strolling around the PAR storage directories, I saw that the modules were included as ia, and in some cases, stripping out the comments and the POD might help reduce the overall size (and hence the bootup time) significantly. Maybe this could be accomplished with a one-way filter ?
Alas, I don't have time to pursue these notions for another month or so, unless my end-users start grousing about it.
Thanks, Dean Arnold Presicient Corp.
