ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zip
-in F<?:\JUST_ADD\view.exe>. This gives one an access to B<EMX>'s
+in F<?:\JUST_ADD\view.exe>. This gives one an access to EMX's
F<.INF> docs as well (text form is available in F</emx/doc> in
-B<EMX>'s distribution).
+EMX's distribution).
=cut
- Target
- Other OSes
- Prerequisites
- - Starting Perl programs under OS/2
- - Starting OS/2 programs under Perl
+ - Starting Perl programs under OS/2 (and DOS and...)
+ - Starting OS/2 (and DOS) programs under Perl
Frequently asked questions
- I cannot run external programs
- I cannot embed perl into my program, or use perl.dll from my program.
- `` and pipe-open do not work under DOS.
+ - Cannot start find.exe "pattern" file
INSTALLATION
- Automatic binary installation
- Manual binary installation
- Some problem (forget which ;-)
- Library ... not found
- Segfault in make
- Specific (mis)features of OS/2 port
+ Specific (mis)features of EMX port
- setpriority, getpriority
- system()
+ - extproc on the first line
- Additional modules:
- Prebuilt methods:
- Misfeatures
The target is to make OS/2 the best supported platform for
using/building/developing Perl and I<Perl applications>, as well as
-make Perl the best language to use under OS/2.
+make Perl the best language to use under OS/2. The secondary target is
+to try to make this work under DOS and Win* as well (but not B<too> hard).
The current state is quite close to this target. Known limitations:
=item *
-There is no simple way to access B<WPS> objects. The only way I know
+There is no simple way to access WPS objects. The only way I know
is via C<OS2::REXX> extension (see L<OS2::REXX>), and we do not have access to
-convenience methods of B<Object REXX>. (Is it possible at all? I know
-of no B<Object-REXX> API.)
+convenience methods of Object-REXX. (Is it possible at all? I know
+of no Object-REXX API.)
=back
=head2 Other OSes
-Since OS/2 port of perl uses a remarkable B<EMX> environment, it can
+Since OS/2 port of perl uses a remarkable EMX environment, it can
run (and build extensions, and - possibly - be build itself) under any
environment which can run EMX. The current list is DOS,
DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT. Out of many perl flavors,
Note that not all features of Perl are available under these
environments. This depends on the features the I<extender> - most
-probably C<RSX> - decided to implement.
+probably RSX - decided to implement.
Cf. L<Prerequisites>.
=over 6
-=item B<EMX>
+=item EMX
-B<EMX> runtime is required (may be substituted by B<RSX>). Note that
+EMX runtime is required (may be substituted by RSX). Note that
it is possible to make F<perl_.exe> to run under DOS without any
external support by binding F<emx.exe>/F<rsx.exe> to it, see L<emxbind>. Note
-that under DOS for best results one should use B<RSX> runtime, which
+that under DOS for best results one should use RSX runtime, which
has much more functions working (like C<fork>, C<popen> and so on). In
-fact B<RSX> is required if there is no C<VCPI> present. Note the
-B<RSX> requires C<DPMI>.
+fact RSX is required if there is no VCPI present. Note the
+RSX requires DPMI.
-Only the latest runtime is supported, currently C<0.9c>.
+Only the latest runtime is supported, currently C<0.9c>. Perl may run
+under earlier versions of EMX, but this is not tested.
-One can get different parts of B<EMX> from, say
+One can get different parts of EMX from, say
ftp://ftp.cdrom.com/pub/os2/emx0.9c/
ftp://hobbes.nmsu.edu/os2/unix/gnu/
will work as well.)
-=item B<RSX>
+=item RSX
-To run Perl on C<DPMI> platforms one needs B<RSX> runtime. This is
+To run Perl on DPMI platforms one needs RSX runtime. This is
needed under DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT (see
-L<"Other OSes">). B<RSX> would not work with C<VCPI>
-only, as B<EMX> would, it requires C<DMPI>.
+L<"Other OSes">). RSX would not work with VCPI
+only, as EMX would, it requires DMPI.
-Having B<RSX> and the latest F<sh.exe> one gets a fully functional
+Having RSX and the latest F<sh.exe> one gets a fully functional
B<*nix>-ish environment under DOS, say, C<fork>, C<``> and
pipe-C<open> work. In fact, MakeMaker works (for static build), so one
can have Perl development environment under DOS.
-One can get B<RSX> from, say
+One can get RSX from, say
ftp://ftp.cdrom.com/pub/os2/emx0.9c/contrib
ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.exe
-=item B<HPFS>
+=item HPFS
Perl does not care about file systems, but to install the whole perl
library intact one needs a file system which supports long file names.
Note that if you do not plan to build the perl itself, it may be
-possible to fool B<EMX> to truncate file names. This is not supported,
-read B<EMX> docs to see how to do it.
+possible to fool EMX to truncate file names. This is not supported,
+read EMX docs to see how to do it.
+
+=item pdksh
+
+To start external programs with complicated command lines (like with
+pipes in between, and/or quoting of arguments), Perl uses an external
+shell. With EMX port such shell should be named <sh.exe>, and located
+either in the wired-in-during-compile locations (usually F<F:/bin>),
+or in configurable location (see L<"PERL_SH_DIR">).
+
+For best results use EMX pdksh. The soon-to-be-available standard
+binary (5.2.12?) runs under DOS (with L<RSX>) as well, meanwhile use
+the binary from
+
+ ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.exe
=back
-=head2 Starting Perl programs under OS/2
+=head2 Starting Perl programs under OS/2 (and DOS and...)
Start your Perl program F<foo.pl> with arguments C<arg1 arg2 arg3> the
same way as on any other platform, by
perl -my_opts foo.pl arg1 arg2 arg3
-Alternately, if you use OS/2-ish shell, like C<CMD> or C<4os2>, put
+Alternately, if you use OS/2-ish shell, like CMD or 4os2, put
the following at the start of your perl script:
- extproc perl -x -S
- #!/usr/bin/perl -my_opts
+ extproc perl -S -my_opts
rename your program to F<foo.cmd>, and start it by typing
foo arg1 arg2 arg3
-(Note that having *nixish full path to perl F</usr/bin/perl> is not
-necessary, F<perl> would be enough, but having full path would make it
-easier to use your script under *nix.)
-
Note that because of stupid OS/2 limitations the full path of the perl
script is not available when you use C<extproc>, thus you are forced to
use C<-S> perl switch, and your script should be on path. As a plus
side, if you know a full path to your script, you may still start it
with
- perl -x ../../blah/foo.cmd arg1 arg2 arg3
+ perl ../../blah/foo.cmd arg1 arg2 arg3
-(note that the argument C<-my_opts> is taken care of by the C<#!> line
-in your script).
+(note that the argument C<-my_opts> is taken care of by the C<extproc> line
+in your script, see L<C<extproc> on the first line>).
To understand what the above I<magic> does, read perl docs about C<-S>
-and C<-x> switches - see L<perlrun>, and cmdref about C<extproc>:
+switch - see L<perlrun>, and cmdref about C<extproc>:
view perl perlrun
man perlrun
or whatever method you prefer.
There are also endless possibilities to use I<executable extensions> of
-B<4OS2>, I<associations> of B<WPS> and so on... However, if you use
+4os2, I<associations> of WPS and so on... However, if you use
*nixish shell (like F<sh.exe> supplied in the binary distribution),
you need to follow the syntax specified in L<perlrun/"Switches">.
-=head2 Starting OS/2 programs under Perl
+=head2 Starting OS/2 (and DOS) programs under Perl
This is what system() (see L<perlfunc/system>), C<``> (see
L<perlop/"I/O Operators">), and I<open pipe> (see L<perlfunc/open>)
do).
Note however that to use some of these operators you need to have a
-C<sh>-syntax shell installed (see L<"Pdksh">,
+sh-syntax shell installed (see L<"Pdksh">,
L<"Frequently asked questions">), and perl should be able to find it
(see L<"PERL_SH_DIR">).
=item
Did you run your programs with C<-w> switch? See
-L<Starting OS/2 programs under Perl>.
+L<Starting OS/2 (and DOS) programs under Perl>.
=item
=over 4
-=item Is your program B<EMX>-compiled with C<-Zmt -Zcrtdll>?
+=item Is your program EMX-compiled with C<-Zmt -Zcrtdll>?
If not, you need to build a stand-alone DLL for perl. Contact me, I
did it once. Sockets would not work, as a lot of other stuff.
-=item Did you use C<ExtUtils::Embed>?
+=item Did you use L<ExtUtils::Embed>?
I had reports it does not work. Somebody would need to fix it.
=head2 C<``> and pipe-C<open> do not work under DOS.
This may a variant of just L<"I cannot run external programs">, or a
-deeper problem. Basically: you I<need> B<RSX> (see L<"Prerequisites">)
+deeper problem. Basically: you I<need> RSX (see L<"Prerequisites">)
for these commands to work, and you may need a port of F<sh.exe> which
understands command arguments. One of such ports is listed in
-L<"Prerequisites"> under B<RSX>.
+L<"Prerequisites"> under RSX. Do not forget to set variable
+C<L<"PERL_SH_DIR">> as well.
+
+DPMI is required for RSX.
+
+=head2 Cannot start C<find.exe "pattern" file>
-C<DPMI> is required for B<RSX>.
+Use one of
+
+ system 'cmd', '/c', 'find "pattern" file';
+ `cmd /c 'find "pattern" file'`
+
+This would start F<find.exe> via F<cmd.exe> via C<sh.exe> via
+C<perl.exe>, but this is a price to pay if you want to use
+non-conforming program. In fact F<find.exe> cannot be started at all
+using C library API only. Otherwise the following command-lines were
+equivalent:
+
+ find "pattern" file
+ find pattern file
=head1 INSTALLATION
installation blues would go away.
Note however, that you need to have F<unzip.exe> on your path, and
-B<EMX> environment I<running>. The latter means that if you just
-installed B<EMX>, and made all the needed changes to F<Config.sys>,
-you may need to reboot in between. Check B<EMX> runtime by running
+EMX environment I<running>. The latter means that if you just
+installed EMX, and made all the needed changes to F<Config.sys>,
+you may need to reboot in between. Check EMX runtime by running
emxrev
=item C<PERL_BADLANG>
may be needed if you change your codepage I<after> perl installation,
-and the new value is not supported by B<EMX>. See L<"PERL_BADLANG">.
+and the new value is not supported by EMX. See L<"PERL_BADLANG">.
=item C<PERL_BADFREE>
=back
+B<NOTE>. Because of a typo the binary installer of 5.00305
+would install a variable C<PERL_SHPATH> into F<Config.sys>. Please
+remove this variable and put C<L<PERL_SH_DIR>> instead.
+
=head2 Manual binary installation
As of version 5.00305, OS/2 perl binary distribution comes split
into 11 components. Unfortunately, to enable configurable binary
-installation, the file paths in the C<zip> files are not absolute, but
+installation, the file paths in the zip files are not absolute, but
relative to some directory.
Note that the extraction with the stored paths is still necessary
-(default with C<unzip>, specify C<-d> to C<pkunzip>). However, you
+(default with unzip, specify C<-d> to pkunzip). However, you
need to know where to extract the files. You need also to manually
change entries in F<Config.sys> to reflect where did you put the
files. Note that if you have some primitive unzipper (like
-C<pkunzip>), you may get a lot of warnings/errors during
+pkunzip), you may get a lot of warnings/errors during
unzipping. Upgrade to C<(w)unzip>.
Below is the sample of what to do to reproduce the configuration on my
unzip perl_exc.zip *.exe *.ico -d f:/emx.add/bin
unzip perl_exc.zip *.dll -d f:/emx.add/dll
-(have the directories with C<*.exe> on C<PATH>, and C<*.dll> on
-C<LIBPATH>);
+(have the directories with C<*.exe> on PATH, and C<*.dll> on
+LIBPATH);
=item Perl_ VIO executable (statically linked)
unzip perl_aou.zip -d f:/emx.add/bin
-(have the directory on C<PATH>);
+(have the directory on PATH);
=item Executables for Perl utilities
unzip perl_utl.zip -d f:/emx.add/bin
-(have the directory on C<PATH>);
+(have the directory on PATH);
=item Main Perl library
unzip perl_man.zip -d f:/perllib/man
This directory should better be on C<MANPATH>. You need to have a
-working C<man> to access these files.
+working man to access these files.
=item Manpages for Perl modules
unzip perl_mam.zip -d f:/perllib/man
This directory should better be on C<MANPATH>. You need to have a
-working C<man> to access these files.
+working man to access these files.
=item Source for Perl documentation
unzip perl_pod.zip -d f:/perllib/lib
This is used by by C<perldoc> program (see L<perldoc>), and may be used to
-generate B<HTML> documentation usable by WWW browsers, and
+generate HTML documentation usable by WWW browsers, and
documentation in zillions of other formats: C<info>, C<LaTeX>,
C<Acrobat>, C<FrameMaker> and so on.
-=item Perl manual in .INF format
+=item Perl manual in F<.INF> format
unzip perl_inf.zip -d d:/os2/book
Set C<PERL_SH_DIR> (see L<"PERL_SH_DIR">) if you move F<sh.exe> from
the above location.
-B<Note.> It may be possible to use some other C<sh>-compatible shell
+B<Note.> It may be possible to use some other sh-compatible shell
(I<not tested>).
=back
=head2 OS/2 F<.INF> file
-Most probably the most convenient form. View it as
+Most probably the most convenient form. Under OS/2 view it as
view perl
view perl perlfunc
view perl ExtUtils::MakeMaker
(currently the last two may hit a wrong location, but this may improve
-soon).
+soon). Under Win* see L<"SYNOPSIS">.
If you want to build the docs yourself, and have I<OS/2 toolkit>, run
=head2 Plain text
If you have perl documentation in the source form, perl utilities
-installed, and B<GNU> C<groff> installed, you may use
+installed, and GNU groff installed, you may use
perldoc perlfunc
perldoc less
=head2 Manpages
-If you have C<man> installed on your system, and you installed perl
+If you have man installed on your system, and you installed perl
manpages, use something like this:
man perlfunc
set MANPATH=c:/man;f:/perllib/man
-=head2 B<HTML>
+=head2 HTML
If you have some WWW browser available, installed the Perl
documentation in the source form, and Perl utilities, you can build
-B<HTML> docs. Cd to directory with F<.pod> files, and do like this
+HTML docs. Cd to directory with F<.pod> files, and do like this
cd f:/perllib/lib/pod
pod2html
explore file:///f:/perllib/lib/pod/perl.html
-Alternatively you may be able to get these docs prebuilt from C<CPAN>.
+Alternatively you may be able to get these docs prebuilt from CPAN.
-=head2 B<GNU> C<info> files
+=head2 GNU C<info> files
-Users of C<Emacs> would appreciate it very much, especially with
+Users of Emacs would appreciate it very much, especially with
C<CPerl> mode loaded. You need to get latest C<pod2info> from C<CPAN>,
or, alternately, prebuilt info pages.
=head2 Prerequisites
-You need to have the latest B<EMX> development environment, the full
-B<GNU> tool suite (C<gawk> renamed to C<awk>, and B<GNU> F<find.exe>
+You need to have the latest EMX development environment, the full
+GNU tool suite (gawk renamed to awk, and GNU F<find.exe>
earlier on path than the OS/2 F<find.exe>, same with F<sort.exe>, to
check use
if you use something like F<CMD.EXE> or latest versions of F<4os2.exe>.
-Make sure your C<gcc> is good for C<-Zomf> linking: run C<omflibs>
+Make sure your gcc is good for C<-Zomf> linking: run C<omflibs>
script in F</emx/lib> directory.
-Check that you have C<link386> installed. It comes standard with OS/2,
+Check that you have link386 installed. It comes standard with OS/2,
but may be not installed due to customization. If typing
link386
shows you do not have it, do I<Selective install>, and choose C<Link
object modules> in I<Optional system utilities/More>. If you get into
-C<link386>, press C<Ctrl-C>.
+link386, press C<Ctrl-C>.
=head2 Getting perl source
You may see a message about errors while extracting F<Configure>. This is
because there is a conflict with a similarly-named file F<configure>.
-Rename F<configure> to F<configure.gnu>. Extract F<Configure> like this
-
- tar --case-sensitive -vzxf perl5.00409.tar.gz perl5.00409/Configure
-
Change to the directory of extraction.
=head2 Application of the patches
You may also need to apply the patches supplied with the binary
distribution of perl.
-Note also that the F<db.lib> and F<db.a> from the B<EMX> distribution
+Note also that the F<db.lib> and F<db.a> from the EMX distribution
are not suitable for multi-threaded compile (note that currently perl
-is not multithreaded, but is compiled as multithreaded for
-compatibility with B<XFree86>-OS/2). Get a corrected one from
+is not multithread-safe, but is compiled as multithreaded for
+compatibility with XFree86-OS/2). Get a corrected one from
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/db_mt.zip
sh Configure -des -D prefix=f:/perllib
-Prefix means where to install the resulting perl library. Giving
+C<prefix> means: where to install the resulting perl library. Giving
correct prefix you may avoid the need to specify C<PERLLIB_PREFIX>,
see L<"PERLLIB_PREFIX">.
I<Ignore the message about missing C<ln>, and about C<-c> option to
-C<tr>>. In fact if you can trace where the latter spurious warning
+tr>. In fact if you can trace where the latter spurious warning
comes from, please inform me.
Now
At some moment the built may die, reporting a I<version mismatch> or
I<unable to run F<perl>>. This means that most of the build has been
finished, and it is the time to move the constructed F<perl.dll> to
-some I<absolute> location in C<LIBPATH>. After this done the build
-should finish without a lot of fuss. I<One can avoid it if one has the
-correct prebuilt version of F<perl.dll> on C<LIBPATH>.>
+some I<absolute> location in LIBPATH. After this is done the build
+should finish without a lot of fuss. I<One can avoid the interruption
+if one has the correct prebuilt version of F<perl.dll> on LIBPATH, but
+probably this is not needed anymore, since F<miniperl.exe> is linked
+statically now.>
Warnings which are safe to ignore: I<mkfifo() redefined> inside
F<POSIX.c>.
segfault (system error C<SYS3175>). To get finer error reports,
cd t
- perl -I ../lib harness
+ perl harness
The report you get may look like
Failed 4/140 test scripts, 97.14% okay. 27/2937 subtests failed, 99.08% okay.
Note that using `make test' target two more tests may fail: C<op/exec:1>
-because of (mis)feature of C<pdksh>, and C<lib/posix:15>, which checks
+because of (mis)feature of pdksh, and C<lib/posix:15>, which checks
that the buffers are not flushed on C<_exit> (this is a bug in the test
which assumes that tty output is buffered).
-I submitted a patch to B<EMX> which makes it possible to fork() with EMX
+I submitted a patch to EMX which makes it possible to fork() with EMX
dynamic libraries loaded, which makes F<lib/io*> tests pass. This means
that soon the number of failing tests may decrease yet more.
=item F<lib/io_pipe.t>
-Checks C<IO::Pipe> module. Some feature of B<EMX> - test fork()s with
+Checks C<IO::Pipe> module. Some feature of EMX - test fork()s with
dynamic extension loaded - unsupported now.
=item F<lib/io_sock.t>
-Checks C<IO::Socket> module. Some feature of B<EMX> - test fork()s
+Checks C<IO::Socket> module. Some feature of EMX - test fork()s
with dynamic extension loaded - unsupported now.
=item F<op/stat.t>
It would put the generated files into needed locations. Manually put
F<perl.exe>, F<perl__.exe> and F<perl___.exe> to a location on your
-C<PATH>, F<perl.dll> to a location on your C<LIBPATH>.
+PATH, F<perl.dll> to a location on your LIBPATH.
Run
make cmdscripts INSTALLCMDDIR=d:/ir/on/path
to convert perl utilities to F<.cmd> files and put them on
-C<PATH>. You need to put F<.EXE>-utilities on path manually. They are
+PATH. You need to put F<.EXE>-utilities on path manually. They are
installed in C<$prefix/bin>, here C<$prefix> is what you gave to
F<Configure>, see L<Making>.
make aout_test
make aout_install
-Manually put F<perl_.exe> to a location on your C<PATH>.
+Manually put F<perl_.exe> to a location on your PATH.
Since C<perl_> has the extensions prebuilt, it does not suffer from
the I<dynamic extensions + fork()> syndrome, thus the failing tests
You do not have MT-safe F<db.lib>. See L<Prerequisites>.
-=head2 Problems with C<tr>
+=head2 Problems with tr
-reported with very old version of C<tr>.
+reported with very old version of tr.
=head2 Some problem (forget which ;-)
-You have an older version of F<perl.dll> on your C<LIBPATH>, which
+You have an older version of F<perl.dll> on your LIBPATH, which
broke the build of extensions.
=head2 Library ... not found
=head2 Segfault in make
-You use an old version of C<GNU> make. See L<Prerequisites>.
+You use an old version of GNU make. See L<Prerequisites>.
=head1 Specific (mis)features of OS/2 port
argument. The meaning of this argument is described in
L<OS2::Process>.
+=head2 C<extproc> on the first line
+
+If the first chars of a script are C<"extproc ">, this line is treated
+as C<#!>-line, thus all the switches on this line are processed (twice
+if script was started via cmd.exe).
+
=head2 Additional modules:
L<OS2::Process>, L<OS2::REXX>, L<OS2::PrfDB>, L<OS2::ExtAttr>. This
=item C<Cwd::sys_cwd(name)>
-Interface to cwd from B<EMX>. Used by C<Cwd::cwd>.
+Interface to cwd from EMX. Used by C<Cwd::cwd>.
=item C<Cwd::sys_abspath(name, dir)>
=item
-Since <flock> is present in B<EMX>, but is not functional, the same is
+Since <flock> is present in EMX, but is not functional, the same is
true for perl. Here is the list of things which may be "broken" on
EMX (from EMX docs):
of F<sh.exe> plague perl as well.
In particular, uppercase letters do not work in C<[...]>-patterns with
-the current C<pdksh>.
+the current pdksh.
=back
=head1 Perl flavors
Because of idiosyncrasies of OS/2 one cannot have all the eggs in the
-same basket (though C<EMX> environment tries hard to overcome this
+same basket (though EMX environment tries hard to overcome this
limitations, so the situation may somehow improve). There are 4
executables for Perl provided by the distribution:
The main workhorse. This is a chimera executable: it is compiled as an
C<a.out>-style executable, but is linked with C<omf>-style dynamic
-library F<perl.dll>, and with dynamic B<CRT> DLL. This executable is a
-C<VIO> application.
+library F<perl.dll>, and with dynamic CRT DLL. This executable is a
+VIO application.
It can load perl dynamic extensions, and it can fork(). Unfortunately,
-with the current version of B<EMX> it cannot fork() with dynamic
-extensions loaded (may be fixed by patches to B<EMX>).
+with the current version of EMX it cannot fork() with dynamic
+extensions loaded (may be fixed by patches to EMX).
B<Note.> Keep in mind that fork() is needed to open a pipe to yourself.
but cannot load dynamic Perl extensions. The supplied executable has a
lot of extensions prebuilt, thus there are situations when it can
perform tasks not possible using F<perl.exe>, like fork()ing when
-having some standard extension loaded. This executable is a C<VIO>
+having some standard extension loaded. This executable is a VIO
application.
B<Note.> A better behaviour could be obtained from C<perl.exe> if it
were statically linked with standard I<Perl extensions>, but
-dynamically linked with the I<Perl DLL> and C<CRT> DLL. Then it would
+dynamically linked with the I<Perl DLL> and CRT DLL. Then it would
be able to fork() with standard extensions, I<and> would be able to
dynamically load arbitrary extensions. Some changes to Makefiles and
hint files should be necessary to achieve this.
=head2 F<perl__.exe>
-This is the same executable as <perl___.exe>, but it is a C<PM>
+This is the same executable as F<perl___.exe>, but it is a PM
application.
-B<Note.> Usually C<STDIN>, C<STDERR>, and C<STDOUT> of a C<PM>
+B<Note.> Usually STDIN, STDERR, and STDOUT of a PM
application are redirected to C<nul>. However, it is possible to see
them if you start C<perl__.exe> from a PM program which emulates a
-console window, like I<Shell mode> of C<Emacs> or C<EPM>. Thus it I<is
+console window, like I<Shell mode> of Emacs or EPM. Thus it I<is
possible> to use Perl debugger (see L<perldebug>) to debug your PM
application.
-This flavor is required if you load extensions which use C<PM>, like
+This flavor is required if you load extensions which use PM, like
the forthcoming C<Perl/Tk>.
=head2 F<perl___.exe>
This is an C<omf>-style executable which is dynamically linked to
-F<perl.dll> and C<CRT> DLL. I know no advantages of this executable
+F<perl.dll> and CRT DLL. I know no advantages of this executable
over C<perl.exe>, but it cannot fork() at all. Well, one advantage is
that the build process is not so convoluted as with C<perl.exe>.
-It is a C<VIO> application.
+It is a VIO application.
=head2 Why strange names?
This I<greatly> increases the load time for the application (as well as
the number of problems during compilation). Since interpreter is in a DLL,
-the C<CRT> is basically forced to reside in a DLL as well (otherwise
-extensions would not be able to use C<CRT>).
+the CRT is basically forced to reside in a DLL as well (otherwise
+extensions would not be able to use CRT).
=head2 Why chimera build?
-Current C<EMX> environment does not allow DLLs compiled using Unixish
+Current EMX environment does not allow DLLs compiled using Unixish
C<a.out> format to export symbols for data. This forces C<omf>-style
compile of F<perl.dll>.
-Current C<EMX> environment does not allow F<.EXE> files compiled in
+Current EMX environment does not allow F<.EXE> files compiled in
C<omf> format to fork(). fork() is needed for exactly three Perl
operations:
=head1 ENVIRONMENT
-Here we list environment variables with are either OS/2-specific, or
-are more important under OS/2 than under other OSes.
+Here we list environment variables with are either OS/2- and DOS- and
+Win*-specific, or are more important under OS/2 than under other OSes.
=head2 C<PERLLIB_PREFIX>
-Specific for OS/2. Should have the form
+Specific for EMX port. Should have the form
path1;path2
=head2 C<PERL_SH_DIR>
-Specific for OS/2. Gives the directory part of the location for
+Specific for EMX port. Gives the directory part of the location for
F<sh.exe>.
=head2 C<TMP> or C<TEMP>
-Specific for OS/2. Used as storage place for temporary files, most
+Specific for EMX port. Used as storage place for temporary files, most
notably C<-e> scripts.
=head1 Evolution
=head2 Threading
-As of release 5.003_01 perl is linked to multithreaded C<CRT>
+As of release 5.003_01 perl is linked to multithreaded CRT
DLL. Perl itself is not multithread-safe, as is not perl
malloc(). However, extensions may use multiple thread on their own
risk.
-Needed to compile C<Perl/Tk> for C<XFreeOS/2> out-of-the-box.
+Needed to compile C<Perl/Tk> for XFree86-OS/2 out-of-the-box.
=head2 Calls to external programs
one non-overridable shell per platform. The obvious choices for OS/2
are F<cmd.exe> and F<sh.exe>. Having perl build itself would be impossible
with F<cmd.exe> as a shell, thus I picked up C<sh.exe>. Thus assures almost
-100% compatibility with the scripts coming from *nix.
+100% compatibility with the scripts coming from *nix. As an added benefit
+this works as well under DOS if you use DOS-enabled port of pdksh
+(see L<"Prerequisites">).
-B<Disadvantages:> currently F<sh.exe> of C<pdksh> calls external programs
+B<Disadvantages:> currently F<sh.exe> of pdksh calls external programs
via fork()/exec(), and there is I<no> functioning exec() on
OS/2. exec() is emulated by EMX by asyncroneous call while the caller
waits for child completion (to pretend that the C<pid> did not change). This
files - and maybe some other extensions at the time you read it.
Note that OS2 perl defines 2 pseudo-extension functions
-OS2::Copy::copy and DynaLoader::mod2fname.
+OS2::Copy::copy and DynaLoader::mod2fname (many more now, see
+L<Prebuilt methods>).
The -R switch of older perl is deprecated. If you need to call a REXX code
which needs access to variables, include the call into a REXX compartment
projects / p5sagit/p5-mst-13.2.git / commitdiff