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