perlos2.pod

MSYS在windows下模拟了一个类unix的终端

Very useful for extensions which use PM, like C<Perl/Tk> or C<OpenGL>.

=head2 F<perl___.exe>

This is an C<omf>-style executable which is dynamically linked to
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 VIO application.

=head2 Why strange names?

Since Perl processes the C<#!>-line (cf. 
L<perlrun/DESCRIPTION>, L<perlrun/Switches>,
L<perldiag/"Not a perl script">, 
L<perldiag/"No Perl script found in input">), it should know when a
program I<is a Perl>. There is some naming convention which allows
Perl to distinguish correct lines from wrong ones. The above names are
almost the only names allowed by this convention which do not contain
digits (which have absolutely different semantics).

=head2 Why dynamic linking?

Well, having several executables dynamically linked to the same huge
library has its advantages, but this would not substantiate the
additional work to make it compile. The reason is the complicated-to-developers
but very quick and convenient-to-users "hard" dynamic linking used by OS/2.

There are two distinctive features of the dyna-linking model of OS/2:
all the references to external functions are resolved at the compile time;
there is no runtime fixup of the DLLs after they are loaded into memory.
The first feature is an enormous advantage over other models: it avoids
conflicts when several DLLs used by an application export entries with
the same name.  In such cases "other" models of dyna-linking just choose
between these two entry points using some random criterion - with predictable
disasters as results.  But it is the second feature which requires the build
of F<perl.dll>.

The address tables of DLLs are patched only once, when they are
loaded. The addresses of the entry points into DLLs are guaranteed to be
the same for all the programs which use the same DLL.  This removes the
runtime fixup - once DLL is loaded, its code is read-only.

While this allows some (significant?) performance advantages, this makes life
much harder for developers, since the above scheme makes it impossible
for a DLL to be "linked" to a symbol in the F<.EXE> file.  Indeed, this
would need a DLL to have different relocations tables for the
(different) executables which use this DLL.

However, a dynamically loaded Perl extension is forced to use some symbols
from the perl
executable, e.g., to know how to find the arguments to the functions:
the arguments live on the perl
internal evaluation stack. The solution is to put the main code of
the interpreter into a DLL, and make the F<.EXE> file which just loads
this DLL into memory and supplies command-arguments.  The extension DLL
cannot link to symbols in F<.EXE>, but it has no problem linking
to symbols in the F<.DLL>.

This I<greatly> increases the load time for the application (as well as
complexity of the compilation). Since interpreter is in a DLL,
the C RTL is basically forced to reside in a DLL as well (otherwise
extensions would not be able to use CRT).  There are some advantages if
you use different flavors of perl, such as running F<perl.exe> and
F<perl__.exe> simultaneously: they share the memory of F<perl.dll>.

B<NOTE>.  There is one additional effect which makes DLLs more wasteful:
DLLs are loaded in the shared memory region, which is a scarse resource
given the 512M barrier of the "standard" OS/2 virtual memory.  The code of
F<.EXE> files is also shared by all the processes which use the particular
F<.EXE>, but they are "shared in the private address space of the process";
this is possible because the address at which different sections
of the F<.EXE> file are loaded is decided at compile-time, thus all the
processes have these sections loaded at same addresses, and no fixup
of internal links inside the F<.EXE> is needed.

Since DLLs may be loaded at run time, to have the same mechanism for for DLLs
one needs to have the address range of I<any of the loaded> DLLs in the
system to be available I<in all the processes> which did not load a particular
DLL yet.  This is why the DLLs are mapped to the shared memory region.

=head2 Why chimera build?

Current EMX environment does not allow DLLs compiled using Unixish
C<a.out> format to export symbols for data (or at least some types of
data). This forces C<omf>-style compile of F<perl.dll>.

Current EMX environment does not allow F<.EXE> files compiled in
C<omf> format to fork(). fork() is needed for exactly three Perl
operations:

=over 4

=item *

explicit fork() in the script, 

=item *

C<open FH, "|-">

=item *

