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.
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.
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)
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)
environments. This depends on the features the I<extender> - most
probably RSX - decided to implement.
environments. This depends on the features the I<extender> - most
probably RSX - decided to implement.
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
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
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
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
or in configurable location (see L<"PERL_SH_DIR">).
For best results use EMX pdksh. The standard binary (5.2.14 or later) runs
or in configurable location (see L<"PERL_SH_DIR">).
For best results use EMX pdksh. The standard binary (5.2.14 or later) runs
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),
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),
Note that B<-S> switch supports scripts with additional extensions
F<.cmd>, F<.btm>, F<.bat>, F<.pl> as well.
Note that B<-S> switch supports scripts with additional extensions
F<.cmd>, F<.btm>, F<.bat>, F<.pl> as well.
=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
=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
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
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
The whole idea of the "standard C API to start applications" is that
the forms C<foo> and C<"foo"> of program arguments are completely
The whole idea of the "standard C API to start applications" is that
the forms C<foo> and C<"foo"> of program arguments are completely
B<NOTE>. Because of a typo the binary installer of 5.00305
would install a variable C<PERL_SHPATH> into F<Config.sys>. Please
B<NOTE>. Because of a typo the binary installer of 5.00305
would install a variable C<PERL_SHPATH> into F<Config.sys>. Please
Same remark as above applies. Additionally, if this directory is not
one of directories on @INC (and @INC is influenced by C<PERLLIB_PREFIX>), you
Same remark as above applies. Additionally, if this directory is not
one of directories on @INC (and @INC is influenced by C<PERLLIB_PREFIX>), you
to convert perl utilities to F<.cmd> files and put them on
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
to convert perl utilities to F<.cmd> files and put them on
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
If you use C<man>, either move the installed F<*/man/> directories to
your C<MANPATH>, or modify C<MANPATH> to match the location. (One
If you use C<man>, either move the installed F<*/man/> directories to
your C<MANPATH>, or modify C<MANPATH> to match the location. (One
Fully build and test the Perl distribution. Make sure that no tests are
failing with C<test> and C<aout_test> targets; fix the bugs in Perl and
the Perl test suite detected by these tests. Make sure that C<all_test>
Fully build and test the Perl distribution. Make sure that no tests are
failing with C<test> and C<aout_test> targets; fix the bugs in Perl and
the Perl test suite detected by these tests. Make sure that C<all_test>
files to this new location. Redo the tests to make sure that the versions of
modules inherited from older versions of Perl are not needed.
files to this new location. Redo the tests to make sure that the versions of
modules inherited from older versions of Perl are not needed.
info about which modules are loaded from which place; so you may use it as
an additional verification tool.
info about which modules are loaded from which place; so you may use it as
an additional verification tool.
if (_execname(buf, sizeof(buf) - 13) != 0)
die_with("Can't find full path: ", strerror(errno), "", "");
if (_execname(buf, sizeof(buf) - 13) != 0)
die_with("Can't find full path: ", strerror(errno), "", "");
any function in the DLL, just the act of loading this DLL will reset your
flags. What is worse, the same compiler was used to compile some HOOK DLLs.
Given that HOOK dlls are executed in the context of I<all> the applications
any function in the DLL, just the act of loading this DLL will reset your
flags. What is worse, the same compiler was used to compile some HOOK DLLs.
Given that HOOK dlls are executed in the context of I<all> the applications
flags on systems using such HOOK DLLs. E.g., F<GAMESRVR.DLL> of B<DIVE>
origin changes the floating point flags on each write to the TTY of a VIO
(windowed text-mode) applications.
flags on systems using such HOOK DLLs. E.g., F<GAMESRVR.DLL> of B<DIVE>
origin changes the floating point flags on each write to the TTY of a VIO
(windowed text-mode) applications.
shutdown will be automatically cancelled. Do not call C<perl_hmq_GET(1)>
unless you are going to process messages on an orderly basis.
shutdown will be automatically cancelled. Do not call C<perl_hmq_GET(1)>
unless you are going to process messages on an orderly basis.
There are two principal conventions (it is useful to call them C<Dos*>
and C<Win*> - though this part of the function signature is not always
There are two principal conventions (it is useful to call them C<Dos*>
and C<Win*> - though this part of the function signature is not always
Some DLLs are only present in some versions of OS/2, or in some
configurations of OS/2. Some exported entry points are present only
Some DLLs are only present in some versions of OS/2, or in some
configurations of OS/2. Some exported entry points are present only
-L<perlrun/DESCRIPTION>, L<perlrun/Switches>,
-L<perldiag/"Not a perl script">,
+L<perlrun/DESCRIPTION>, L<perlrun/Command Switches>,
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
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
B<REMARK>. C<LIBPATHSTRICT>, C<BEGINLIBPATH> and C<ENDLIBPATH> are
not environment variables, although F<cmd.exe> emulates them on C<SET
B<REMARK>. C<LIBPATHSTRICT>, C<BEGINLIBPATH> and C<ENDLIBPATH> are
not environment variables, although F<cmd.exe> emulates them on C<SET
-...> lines. From Perl they may be accessed by L<Cwd::extLibpath> and
-L<Cwd::extLibpath_set>.
+...> lines. From Perl they may be accessed by
+L<Cwd::extLibpath|/Cwd::extLibpath([type])> and
+L<Cwd::extLibpath_set|/Cwd::extLibpath_set( path [, type ] )>.
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
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
B<Disadvantages:> currently F<sh.exe> of pdksh calls external programs
via fork()/exec(), and there is I<no> functioning exec() on
B<Disadvantages:> currently F<sh.exe> of pdksh calls external programs
via fork()/exec(), and there is I<no> functioning exec() on