Re: Re: The Perl Compiler (turning perl scripts into binary executables)

I think you're wrong about the way Perl2Exe and PerlApp work. I think it's for a reason that PerlApp only works on WinNT and not on Win98. Like Activestate states, it's because the Win98 API is lacking something that is needed for the compilation. That means more is involved than just creating a self-extracting thing.
Besides, while running it does not extract anything anywhere.

We are trying to create a multiplatform, maybe eventually a crossplatform compiler that creates free-standing executables.
This means you would not need to have Perl installed on your machine to run the script.

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

Comment on Re: Re: The Perl Compiler (turning perl scripts into binary executables)

Replies are listed 'Best First'.
Re: Re: Re: The Perl Compiler (turning perl scripts into binary executables) by joefission (Monk) on Jul 11, 2001 at 17:08 UTC
Besides, while running it does not extract anything anywhere. I respectfully disagree. The free-standing executable's @inc paths are . and %temp%\scriptname\uniqueid. The subdirectory contains perl56.dll and perlapp.dll which looks like the interpreter (based on file size) + some other goodies. Update: I didn't mean to imply that all of the script-dependent modules are in the subdirectory. They aren't. Now I wonder what's going on in Linux and Solaris. I've seen WinNT errors thrown when a stand-alone script is run without proper permissions(actually, wrong user). The error stated that Perl.exe was causing it. I hope I saved a screen shot of it somewhere... You're right Jouke, I don't know exactly how it works. I'm just gues^H^H^H^H reasoning it out. The Win32API that needs NT to build, but not to run has me stumped. Hopefully Win9x/ME will be dead before anyone would want to use the perl monk compiler on it.	[reply]
Details on PerlApp by John M. Dlugosz (Monsignor) on Jul 11, 2001 at 20:37 UTC
The reason PerlApp only works on NT (not 9x) is the lack of functions for manipulating EXE files. Obviously having OS support for that makes writing any kind of compiler easier! Specifically, it works by taking the stub EXE and sticking all the files to bundle as "resources" to a copy of that EXE. I'm pretty sure it's uncompressed, too! Instead of using the resource fork as an archive, you could implement it as a tarball concatenated after the stub, as with a typical self-extracting archive. Then you would not need those exotic functions, and the source for the stub would be portable (as opposed to using OS-specific features to read the resources). —John	[reply]