C<open FH, "-|">, in other words, opening pipes to itself.

=back

While these operations are not questions of life and death, they are
needed for a lot of
useful scripts. This forces C<a.out>-style compile of
F<perl.exe>.


=head1 ENVIRONMENT

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 EMX port. Should have the form

  path1;path2

or

  path1 path2

If the beginning of some prebuilt path matches F<path1>, it is
substituted with F<path2>.

Should be used if the perl library is moved from the default
location in preference to C<PERL(5)LIB>, since this would not leave wrong
entries in @INC.  For example, if the compiled version of perl looks for @INC
in F<f:/perllib/lib>, and you want to install the library in
F<h:/opt/gnu>, do

  set PERLLIB_PREFIX=f:/perllib/lib;h:/opt/gnu

This will cause Perl with the prebuilt @INC of

  f:/perllib/lib/5.00553/os2
  f:/perllib/lib/5.00553
  f:/perllib/lib/site_perl/5.00553/os2
  f:/perllib/lib/site_perl/5.00553
  .

to use the following @INC:

  h:/opt/gnu/5.00553/os2
  h:/opt/gnu/5.00553
  h:/opt/gnu/site_perl/5.00553/os2
  h:/opt/gnu/site_perl/5.00553
  .

=head2 C<PERL_BADLANG>

If 0, perl ignores setlocale() failing. May be useful with some
strange I<locale>s.

=head2 C<PERL_BADFREE>

If 0, perl would not warn of in case of unwarranted free(). With older
perls this might be
useful in conjunction with the module DB_File, which was buggy when
dynamically linked and OMF-built.

Should not be set with newer Perls, since this may hide some I<real> problems.

=head2 C<PERL_SH_DIR>

Specific for EMX port. Gives the directory part of the location for
F<sh.exe>.

=head2 C<USE_PERL_FLOCK>

Specific for EMX port. Since L<flock(3)> is present in EMX, but is not 
functional, it is emulated by perl.  To disable the emulations, set 
environment variable C<USE_PERL_FLOCK=0>.

=head2 C<TMP> or C<TEMP>

Specific for EMX port. Used as storage place for temporary files.

=head1 Evolution

Here we list major changes which could make you by surprise.

=head2 Priorities

C<setpriority> and C<getpriority> are not compatible with earlier
ports by Andreas Kaiser. See C<"setpriority, getpriority">.

=head2 DLL name mangling

With the release 5.003_01 the dynamically loadable libraries
should be rebuilt when a different version of Perl is compiled. In particular,
DLLs (including F<perl.dll>) are now created with the names
which contain a checksum, thus allowing workaround for OS/2 scheme of
caching DLLs.

It may be possible to code a simple workaround which would 

=over

=item *

find the old DLLs looking through the old @INC;

=item *

mangle the names according to the scheme of new perl and copy the DLLs to
these names;

=item *

edit the internal C<LX> tables of DLL to reflect the change of the name
(probably not needed for Perl extension DLLs, since the internally coded names
are not used for "specific" DLLs, they used only for "global" DLLs).

=item *

edit the internal C<IMPORT> tables and change the name of the "old"
F<perl????.dll> to the "new" F<perl????.dll>.

=back

=head2 Threading

As of release 5.003_01 perl is linked to multithreaded C RTL
DLL.  If perl itself is not compiled multithread-enabled, so will not be perl's
malloc(). However, extensions may use multiple thread on their own
risk. 

This was needed to compile C<Perl/Tk> for XFree86-OS/2 out-of-the-box, and
link with DLLs for other useful libraries, which typically are compiled
with C<-Zmt -Zcrtdll>.

=head2 Calls to external programs

Due to a popular demand the perl external program calling has been
changed wrt Andreas Kaiser's port.  I<If> perl needs to call an
external program I<via shell>, the F<f:/bin/sh.exe> will be called, or
whatever is the override, see L<"PERL_SH_DIR">.

Thus means that you need to get some copy of a F<sh.exe> as well (I
use one from pdksh). The path F<F:/bin> above is set up automatically during
the build to a correct value on the builder machine, but is
overridable at runtime,

