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
