perlos2.pod

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

If you read this file _as_is_, just ignore the funny characters you
see. It is written in the POD format (see perlpod manpage) which is
specially designed to be readable as is.

=head1 NAME

perlos2 - Perl under OS/2, DOS, Win0.3*, Win0.95 and WinNT.

=head1 SYNOPSIS

One can read this document in the following formats:

	man perlos2
	view perl perlos2
	explorer perlos2.html
	info perlos2

to list some (not all may be available simultaneously), or it may
be read I<as is>: either as F<README.os2>, or F<pod/perlos2.pod>.

To read the F<.INF> version of documentation (B<very> recommended)
outside of OS/2, one needs an IBM's reader (may be available on IBM
ftp sites (?)  (URL anyone?)) or shipped with PC DOS 7.0 and IBM's
Visual Age C++ 3.5.

A copy of a Win* viewer is contained in the "Just add OS/2 Warp" package

  ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zip

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 
EMX's distribution).  There is also a different viewer named xview.

Note that if you have F<lynx.exe> or F<netscape.exe> installed, you can follow WWW links
from this document in F<.INF> format. If you have EMX docs installed 
correctly, you can follow library links (you need to have C<view emxbook>
working by setting C<EMXBOOK> environment variable as it is described
in EMX docs).

=cut

Contents (This may be a little bit obsolete)
 
 perlos2 - Perl under OS/2, DOS, Win0.3*, Win0.95 and WinNT. 

      NAME
      SYNOPSIS
      DESCRIPTION
	 -  Target
	 -  Other OSes
	 -  Prerequisites
	 -  Starting Perl programs under OS/2 (and DOS and...)
	 -  Starting OS/2 (and DOS) programs under Perl
      Frequently asked questions
	 -  "It does not work"
	 -  I cannot run external programs
	 -  I cannot embed perl into my program, or use perl.dll from my
	 -  `` and pipe-open do not work under DOS.
	 -  Cannot start find.exe "pattern" file
      INSTALLATION
	 -  Automatic binary installation
	 -  Manual binary installation
	 -  Warning
      Accessing documentation
	 -  OS/2 .INF file
	 -  Plain text
	 -  Manpages
	 -  HTML
	 -  GNU info files
	 -  PDF files
	 -  LaTeX docs
      BUILD
	 -  The short story
	 -  Prerequisites
	 -  Getting perl source
	 -  Application of the patches
	 -  Hand-editing
	 -  Making
	 -  Testing
	 -  Installing the built perl
	 -  a.out-style build
      Build FAQ
	 -  Some / became \ in pdksh.
	 -  'errno' - unresolved external
	 -  Problems with tr or sed
	 -  Some problem (forget which ;-)
	 -  Library ... not found
	 -  Segfault in make
	 -  op/sprintf test failure
      Specific (mis)features of OS/2 port
	 -  setpriority, getpriority
	 -  system()
	 -  extproc on the first line
	 -  Additional modules:
	 -  Prebuilt methods:
	 -  Prebuilt variables:
	 -  Misfeatures
	 -  Modifications
	 -  Identifying DLLs
	 -  Centralized management of resources
      Perl flavors
	 -  perl.exe
	 -  perl_.exe
	 -  perl__.exe
	 -  perl___.exe
	 -  Why strange names?
	 -  Why dynamic linking?
	 -  Why chimera build?
      ENVIRONMENT
	 -  PERLLIB_PREFIX
	 -  PERL_BADLANG
	 -  PERL_BADFREE
	 -  PERL_SH_DIR
	 -  USE_PERL_FLOCK
	 -  TMP or TEMP
      Evolution
	 -  Text-mode filehandles
	 -  Priorities
	 -  DLL name mangling: pre 5.6.2
	 -  DLL name mangling: 5.6.2 and beyond
	 -  DLL forwarder generation
	 -  Threading
	 -  Calls to external programs
	 -  Memory allocation
	 -  Threads
      BUGS
      AUTHOR
      SEE ALSO

=head1 DESCRIPTION

=head2 Target

The target is to make OS/2 one of 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. 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:

=over 5

=item *

Some *nix programs use fork() a lot; with the mostly useful flavors of
perl for OS/2 (there are several built simultaneously) this is
supported; but some flavors do not support this (e.g., when Perl is
called from inside REXX).  Using fork() after
I<use>ing dynamically loading extensions would not work with I<very> old
versions of EMX.

=item *

You need a separate perl executable F<perl__.exe> (see L<perl__.exe>)
if you want to use PM code in your application (as Perl/Tk or OpenGL
Perl modules do) without having a text-mode window present.

While using the standard F<perl.exe> from a text-mode window is possible
too, I have seen cases when this causes degradation of the system stability.
Using F<perl__.exe> avoids such a degradation.

=item *

There is no simple way to access WPS objects. The only way I know
is via C<OS2::REXX> and C<SOM> extensions (see L<OS2::REXX>, L<Som>).
However, we do not have access to
convenience methods of Object-REXX. (Is it possible at all? I know
of no Object-REXX API.)  The C<SOM> extension (currently in alpha-text)
may eventually remove this shortcoming; however, due to the fact that
DII is not supported by the C<SOM> module, using C<SOM> is not as
convenient as one would like it.

=back

Please keep this list up-to-date by informing me about other items.

=head2 Other OSes

