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

[joefission]

PerlApp runs on Win32, Linux, and Solaris.

perlapp (and perl2exe) seems to:
1. Scan the script.
2. Grab the scanned use and require modules/files found in  @inc.
3. use some sort of self-extracting zip/tar and tarball perl, the script, associated modules, files, etc.
4. Run this executable on the host. The self-extractor (after untarring/unzipping into /temp) executes perl script.

Of course the devil is in the details :-) The version of perl that is tarred has @inc of /temp and the local directory.
The self-extractor/perl-boot-loader might be the hardest part (then again, I haven't looked for it).

Are we trying to build a multi-platform compiler, cross-platform compiler, or a free-standing executable of perl scripts?
The difference (to me) being:
multi-platform means win32 compiler for win32 executables, linux for linux (I think this is what is being said)
cross-platform means I can build a linux executable on a win32 machine (this would be crazy, huh?)
free-standing would be the sleazy method described above. I guess that could be considered multi-platform, but I don't know if it's actually a compiler.

[BrentDax]

Multi-platform compiler. The goal is to be able to write a Perl script on a system that has perl, run it through the compiler, and have an executable you can drop into another system running the same OS and processor but not necessarily containing perl. (At least I think so. crazyinsomniac, correct me if I'm wrong...)

=cut
--Brent Dax


@HPAJ=split("", "rekcaH lreP rentonA tsuJ");
print reverse @HPAJ;  #sucky but who cares?

[Jouke]

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

[joefission]

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.

[John M. Dlugosz]

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