• ActiveState has PerlApp, which only runs on WinNT and only creates executables for Win32 platforms
• IndigoSTAR has perl2exe which runs on multiple platforms and creates executables for multiple platforms
• perlcc has been written by Malcolm Beattie and should compile into C OR executable, but needs a C-compiler to actually create the binary executable. And it's not stable. Far from that. I've tried it on a Linux box with Perl 5.00503 and it failed to compile a simple script that used a few modules.

ActiveState PDK v3.0 comes with versions of PerlApp for both Windows and Linux / Solaris.

Of course, it's not free or open source. Good luck!

Error: Keyboard not attached. Press F1 to continue.

As for an implementation idea, take a gander at Ultimate Binary Wrapper by Ilya.

You will need to play fancy games with any binary extensions. But for pure Perl code, this should be a doable project.

I think you have to start by saying, "Do I care more about time to develop the project, time to run compiled code, or space the compiled code takes up" and go from there. It'd be relatively easy to write something that just stuck your script in a big ol string in the C source and compiled it, but I wouldn't really recommend that, as all you'd get for the work was something you could grab and drop on a different box with the same architecture.

As for coders...I'm willing to help. It'll be my first collaborative project and my first work with Perl internals, but if that doesn't scare you off, count me in. :^)

=cut
--Brent Dax

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

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.

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?
[download]

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

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.

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

Update: Just incase it wasn't clear before: Count me in! I definitely would like to help code this. As for ideas, there are two main routes I can think of. One is to convert the perl code into relavent C code, this is probably a slow solution. The other is to convert it straight to a machine representation, this is probably not a portable solution. I just joined sourceforge, and can't wait to start. (P.S. I'll be gone tommorow for a robotics demonstartion, so if you try to contact me, I'll have to respond on Thursday)

The 15 year old, freshman programmer,
Stephen Rawls

I think we would have to rely heavily on Perl itself. Not as a programminglanguage to write the compiler itself in, but the C-source of Perl to use, or the B::Bytecode or something to get to the backend of the Perl compilation process itself.

I think the last thing we should do is to rewrite the Perl engine itself!! How could we ever keep up with new versions if we were writing every part ourselves?

No, re-use what has been done, and write only the last part of the process, namely the creation of the binary executable.

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

Observation 1: You can let the compiler out if the source doesn't contain the letter 'e'! Observation 2: Normal programs can be written without the letter 'e'. 'E' doesn't count.

How about:

do "config.pl";
[download]

I'm not quite sure if you get what we're trying to do. We're not writing a compiler IN Perl, we're writing one FOR Perl. That basically requires us to figure out a way to take Perl's parse tree and somehow encode it into an executable such that we can regenerate it. (crazyinsomniac--I'll be sending you an e-mail soon explaining my idea for this.) The perl source will do all of the parsing for us--we're just parsing its parse trees, so to speak.

Besides, even if we *were* writing a compiler in Perl, we'd probably use Parse::RecDescent. It's easily powerful enough to parse C, and supposedly the next version will be able to parse Perl.

=cut
--Brent Dax


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

~Cybercosis

nemo accipere quod non merere

a few things to note...

first, perlcc can compile perl source code into a binary:  perlcc perl_source.pl -o perl_bin_executable - and there's no offending C source involved. unfortunately, it's also less than stable (i get terrible errors with it on 5.6.1, when i use map{}, and have had no luck making it play nicely with Socket.pm)

secondly, if you know a teensy bit of C (or are good at faking it <g>) you can always shove your very own perl interpreter into a .c file, and include the code in a char'd string (see perlman:perlembed for oodles of information on that ((: )

now, i agree with the many others who have said that compiling perl scripts won't protect the source.. but as far as i could tell, that wasn't what all this was about, was it?

Being able to write a decent snippet, one-liner, or full- fledged program in perl, and then distribute it to those who -don't- have some/any/all of the following:

• some perl module or another
• a perl interpreter! (:
• any programming knowledge whatsoever

lastly, if you need help on this project, i'd be more than happy to help (assuming the need isn't already filled by the mega-experienced perl adepts and gods who haunt the monastery) (:

Good Luck,
strfry()

No-one said we would start from scratch....we may be using something that Malcolm wrote, but his basic idea is to use a c-compiler to create the executables and that's not likely to become our way to do it...

But who knows....

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

As someone who uses perl2exe let me throw in my two cents..
I create perl programs that work as simple helper apps to some of our internal Windows software. These scripts I compile into an exe format to keep from having to install Perl on every workstation who may need to use it, then having to keep everyone up to date with the perl versions and modules. It is not a matter of 'hiding' the source code as much as it making the program easier to access.
SO for me it's a matter of keeping my administration overhead low

On your second note about not being able to hide the internals I agree fully and I don't use the complier to 'secure' anything

On the idea of this project I would love to see it happen. I can't do much to help other than test (I'm not that great of programmer). From a user perspective I have found the EXEs created by perl2exe tend to be quite large in file size and it would be nice to see smaller exes

Like I stated in my first reply to this thread, we are trying to compile the source...not to hide it. A compiler is not the same as an obfuscator.

The main idea (for me) for a Perl compiler is that it enables you to write Perl programs and enable anyone to run it, regardless if they installed a Perl interpreter or not (like I did with pVoice).

Thanks to OeufMayo and neophyte my program is now compiled for the Win32 platform, which simplifies installation enormously for people who want to use the application instead of co-develop it.

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