Re: [MacPerl] How Cross Platform is Perl

[pvhp@forte.com (Peter Prymmer)]

Brian McNett wrote to Tom Schruefer:

> > For instance, replacing the interface code, could one run the same basic 
> > Perl program on all the supported platforms?  
> 
> Actually, there are ways (tricky ways, but ways nonetheless) to write the 
> interface code such that a single program, interface and all will be 
> supported by all platforms.  Perl can do a conditional test for what OS 
> it's running on, and a knowledgealbe programmer can make his code adapt 
> the interface on the fly depending on the OS.,  I'm not saying that 
> anyone's actually done this, but it should be possible to write each 
> interface as a seperate package, and call the packages from within a 
> conditional test for $^O.

People have actually done this.  See e.g. the perldoc script that comes
with perl.  It works like a charm on unix, windows, vms, && os/390
mainframes.  I know that in the past I have tried to use it on Macs and
I suspect that it still has some file path problems on macs but it ought
to work with minor modification.  Owing to Matthius's excellent Shuck program
I suspect that the MacPerl world has had little reason to patch perldoc
though.

For another example see:

  http://language.perl.com/ppt/src/wc/index.html
  http://language.perl.com/ppt/src/wc/wc.pvhp

a script that was an adaptation of a unix command line tool that runs as 
such on unix, vms, windows, mvs, && Mac MPW; but was provided with a
MacPerl::Pick selection box to input -l -c type options when run
as a MacPerl app (where it is intended to run as a droplet for dropping
files onto).

> Practically, one must know how to write interface code for every OS one 
> plans to deploy on.  This can be Perl/tk for Unix, the Mac Toolbox for 
> our favorite GUI, and whatever is available under Win32 Perl (not even 
> sure myself, might be able to get way with Perl/tk).

Perl/Tk runs on Win32 (NT/95/98/2k) as well as OS/2's presentation 
manager (PM).  On Win32 there is also a Win32::GUI module that allows you
to write "more Win32 native" GUIs there.  Perl/Tk is in beta on VMS
but has not been ported to the Mac.

> > Is it possible to build Perl executables for a Win95 or WinNT system, 
> > like can be done for the Mac?  
> 
> The simple answer to this is no.  However, the REASON for executables 
> (runtime interpreters actually) in MacPerl is to make up for both some 
> missing functionality, and the lack of ubiquity of full installations of 
> Perl on the Mac.  This missing functionality is that (under Unix) any 
> process (including Perl itself) may invoke Perl.  Thus under Unix, every 
> Perl script *can behave* like a stand-alone app.  Not so sure about NT.

I believe the simple answer to the question is yes.  See the mention of 
PerlApp for example included with the Perl Development Kit from Activestate:

  http://www.activestate.com/pdk/

 "PerlApp Turns your Perl scripts into executables 
  that at your option, can be free-standing so
  that you can run Perl scripts on computers 
  without Perl."

which sounds like what was requested.  On unix it's possible to use perlcc
or the B module to create binaries.  (perlcc does not quite work yet on VMS).
Note however that the API for creating standalones is quite different on 
the various platforms.

> > Could the same core code be run as a CGI  on a UNIX system, using HTML for
> > its interface?
> 
> Properly written, the same core code could be run as a CGI under ANY OS, 
> but unless you really need it to run as a CGI, see my answer about 
> interface code.  I think the CGI route is very much a sub-optimal 
> solution.

It strongly depends on the nature of the problem.  For simple queries
that return text and/or blob info CGI has been displacing expensive 
client/server dbms solutions.  It has the advantage that the developer
only requires prospective clients to have installed a basic web browser
(lynx, netscape, i.e., opera, etc.) thereby solving the deployment
problem quite simply.  Well perhaps not so simply since is makes the 
assumption that _everyone_ has a web browser, sometimes further assuming 
that everyone has a particular version of a particular browser with a 
particular plugin already installed.  Such assumptions rarely pan out
for a web site intended to serve the entire internet, but can work out
for an intranet intened to serve the administartors at a school e.g.

For general information on portability - with an emphasis on non-portable
construct that should be avoided - see the perlport doc at e.g.:

  http://www.perl.com/pub/doc/manual/html/pod/perlport.html

Peter Prymmer



===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org