Seitenanfang

Perl for Windows: Wrong point of view?

Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.


There are two parts of the world: Windows and others. While "others" have many names like Linux, FreeBSD, Solaris, all of them usually come with preinstalled Perl, but Windows? There are ActivePerl and Strawberry Perl, but is this enough?

Perl is still rarely used on Windows, but this might be the result of a different point of view between Perl guys and Windows guys.

Windows users are used to two kinds of software:

  • Applications
  • Runtime libraries required by applications
Visual Basic apps required VB5 or VB6 runtimes, .net apps require the .net framework runtimes and don't forget Java which requires a Java *DK to be installed, but Perl? The user has to install a Perl, then download the script he wants to run and finally start working himself into something strange called "CPAN client" to install the dependencies of his script.

Perl runtime?

I'd love to see a "Strawberry runtime" which could be the same installer file which is offered for the full installation.

Next part would be a new approach on a "perl2exe" compiler: Grab a (project|script|module), run it through perl2exe and you get a project.exe file which has a very small and simple launcher, a list of dependencies (META.YML?) and the (project|script|module) perl source. The launcher would have to

  • check for an installed Strawberry runtime
  • direct the user to the Strawberry download page, if there is no runtime installed
  • launch the app-starter which should be part of the Strawberry
The to-be-created Strawberry app-starter could check the dependencies, install anything needed from CPAN automatically (maybe with very little user input) and finally push the sourcecode from project.exe to the perl interpreter.

Perl applications would be runable as one-file-download without messing up the registry and without installation and adding a "--msi" switch to also create an application.msi installer using perl2exe would be easy, too.

This will not work...

There would be few limitations, because all project files would have to live in one file, but this is no excuse.

I'd say, more than 95% of the Perl applications will work without any problem if all files are copied together in one which is passed to the interpreter. OS-specific source code within the application doesn't count, because it would be Windows OS-specific if they'd be written for Windows.

I'm still a Perl guy without C or C++ knowledge and without enough EXE, DLL or MSI knowledge to create this solution, but it shouldn't be too hard to get a working version. Even if 0.01 would have a long list of limitations and rules which must be respected while writing the Perl script, I'm sure that people would try - and use it!

Don't try to create a completely working solution from scratch, try to create a solution and fix problems lateron!

 

2 Kommentare. Schreib was dazu

  1. I haven't used PAR, but I'm lead to believe it does 90% of what you are suggesting:


    http://search.cpan.org/~smueller/PAR-1.002/lib/PAR/Tutorial.pod

  2. Sebastian

    We were discussing PAR some (long) time ago on the Padre channel (http://irclog.perlgeek.de/padre/2009-09-11#i_1491574).

    It's a solution, but the Perl interpreter and every single required module is packed for every binary, so you end up having 1000 Perl interpreters on your hard disk, one for every script :-(

Schreib was dazu

Die folgenden HTML-Tags sind erlaubt:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>