On 6 Jul 2004 at 9:41, Dean Arnold wrote:
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.
I don't have any clean good ideas on how to do it. Forking leaves the chance for zombies if the application croaks. Also, any scheme has to be conditionally included, so those who don't need it, don't pay for it.
Not certain I understand that comment. I admit, I haven't dived into the code, but (assuming theres a manifest of some sort), a command line switch would conditionally pull a startup executable into the PAR, and, on execution startup, if the manifest says theres a startup exe, it unpacks and forks it. Anyone who doesn't want a startup doesn't pay much (if any) penalty.
As for zombies: if your application is dying, you've probably got a lot more to worry about than zombies.
> parl.exe and parldyn.exe are currently
pre-built with only the required modules needed for unpacking. Having a conditional facility in them would mean switching to some kind of dynamic build.
Whatever might work is probably going to require some significant re-working of the current code. Anyway, I'm not motivated to tackle this. The first thing I do is turn off any splash screens, no matter how slow a program might be. If it's a useful program, I know what's happening, after 20 or 30 times.
Didn't mean to imply I expected someone else to do it (tho it would be nice 8^}). I don't have much time for it now either, just trying to solicit feedback on a) desirability, b) feasibility, and c) maybe some design hints.
My target users may not have your skillset or expectations. They're used to instant gratification, and need feedback before they start pounding random keys, and calling tech support.
FWIW: I'm also looking at an alternative of using Inno Setup to do a startup of the app after install that just starts up and exits, causing everything to get unpacked while there's an installer splash screen. Still haven't figured out how to do that yet, tho.
BTW, if you don't use pp -C, the modules are all still in the temp cache the second time around and not unpacked again. Subsequent executions should start faster.
Yep, I grok that. (tho even that scenario seems to take a while for my app to boot, tho much less than initial execute). Of course, when someone cleans out their temp space, they're going to get the startup delay again, which, from a support standpoint, can actually be worse than always taking a long time. Annoying consistent behavior is sometimes more comfortable than occasional inconsistency...but I spose if my users are running Windows, they're probably used to the latter.
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).
I should have mentioned that before. The -a option is a recent addition that I haven't actually used yet. $ENV{PAR_TEMP} is there already, and -a files are extracted to the $ENV{PAR_TEMP}."/inc" dir. For example, using -a and aliasing:
pp -a original_dir/some.txt;another_dir/renamed.txt -o t.exe t.pl
would extracted a copy of original_dir/some.txt as:
$ENV{PAR_TEMP}."/inc/another_dir/renamed.txt"
Thanks for that tip. I'll give it a shot when I get a chance.
Alan Stewart
Regards, Dean Arnold Presicient Corp.