B<Reasons:> a consensus on C<perl5-porters> was that perl should use
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>. This assures almost
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 pdksh calls external programs
via fork()/exec(), and there is I<no> functioning exec() on
OS/2. exec() is emulated by EMX by an asynchronous call while the caller
waits for child completion (to pretend that the C<pid> did not change). This
means that 1 I<extra> copy of F<sh.exe> is made active via fork()/exec(),
which may lead to some resources taken from the system (even if we do
not count extra work needed for fork()ing).

Note that this a lesser issue now when we do not spawn F<sh.exe>
unless needed (metachars found).

One can always start F<cmd.exe> explicitly via

  system 'cmd', '/c', 'mycmd', 'arg1', 'arg2', ...

If you need to use F<cmd.exe>, and do not want to hand-edit thousands of your
scripts, the long-term solution proposed on p5-p is to have a directive

  use OS2::Cmd;

which will override system(), exec(), C<``>, and
C<open(,'...|')>. With current perl you may override only system(),
readpipe() - the explicit version of C<``>, and maybe exec(). The code
will substitute the one-argument call to system() by
C<CORE::system('cmd.exe', '/c', shift)>.

If you have some working code for C<OS2::Cmd>, please send it to me,
I will include it into distribution. I have no need for such a module, so
cannot test it.

For the details of the current situation with calling external programs,
see L<Starting OS/2 (and DOS) programs under Perl>.  Set us mention a couple
of features:

=over 4

=item *

External scripts may be called by their basename.  Perl will try the same
extensions as when processing B<-S> command-line switch.

=item *

External scripts starting with C<#!> or C<extproc > will be executed directly,
without calling the shell, by calling the program specified on the rest of
the first line.

=back

=head2 Memory allocation

Perl uses its own malloc() under OS/2 - interpreters are usually malloc-bound
for speed, but perl is not, since its malloc is lightning-fast.
Perl-memory-usage-tuned benchmarks show that Perl's malloc is 5 times quicker
than EMX one.  I do not have convincing data about memory footprint, but
a (pretty random) benchmark showed that Perl's one is 5% better.

Combination of perl's malloc() and rigid DLL name resolution creates
a special problem with library functions which expect their return value to
be free()d by system's free(). To facilitate extensions which need to call 
such functions, system memory-allocation functions are still available with
the prefix C<emx_> added. (Currently only DLL perl has this, it should 
propagate to F<perl_.exe> shortly.)

=head2 Threads

One can build perl with thread support enabled by providing C<-D usethreads>
option to F<Configure>.  Currently OS/2 support of threads is very 
preliminary.

Most notable problems: 

=over 4

=item C<COND_WAIT> 

may have a race condition.  Needs a reimplementation (in terms of chaining
waiting threads, with the linked list stored in per-thread structure?).

=item F<os2.c>

has a couple of static variables used in OS/2-specific functions.  (Need to be
moved to per-thread structure, or serialized?)

=back

Note that these problems should not discourage experimenting, since they
have a low probability of affecting small programs.

=cut

OS/2 extensions
~~~~~~~~~~~~~~~
I include 3 extensions by Andreas Kaiser, OS2::REXX, OS2::UPM, and OS2::FTP, 
into my ftp directory, mirrored on CPAN. I made
some minor changes needed to compile them by standard tools. I cannot 
test UPM and FTP, so I will appreciate your feedback. Other extensions
there are OS2::ExtAttr, OS2::PrfDB for tied access to EAs and .INI
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 (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
created by 
	REXX_call {...block...};

Two new functions are supported by REXX code, 
	REXX_eval 'string';
	REXX_eval_with 'string', REXX_function_name => \&perl_sub_reference;

If you have some other extensions you want to share, send the code to
me.  At least two are available: tied access to EA's, and tied access
to system databases.

=head1 AUTHOR

Ilya Zakharevich, [e-mail]

=head1 SEE ALSO

perl(1).

=cut