Since OS/2 port of perl uses a remarkable EMX environment, it can
run (and build extensions, and - possibly - be built 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,
only one works, see L<"perl_.exe">.

Note that not all features of Perl are available under these
environments. This depends on the features the I<extender> - most
probably RSX - decided to implement.

Cf. L<Prerequisites>.

=head2 Prerequisites

=over 6

=item EMX

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 RSX runtime, which
has much more functions working (like C<fork>, C<popen> and so on). In
fact RSX is required if there is no VCPI present. Note the
RSX requires DPMI.  Many implementations of DPMI are known to be very
buggy, beware!

Only the latest runtime is supported, currently C<0.9d fix 03>. Perl may run
under earlier versions of EMX, but this is not tested.

One can get different parts of EMX from, say

  http://www.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/
  http://powerusersbbs.com/pub/os2/dev/   [EMX+GCC Development]
  http://hobbes.nmsu.edu/pub/os2/dev/emx/v0.9d/

The runtime component should have the name F<emxrt.zip>.

B<NOTE>. When using F<emx.exe>/F<rsx.exe>, it is enough to have them on your path. One
does not need to specify them explicitly (though this

  emx perl_.exe -de 0

will work as well.)

=item RSX

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">). RSX would not work with VCPI
only, as EMX would, it requires DMPI.

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 RSX from, say

  ftp://ftp.cdrom.com/pub/os2/emx09c/contrib
  ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc
  ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/contrib

Contact the author on C<[e-mail]>.

The latest F<sh.exe> with DOS hooks is available in

  http://www.ilyaz.org/software/os2/

as F<sh_dos.zip> or under similar names starting with C<sh>, C<pdksh> etc.

=item HPFS

Perl does not care about file systems, but the perl library contains
many files with long names, so to install it 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 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 F<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 standard binary (5.2.14 or later) runs
under DOS (with L<RSX>) as well, see

  http://www.ilyaz.org/software/os2/

=back

=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 foo.pl arg1 arg2 arg3

If you want to specify perl options C<-my_opts> to the perl itself (as
opposed to your program), use

	perl -my_opts foo.pl arg1 arg2 arg3

Alternately, if you use OS/2-ish shell, like CMD or 4os2, put
the following at the start of your perl script:

	extproc perl -S -my_opts

rename your program to F<foo.cmd>, and start it by typing

	foo arg1 arg2 arg3

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 the C<PATH>. As a plus
side, if you know a full path to your script, you may still start it
with 

	perl ../../blah/foo.cmd arg1 arg2 arg3

(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>
switch - see L<perlrun>, and cmdref about C<extproc>:

	view perl perlrun
	man perlrun
	view cmdref extproc
	help extproc

or whatever method you prefer.

There are also endless possibilities to use I<executable extensions> of
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">.

Note that B<-S> switch supports scripts with additional extensions 
F<.cmd>, F<.btm>, F<.bat>, F<.pl> as well.

=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>)
are for. (Avoid exec() (see L<perlfunc/exec>) unless you know what you
do).

Note however that to use some of these operators you need to have a
sh-syntax shell installed (see L<"Pdksh">, 
L<"Frequently asked questions">), and perl should be able to find it
(see L<"PERL_SH_DIR">).

The cases when the shell is used are:

=over

=item 1

One-argument system() (see L<perlfunc/system>), exec() (see L<perlfunc/exec>)
with redirection or shell meta-characters;

=item 2

Pipe-open (see L<perlfunc/open>) with the command which contains redirection 
or shell meta-characters;

=item 3

Backticks C<``> (see L<perlop/"I/O Operators">) with the command which contains
redirection or shell meta-characters;

=item 4

If the executable called by system()/exec()/pipe-open()/C<``> is a script
with the "magic" C<#!> line or C<extproc> line which specifies shell;

=item 5

If the executable called by system()/exec()/pipe-open()/C<``> is a script
without "magic" line, and C<$ENV{EXECSHELL}> is set to shell;

=item 6

If the executable called by system()/exec()/pipe-open()/C<``> is not
found (is not this remark obsolete?);

=item 7

For globbing (see L<perlfunc/glob>, L<perlop/"I/O Operators">)
(obsolete? Perl uses builtin globbing nowadays...).

=back

For the sake of speed for a common case, in the above algorithms 
backslashes in the command name are not considered as shell metacharacters.

Perl starts scripts which begin with cookies
C<extproc> or C<#!> directly, without an intervention of shell.  Perl uses the
same algorithm to find the executable as F<pdksh>: if the path
on C<#!> line does not work, and contains C</>, then the directory
part of the executable is ignored, and the executable
is searched in F<.> and on C<PATH>.  To find arguments for these scripts
Perl uses a different algorithm than F<pdksh>: up to 3 arguments are 
recognized, and trailing whitespace is stripped.

If a script
does not contain such a cooky, then to avoid calling F<sh.exe>, Perl uses
the same algorithm as F<pdksh>: if C<$ENV{EXECSHELL}> is set, the
script is given as the first argument to this command, if not set, then
C<$ENV{COMSPEC} /c> is used (or a hardwired guess if C<$ENV{COMSPEC}> is
not set).

When starting scripts directly, Perl uses exactly the same algorithm as for 
the search of script given by B<-S> command-line option: it will look in
the current directory, then on components of C<$ENV{PATH}> using the 
following order of appended extensions: no extension, F<.cmd>, F<.btm>, 
F<.bat>, F<.pl>.

Note that Perl will start to look for scripts only if OS/2 cannot start the