1 |
If you read this file _as_is_, just ignore the funny characters you |
2 |
see. It is written in the POD format (see perlpod manpage) which is |
3 |
specially designed to be readable as is. |
4 |
|
5 |
=head1 NAME |
6 |
|
7 |
perlos2 - Perl under OS/2, DOS, Win0.3*, Win0.95 and WinNT. |
8 |
|
9 |
=head1 SYNOPSIS |
10 |
|
11 |
One can read this document in the following formats: |
12 |
|
13 |
man perlos2 |
14 |
view perl perlos2 |
15 |
explorer perlos2.html |
16 |
info perlos2 |
17 |
|
18 |
to list some (not all may be available simultaneously), or it may |
19 |
be read I<as is>: either as F<README.os2>, or F<pod/perlos2.pod>. |
20 |
|
21 |
To read the F<.INF> version of documentation (B<very> recommended) |
22 |
outside of OS/2, one needs an IBM's reader (may be available on IBM |
23 |
ftp sites (?) (URL anyone?)) or shipped with PC DOS 7.0 and IBM's |
24 |
Visual Age C++ 3.5. |
25 |
|
26 |
A copy of a Win* viewer is contained in the "Just add OS/2 Warp" package |
27 |
|
28 |
ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zip |
29 |
|
30 |
in F<?:\JUST_ADD\view.exe>. This gives one an access to EMX's |
31 |
F<.INF> docs as well (text form is available in F</emx/doc> in |
32 |
EMX's distribution). There is also a different viewer named xview. |
33 |
|
34 |
Note that if you have F<lynx.exe> or F<netscape.exe> installed, you can follow WWW links |
35 |
from this document in F<.INF> format. If you have EMX docs installed |
36 |
correctly, you can follow library links (you need to have C<view emxbook> |
37 |
working by setting C<EMXBOOK> environment variable as it is described |
38 |
in EMX docs). |
39 |
|
40 |
=cut |
41 |
|
42 |
Contents (This may be a little bit obsolete) |
43 |
|
44 |
perlos2 - Perl under OS/2, DOS, Win0.3*, Win0.95 and WinNT. |
45 |
|
46 |
NAME |
47 |
SYNOPSIS |
48 |
DESCRIPTION |
49 |
- Target |
50 |
- Other OSes |
51 |
- Prerequisites |
52 |
- Starting Perl programs under OS/2 (and DOS and...) |
53 |
- Starting OS/2 (and DOS) programs under Perl |
54 |
Frequently asked questions |
55 |
- "It does not work" |
56 |
- I cannot run external programs |
57 |
- I cannot embed perl into my program, or use perl.dll from my |
58 |
- `` and pipe-open do not work under DOS. |
59 |
- Cannot start find.exe "pattern" file |
60 |
INSTALLATION |
61 |
- Automatic binary installation |
62 |
- Manual binary installation |
63 |
- Warning |
64 |
Accessing documentation |
65 |
- OS/2 .INF file |
66 |
- Plain text |
67 |
- Manpages |
68 |
- HTML |
69 |
- GNU info files |
70 |
- PDF files |
71 |
- LaTeX docs |
72 |
BUILD |
73 |
- The short story |
74 |
- Prerequisites |
75 |
- Getting perl source |
76 |
- Application of the patches |
77 |
- Hand-editing |
78 |
- Making |
79 |
- Testing |
80 |
- Installing the built perl |
81 |
- a.out-style build |
82 |
Build FAQ |
83 |
- Some / became \ in pdksh. |
84 |
- 'errno' - unresolved external |
85 |
- Problems with tr or sed |
86 |
- Some problem (forget which ;-) |
87 |
- Library ... not found |
88 |
- Segfault in make |
89 |
- op/sprintf test failure |
90 |
Specific (mis)features of OS/2 port |
91 |
- setpriority, getpriority |
92 |
- system() |
93 |
- extproc on the first line |
94 |
- Additional modules: |
95 |
- Prebuilt methods: |
96 |
- Prebuilt variables: |
97 |
- Misfeatures |
98 |
- Modifications |
99 |
- Identifying DLLs |
100 |
- Centralized management of resources |
101 |
Perl flavors |
102 |
- perl.exe |
103 |
- perl_.exe |
104 |
- perl__.exe |
105 |
- perl___.exe |
106 |
- Why strange names? |
107 |
- Why dynamic linking? |
108 |
- Why chimera build? |
109 |
ENVIRONMENT |
110 |
- PERLLIB_PREFIX |
111 |
- PERL_BADLANG |
112 |
- PERL_BADFREE |
113 |
- PERL_SH_DIR |
114 |
- USE_PERL_FLOCK |
115 |
- TMP or TEMP |
116 |
Evolution |
117 |
- Text-mode filehandles |
118 |
- Priorities |
119 |
- DLL name mangling: pre 5.6.2 |
120 |
- DLL name mangling: 5.6.2 and beyond |
121 |
- DLL forwarder generation |
122 |
- Threading |
123 |
- Calls to external programs |
124 |
- Memory allocation |
125 |
- Threads |
126 |
BUGS |
127 |
AUTHOR |
128 |
SEE ALSO |
129 |
|
130 |
=head1 DESCRIPTION |
131 |
|
132 |
=head2 Target |
133 |
|
134 |
The target is to make OS/2 one of the best supported platform for |
135 |
using/building/developing Perl and I<Perl applications>, as well as |
136 |
make Perl the best language to use under OS/2. The secondary target is |
137 |
to try to make this work under DOS and Win* as well (but not B<too> hard). |
138 |
|
139 |
The current state is quite close to this target. Known limitations: |
140 |
|
141 |
=over 5 |
142 |
|
143 |
=item * |
144 |
|
145 |
Some *nix programs use fork() a lot; with the mostly useful flavors of |
146 |
perl for OS/2 (there are several built simultaneously) this is |
147 |
supported; but some flavors do not support this (e.g., when Perl is |
148 |
called from inside REXX). Using fork() after |
149 |
I<use>ing dynamically loading extensions would not work with I<very> old |
150 |
versions of EMX. |
151 |
|
152 |
=item * |
153 |
|
154 |
You need a separate perl executable F<perl__.exe> (see L</perl__.exe>) |
155 |
if you want to use PM code in your application (as Perl/Tk or OpenGL |
156 |
Perl modules do) without having a text-mode window present. |
157 |
|
158 |
While using the standard F<perl.exe> from a text-mode window is possible |
159 |
too, I have seen cases when this causes degradation of the system stability. |
160 |
Using F<perl__.exe> avoids such a degradation. |
161 |
|
162 |
=item * |
163 |
|
164 |
There is no simple way to access WPS objects. The only way I know |
165 |
is via C<OS2::REXX> and C<SOM> extensions (see L<OS2::REXX>, L<SOM>). |
166 |
However, we do not have access to |
167 |
convenience methods of Object-REXX. (Is it possible at all? I know |
168 |
of no Object-REXX API.) The C<SOM> extension (currently in alpha-text) |
169 |
may eventually remove this shortcoming; however, due to the fact that |
170 |
DII is not supported by the C<SOM> module, using C<SOM> is not as |
171 |
convenient as one would like it. |
172 |
|
173 |
=back |
174 |
|
175 |
Please keep this list up-to-date by informing me about other items. |
176 |
|
177 |
=head2 Other OSes |
178 |
|
179 |
Since OS/2 port of perl uses a remarkable EMX environment, it can |
180 |
run (and build extensions, and - possibly - be built itself) under any |
181 |
environment which can run EMX. The current list is DOS, |
182 |
DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT. Out of many perl flavors, |
183 |
only one works, see L</"F<perl_.exe>">. |
184 |
|
185 |
Note that not all features of Perl are available under these |
186 |
environments. This depends on the features the I<extender> - most |
187 |
probably RSX - decided to implement. |
188 |
|
189 |
Cf. L</Prerequisites>. |
190 |
|
191 |
=head2 Prerequisites |
192 |
|
193 |
=over 6 |
194 |
|
195 |
=item EMX |
196 |
|
197 |
EMX runtime is required (may be substituted by RSX). Note that |
198 |
it is possible to make F<perl_.exe> to run under DOS without any |
199 |
external support by binding F<emx.exe>/F<rsx.exe> to it, see C<emxbind>. Note |
200 |
that under DOS for best results one should use RSX runtime, which |
201 |
has much more functions working (like C<fork>, C<popen> and so on). In |
202 |
fact RSX is required if there is no VCPI present. Note the |
203 |
RSX requires DPMI. Many implementations of DPMI are known to be very |
204 |
buggy, beware! |
205 |
|
206 |
Only the latest runtime is supported, currently C<0.9d fix 03>. Perl may run |
207 |
under earlier versions of EMX, but this is not tested. |
208 |
|
209 |
One can get different parts of EMX from, say |
210 |
|
211 |
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/ |
212 |
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/dev/emx/v0.9d/ |
213 |
|
214 |
The runtime component should have the name F<emxrt.zip>. |
215 |
|
216 |
B<NOTE>. When using F<emx.exe>/F<rsx.exe>, it is enough to have them on your path. One |
217 |
does not need to specify them explicitly (though this |
218 |
|
219 |
emx perl_.exe -de 0 |
220 |
|
221 |
will work as well.) |
222 |
|
223 |
=item RSX |
224 |
|
225 |
To run Perl on DPMI platforms one needs RSX runtime. This is |
226 |
needed under DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT (see |
227 |
L</"Other OSes">). RSX would not work with VCPI |
228 |
only, as EMX would, it requires DMPI. |
229 |
|
230 |
Having RSX and the latest F<sh.exe> one gets a fully functional |
231 |
B<*nix>-ish environment under DOS, say, C<fork>, C<``> and |
232 |
pipe-C<open> work. In fact, MakeMaker works (for static build), so one |
233 |
can have Perl development environment under DOS. |
234 |
|
235 |
One can get RSX from, say |
236 |
|
237 |
http://cd.textfiles.com/hobbesos29804/disk1/EMX09C/ |
238 |
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/contrib/ |
239 |
|
240 |
Contact the author on C<rainer@mathematik.uni-bielefeld.de>. |
241 |
|
242 |
The latest F<sh.exe> with DOS hooks is available in |
243 |
|
244 |
http://www.ilyaz.org/software/os2/ |
245 |
|
246 |
as F<sh_dos.zip> or under similar names starting with C<sh>, C<pdksh> etc. |
247 |
|
248 |
=item HPFS |
249 |
|
250 |
Perl does not care about file systems, but the perl library contains |
251 |
many files with long names, so to install it intact one needs a file |
252 |
system which supports long file names. |
253 |
|
254 |
Note that if you do not plan to build the perl itself, it may be |
255 |
possible to fool EMX to truncate file names. This is not supported, |
256 |
read EMX docs to see how to do it. |
257 |
|
258 |
=item pdksh |
259 |
|
260 |
To start external programs with complicated command lines (like with |
261 |
pipes in between, and/or quoting of arguments), Perl uses an external |
262 |
shell. With EMX port such shell should be named F<sh.exe>, and located |
263 |
either in the wired-in-during-compile locations (usually F<F:/bin>), |
264 |
or in configurable location (see L</"C<PERL_SH_DIR>">). |
265 |
|
266 |
For best results use EMX pdksh. The standard binary (5.2.14 or later) runs |
267 |
under DOS (with L</RSX>) as well, see |
268 |
|
269 |
http://www.ilyaz.org/software/os2/ |
270 |
|
271 |
=back |
272 |
|
273 |
=head2 Starting Perl programs under OS/2 (and DOS and...) |
274 |
|
275 |
Start your Perl program F<foo.pl> with arguments C<arg1 arg2 arg3> the |
276 |
same way as on any other platform, by |
277 |
|
278 |
perl foo.pl arg1 arg2 arg3 |
279 |
|
280 |
If you want to specify perl options C<-my_opts> to the perl itself (as |
281 |
opposed to your program), use |
282 |
|
283 |
perl -my_opts foo.pl arg1 arg2 arg3 |
284 |
|
285 |
Alternately, if you use OS/2-ish shell, like CMD or 4os2, put |
286 |
the following at the start of your perl script: |
287 |
|
288 |
extproc perl -S -my_opts |
289 |
|
290 |
rename your program to F<foo.cmd>, and start it by typing |
291 |
|
292 |
foo arg1 arg2 arg3 |
293 |
|
294 |
Note that because of stupid OS/2 limitations the full path of the perl |
295 |
script is not available when you use C<extproc>, thus you are forced to |
296 |
use C<-S> perl switch, and your script should be on the C<PATH>. As a plus |
297 |
side, if you know a full path to your script, you may still start it |
298 |
with |
299 |
|
300 |
perl ../../blah/foo.cmd arg1 arg2 arg3 |
301 |
|
302 |
(note that the argument C<-my_opts> is taken care of by the C<extproc> line |
303 |
in your script, see L<C<extproc> on the first line>). |
304 |
|
305 |
To understand what the above I<magic> does, read perl docs about C<-S> |
306 |
switch - see L<perlrun>, and cmdref about C<extproc>: |
307 |
|
308 |
view perl perlrun |
309 |
man perlrun |
310 |
view cmdref extproc |
311 |
help extproc |
312 |
|
313 |
or whatever method you prefer. |
314 |
|
315 |
There are also endless possibilities to use I<executable extensions> of |
316 |
4os2, I<associations> of WPS and so on... However, if you use |
317 |
*nixish shell (like F<sh.exe> supplied in the binary distribution), |
318 |
you need to follow the syntax specified in L<perlrun/"Command Switches">. |
319 |
|
320 |
Note that B<-S> switch supports scripts with additional extensions |
321 |
F<.cmd>, F<.btm>, F<.bat>, F<.pl> as well. |
322 |
|
323 |
=head2 Starting OS/2 (and DOS) programs under Perl |
324 |
|
325 |
This is what system() (see L<perlfunc/system>), C<``> (see |
326 |
L<perlop/"I/O Operators">), and I<open pipe> (see L<perlfunc/open>) |
327 |
are for. (Avoid exec() (see L<perlfunc/exec>) unless you know what you |
328 |
do). |
329 |
|
330 |
Note however that to use some of these operators you need to have a |
331 |
sh-syntax shell installed (see L</"Pdksh">, |
332 |
L</"Frequently asked questions">), and perl should be able to find it |
333 |
(see L</"C<PERL_SH_DIR>">). |
334 |
|
335 |
The cases when the shell is used are: |
336 |
|
337 |
=over |
338 |
|
339 |
=item 1 |
340 |
|
341 |
One-argument system() (see L<perlfunc/system>), exec() (see L<perlfunc/exec>) |
342 |
with redirection or shell meta-characters; |
343 |
|
344 |
=item 2 |
345 |
|
346 |
Pipe-open (see L<perlfunc/open>) with the command which contains redirection |
347 |
or shell meta-characters; |
348 |
|
349 |
=item 3 |
350 |
|
351 |
Backticks C<``> (see L<perlop/"I/O Operators">) with the command which contains |
352 |
redirection or shell meta-characters; |
353 |
|
354 |
=item 4 |
355 |
|
356 |
If the executable called by system()/exec()/pipe-open()/C<``> is a script |
357 |
with the "magic" C<#!> line or C<extproc> line which specifies shell; |
358 |
|
359 |
=item 5 |
360 |
|
361 |
If the executable called by system()/exec()/pipe-open()/C<``> is a script |
362 |
without "magic" line, and C<$ENV{EXECSHELL}> is set to shell; |
363 |
|
364 |
=item 6 |
365 |
|
366 |
If the executable called by system()/exec()/pipe-open()/C<``> is not |
367 |
found (is not this remark obsolete?); |
368 |
|
369 |
=item 7 |
370 |
|
371 |
For globbing (see L<perlfunc/glob>, L<perlop/"I/O Operators">) |
372 |
(obsolete? Perl uses builtin globbing nowadays...). |
373 |
|
374 |
=back |
375 |
|
376 |
For the sake of speed for a common case, in the above algorithms |
377 |
backslashes in the command name are not considered as shell metacharacters. |
378 |
|
379 |
Perl starts scripts which begin with cookies |
380 |
C<extproc> or C<#!> directly, without an intervention of shell. Perl uses the |
381 |
same algorithm to find the executable as F<pdksh>: if the path |
382 |
on C<#!> line does not work, and contains C</>, then the directory |
383 |
part of the executable is ignored, and the executable |
384 |
is searched in F<.> and on C<PATH>. To find arguments for these scripts |
385 |
Perl uses a different algorithm than F<pdksh>: up to 3 arguments are |
386 |
recognized, and trailing whitespace is stripped. |
387 |
|
388 |
If a script |
389 |
does not contain such a cooky, then to avoid calling F<sh.exe>, Perl uses |
390 |
the same algorithm as F<pdksh>: if C<$ENV{EXECSHELL}> is set, the |
391 |
script is given as the first argument to this command, if not set, then |
392 |
C<$ENV{COMSPEC} /c> is used (or a hardwired guess if C<$ENV{COMSPEC}> is |
393 |
not set). |
394 |
|
395 |
When starting scripts directly, Perl uses exactly the same algorithm as for |
396 |
the search of script given by B<-S> command-line option: it will look in |
397 |
the current directory, then on components of C<$ENV{PATH}> using the |
398 |
following order of appended extensions: no extension, F<.cmd>, F<.btm>, |
399 |
F<.bat>, F<.pl>. |
400 |
|
401 |
Note that Perl will start to look for scripts only if OS/2 cannot start the |
402 |
specified application, thus C<system 'blah'> will not look for a script if |
403 |
there is an executable file F<blah.exe> I<anywhere> on C<PATH>. In |
404 |
other words, C<PATH> is essentially searched twice: once by the OS for |
405 |
an executable, then by Perl for scripts. |
406 |
|
407 |
Note also that executable files on OS/2 can have an arbitrary extension, but |
408 |
F<.exe> will be automatically appended if no dot is present in the name. The |
409 |
workaround is as simple as that: since F<blah.> and F<blah> denote the same |
410 |
file (at list on FAT and HPFS file systems), to start an executable residing in |
411 |
file F<n:/bin/blah> (no extension) give an argument C<n:/bin/blah.> (dot |
412 |
appended) to system(). |
413 |
|
414 |
Perl will start PM programs from VIO (=text-mode) Perl process in a |
415 |
separate PM session; |
416 |
the opposite is not true: when you start a non-PM program from a PM |
417 |
Perl process, Perl would not run it in a separate session. If a separate |
418 |
session is desired, either ensure |
419 |
that shell will be used, as in C<system 'cmd /c myprog'>, or start it using |
420 |
optional arguments to system() documented in C<OS2::Process> module. This |
421 |
is considered to be a feature. |
422 |
|
423 |
=head1 Frequently asked questions |
424 |
|
425 |
=head2 "It does not work" |
426 |
|
427 |
Perl binary distributions come with a F<testperl.cmd> script which tries |
428 |
to detect common problems with misconfigured installations. There is a |
429 |
pretty large chance it will discover which step of the installation you |
430 |
managed to goof. C<;-)> |
431 |
|
432 |
=head2 I cannot run external programs |
433 |
|
434 |
=over 4 |
435 |
|
436 |
=item * |
437 |
|
438 |
Did you run your programs with C<-w> switch? See |
439 |
L<Starting OSE<sol>2 (and DOS) programs under Perl>. |
440 |
|
441 |
=item * |
442 |
|
443 |
Do you try to run I<internal> shell commands, like C<`copy a b`> |
444 |
(internal for F<cmd.exe>), or C<`glob a*b`> (internal for ksh)? You |
445 |
need to specify your shell explicitly, like C<`cmd /c copy a b`>, |
446 |
since Perl cannot deduce which commands are internal to your shell. |
447 |
|
448 |
=back |
449 |
|
450 |
=head2 I cannot embed perl into my program, or use F<perl.dll> from my |
451 |
program. |
452 |
|
453 |
=over 4 |
454 |
|
455 |
=item Is your program EMX-compiled with C<-Zmt -Zcrtdll>? |
456 |
|
457 |
Well, nowadays Perl DLL should be usable from a differently compiled |
458 |
program too... If you can run Perl code from REXX scripts (see |
459 |
L<OS2::REXX>), then there are some other aspect of interaction which |
460 |
are overlooked by the current hackish code to support |
461 |
differently-compiled principal programs. |
462 |
|
463 |
If everything else fails, you need to build a stand-alone DLL for |
464 |
perl. Contact me, I did it once. Sockets would not work, as a lot of |
465 |
other stuff. |
466 |
|
467 |
=item Did you use L<ExtUtils::Embed>? |
468 |
|
469 |
Some time ago I had reports it does not work. Nowadays it is checked |
470 |
in the Perl test suite, so grep F<./t> subdirectory of the build tree |
471 |
(as well as F<*.t> files in the F<./lib> subdirectory) to find how it |
472 |
should be done "correctly". |
473 |
|
474 |
=back |
475 |
|
476 |
=head2 C<``> and pipe-C<open> do not work under DOS. |
477 |
|
478 |
This may a variant of just L</"I cannot run external programs">, or a |
479 |
deeper problem. Basically: you I<need> RSX (see L</Prerequisites>) |
480 |
for these commands to work, and you may need a port of F<sh.exe> which |
481 |
understands command arguments. One of such ports is listed in |
482 |
L</Prerequisites> under RSX. Do not forget to set variable |
483 |
L</"C<PERL_SH_DIR>"> as well. |
484 |
|
485 |
DPMI is required for RSX. |
486 |
|
487 |
=head2 Cannot start C<find.exe "pattern" file> |
488 |
|
489 |
The whole idea of the "standard C API to start applications" is that |
490 |
the forms C<foo> and C<"foo"> of program arguments are completely |
491 |
interchangeable. F<find> breaks this paradigm; |
492 |
|
493 |
find "pattern" file |
494 |
find pattern file |
495 |
|
496 |
are not equivalent; F<find> cannot be started directly using the above |
497 |
API. One needs a way to surround the doublequotes in some other |
498 |
quoting construction, necessarily having an extra non-Unixish shell in |
499 |
between. |
500 |
|
501 |
Use one of |
502 |
|
503 |
system 'cmd', '/c', 'find "pattern" file'; |
504 |
`cmd /c 'find "pattern" file'` |
505 |
|
506 |
This would start F<find.exe> via F<cmd.exe> via C<sh.exe> via |
507 |
C<perl.exe>, but this is a price to pay if you want to use |
508 |
non-conforming program. |
509 |
|
510 |
=head1 INSTALLATION |
511 |
|
512 |
=head2 Automatic binary installation |
513 |
|
514 |
The most convenient way of installing a binary distribution of perl is via perl installer |
515 |
F<install.exe>. Just follow the instructions, and 99% of the |
516 |
installation blues would go away. |
517 |
|
518 |
Note however, that you need to have F<unzip.exe> on your path, and |
519 |
EMX environment I<running>. The latter means that if you just |
520 |
installed EMX, and made all the needed changes to F<Config.sys>, |
521 |
you may need to reboot in between. Check EMX runtime by running |
522 |
|
523 |
emxrev |
524 |
|
525 |
Binary installer also creates a folder on your desktop with some useful |
526 |
objects. If you need to change some aspects of the work of the binary |
527 |
installer, feel free to edit the file F<Perl.pkg>. This may be useful |
528 |
e.g., if you need to run the installer many times and do not want to |
529 |
make many interactive changes in the GUI. |
530 |
|
531 |
B<Things not taken care of by automatic binary installation:> |
532 |
|
533 |
=over 15 |
534 |
|
535 |
=item C<PERL_BADLANG> |
536 |
|
537 |
may be needed if you change your codepage I<after> perl installation, |
538 |
and the new value is not supported by EMX. See L</"C<PERL_BADLANG>">. |
539 |
|
540 |
=item C<PERL_BADFREE> |
541 |
|
542 |
see L</"C<PERL_BADFREE>">. |
543 |
|
544 |
=item F<Config.pm> |
545 |
|
546 |
This file resides somewhere deep in the location you installed your |
547 |
perl library, find it out by |
548 |
|
549 |
perl -MConfig -le "print $INC{'Config.pm'}" |
550 |
|
551 |
While most important values in this file I<are> updated by the binary |
552 |
installer, some of them may need to be hand-edited. I know no such |
553 |
data, please keep me informed if you find one. Moreover, manual |
554 |
changes to the installed version may need to be accompanied by an edit |
555 |
of this file. |
556 |
|
557 |
=back |
558 |
|
559 |
B<NOTE>. Because of a typo the binary installer of 5.00305 |
560 |
would install a variable C<PERL_SHPATH> into F<Config.sys>. Please |
561 |
remove this variable and put L</C<PERL_SH_DIR>> instead. |
562 |
|
563 |
=head2 Manual binary installation |
564 |
|
565 |
As of version 5.00305, OS/2 perl binary distribution comes split |
566 |
into 11 components. Unfortunately, to enable configurable binary |
567 |
installation, the file paths in the zip files are not absolute, but |
568 |
relative to some directory. |
569 |
|
570 |
Note that the extraction with the stored paths is still necessary |
571 |
(default with unzip, specify C<-d> to pkunzip). However, you |
572 |
need to know where to extract the files. You need also to manually |
573 |
change entries in F<Config.sys> to reflect where did you put the |
574 |
files. Note that if you have some primitive unzipper (like |
575 |
C<pkunzip>), you may get a lot of warnings/errors during |
576 |
unzipping. Upgrade to C<(w)unzip>. |
577 |
|
578 |
Below is the sample of what to do to reproduce the configuration on my |
579 |
machine. In F<VIEW.EXE> you can press C<Ctrl-Insert> now, and |
580 |
cut-and-paste from the resulting file - created in the directory you |
581 |
started F<VIEW.EXE> from. |
582 |
|
583 |
For each component, we mention environment variables related to each |
584 |
installation directory. Either choose directories to match your |
585 |
values of the variables, or create/append-to variables to take into |
586 |
account the directories. |
587 |
|
588 |
=over 3 |
589 |
|
590 |
=item Perl VIO and PM executables (dynamically linked) |
591 |
|
592 |
unzip perl_exc.zip *.exe *.ico -d f:/emx.add/bin |
593 |
unzip perl_exc.zip *.dll -d f:/emx.add/dll |
594 |
|
595 |
(have the directories with C<*.exe> on PATH, and C<*.dll> on |
596 |
LIBPATH); |
597 |
|
598 |
=item Perl_ VIO executable (statically linked) |
599 |
|
600 |
unzip perl_aou.zip -d f:/emx.add/bin |
601 |
|
602 |
(have the directory on PATH); |
603 |
|
604 |
=item Executables for Perl utilities |
605 |
|
606 |
unzip perl_utl.zip -d f:/emx.add/bin |
607 |
|
608 |
(have the directory on PATH); |
609 |
|
610 |
=item Main Perl library |
611 |
|
612 |
unzip perl_mlb.zip -d f:/perllib/lib |
613 |
|
614 |
If this directory is exactly the same as the prefix which was compiled |
615 |
into F<perl.exe>, you do not need to change |
616 |
anything. However, for perl to find the library if you use a different |
617 |
path, you need to |
618 |
C<set PERLLIB_PREFIX> in F<Config.sys>, see L</"C<PERLLIB_PREFIX>">. |
619 |
|
620 |
=item Additional Perl modules |
621 |
|
622 |
unzip perl_ste.zip -d f:/perllib/lib/site_perl/5.26.0/ |
623 |
|
624 |
Same remark as above applies. Additionally, if this directory is not |
625 |
one of directories on @INC (and @INC is influenced by C<PERLLIB_PREFIX>), you |
626 |
need to put this |
627 |
directory and subdirectory F<./os2> in C<PERLLIB> or C<PERL5LIB> |
628 |
variable. Do not use C<PERL5LIB> unless you have it set already. See |
629 |
L<perl/"ENVIRONMENT">. |
630 |
|
631 |
B<[Check whether this extraction directory is still applicable with |
632 |
the new directory structure layout!]> |
633 |
|
634 |
=item Tools to compile Perl modules |
635 |
|
636 |
unzip perl_blb.zip -d f:/perllib/lib |
637 |
|
638 |
Same remark as for F<perl_ste.zip>. |
639 |
|
640 |
=item Manpages for Perl and utilities |
641 |
|
642 |
unzip perl_man.zip -d f:/perllib/man |
643 |
|
644 |
This directory should better be on C<MANPATH>. You need to have a |
645 |
working F<man> to access these files. |
646 |
|
647 |
=item Manpages for Perl modules |
648 |
|
649 |
unzip perl_mam.zip -d f:/perllib/man |
650 |
|
651 |
This directory should better be on C<MANPATH>. You need to have a |
652 |
working man to access these files. |
653 |
|
654 |
=item Source for Perl documentation |
655 |
|
656 |
unzip perl_pod.zip -d f:/perllib/lib |
657 |
|
658 |
This is used by the C<perldoc> program (see L<perldoc>), and may be used to |
659 |
generate HTML documentation usable by WWW browsers, and |
660 |
documentation in zillions of other formats: C<info>, C<LaTeX>, |
661 |
C<Acrobat>, C<FrameMaker> and so on. [Use programs such as |
662 |
F<pod2latex> etc.] |
663 |
|
664 |
=item Perl manual in F<.INF> format |
665 |
|
666 |
unzip perl_inf.zip -d d:/os2/book |
667 |
|
668 |
This directory should better be on C<BOOKSHELF>. |
669 |
|
670 |
=item Pdksh |
671 |
|
672 |
unzip perl_sh.zip -d f:/bin |
673 |
|
674 |
This is used by perl to run external commands which explicitly |
675 |
require shell, like the commands using I<redirection> and I<shell |
676 |
metacharacters>. It is also used instead of explicit F</bin/sh>. |
677 |
|
678 |
Set C<PERL_SH_DIR> (see L</"C<PERL_SH_DIR>">) if you move F<sh.exe> from |
679 |
the above location. |
680 |
|
681 |
B<Note.> It may be possible to use some other sh-compatible shell (untested). |
682 |
|
683 |
=back |
684 |
|
685 |
After you installed the components you needed and updated the |
686 |
F<Config.sys> correspondingly, you need to hand-edit |
687 |
F<Config.pm>. This file resides somewhere deep in the location you |
688 |
installed your perl library, find it out by |
689 |
|
690 |
perl -MConfig -le "print $INC{'Config.pm'}" |
691 |
|
692 |
You need to correct all the entries which look like file paths (they |
693 |
currently start with C<f:/>). |
694 |
|
695 |
=head2 B<Warning> |
696 |
|
697 |
The automatic and manual perl installation leave precompiled paths |
698 |
inside perl executables. While these paths are overwriteable (see |
699 |
L</"C<PERLLIB_PREFIX>">, L</"C<PERL_SH_DIR>">), some people may prefer |
700 |
binary editing of paths inside the executables/DLLs. |
701 |
|
702 |
=head1 Accessing documentation |
703 |
|
704 |
Depending on how you built/installed perl you may have (otherwise |
705 |
identical) Perl documentation in the following formats: |
706 |
|
707 |
=head2 OS/2 F<.INF> file |
708 |
|
709 |
Most probably the most convenient form. Under OS/2 view it as |
710 |
|
711 |
view perl |
712 |
view perl perlfunc |
713 |
view perl less |
714 |
view perl ExtUtils::MakeMaker |
715 |
|
716 |
(currently the last two may hit a wrong location, but this may improve |
717 |
soon). Under Win* see L</"SYNOPSIS">. |
718 |
|
719 |
If you want to build the docs yourself, and have I<OS/2 toolkit>, run |
720 |
|
721 |
pod2ipf > perl.ipf |
722 |
|
723 |
in F</perllib/lib/pod> directory, then |
724 |
|
725 |
ipfc /inf perl.ipf |
726 |
|
727 |
(Expect a lot of errors during the both steps.) Now move it on your |
728 |
BOOKSHELF path. |
729 |
|
730 |
=head2 Plain text |
731 |
|
732 |
If you have perl documentation in the source form, perl utilities |
733 |
installed, and GNU groff installed, you may use |
734 |
|
735 |
perldoc perlfunc |
736 |
perldoc less |
737 |
perldoc ExtUtils::MakeMaker |
738 |
|
739 |
to access the perl documentation in the text form (note that you may get |
740 |
better results using perl manpages). |
741 |
|
742 |
Alternately, try running pod2text on F<.pod> files. |
743 |
|
744 |
=head2 Manpages |
745 |
|
746 |
If you have F<man> installed on your system, and you installed perl |
747 |
manpages, use something like this: |
748 |
|
749 |
man perlfunc |
750 |
man 3 less |
751 |
man ExtUtils.MakeMaker |
752 |
|
753 |
to access documentation for different components of Perl. Start with |
754 |
|
755 |
man perl |
756 |
|
757 |
Note that dot (F<.>) is used as a package separator for documentation |
758 |
for packages, and as usual, sometimes you need to give the section - C<3> |
759 |
above - to avoid shadowing by the I<less(1) manpage>. |
760 |
|
761 |
Make sure that the directory B<above> the directory with manpages is |
762 |
on our C<MANPATH>, like this |
763 |
|
764 |
set MANPATH=c:/man;f:/perllib/man |
765 |
|
766 |
for Perl manpages in C<f:/perllib/man/man1/> etc. |
767 |
|
768 |
=head2 HTML |
769 |
|
770 |
If you have some WWW browser available, installed the Perl |
771 |
documentation in the source form, and Perl utilities, you can build |
772 |
HTML docs. Cd to directory with F<.pod> files, and do like this |
773 |
|
774 |
cd f:/perllib/lib/pod |
775 |
pod2html |
776 |
|
777 |
After this you can direct your browser the file F<perl.html> in this |
778 |
directory, and go ahead with reading docs, like this: |
779 |
|
780 |
explore file:///f:/perllib/lib/pod/perl.html |
781 |
|
782 |
Alternatively you may be able to get these docs prebuilt from CPAN. |
783 |
|
784 |
=head2 GNU C<info> files |
785 |
|
786 |
Users of Emacs would appreciate it very much, especially with |
787 |
C<CPerl> mode loaded. You need to get latest C<pod2texi> from C<CPAN>, |
788 |
or, alternately, the prebuilt info pages. |
789 |
|
790 |
=head2 F<PDF> files |
791 |
|
792 |
for C<Acrobat> are available on CPAN (may be for slightly older version of |
793 |
perl). |
794 |
|
795 |
=head2 C<LaTeX> docs |
796 |
|
797 |
can be constructed using C<pod2latex>. |
798 |
|
799 |
=head1 BUILD |
800 |
|
801 |
Here we discuss how to build Perl under OS/2. |
802 |
|
803 |
=head2 The short story |
804 |
|
805 |
Assume that you are a seasoned porter, so are sure that all the necessary |
806 |
tools are already present on your system, and you know how to get the Perl |
807 |
source distribution. Untar it, change to the extract directory, and |
808 |
|
809 |
gnupatch -p0 < os2\diff.configure |
810 |
sh Configure -des -D prefix=f:/perllib |
811 |
make |
812 |
make test |
813 |
make install |
814 |
make aout_test |
815 |
make aout_install |
816 |
|
817 |
This puts the executables in f:/perllib/bin. Manually move them to the |
818 |
C<PATH>, manually move the built F<perl*.dll> to C<LIBPATH> (here for |
819 |
Perl DLL F<*> is a not-very-meaningful hex checksum), and run |
820 |
|
821 |
make installcmd INSTALLCMDDIR=d:/ir/on/path |
822 |
|
823 |
Assuming that the C<man>-files were put on an appropriate location, |
824 |
this completes the installation of minimal Perl system. (The binary |
825 |
distribution contains also a lot of additional modules, and the |
826 |
documentation in INF format.) |
827 |
|
828 |
What follows is a detailed guide through these steps. |
829 |
|
830 |
=head2 Prerequisites |
831 |
|
832 |
You need to have the latest EMX development environment, the full |
833 |
GNU tool suite (gawk renamed to awk, and GNU F<find.exe> |
834 |
earlier on path than the OS/2 F<find.exe>, same with F<sort.exe>, to |
835 |
check use |
836 |
|
837 |
find --version |
838 |
sort --version |
839 |
|
840 |
). You need the latest version of F<pdksh> installed as F<sh.exe>. |
841 |
|
842 |
Check that you have B<BSD> libraries and headers installed, and - |
843 |
optionally - Berkeley DB headers and libraries, and crypt. |
844 |
|
845 |
Possible locations to get the files: |
846 |
|
847 |
|
848 |
ftp://ftp.uni-heidelberg.de/pub/os2/unix/ |
849 |
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2 |
850 |
http://cd.textfiles.com/hobbesos29804/disk1/DEV32/ |
851 |
http://cd.textfiles.com/hobbesos29804/disk1/EMX09C/ |
852 |
|
853 |
It is reported that the following archives contain enough utils to |
854 |
build perl: F<gnufutil.zip>, F<gnusutil.zip>, F<gnututil.zip>, F<gnused.zip>, |
855 |
F<gnupatch.zip>, F<gnuawk.zip>, F<gnumake.zip>, F<gnugrep.zip>, F<bsddev.zip> and |
856 |
F<ksh527rt.zip> (or a later version). Note that all these utilities are |
857 |
known to be available from LEO: |
858 |
|
859 |
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/ |
860 |
|
861 |
Note also that the F<db.lib> and F<db.a> from the EMX distribution |
862 |
are not suitable for multi-threaded compile (even single-threaded |
863 |
flavor of Perl uses multi-threaded C RTL, for |
864 |
compatibility with XFree86-OS/2). Get a corrected one from |
865 |
|
866 |
http://www.ilyaz.org/software/os2/db_mt.zip |
867 |
|
868 |
If you have I<exactly the same version of Perl> installed already, |
869 |
make sure that no copies or perl are currently running. Later steps |
870 |
of the build may fail since an older version of F<perl.dll> loaded into |
871 |
memory may be found. Running C<make test> becomes meaningless, since |
872 |
the test are checking a previous build of perl (this situation is detected |
873 |
and reported by F<os2/os2_base.t> test). Do not forget to unset |
874 |
C<PERL_EMXLOAD_SEC> in environment. |
875 |
|
876 |
Also make sure that you have F</tmp> directory on the current drive, |
877 |
and F<.> directory in your C<LIBPATH>. One may try to correct the |
878 |
latter condition by |
879 |
|
880 |
set BEGINLIBPATH .\. |
881 |
|
882 |
if you use something like F<CMD.EXE> or latest versions of |
883 |
F<4os2.exe>. (Setting BEGINLIBPATH to just C<.> is ignored by the |
884 |
OS/2 kernel.) |
885 |
|
886 |
Make sure your gcc is good for C<-Zomf> linking: run C<omflibs> |
887 |
script in F</emx/lib> directory. |
888 |
|
889 |
Check that you have link386 installed. It comes standard with OS/2, |
890 |
but may be not installed due to customization. If typing |
891 |
|
892 |
link386 |
893 |
|
894 |
shows you do not have it, do I<Selective install>, and choose C<Link |
895 |
object modules> in I<Optional system utilities/More>. If you get into |
896 |
link386 prompts, press C<Ctrl-C> to exit. |
897 |
|
898 |
=head2 Getting perl source |
899 |
|
900 |
You need to fetch the latest perl source (including developers |
901 |
releases). With some probability it is located in |
902 |
|
903 |
http://www.cpan.org/src/ |
904 |
http://www.cpan.org/src/unsupported |
905 |
|
906 |
If not, you may need to dig in the indices to find it in the directory |
907 |
of the current maintainer. |
908 |
|
909 |
Quick cycle of developers release may break the OS/2 build time to |
910 |
time, looking into |
911 |
|
912 |
http://www.cpan.org/ports/os2/ |
913 |
|
914 |
may indicate the latest release which was publicly released by the |
915 |
maintainer. Note that the release may include some additional patches |
916 |
to apply to the current source of perl. |
917 |
|
918 |
Extract it like this |
919 |
|
920 |
tar vzxf perl5.00409.tar.gz |
921 |
|
922 |
You may see a message about errors while extracting F<Configure>. This is |
923 |
because there is a conflict with a similarly-named file F<configure>. |
924 |
|
925 |
Change to the directory of extraction. |
926 |
|
927 |
=head2 Application of the patches |
928 |
|
929 |
You need to apply the patches in F<./os2/diff.*> like this: |
930 |
|
931 |
gnupatch -p0 < os2\diff.configure |
932 |
|
933 |
You may also need to apply the patches supplied with the binary |
934 |
distribution of perl. It also makes sense to look on the |
935 |
perl5-porters mailing list for the latest OS/2-related patches (see |
936 |
L<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/>). Such |
937 |
patches usually contain strings C</os2/> and C<patch>, so it makes |
938 |
sense looking for these strings. |
939 |
|
940 |
=head2 Hand-editing |
941 |
|
942 |
You may look into the file F<./hints/os2.sh> and correct anything |
943 |
wrong you find there. I do not expect it is needed anywhere. |
944 |
|
945 |
=head2 Making |
946 |
|
947 |
sh Configure -des -D prefix=f:/perllib |
948 |
|
949 |
C<prefix> means: where to install the resulting perl library. Giving |
950 |
correct prefix you may avoid the need to specify C<PERLLIB_PREFIX>, |
951 |
see L</"C<PERLLIB_PREFIX>">. |
952 |
|
953 |
I<Ignore the message about missing C<ln>, and about C<-c> option to |
954 |
tr>. The latter is most probably already fixed, if you see it and can trace |
955 |
where the latter spurious warning comes from, please inform me. |
956 |
|
957 |
Now |
958 |
|
959 |
make |
960 |
|
961 |
At some moment the built may die, reporting a I<version mismatch> or |
962 |
I<unable to run F<perl>>. This means that you do not have F<.> in |
963 |
your LIBPATH, so F<perl.exe> cannot find the needed F<perl67B2.dll> (treat |
964 |
these hex digits as line noise). After this is fixed the build |
965 |
should finish without a lot of fuss. |
966 |
|
967 |
=head2 Testing |
968 |
|
969 |
Now run |
970 |
|
971 |
make test |
972 |
|
973 |
All tests should succeed (with some of them skipped). If you have the |
974 |
same version of Perl installed, it is crucial that you have C<.> early |
975 |
in your LIBPATH (or in BEGINLIBPATH), otherwise your tests will most |
976 |
probably test the wrong version of Perl. |
977 |
|
978 |
Some tests may generate extra messages similar to |
979 |
|
980 |
=over 4 |
981 |
|
982 |
=item A lot of C<bad free> |
983 |
|
984 |
in database tests related to Berkeley DB. I<This should be fixed already.> |
985 |
If it persists, you may disable this warnings, see L</"C<PERL_BADFREE>">. |
986 |
|
987 |
=item Process terminated by SIGTERM/SIGINT |
988 |
|
989 |
This is a standard message issued by OS/2 applications. *nix |
990 |
applications die in silence. It is considered to be a feature. One can |
991 |
easily disable this by appropriate sighandlers. |
992 |
|
993 |
However the test engine bleeds these message to screen in unexpected |
994 |
moments. Two messages of this kind I<should> be present during |
995 |
testing. |
996 |
|
997 |
=back |
998 |
|
999 |
To get finer test reports, call |
1000 |
|
1001 |
perl t/harness |
1002 |
|
1003 |
The report with F<io/pipe.t> failing may look like this: |
1004 |
|
1005 |
Failed Test Status Wstat Total Fail Failed List of failed |
1006 |
------------------------------------------------------------ |
1007 |
io/pipe.t 12 1 8.33% 9 |
1008 |
7 tests skipped, plus 56 subtests skipped. |
1009 |
Failed 1/195 test scripts, 99.49% okay. 1/6542 subtests failed, |
1010 |
99.98% okay. |
1011 |
|
1012 |
The reasons for most important skipped tests are: |
1013 |
|
1014 |
=over 8 |
1015 |
|
1016 |
=item F<op/fs.t> |
1017 |
|
1018 |
=over 4 |
1019 |
|
1020 |
=item Z<>18 |
1021 |
|
1022 |
Checks C<atime> and C<mtime> of C<stat()> - unfortunately, HPFS |
1023 |
provides only 2sec time granularity (for compatibility with FAT?). |
1024 |
|
1025 |
=item Z<>25 |
1026 |
|
1027 |
Checks C<truncate()> on a filehandle just opened for write - I do not |
1028 |
know why this should or should not work. |
1029 |
|
1030 |
=back |
1031 |
|
1032 |
=item F<op/stat.t> |
1033 |
|
1034 |
Checks C<stat()>. Tests: |
1035 |
|
1036 |
=over 4 |
1037 |
|
1038 |
=item 4 |
1039 |
|
1040 |
Checks C<atime> and C<mtime> of C<stat()> - unfortunately, HPFS |
1041 |
provides only 2sec time granularity (for compatibility with FAT?). |
1042 |
|
1043 |
=back |
1044 |
|
1045 |
=back |
1046 |
|
1047 |
=head2 Installing the built perl |
1048 |
|
1049 |
If you haven't yet moved C<perl*.dll> onto LIBPATH, do it now. |
1050 |
|
1051 |
Run |
1052 |
|
1053 |
make install |
1054 |
|
1055 |
It would put the generated files into needed locations. Manually put |
1056 |
F<perl.exe>, F<perl__.exe> and F<perl___.exe> to a location on your |
1057 |
PATH, F<perl.dll> to a location on your LIBPATH. |
1058 |
|
1059 |
Run |
1060 |
|
1061 |
make installcmd INSTALLCMDDIR=d:/ir/on/path |
1062 |
|
1063 |
to convert perl utilities to F<.cmd> files and put them on |
1064 |
PATH. You need to put F<.EXE>-utilities on path manually. They are |
1065 |
installed in C<$prefix/bin>, here C<$prefix> is what you gave to |
1066 |
F<Configure>, see L</Making>. |
1067 |
|
1068 |
If you use C<man>, either move the installed F<*/man/> directories to |
1069 |
your C<MANPATH>, or modify C<MANPATH> to match the location. (One |
1070 |
could have avoided this by providing a correct C<manpath> option to |
1071 |
F<./Configure>, or editing F<./config.sh> between configuring and |
1072 |
making steps.) |
1073 |
|
1074 |
=head2 C<a.out>-style build |
1075 |
|
1076 |
Proceed as above, but make F<perl_.exe> (see L</"F<perl_.exe>">) by |
1077 |
|
1078 |
make perl_ |
1079 |
|
1080 |
test and install by |
1081 |
|
1082 |
make aout_test |
1083 |
make aout_install |
1084 |
|
1085 |
Manually put F<perl_.exe> to a location on your PATH. |
1086 |
|
1087 |
B<Note.> The build process for C<perl_> I<does not know> about all the |
1088 |
dependencies, so you should make sure that anything is up-to-date, |
1089 |
say, by doing |
1090 |
|
1091 |
make perl_dll |
1092 |
|
1093 |
first. |
1094 |
|
1095 |
=head1 Building a binary distribution |
1096 |
|
1097 |
[This section provides a short overview only...] |
1098 |
|
1099 |
Building should proceed differently depending on whether the version of perl |
1100 |
you install is already present and used on your system, or is a new version |
1101 |
not yet used. The description below assumes that the version is new, so |
1102 |
installing its DLLs and F<.pm> files will not disrupt the operation of your |
1103 |
system even if some intermediate steps are not yet fully working. |
1104 |
|
1105 |
The other cases require a little bit more convoluted procedures. Below I |
1106 |
suppose that the current version of Perl is C<5.8.2>, so the executables are |
1107 |
named accordingly. |
1108 |
|
1109 |
=over |
1110 |
|
1111 |
=item 1. |
1112 |
|
1113 |
Fully build and test the Perl distribution. Make sure that no tests are |
1114 |
failing with C<test> and C<aout_test> targets; fix the bugs in Perl and |
1115 |
the Perl test suite detected by these tests. Make sure that C<all_test> |
1116 |
make target runs as clean as possible. Check that F<os2/perlrexx.cmd> |
1117 |
runs fine. |
1118 |
|
1119 |
=item 2. |
1120 |
|
1121 |
Fully install Perl, including C<installcmd> target. Copy the generated DLLs |
1122 |
to C<LIBPATH>; copy the numbered Perl executables (as in F<perl5.8.2.exe>) |
1123 |
to C<PATH>; copy C<perl_.exe> to C<PATH> as C<perl_5.8.2.exe>. Think whether |
1124 |
you need backward-compatibility DLLs. In most cases you do not need to install |
1125 |
them yet; but sometime this may simplify the following steps. |
1126 |
|
1127 |
=item 3. |
1128 |
|
1129 |
Make sure that C<CPAN.pm> can download files from CPAN. If not, you may need |
1130 |
to manually install C<Net::FTP>. |
1131 |
|
1132 |
=item 4. |
1133 |
|
1134 |
Install the bundle C<Bundle::OS2_default> |
1135 |
|
1136 |
perl5.8.2 -MCPAN -e "install Bundle::OS2_default" < nul |& tee 00cpan_i_1 |
1137 |
|
1138 |
This may take a couple of hours on 1GHz processor (when run the first time). |
1139 |
And this should not be necessarily a smooth procedure. Some modules may not |
1140 |
specify required dependencies, so one may need to repeat this procedure several |
1141 |
times until the results stabilize. |
1142 |
|
1143 |
perl5.8.2 -MCPAN -e "install Bundle::OS2_default" < nul |& tee 00cpan_i_2 |
1144 |
perl5.8.2 -MCPAN -e "install Bundle::OS2_default" < nul |& tee 00cpan_i_3 |
1145 |
|
1146 |
Even after they stabilize, some tests may fail. |
1147 |
|
1148 |
Fix as many discovered bugs as possible. Document all the bugs which are not |
1149 |
fixed, and all the failures with unknown reasons. Inspect the produced logs |
1150 |
F<00cpan_i_1> to find suspiciously skipped tests, and other fishy events. |
1151 |
|
1152 |
Keep in mind that I<installation> of some modules may fail too: for example, |
1153 |
the DLLs to update may be already loaded by F<CPAN.pm>. Inspect the C<install> |
1154 |
logs (in the example above F<00cpan_i_1> etc) for errors, and install things |
1155 |
manually, as in |
1156 |
|
1157 |
cd $CPANHOME/.cpan/build/Digest-MD5-2.31 |
1158 |
make install |
1159 |
|
1160 |
Some distributions may fail some tests, but you may want to install them |
1161 |
anyway (as above, or via C<force install> command of C<CPAN.pm> shell-mode). |
1162 |
|
1163 |
Since this procedure may take quite a long time to complete, it makes sense |
1164 |
to "freeze" your CPAN configuration by disabling periodic updates of the |
1165 |
local copy of CPAN index: set C<index_expire> to some big value (I use 365), |
1166 |
then save the settings |
1167 |
|
1168 |
CPAN> o conf index_expire 365 |
1169 |
CPAN> o conf commit |
1170 |
|
1171 |
Reset back to the default value C<1> when you are finished. |
1172 |
|
1173 |
=item 5. |
1174 |
|
1175 |
When satisfied with the results, rerun the C<installcmd> target. Now you |
1176 |
can copy C<perl5.8.2.exe> to C<perl.exe>, and install the other OMF-build |
1177 |
executables: C<perl__.exe> etc. They are ready to be used. |
1178 |
|
1179 |
=item 6. |
1180 |
|
1181 |
Change to the C<./pod> directory of the build tree, download the Perl logo |
1182 |
F<CamelGrayBig.BMP>, and run |
1183 |
|
1184 |
( perl2ipf > perl.ipf ) |& tee 00ipf |
1185 |
ipfc /INF perl.ipf |& tee 00inf |
1186 |
|
1187 |
This produces the Perl docs online book C<perl.INF>. Install in on |
1188 |
C<BOOKSHELF> path. |
1189 |
|
1190 |
=item 7. |
1191 |
|
1192 |
Now is the time to build statically linked executable F<perl_.exe> which |
1193 |
includes newly-installed via C<Bundle::OS2_default> modules. Doing testing |
1194 |
via C<CPAN.pm> is going to be painfully slow, since it statically links |
1195 |
a new executable per XS extension. |
1196 |
|
1197 |
Here is a possible workaround: create a toplevel F<Makefile.PL> in |
1198 |
F<$CPANHOME/.cpan/build/> with contents being (compare with L</Making |
1199 |
executables with a custom collection of statically loaded extensions>) |
1200 |
|
1201 |
use ExtUtils::MakeMaker; |
1202 |
WriteMakefile NAME => 'dummy'; |
1203 |
|
1204 |
execute this as |
1205 |
|
1206 |
perl_5.8.2.exe Makefile.PL <nul |& tee 00aout_c1 |
1207 |
make -k all test <nul |& 00aout_t1 |
1208 |
|
1209 |
Again, this procedure should not be absolutely smooth. Some C<Makefile.PL>'s |
1210 |
in subdirectories may be buggy, and would not run as "child" scripts. The |
1211 |
interdependency of modules can strike you; however, since non-XS modules |
1212 |
are already installed, the prerequisites of most modules have a very good |
1213 |
chance to be present. |
1214 |
|
1215 |
If you discover some glitches, move directories of problematic modules to a |
1216 |
different location; if these modules are non-XS modules, you may just ignore |
1217 |
them - they are already installed; the remaining, XS, modules you need to |
1218 |
install manually one by one. |
1219 |
|
1220 |
After each such removal you need to rerun the C<Makefile.PL>/C<make> process; |
1221 |
usually this procedure converges soon. (But be sure to convert all the |
1222 |
necessary external C libraries from F<.lib> format to F<.a> format: run one of |
1223 |
|
1224 |
emxaout foo.lib |
1225 |
emximp -o foo.a foo.lib |
1226 |
|
1227 |
whichever is appropriate.) Also, make sure that the DLLs for external |
1228 |
libraries are usable with with executables compiled without C<-Zmtd> options. |
1229 |
|
1230 |
When you are sure that only a few subdirectories |
1231 |
lead to failures, you may want to add C<-j4> option to C<make> to speed up |
1232 |
skipping subdirectories with already finished build. |
1233 |
|
1234 |
When you are satisfied with the results of tests, install the build C libraries |
1235 |
for extensions: |
1236 |
|
1237 |
make install |& tee 00aout_i |
1238 |
|
1239 |
Now you can rename the file F<./perl.exe> generated during the last phase |
1240 |
to F<perl_5.8.2.exe>; place it on C<PATH>; if there is an inter-dependency |
1241 |
between some XS modules, you may need to repeat the C<test>/C<install> loop |
1242 |
with this new executable and some excluded modules - until the procedure |
1243 |
converges. |
1244 |
|
1245 |
Now you have all the necessary F<.a> libraries for these Perl modules in the |
1246 |
places where Perl builder can find it. Use the perl builder: change to an |
1247 |
empty directory, create a "dummy" F<Makefile.PL> again, and run |
1248 |
|
1249 |
perl_5.8.2.exe Makefile.PL |& tee 00c |
1250 |
make perl |& tee 00p |
1251 |
|
1252 |
This should create an executable F<./perl.exe> with all the statically loaded |
1253 |
extensions built in. Compare the generated F<perlmain.c> files to make sure |
1254 |
that during the iterations the number of loaded extensions only increases. |
1255 |
Rename F<./perl.exe> to F<perl_5.8.2.exe> on C<PATH>. |
1256 |
|
1257 |
When it converges, you got a functional variant of F<perl_5.8.2.exe>; copy it |
1258 |
to C<perl_.exe>. You are done with generation of the local Perl installation. |
1259 |
|
1260 |
=item 8. |
1261 |
|
1262 |
Make sure that the installed modules are actually installed in the location |
1263 |
of the new Perl, and are not inherited from entries of @INC given for |
1264 |
inheritance from the older versions of Perl: set C<PERLLIB_582_PREFIX> to |
1265 |
redirect the new version of Perl to a new location, and copy the installed |
1266 |
files to this new location. Redo the tests to make sure that the versions of |
1267 |
modules inherited from older versions of Perl are not needed. |
1268 |
|
1269 |
Actually, the log output of L<pod2ipf(1)> during the step 6 gives a very detailed |
1270 |
info about which modules are loaded from which place; so you may use it as |
1271 |
an additional verification tool. |
1272 |
|
1273 |
Check that some temporary files did not make into the perl install tree. |
1274 |
Run something like this |
1275 |
|
1276 |
pfind . -f "!(/\.(pm|pl|ix|al|h|a|lib|txt|pod|imp|bs|dll|ld|bs|inc|xbm|yml|cgi|uu|e2x|skip|packlist|eg|cfg|html|pub|enc|all|ini|po|pot)$/i or /^\w+$/") | less |
1277 |
|
1278 |
in the install tree (both top one and F<sitelib> one). |
1279 |
|
1280 |
Compress all the DLLs with F<lxlite>. The tiny F<.exe> can be compressed with |
1281 |
C</c:max> (the bug only appears when there is a fixup in the last 6 bytes of a |
1282 |
page (?); since the tiny executables are much smaller than a page, the bug |
1283 |
will not hit). Do not compress C<perl_.exe> - it would not work under DOS. |
1284 |
|
1285 |
=item 9. |
1286 |
|
1287 |
Now you can generate the binary distribution. This is done by running the |
1288 |
test of the CPAN distribution C<OS2::SoftInstaller>. Tune up the file |
1289 |
F<test.pl> to suit the layout of current version of Perl first. Do not |
1290 |
forget to pack the necessary external DLLs accordingly. Include the |
1291 |
description of the bugs and test suite failures you could not fix. Include |
1292 |
the small-stack versions of Perl executables from Perl build directory. |
1293 |
|
1294 |
Include F<perl5.def> so that people can relink the perl DLL preserving |
1295 |
the binary compatibility, or can create compatibility DLLs. Include the diff |
1296 |
files (C<diff -pu old new>) of fixes you did so that people can rebuild your |
1297 |
version. Include F<perl5.map> so that one can use remote debugging. |
1298 |
|
1299 |
=item 10. |
1300 |
|
1301 |
Share what you did with the other people. Relax. Enjoy fruits of your work. |
1302 |
|
1303 |
=item 11. |
1304 |
|
1305 |
Brace yourself for thanks, bug reports, hate mail and spam coming as result |
1306 |
of the previous step. No good deed should remain unpunished! |
1307 |
|
1308 |
=back |
1309 |
|
1310 |
=head1 Building custom F<.EXE> files |
1311 |
|
1312 |
The Perl executables can be easily rebuilt at any moment. Moreover, one can |
1313 |
use the I<embedding> interface (see L<perlembed>) to make very customized |
1314 |
executables. |
1315 |
|
1316 |
=head2 Making executables with a custom collection of statically loaded extensions |
1317 |
|
1318 |
It is a little bit easier to do so while I<decreasing> the list of statically |
1319 |
loaded extensions. We discuss this case only here. |
1320 |
|
1321 |
=over |
1322 |
|
1323 |
=item 1. |
1324 |
|
1325 |
Change to an empty directory, and create a placeholder <Makefile.PL>: |
1326 |
|
1327 |
use ExtUtils::MakeMaker; |
1328 |
WriteMakefile NAME => 'dummy'; |
1329 |
|
1330 |
=item 2. |
1331 |
|
1332 |
Run it with the flavor of Perl (F<perl.exe> or F<perl_.exe>) you want to |
1333 |
rebuild. |
1334 |
|
1335 |
perl_ Makefile.PL |
1336 |
|
1337 |
=item 3. |
1338 |
|
1339 |
Ask it to create new Perl executable: |
1340 |
|
1341 |
make perl |
1342 |
|
1343 |
(you may need to manually add C<PERLTYPE=-DPERL_CORE> to this commandline on |
1344 |
some versions of Perl; the symptom is that the command-line globbing does not |
1345 |
work from OS/2 shells with the newly-compiled executable; check with |
1346 |
|
1347 |
.\perl.exe -wle "print for @ARGV" * |
1348 |
|
1349 |
). |
1350 |
|
1351 |
=item 4. |
1352 |
|
1353 |
The previous step created F<perlmain.c> which contains a list of newXS() calls |
1354 |
near the end. Removing unnecessary calls, and rerunning |
1355 |
|
1356 |
make perl |
1357 |
|
1358 |
will produce a customized executable. |
1359 |
|
1360 |
=back |
1361 |
|
1362 |
=head2 Making executables with a custom search-paths |
1363 |
|
1364 |
The default perl executable is flexible enough to support most usages. |
1365 |
However, one may want something yet more flexible; for example, one may want |
1366 |
to find Perl DLL relatively to the location of the EXE file; or one may want |
1367 |
to ignore the environment when setting the Perl-library search patch, etc. |
1368 |
|
1369 |
If you fill comfortable with I<embedding> interface (see L<perlembed>), such |
1370 |
things are easy to do repeating the steps outlined in L/<Making |
1371 |
executables with a custom collection of statically loaded extensions>, and |
1372 |
doing more comprehensive edits to main() of F<perlmain.c>. The people with |
1373 |
little desire to understand Perl can just rename main(), and do necessary |
1374 |
modification in a custom main() which calls the renamed function in appropriate |
1375 |
time. |
1376 |
|
1377 |
However, there is a third way: perl DLL exports the main() function and several |
1378 |
callbacks to customize the search path. Below is a complete example of a |
1379 |
"Perl loader" which |
1380 |
|
1381 |
=over |
1382 |
|
1383 |
=item 1. |
1384 |
|
1385 |
Looks for Perl DLL in the directory C<$exedir/../dll>; |
1386 |
|
1387 |
=item 2. |
1388 |
|
1389 |
Prepends the above directory to C<BEGINLIBPATH>; |
1390 |
|
1391 |
=item 3. |
1392 |
|
1393 |
Fails if the Perl DLL found via C<BEGINLIBPATH> is different from what was |
1394 |
loaded on step 1; e.g., another process could have loaded it from C<LIBPATH> |
1395 |
or from a different value of C<BEGINLIBPATH>. In these cases one needs to |
1396 |
modify the setting of the system so that this other process either does not |
1397 |
run, or loads the DLL from C<BEGINLIBPATH> with C<LIBPATHSTRICT=T> (available |
1398 |
with kernels after September 2000). |
1399 |
|
1400 |
=item 4. |
1401 |
|
1402 |
Loads Perl library from C<$exedir/../dll/lib/>. |
1403 |
|
1404 |
=item 5. |
1405 |
|
1406 |
Uses Bourne shell from C<$exedir/../dll/sh/ksh.exe>. |
1407 |
|
1408 |
=back |
1409 |
|
1410 |
For best results compile the C file below with the same options as the Perl |
1411 |
DLL. However, a lot of functionality will work even if the executable is not |
1412 |
an EMX applications, e.g., if compiled with |
1413 |
|
1414 |
gcc -Wall -DDOSISH -DOS2=1 -O2 -s -Zomf -Zsys perl-starter.c \ |
1415 |
-DPERL_DLL_BASENAME=\"perl312F\" -Zstack 8192 -Zlinker /PM:VIO |
1416 |
|
1417 |
Here is the sample C file: |
1418 |
|
1419 |
#define INCL_DOS |
1420 |
#define INCL_NOPM |
1421 |
/* These are needed for compile if os2.h includes os2tk.h, not |
1422 |
* os2emx.h */ |
1423 |
#define INCL_DOSPROCESS |
1424 |
#include <os2.h> |
1425 |
|
1426 |
#include "EXTERN.h" |
1427 |
#define PERL_IN_MINIPERLMAIN_C |
1428 |
#include "perl.h" |
1429 |
|
1430 |
static char *me; |
1431 |
HMODULE handle; |
1432 |
|
1433 |
static void |
1434 |
die_with(char *msg1, char *msg2, char *msg3, char *msg4) |
1435 |
{ |
1436 |
ULONG c; |
1437 |
char *s = " error: "; |
1438 |
|
1439 |
DosWrite(2, me, strlen(me), &c); |
1440 |
DosWrite(2, s, strlen(s), &c); |
1441 |
DosWrite(2, msg1, strlen(msg1), &c); |
1442 |
DosWrite(2, msg2, strlen(msg2), &c); |
1443 |
DosWrite(2, msg3, strlen(msg3), &c); |
1444 |
DosWrite(2, msg4, strlen(msg4), &c); |
1445 |
DosWrite(2, "\r\n", 2, &c); |
1446 |
exit(255); |
1447 |
} |
1448 |
|
1449 |
typedef ULONG (*fill_extLibpath_t)(int type, |
1450 |
char *pre, |
1451 |
char *post, |
1452 |
int replace, |
1453 |
char *msg); |
1454 |
typedef int (*main_t)(int type, char *argv[], char *env[]); |
1455 |
typedef int (*handler_t)(void* data, int which); |
1456 |
|
1457 |
#ifndef PERL_DLL_BASENAME |
1458 |
# define PERL_DLL_BASENAME "perl" |
1459 |
#endif |
1460 |
|
1461 |
static HMODULE |
1462 |
load_perl_dll(char *basename) |
1463 |
{ |
1464 |
char buf[300], fail[260]; |
1465 |
STRLEN l, dirl; |
1466 |
fill_extLibpath_t f; |
1467 |
ULONG rc_fullname; |
1468 |
HMODULE handle, handle1; |
1469 |
|
1470 |
if (_execname(buf, sizeof(buf) - 13) != 0) |
1471 |
die_with("Can't find full path: ", strerror(errno), "", ""); |
1472 |
/* XXXX Fill 'me' with new value */ |
1473 |
l = strlen(buf); |
1474 |
while (l && buf[l-1] != '/' && buf[l-1] != '\\') |
1475 |
l--; |
1476 |
dirl = l - 1; |
1477 |
strcpy(buf + l, basename); |
1478 |
l += strlen(basename); |
1479 |
strcpy(buf + l, ".dll"); |
1480 |
if ( (rc_fullname = DosLoadModule(fail, sizeof fail, buf, &handle)) |
1481 |
!= 0 |
1482 |
&& DosLoadModule(fail, sizeof fail, basename, &handle) != 0 ) |
1483 |
die_with("Can't load DLL ", buf, "", ""); |
1484 |
if (rc_fullname) |
1485 |
return handle; /* was loaded with short name; all is fine */ |
1486 |
if (DosQueryProcAddr(handle, 0, "fill_extLibpath", (PFN*)&f)) |
1487 |
die_with(buf, |
1488 |
": DLL exports no symbol ", |
1489 |
"fill_extLibpath", |
1490 |
""); |
1491 |
buf[dirl] = 0; |
1492 |
if (f(0 /*BEGINLIBPATH*/, buf /* prepend */, NULL /* append */, |
1493 |
0 /* keep old value */, me)) |
1494 |
die_with(me, ": prepending BEGINLIBPATH", "", ""); |
1495 |
if (DosLoadModule(fail, sizeof fail, basename, &handle1) != 0) |
1496 |
die_with(me, |
1497 |
": finding perl DLL again via BEGINLIBPATH", |
1498 |
"", |
1499 |
""); |
1500 |
buf[dirl] = '\\'; |
1501 |
if (handle1 != handle) { |
1502 |
if (DosQueryModuleName(handle1, sizeof(fail), fail)) |
1503 |
strcpy(fail, "???"); |
1504 |
die_with(buf, |
1505 |
":\n\tperl DLL via BEGINLIBPATH is different: \n\t", |
1506 |
fail, |
1507 |
"\n\tYou may need to manipulate global BEGINLIBPATH" |
1508 |
" and LIBPATHSTRICT" |
1509 |
"\n\tso that the other copy is loaded via" |
1510 |
BEGINLIBPATH."); |
1511 |
} |
1512 |
return handle; |
1513 |
} |
1514 |
|
1515 |
int |
1516 |
main(int argc, char **argv, char **env) |
1517 |
{ |
1518 |
main_t f; |
1519 |
handler_t h; |
1520 |
|
1521 |
me = argv[0]; |
1522 |
/**/ |
1523 |
handle = load_perl_dll(PERL_DLL_BASENAME); |
1524 |
|
1525 |
if (DosQueryProcAddr(handle, |
1526 |
0, |
1527 |
"Perl_OS2_handler_install", |
1528 |
(PFN*)&h)) |
1529 |
die_with(PERL_DLL_BASENAME, |
1530 |
": DLL exports no symbol ", |
1531 |
"Perl_OS2_handler_install", |
1532 |
""); |
1533 |
if ( !h((void *)"~installprefix", Perlos2_handler_perllib_from) |
1534 |
|| !h((void *)"~dll", Perlos2_handler_perllib_to) |
1535 |
|| !h((void *)"~dll/sh/ksh.exe", Perlos2_handler_perl_sh) ) |
1536 |
die_with(PERL_DLL_BASENAME, |
1537 |
": Can't install @INC manglers", |
1538 |
"", |
1539 |
""); |
1540 |
if (DosQueryProcAddr(handle, 0, "dll_perlmain", (PFN*)&f)) |
1541 |
die_with(PERL_DLL_BASENAME, |
1542 |
": DLL exports no symbol ", |
1543 |
"dll_perlmain", |
1544 |
""); |
1545 |
return f(argc, argv, env); |
1546 |
} |
1547 |
|
1548 |
=head1 Build FAQ |
1549 |
|
1550 |
=head2 Some C</> became C<\> in pdksh. |
1551 |
|
1552 |
You have a very old pdksh. See L</Prerequisites>. |
1553 |
|
1554 |
=head2 C<'errno'> - unresolved external |
1555 |
|
1556 |
You do not have MT-safe F<db.lib>. See L</Prerequisites>. |
1557 |
|
1558 |
=head2 Problems with tr or sed |
1559 |
|
1560 |
reported with very old version of tr and sed. |
1561 |
|
1562 |
=head2 Some problem (forget which ;-) |
1563 |
|
1564 |
You have an older version of F<perl.dll> on your LIBPATH, which |
1565 |
broke the build of extensions. |
1566 |
|
1567 |
=head2 Library ... not found |
1568 |
|
1569 |
You did not run C<omflibs>. See L</Prerequisites>. |
1570 |
|
1571 |
=head2 Segfault in make |
1572 |
|
1573 |
You use an old version of GNU make. See L</Prerequisites>. |
1574 |
|
1575 |
=head2 op/sprintf test failure |
1576 |
|
1577 |
This can result from a bug in emx sprintf which was fixed in 0.9d fix 03. |
1578 |
|
1579 |
=head1 Specific (mis)features of OS/2 port |
1580 |
|
1581 |
=head2 C<setpriority>, C<getpriority> |
1582 |
|
1583 |
Note that these functions are compatible with *nix, not with the older |
1584 |
ports of '94 - 95. The priorities are absolute, go from 32 to -95, |
1585 |
lower is quicker. 0 is the default priority. |
1586 |
|
1587 |
B<WARNING>. Calling C<getpriority> on a non-existing process could lock |
1588 |
the system before Warp3 fixpak22. Starting with Warp3, Perl will use |
1589 |
a workaround: it aborts getpriority() if the process is not present. |
1590 |
This is not possible on older versions C<2.*>, and has a race |
1591 |
condition anyway. |
1592 |
|
1593 |
=head2 C<system()> |
1594 |
|
1595 |
Multi-argument form of C<system()> allows an additional numeric |
1596 |
argument. The meaning of this argument is described in |
1597 |
L<OS2::Process>. |
1598 |
|
1599 |
When finding a program to run, Perl first asks the OS to look for executables |
1600 |
on C<PATH> (OS/2 adds extension F<.exe> if no extension is present). |
1601 |
If not found, it looks for a script with possible extensions |
1602 |
added in this order: no extension, F<.cmd>, F<.btm>, |
1603 |
F<.bat>, F<.pl>. If found, Perl checks the start of the file for magic |
1604 |
strings C<"#!"> and C<"extproc ">. If found, Perl uses the rest of the |
1605 |
first line as the beginning of the command line to run this script. The |
1606 |
only mangling done to the first line is extraction of arguments (currently |
1607 |
up to 3), and ignoring of the path-part of the "interpreter" name if it can't |
1608 |
be found using the full path. |
1609 |
|
1610 |
E.g., C<system 'foo', 'bar', 'baz'> may lead Perl to finding |
1611 |
F<C:/emx/bin/foo.cmd> with the first line being |
1612 |
|
1613 |
extproc /bin/bash -x -c |
1614 |
|
1615 |
If F</bin/bash.exe> is not found, then Perl looks for an executable F<bash.exe> on |
1616 |
C<PATH>. If found in F<C:/emx.add/bin/bash.exe>, then the above system() is |
1617 |
translated to |
1618 |
|
1619 |
system qw(C:/emx.add/bin/bash.exe -x -c C:/emx/bin/foo.cmd bar baz) |
1620 |
|
1621 |
One additional translation is performed: instead of F</bin/sh> Perl uses |
1622 |
the hardwired-or-customized shell (see L</"C<PERL_SH_DIR>">). |
1623 |
|
1624 |
The above search for "interpreter" is recursive: if F<bash> executable is not |
1625 |
found, but F<bash.btm> is found, Perl will investigate its first line etc. |
1626 |
The only hardwired limit on the recursion depth is implicit: there is a limit |
1627 |
4 on the number of additional arguments inserted before the actual arguments |
1628 |
given to system(). In particular, if no additional arguments are specified |
1629 |
on the "magic" first lines, then the limit on the depth is 4. |
1630 |
|
1631 |
If Perl finds that the found executable is of PM type when the |
1632 |
current session is not, it will start the new process in a separate session of |
1633 |
necessary type. Call via C<OS2::Process> to disable this magic. |
1634 |
|
1635 |
B<WARNING>. Due to the described logic, you need to explicitly |
1636 |
specify F<.com> extension if needed. Moreover, if the executable |
1637 |
F<perl5.6.1> is requested, Perl will not look for F<perl5.6.1.exe>. |
1638 |
[This may change in the future.] |
1639 |
|
1640 |
=head2 C<extproc> on the first line |
1641 |
|
1642 |
If the first chars of a Perl script are C<"extproc ">, this line is treated |
1643 |
as C<#!>-line, thus all the switches on this line are processed (twice |
1644 |
if script was started via cmd.exe). See L<perlrun/DESCRIPTION>. |
1645 |
|
1646 |
=head2 Additional modules: |
1647 |
|
1648 |
L<OS2::Process>, L<OS2::DLL>, L<OS2::REXX>, L<OS2::PrfDB>, L<OS2::ExtAttr>. These |
1649 |
modules provide access to additional numeric argument for C<system> |
1650 |
and to the information about the running process, |
1651 |
to DLLs having functions with REXX signature and to the REXX runtime, to |
1652 |
OS/2 databases in the F<.INI> format, and to Extended Attributes. |
1653 |
|
1654 |
Two additional extensions by Andreas Kaiser, C<OS2::UPM>, and |
1655 |
C<OS2::FTP>, are included into C<ILYAZ> directory, mirrored on CPAN. |
1656 |
Other OS/2-related extensions are available too. |
1657 |
|
1658 |
=head2 Prebuilt methods: |
1659 |
|
1660 |
=over 4 |
1661 |
|
1662 |
=item C<File::Copy::syscopy> |
1663 |
|
1664 |
used by C<File::Copy::copy>, see L<File::Copy>. |
1665 |
|
1666 |
=item C<DynaLoader::mod2fname> |
1667 |
|
1668 |
used by C<DynaLoader> for DLL name mangling. |
1669 |
|
1670 |
=item C<Cwd::current_drive()> |
1671 |
|
1672 |
Self explanatory. |
1673 |
|
1674 |
=item C<Cwd::sys_chdir(name)> |
1675 |
|
1676 |
leaves drive as it is. |
1677 |
|
1678 |
=item C<Cwd::change_drive(name)> |
1679 |
|
1680 |
changes the "current" drive. |
1681 |
|
1682 |
=item C<Cwd::sys_is_absolute(name)> |
1683 |
|
1684 |
means has drive letter and is_rooted. |
1685 |
|
1686 |
=item C<Cwd::sys_is_rooted(name)> |
1687 |
|
1688 |
means has leading C<[/\\]> (maybe after a drive-letter:). |
1689 |
|
1690 |
=item C<Cwd::sys_is_relative(name)> |
1691 |
|
1692 |
means changes with current dir. |
1693 |
|
1694 |
=item C<Cwd::sys_cwd(name)> |
1695 |
|
1696 |
Interface to cwd from EMX. Used by C<Cwd::cwd>. |
1697 |
|
1698 |
=item C<Cwd::sys_abspath(name, dir)> |
1699 |
|
1700 |
Really really odious function to implement. Returns absolute name of |
1701 |
file which would have C<name> if CWD were C<dir>. C<Dir> defaults to the |
1702 |
current dir. |
1703 |
|
1704 |
=item C<Cwd::extLibpath([type])> |
1705 |
|
1706 |
Get current value of extended library search path. If C<type> is |
1707 |
present and positive, works with C<END_LIBPATH>, if negative, works |
1708 |
with C<LIBPATHSTRICT>, otherwise with C<BEGIN_LIBPATH>. |
1709 |
|
1710 |
=item C<Cwd::extLibpath_set( path [, type ] )> |
1711 |
|
1712 |
Set current value of extended library search path. If C<type> is |
1713 |
present and positive, works with <END_LIBPATH>, if negative, works |
1714 |
with C<LIBPATHSTRICT>, otherwise with C<BEGIN_LIBPATH>. |
1715 |
|
1716 |
=item C<OS2::Error(do_harderror,do_exception)> |
1717 |
|
1718 |
Returns C<undef> if it was not called yet, otherwise bit 1 is |
1719 |
set if on the previous call do_harderror was enabled, bit |
1720 |
2 is set if on previous call do_exception was enabled. |
1721 |
|
1722 |
This function enables/disables error popups associated with |
1723 |
hardware errors (Disk not ready etc.) and software exceptions. |
1724 |
|
1725 |
I know of no way to find out the state of popups I<before> the first call |
1726 |
to this function. |
1727 |
|
1728 |
=item C<OS2::Errors2Drive(drive)> |
1729 |
|
1730 |
Returns C<undef> if it was not called yet, otherwise return false if errors |
1731 |
were not requested to be written to a hard drive, or the drive letter if |
1732 |
this was requested. |
1733 |
|
1734 |
This function may redirect error popups associated with hardware errors |
1735 |
(Disk not ready etc.) and software exceptions to the file POPUPLOG.OS2 at |
1736 |
the root directory of the specified drive. Overrides OS2::Error() specified |
1737 |
by individual programs. Given argument undef will disable redirection. |
1738 |
|
1739 |
Has global effect, persists after the application exits. |
1740 |
|
1741 |
I know of no way to find out the state of redirection of popups to the disk |
1742 |
I<before> the first call to this function. |
1743 |
|
1744 |
=item OS2::SysInfo() |
1745 |
|
1746 |
Returns a hash with system information. The keys of the hash are |
1747 |
|
1748 |
MAX_PATH_LENGTH, MAX_TEXT_SESSIONS, MAX_PM_SESSIONS, |
1749 |
MAX_VDM_SESSIONS, BOOT_DRIVE, DYN_PRI_VARIATION, |
1750 |
MAX_WAIT, MIN_SLICE, MAX_SLICE, PAGE_SIZE, |
1751 |
VERSION_MAJOR, VERSION_MINOR, VERSION_REVISION, |
1752 |
MS_COUNT, TIME_LOW, TIME_HIGH, TOTPHYSMEM, TOTRESMEM, |
1753 |
TOTAVAILMEM, MAXPRMEM, MAXSHMEM, TIMER_INTERVAL, |
1754 |
MAX_COMP_LENGTH, FOREGROUND_FS_SESSION, |
1755 |
FOREGROUND_PROCESS |
1756 |
|
1757 |
=item OS2::BootDrive() |
1758 |
|
1759 |
Returns a letter without colon. |
1760 |
|
1761 |
=item C<OS2::MorphPM(serve)>, C<OS2::UnMorphPM(serve)> |
1762 |
|
1763 |
Transforms the current application into a PM application and back. |
1764 |
The argument true means that a real message loop is going to be served. |
1765 |
OS2::MorphPM() returns the PM message queue handle as an integer. |
1766 |
|
1767 |
See L</"Centralized management of resources"> for additional details. |
1768 |
|
1769 |
=item C<OS2::Serve_Messages(force)> |
1770 |
|
1771 |
Fake on-demand retrieval of outstanding PM messages. If C<force> is false, |
1772 |
will not dispatch messages if a real message loop is known to |
1773 |
be present. Returns number of messages retrieved. |
1774 |
|
1775 |
Dies with "QUITing..." if WM_QUIT message is obtained. |
1776 |
|
1777 |
=item C<OS2::Process_Messages(force [, cnt])> |
1778 |
|
1779 |
Retrieval of PM messages until window creation/destruction. |
1780 |
If C<force> is false, will not dispatch messages if a real message loop |
1781 |
is known to be present. |
1782 |
|
1783 |
Returns change in number of windows. If C<cnt> is given, |
1784 |
it is incremented by the number of messages retrieved. |
1785 |
|
1786 |
Dies with "QUITing..." if WM_QUIT message is obtained. |
1787 |
|
1788 |
=item C<OS2::_control87(new,mask)> |
1789 |
|
1790 |
the same as L<_control87(3)> of EMX. Takes integers as arguments, returns |
1791 |
the previous coprocessor control word as an integer. Only bits in C<new> which |
1792 |
are present in C<mask> are changed in the control word. |
1793 |
|
1794 |
=item OS2::get_control87() |
1795 |
|
1796 |
gets the coprocessor control word as an integer. |
1797 |
|
1798 |
=item C<OS2::set_control87_em(new=MCW_EM,mask=MCW_EM)> |
1799 |
|
1800 |
The variant of OS2::_control87() with default values good for |
1801 |
handling exception mask: if no C<mask>, uses exception mask part of C<new> |
1802 |
only. If no C<new>, disables all the floating point exceptions. |
1803 |
|
1804 |
See L</"Misfeatures"> for details. |
1805 |
|
1806 |
=item C<OS2::DLLname([how [, \&xsub]])> |
1807 |
|
1808 |
Gives the information about the Perl DLL or the DLL containing the C |
1809 |
function bound to by C<&xsub>. The meaning of C<how> is: default (2): |
1810 |
full name; 0: handle; 1: module name. |
1811 |
|
1812 |
=back |
1813 |
|
1814 |
(Note that some of these may be moved to different libraries - |
1815 |
eventually). |
1816 |
|
1817 |
|
1818 |
=head2 Prebuilt variables: |
1819 |
|
1820 |
=over 4 |
1821 |
|
1822 |
=item $OS2::emx_rev |
1823 |
|
1824 |
numeric value is the same as _emx_rev of EMX, a string value the same |
1825 |
as _emx_vprt (similar to C<0.9c>). |
1826 |
|
1827 |
=item $OS2::emx_env |
1828 |
|
1829 |
same as _emx_env of EMX, a number similar to 0x8001. |
1830 |
|
1831 |
=item $OS2::os_ver |
1832 |
|
1833 |
a number C<OS_MAJOR + 0.001 * OS_MINOR>. |
1834 |
|
1835 |
=item $OS2::is_aout |
1836 |
|
1837 |
true if the Perl library was compiled in AOUT format. |
1838 |
|
1839 |
=item $OS2::can_fork |
1840 |
|
1841 |
true if the current executable is an AOUT EMX executable, so Perl can |
1842 |
fork. Do not use this, use the portable check for |
1843 |
$Config::Config{dfork}. |
1844 |
|
1845 |
=item $OS2::nsyserror |
1846 |
|
1847 |
This variable (default is 1) controls whether to enforce the contents |
1848 |
of $^E to start with C<SYS0003>-like id. If set to 0, then the string |
1849 |
value of $^E is what is available from the OS/2 message file. (Some |
1850 |
messages in this file have an C<SYS0003>-like id prepended, some not.) |
1851 |
|
1852 |
=back |
1853 |
|
1854 |
=head2 Misfeatures |
1855 |
|
1856 |
=over 4 |
1857 |
|
1858 |
=item * |
1859 |
|
1860 |
Since L<flock(3)> is present in EMX, but is not functional, it is |
1861 |
emulated by perl. To disable the emulations, set environment variable |
1862 |
C<USE_PERL_FLOCK=0>. |
1863 |
|
1864 |
=item * |
1865 |
|
1866 |
Here is the list of things which may be "broken" on |
1867 |
EMX (from EMX docs): |
1868 |
|
1869 |
=over 4 |
1870 |
|
1871 |
=item * |
1872 |
|
1873 |
The functions L<recvmsg(3)>, L<sendmsg(3)>, and L<socketpair(3)> are not |
1874 |
implemented. |
1875 |
|
1876 |
=item * |
1877 |
|
1878 |
L<sock_init(3)> is not required and not implemented. |
1879 |
|
1880 |
=item * |
1881 |
|
1882 |
L<flock(3)> is not yet implemented (dummy function). (Perl has a workaround.) |
1883 |
|
1884 |
=item * |
1885 |
|
1886 |
L<kill(3)>: Special treatment of PID=0, PID=1 and PID=-1 is not implemented. |
1887 |
|
1888 |
=item * |
1889 |
|
1890 |
L<waitpid(3)>: |
1891 |
|
1892 |
WUNTRACED |
1893 |
Not implemented. |
1894 |
waitpid() is not implemented for negative values of PID. |
1895 |
|
1896 |
=back |
1897 |
|
1898 |
Note that C<kill -9> does not work with the current version of EMX. |
1899 |
|
1900 |
=item * |
1901 |
|
1902 |
See L</"Text-mode filehandles">. |
1903 |
|
1904 |
=item * |
1905 |
|
1906 |
Unix-domain sockets on OS/2 live in a pseudo-file-system C</sockets/...>. |
1907 |
To avoid a failure to create a socket with a name of a different form, |
1908 |
C<"/socket/"> is prepended to the socket name (unless it starts with this |
1909 |
already). |
1910 |
|
1911 |
This may lead to problems later in case the socket is accessed via the |
1912 |
"usual" file-system calls using the "initial" name. |
1913 |
|
1914 |
=item * |
1915 |
|
1916 |
Apparently, IBM used a compiler (for some period of time around '95?) which |
1917 |
changes FP mask right and left. This is not I<that> bad for IBM's |
1918 |
programs, but the same compiler was used for DLLs which are used with |
1919 |
general-purpose applications. When these DLLs are used, the state of |
1920 |
floating-point flags in the application is not predictable. |
1921 |
|
1922 |
What is much worse, some DLLs change the floating point flags when in |
1923 |
_DLLInitTerm() (e.g., F<TCP32IP>). This means that even if you do not I<call> |
1924 |
any function in the DLL, just the act of loading this DLL will reset your |
1925 |
flags. What is worse, the same compiler was used to compile some HOOK DLLs. |
1926 |
Given that HOOK dlls are executed in the context of I<all> the applications |
1927 |
in the system, this means a complete unpredictability of floating point |
1928 |
flags on systems using such HOOK DLLs. E.g., F<GAMESRVR.DLL> of B<DIVE> |
1929 |
origin changes the floating point flags on each write to the TTY of a VIO |
1930 |
(windowed text-mode) applications. |
1931 |
|
1932 |
Some other (not completely debugged) situations when FP flags change include |
1933 |
some video drivers (?), and some operations related to creation of the windows. |
1934 |
People who code B<OpenGL> may have more experience on this. |
1935 |
|
1936 |
Perl is generally used in the situation when all the floating-point |
1937 |
exceptions are ignored, as is the default under EMX. If they are not ignored, |
1938 |
some benign Perl programs would get a C<SIGFPE> and would die a horrible death. |
1939 |
|
1940 |
To circumvent this, Perl uses two hacks. They help against I<one> type of |
1941 |
damage only: FP flags changed when loading a DLL. |
1942 |
|
1943 |
One of the hacks is to disable floating point exceptions on Perl startup (as |
1944 |
is the default with EMX). This helps only with compile-time-linked DLLs |
1945 |
changing the flags before main() had a chance to be called. |
1946 |
|
1947 |
The other hack is to restore FP flags after a call to dlopen(). This helps |
1948 |
against similar damage done by DLLs _DLLInitTerm() at runtime. Currently |
1949 |
no way to switch these hacks off is provided. |
1950 |
|
1951 |
=back |
1952 |
|
1953 |
=head2 Modifications |
1954 |
|
1955 |
Perl modifies some standard C library calls in the following ways: |
1956 |
|
1957 |
=over 9 |
1958 |
|
1959 |
=item C<popen> |
1960 |
|
1961 |
C<my_popen> uses F<sh.exe> if shell is required, cf. L</"C<PERL_SH_DIR>">. |
1962 |
|
1963 |
=item C<tmpnam> |
1964 |
|
1965 |
is created using C<TMP> or C<TEMP> environment variable, via |
1966 |
C<tempnam>. |
1967 |
|
1968 |
=item C<tmpfile> |
1969 |
|
1970 |
If the current directory is not writable, file is created using modified |
1971 |
C<tmpnam>, so there may be a race condition. |
1972 |
|
1973 |
=item C<ctermid> |
1974 |
|
1975 |
a dummy implementation. |
1976 |
|
1977 |
=item C<stat> |
1978 |
|
1979 |
C<os2_stat> special-cases F</dev/tty> and F</dev/con>. |
1980 |
|
1981 |
=item C<mkdir>, C<rmdir> |
1982 |
|
1983 |
these EMX functions do not work if the path contains a trailing C</>. |
1984 |
Perl contains a workaround for this. |
1985 |
|
1986 |
=item C<flock> |
1987 |
|
1988 |
Since L<flock(3)> is present in EMX, but is not functional, it is |
1989 |
emulated by perl. To disable the emulations, set environment variable |
1990 |
C<USE_PERL_FLOCK=0>. |
1991 |
|
1992 |
=back |
1993 |
|
1994 |
=head2 Identifying DLLs |
1995 |
|
1996 |
All the DLLs built with the current versions of Perl have ID strings |
1997 |
identifying the name of the extension, its version, and the version |
1998 |
of Perl required for this DLL. Run C<bldlevel DLL-name> to find this |
1999 |
info. |
2000 |
|
2001 |
=head2 Centralized management of resources |
2002 |
|
2003 |
Since to call certain OS/2 API one needs to have a correctly initialized |
2004 |
C<Win> subsystem, OS/2-specific extensions may require getting C<HAB>s and |
2005 |
C<HMQ>s. If an extension would do it on its own, another extension could |
2006 |
fail to initialize. |
2007 |
|
2008 |
Perl provides a centralized management of these resources: |
2009 |
|
2010 |
=over |
2011 |
|
2012 |
=item C<HAB> |
2013 |
|
2014 |
To get the HAB, the extension should call C<hab = perl_hab_GET()> in C. After |
2015 |
this call is performed, C<hab> may be accessed as C<Perl_hab>. There is |
2016 |
no need to release the HAB after it is used. |
2017 |
|
2018 |
If by some reasons F<perl.h> cannot be included, use |
2019 |
|
2020 |
extern int Perl_hab_GET(void); |
2021 |
|
2022 |
instead. |
2023 |
|
2024 |
=item C<HMQ> |
2025 |
|
2026 |
There are two cases: |
2027 |
|
2028 |
=over |
2029 |
|
2030 |
=item * |
2031 |
|
2032 |
the extension needs an C<HMQ> only because some API will not work otherwise. |
2033 |
Use C<serve = 0> below. |
2034 |
|
2035 |
=item * |
2036 |
|
2037 |
the extension needs an C<HMQ> since it wants to engage in a PM event loop. |
2038 |
Use C<serve = 1> below. |
2039 |
|
2040 |
=back |
2041 |
|
2042 |
To get an C<HMQ>, the extension should call C<hmq = perl_hmq_GET(serve)> in C. |
2043 |
After this call is performed, C<hmq> may be accessed as C<Perl_hmq>. |
2044 |
|
2045 |
To signal to Perl that HMQ is not needed any more, call |
2046 |
C<perl_hmq_UNSET(serve)>. Perl process will automatically morph/unmorph itself |
2047 |
into/from a PM process if HMQ is needed/not-needed. Perl will automatically |
2048 |
enable/disable C<WM_QUIT> message during shutdown if the message queue is |
2049 |
served/not-served. |
2050 |
|
2051 |
B<NOTE>. If during a shutdown there is a message queue which did not disable |
2052 |
WM_QUIT, and which did not process the received WM_QUIT message, the |
2053 |
shutdown will be automatically cancelled. Do not call C<perl_hmq_GET(1)> |
2054 |
unless you are going to process messages on an orderly basis. |
2055 |
|
2056 |
=item Treating errors reported by OS/2 API |
2057 |
|
2058 |
There are two principal conventions (it is useful to call them C<Dos*> |
2059 |
and C<Win*> - though this part of the function signature is not always |
2060 |
determined by the name of the API) of reporting the error conditions |
2061 |
of OS/2 API. Most of C<Dos*> APIs report the error code as the result |
2062 |
of the call (so 0 means success, and there are many types of errors). |
2063 |
Most of C<Win*> API report success/fail via the result being |
2064 |
C<TRUE>/C<FALSE>; to find the reason for the failure one should call |
2065 |
WinGetLastError() API. |
2066 |
|
2067 |
Some C<Win*> entry points also overload a "meaningful" return value |
2068 |
with the error indicator; having a 0 return value indicates an error. |
2069 |
Yet some other C<Win*> entry points overload things even more, and 0 |
2070 |
return value may mean a successful call returning a valid value 0, as |
2071 |
well as an error condition; in the case of a 0 return value one should |
2072 |
call WinGetLastError() API to distinguish a successful call from a |
2073 |
failing one. |
2074 |
|
2075 |
By convention, all the calls to OS/2 API should indicate their |
2076 |
failures by resetting $^E. All the Perl-accessible functions which |
2077 |
call OS/2 API may be broken into two classes: some die()s when an API |
2078 |
error is encountered, the other report the error via a false return |
2079 |
value (of course, this does not concern Perl-accessible functions |
2080 |
which I<expect> a failure of the OS/2 API call, having some workarounds |
2081 |
coded). |
2082 |
|
2083 |
Obviously, in the situation of the last type of the signature of an OS/2 |
2084 |
API, it is must more convenient for the users if the failure is |
2085 |
indicated by die()ing: one does not need to check $^E to know that |
2086 |
something went wrong. If, however, this solution is not desirable by |
2087 |
some reason, the code in question should reset $^E to 0 before making |
2088 |
this OS/2 API call, so that the caller of this Perl-accessible |
2089 |
function has a chance to distinguish a success-but-0-return value from |
2090 |
a failure. (One may return undef as an alternative way of reporting |
2091 |
an error.) |
2092 |
|
2093 |
The macros to simplify this type of error propagation are |
2094 |
|
2095 |
=over |
2096 |
|
2097 |
=item C<CheckOSError(expr)> |
2098 |
|
2099 |
Returns true on error, sets $^E. Expects expr() be a call of |
2100 |
C<Dos*>-style API. |
2101 |
|
2102 |
=item C<CheckWinError(expr)> |
2103 |
|
2104 |
Returns true on error, sets $^E. Expects expr() be a call of |
2105 |
C<Win*>-style API. |
2106 |
|
2107 |
=item C<SaveWinError(expr)> |
2108 |
|
2109 |
Returns C<expr>, sets $^E from WinGetLastError() if C<expr> is false. |
2110 |
|
2111 |
=item C<SaveCroakWinError(expr,die,name1,name2)> |
2112 |
|
2113 |
Returns C<expr>, sets $^E from WinGetLastError() if C<expr> is false, |
2114 |
and die()s if C<die> and $^E are true. The message to die is the |
2115 |
concatenated strings C<name1> and C<name2>, separated by C<": "> from |
2116 |
the contents of $^E. |
2117 |
|
2118 |
=item C<WinError_2_Perl_rc> |
2119 |
|
2120 |
Sets C<Perl_rc> to the return value of WinGetLastError(). |
2121 |
|
2122 |
=item C<FillWinError> |
2123 |
|
2124 |
Sets C<Perl_rc> to the return value of WinGetLastError(), and sets $^E |
2125 |
to the corresponding value. |
2126 |
|
2127 |
=item C<FillOSError(rc)> |
2128 |
|
2129 |
Sets C<Perl_rc> to C<rc>, and sets $^E to the corresponding value. |
2130 |
|
2131 |
=back |
2132 |
|
2133 |
=item Loading DLLs and ordinals in DLLs |
2134 |
|
2135 |
Some DLLs are only present in some versions of OS/2, or in some |
2136 |
configurations of OS/2. Some exported entry points are present only |
2137 |
in DLLs shipped with some versions of OS/2. If these DLLs and entry |
2138 |
points were linked directly for a Perl executable/DLL or from a Perl |
2139 |
extensions, this binary would work only with the specified |
2140 |
versions/setups. Even if these entry points were not needed, the |
2141 |
I<load> of the executable (or DLL) would fail. |
2142 |
|
2143 |
For example, many newer useful APIs are not present in OS/2 v2; many |
2144 |
PM-related APIs require DLLs not available on floppy-boot setup. |
2145 |
|
2146 |
To make these calls fail I<only when the calls are executed>, one |
2147 |
should call these API via a dynamic linking API. There is a subsystem |
2148 |
in Perl to simplify such type of calls. A large number of entry |
2149 |
points available for such linking is provided (see C<entries_ordinals> |
2150 |
- and also C<PMWIN_entries> - in F<os2ish.h>). These ordinals can be |
2151 |
accessed via the APIs: |
2152 |
|
2153 |
CallORD(), DeclFuncByORD(), DeclVoidFuncByORD(), |
2154 |
DeclOSFuncByORD(), DeclWinFuncByORD(), AssignFuncPByORD(), |
2155 |
DeclWinFuncByORD_CACHE(), DeclWinFuncByORD_CACHE_survive(), |
2156 |
DeclWinFuncByORD_CACHE_resetError_survive(), |
2157 |
DeclWinFunc_CACHE(), DeclWinFunc_CACHE_resetError(), |
2158 |
DeclWinFunc_CACHE_survive(), DeclWinFunc_CACHE_resetError_survive() |
2159 |
|
2160 |
See the header files and the C code in the supplied OS/2-related |
2161 |
modules for the details on usage of these functions. |
2162 |
|
2163 |
Some of these functions also combine dynaloading semantic with the |
2164 |
error-propagation semantic discussed above. |
2165 |
|
2166 |
=back |
2167 |
|
2168 |
=head1 Perl flavors |
2169 |
|
2170 |
Because of idiosyncrasies of OS/2 one cannot have all the eggs in the |
2171 |
same basket (though EMX environment tries hard to overcome this |
2172 |
limitations, so the situation may somehow improve). There are 4 |
2173 |
executables for Perl provided by the distribution: |
2174 |
|
2175 |
=head2 F<perl.exe> |
2176 |
|
2177 |
The main workhorse. This is a chimera executable: it is compiled as an |
2178 |
C<a.out>-style executable, but is linked with C<omf>-style dynamic |
2179 |
library F<perl.dll>, and with dynamic CRT DLL. This executable is a |
2180 |
VIO application. |
2181 |
|
2182 |
It can load perl dynamic extensions, and it can fork(). |
2183 |
|
2184 |
B<Note.> Keep in mind that fork() is needed to open a pipe to yourself. |
2185 |
|
2186 |
=head2 F<perl_.exe> |
2187 |
|
2188 |
This is a statically linked C<a.out>-style executable. It cannot |
2189 |
load dynamic Perl extensions. The executable supplied in binary |
2190 |
distributions has a lot of extensions prebuilt, thus the above restriction is |
2191 |
important only if you use custom-built extensions. This executable is a VIO |
2192 |
application. |
2193 |
|
2194 |
I<This is the only executable with does not require OS/2.> The |
2195 |
friends locked into C<M$> world would appreciate the fact that this |
2196 |
executable runs under DOS, Win0.3*, Win0.95 and WinNT with an |
2197 |
appropriate extender. See L</"Other OSes">. |
2198 |
|
2199 |
=head2 F<perl__.exe> |
2200 |
|
2201 |
This is the same executable as F<perl___.exe>, but it is a PM |
2202 |
application. |
2203 |
|
2204 |
B<Note.> Usually (unless explicitly redirected during the startup) |
2205 |
STDIN, STDERR, and STDOUT of a PM |
2206 |
application are redirected to F<nul>. However, it is possible to I<see> |
2207 |
them if you start C<perl__.exe> from a PM program which emulates a |
2208 |
console window, like I<Shell mode> of Emacs or EPM. Thus it I<is |
2209 |
possible> to use Perl debugger (see L<perldebug>) to debug your PM |
2210 |
application (but beware of the message loop lockups - this will not |
2211 |
work if you have a message queue to serve, unless you hook the serving |
2212 |
into the getc() function of the debugger). |
2213 |
|
2214 |
Another way to see the output of a PM program is to run it as |
2215 |
|
2216 |
pm_prog args 2>&1 | cat - |
2217 |
|
2218 |
with a shell I<different> from F<cmd.exe>, so that it does not create |
2219 |
a link between a VIO session and the session of C<pm_porg>. (Such a link |
2220 |
closes the VIO window.) E.g., this works with F<sh.exe> - or with Perl! |
2221 |
|
2222 |
open P, 'pm_prog args 2>&1 |' or die; |
2223 |
print while <P>; |
2224 |
|
2225 |
The flavor F<perl__.exe> is required if you want to start your program without |
2226 |
a VIO window present, but not C<detach>ed (run C<help detach> for more info). |
2227 |
Very useful for extensions which use PM, like C<Perl/Tk> or C<OpenGL>. |
2228 |
|
2229 |
Note also that the differences between PM and VIO executables are only |
2230 |
in the I<default> behaviour. One can start I<any> executable in |
2231 |
I<any> kind of session by using the arguments C</fs>, C</pm> or |
2232 |
C</win> switches of the command C<start> (of F<CMD.EXE> or a similar |
2233 |
shell). Alternatively, one can use the numeric first argument of the |
2234 |
C<system> Perl function (see L<OS2::Process>). |
2235 |
|
2236 |
=head2 F<perl___.exe> |
2237 |
|
2238 |
This is an C<omf>-style executable which is dynamically linked to |
2239 |
F<perl.dll> and CRT DLL. I know no advantages of this executable |
2240 |
over C<perl.exe>, but it cannot fork() at all. Well, one advantage is |
2241 |
that the build process is not so convoluted as with C<perl.exe>. |
2242 |
|
2243 |
It is a VIO application. |
2244 |
|
2245 |
=head2 Why strange names? |
2246 |
|
2247 |
Since Perl processes the C<#!>-line (cf. |
2248 |
L<perlrun/DESCRIPTION>, L<perlrun/Command Switches>, |
2249 |
L<perldiag/"No Perl script found in input">), it should know when a |
2250 |
program I<is a Perl>. There is some naming convention which allows |
2251 |
Perl to distinguish correct lines from wrong ones. The above names are |
2252 |
almost the only names allowed by this convention which do not contain |
2253 |
digits (which have absolutely different semantics). |
2254 |
|
2255 |
=head2 Why dynamic linking? |
2256 |
|
2257 |
Well, having several executables dynamically linked to the same huge |
2258 |
library has its advantages, but this would not substantiate the |
2259 |
additional work to make it compile. The reason is the complicated-to-developers |
2260 |
but very quick and convenient-to-users "hard" dynamic linking used by OS/2. |
2261 |
|
2262 |
There are two distinctive features of the dyna-linking model of OS/2: |
2263 |
first, all the references to external functions are resolved at the compile time; |
2264 |
second, there is no runtime fixup of the DLLs after they are loaded into memory. |
2265 |
The first feature is an enormous advantage over other models: it avoids |
2266 |
conflicts when several DLLs used by an application export entries with |
2267 |
the same name. In such cases "other" models of dyna-linking just choose |
2268 |
between these two entry points using some random criterion - with predictable |
2269 |
disasters as results. But it is the second feature which requires the build |
2270 |
of F<perl.dll>. |
2271 |
|
2272 |
The address tables of DLLs are patched only once, when they are |
2273 |
loaded. The addresses of the entry points into DLLs are guaranteed to be |
2274 |
the same for all the programs which use the same DLL. This removes the |
2275 |
runtime fixup - once DLL is loaded, its code is read-only. |
2276 |
|
2277 |
While this allows some (significant?) performance advantages, this makes life |
2278 |
much harder for developers, since the above scheme makes it impossible |
2279 |
for a DLL to be "linked" to a symbol in the F<.EXE> file. Indeed, this |
2280 |
would need a DLL to have different relocations tables for the |
2281 |
(different) executables which use this DLL. |
2282 |
|
2283 |
However, a dynamically loaded Perl extension is forced to use some symbols |
2284 |
from the perl |
2285 |
executable, e.g., to know how to find the arguments to the functions: |
2286 |
the arguments live on the perl |
2287 |
internal evaluation stack. The solution is to put the main code of |
2288 |
the interpreter into a DLL, and make the F<.EXE> file which just loads |
2289 |
this DLL into memory and supplies command-arguments. The extension DLL |
2290 |
cannot link to symbols in F<.EXE>, but it has no problem linking |
2291 |
to symbols in the F<.DLL>. |
2292 |
|
2293 |
This I<greatly> increases the load time for the application (as well as |
2294 |
complexity of the compilation). Since interpreter is in a DLL, |
2295 |
the C RTL is basically forced to reside in a DLL as well (otherwise |
2296 |
extensions would not be able to use CRT). There are some advantages if |
2297 |
you use different flavors of perl, such as running F<perl.exe> and |
2298 |
F<perl__.exe> simultaneously: they share the memory of F<perl.dll>. |
2299 |
|
2300 |
B<NOTE>. There is one additional effect which makes DLLs more wasteful: |
2301 |
DLLs are loaded in the shared memory region, which is a scarse resource |
2302 |
given the 512M barrier of the "standard" OS/2 virtual memory. The code of |
2303 |
F<.EXE> files is also shared by all the processes which use the particular |
2304 |
F<.EXE>, but they are "shared in the private address space of the process"; |
2305 |
this is possible because the address at which different sections |
2306 |
of the F<.EXE> file are loaded is decided at compile-time, thus all the |
2307 |
processes have these sections loaded at same addresses, and no fixup |
2308 |
of internal links inside the F<.EXE> is needed. |
2309 |
|
2310 |
Since DLLs may be loaded at run time, to have the same mechanism for DLLs |
2311 |
one needs to have the address range of I<any of the loaded> DLLs in the |
2312 |
system to be available I<in all the processes> which did not load a particular |
2313 |
DLL yet. This is why the DLLs are mapped to the shared memory region. |
2314 |
|
2315 |
=head2 Why chimera build? |
2316 |
|
2317 |
Current EMX environment does not allow DLLs compiled using Unixish |
2318 |
C<a.out> format to export symbols for data (or at least some types of |
2319 |
data). This forces C<omf>-style compile of F<perl.dll>. |
2320 |
|
2321 |
Current EMX environment does not allow F<.EXE> files compiled in |
2322 |
C<omf> format to fork(). fork() is needed for exactly three Perl |
2323 |
operations: |
2324 |
|
2325 |
=over 4 |
2326 |
|
2327 |
=item * |
2328 |
|
2329 |
explicit fork() in the script, |
2330 |
|
2331 |
=item * |
2332 |
|
2333 |
C<open FH, "|-"> |
2334 |
|
2335 |
=item * |
2336 |
|
2337 |
C<open FH, "-|">, in other words, opening pipes to itself. |
2338 |
|
2339 |
=back |
2340 |
|
2341 |
While these operations are not questions of life and death, they are |
2342 |
needed for a lot of |
2343 |
useful scripts. This forces C<a.out>-style compile of |
2344 |
F<perl.exe>. |
2345 |
|
2346 |
|
2347 |
=head1 ENVIRONMENT |
2348 |
|
2349 |
Here we list environment variables with are either OS/2- and DOS- and |
2350 |
Win*-specific, or are more important under OS/2 than under other OSes. |
2351 |
|
2352 |
=head2 C<PERLLIB_PREFIX> |
2353 |
|
2354 |
Specific for EMX port. Should have the form |
2355 |
|
2356 |
path1;path2 |
2357 |
|
2358 |
or |
2359 |
|
2360 |
path1 path2 |
2361 |
|
2362 |
If the beginning of some prebuilt path matches F<path1>, it is |
2363 |
substituted with F<path2>. |
2364 |
|
2365 |
Should be used if the perl library is moved from the default |
2366 |
location in preference to C<PERL(5)LIB>, since this would not leave wrong |
2367 |
entries in @INC. For example, if the compiled version of perl looks for @INC |
2368 |
in F<f:/perllib/lib>, and you want to install the library in |
2369 |
F<h:/opt/gnu>, do |
2370 |
|
2371 |
set PERLLIB_PREFIX=f:/perllib/lib;h:/opt/gnu |
2372 |
|
2373 |
This will cause Perl with the prebuilt @INC of |
2374 |
|
2375 |
f:/perllib/lib/5.00553/os2 |
2376 |
f:/perllib/lib/5.00553 |
2377 |
f:/perllib/lib/site_perl/5.00553/os2 |
2378 |
f:/perllib/lib/site_perl/5.00553 |
2379 |
. |
2380 |
|
2381 |
to use the following @INC: |
2382 |
|
2383 |
h:/opt/gnu/5.00553/os2 |
2384 |
h:/opt/gnu/5.00553 |
2385 |
h:/opt/gnu/site_perl/5.00553/os2 |
2386 |
h:/opt/gnu/site_perl/5.00553 |
2387 |
. |
2388 |
|
2389 |
=head2 C<PERL_BADLANG> |
2390 |
|
2391 |
If 0, perl ignores setlocale() failing. May be useful with some |
2392 |
strange I<locale>s. |
2393 |
|
2394 |
=head2 C<PERL_BADFREE> |
2395 |
|
2396 |
If 0, perl would not warn of in case of unwarranted free(). With older |
2397 |
perls this might be |
2398 |
useful in conjunction with the module DB_File, which was buggy when |
2399 |
dynamically linked and OMF-built. |
2400 |
|
2401 |
Should not be set with newer Perls, since this may hide some I<real> problems. |
2402 |
|
2403 |
=head2 C<PERL_SH_DIR> |
2404 |
|
2405 |
Specific for EMX port. Gives the directory part of the location for |
2406 |
F<sh.exe>. |
2407 |
|
2408 |
=head2 C<USE_PERL_FLOCK> |
2409 |
|
2410 |
Specific for EMX port. Since L<flock(3)> is present in EMX, but is not |
2411 |
functional, it is emulated by perl. To disable the emulations, set |
2412 |
environment variable C<USE_PERL_FLOCK=0>. |
2413 |
|
2414 |
=head2 C<TMP> or C<TEMP> |
2415 |
|
2416 |
Specific for EMX port. Used as storage place for temporary files. |
2417 |
|
2418 |
=head1 Evolution |
2419 |
|
2420 |
Here we list major changes which could make you by surprise. |
2421 |
|
2422 |
=head2 Text-mode filehandles |
2423 |
|
2424 |
Starting from version 5.8, Perl uses a builtin translation layer for |
2425 |
text-mode files. This replaces the efficient well-tested EMX layer by |
2426 |
some code which should be best characterized as a "quick hack". |
2427 |
|
2428 |
In addition to possible bugs and an inability to follow changes to the |
2429 |
translation policy with off/on switches of TERMIO translation, this |
2430 |
introduces a serious incompatible change: before sysread() on |
2431 |
text-mode filehandles would go through the translation layer, now it |
2432 |
would not. |
2433 |
|
2434 |
=head2 Priorities |
2435 |
|
2436 |
C<setpriority> and C<getpriority> are not compatible with earlier |
2437 |
ports by Andreas Kaiser. See C<"setpriority, getpriority">. |
2438 |
|
2439 |
=head2 DLL name mangling: pre 5.6.2 |
2440 |
|
2441 |
With the release 5.003_01 the dynamically loadable libraries |
2442 |
should be rebuilt when a different version of Perl is compiled. In particular, |
2443 |
DLLs (including F<perl.dll>) are now created with the names |
2444 |
which contain a checksum, thus allowing workaround for OS/2 scheme of |
2445 |
caching DLLs. |
2446 |
|
2447 |
It may be possible to code a simple workaround which would |
2448 |
|
2449 |
=over |
2450 |
|
2451 |
=item * |
2452 |
|
2453 |
find the old DLLs looking through the old @INC; |
2454 |
|
2455 |
=item * |
2456 |
|
2457 |
mangle the names according to the scheme of new perl and copy the DLLs to |
2458 |
these names; |
2459 |
|
2460 |
=item * |
2461 |
|
2462 |
edit the internal C<LX> tables of DLL to reflect the change of the name |
2463 |
(probably not needed for Perl extension DLLs, since the internally coded names |
2464 |
are not used for "specific" DLLs, they used only for "global" DLLs). |
2465 |
|
2466 |
=item * |
2467 |
|
2468 |
edit the internal C<IMPORT> tables and change the name of the "old" |
2469 |
F<perl????.dll> to the "new" F<perl????.dll>. |
2470 |
|
2471 |
=back |
2472 |
|
2473 |
=head2 DLL name mangling: 5.6.2 and beyond |
2474 |
|
2475 |
In fact mangling of I<extension> DLLs was done due to misunderstanding |
2476 |
of the OS/2 dynaloading model. OS/2 (effectively) maintains two |
2477 |
different tables of loaded DLL: |
2478 |
|
2479 |
=over |
2480 |
|
2481 |
=item Global DLLs |
2482 |
|
2483 |
those loaded by the base name from C<LIBPATH>; including those |
2484 |
associated at link time; |
2485 |
|
2486 |
=item specific DLLs |
2487 |
|
2488 |
loaded by the full name. |
2489 |
|
2490 |
=back |
2491 |
|
2492 |
When resolving a request for a global DLL, the table of already-loaded |
2493 |
specific DLLs is (effectively) ignored; moreover, specific DLLs are |
2494 |
I<always> loaded from the prescribed path. |
2495 |
|
2496 |
There is/was a minor twist which makes this scheme fragile: what to do |
2497 |
with DLLs loaded from |
2498 |
|
2499 |
=over |
2500 |
|
2501 |
=item C<BEGINLIBPATH> and C<ENDLIBPATH> |
2502 |
|
2503 |
(which depend on the process) |
2504 |
|
2505 |
=item F<.> from C<LIBPATH> |
2506 |
|
2507 |
which I<effectively> depends on the process (although C<LIBPATH> is the |
2508 |
same for all the processes). |
2509 |
|
2510 |
=back |
2511 |
|
2512 |
Unless C<LIBPATHSTRICT> is set to C<T> (and the kernel is after |
2513 |
2000/09/01), such DLLs are considered to be global. When loading a |
2514 |
global DLL it is first looked in the table of already-loaded global |
2515 |
DLLs. Because of this the fact that one executable loaded a DLL from |
2516 |
C<BEGINLIBPATH> and C<ENDLIBPATH>, or F<.> from C<LIBPATH> may affect |
2517 |
I<which> DLL is loaded when I<another> executable requests a DLL with |
2518 |
the same name. I<This> is the reason for version-specific mangling of |
2519 |
the DLL name for perl DLL. |
2520 |
|
2521 |
Since the Perl extension DLLs are always loaded with the full path, |
2522 |
there is no need to mangle their names in a version-specific ways: |
2523 |
their directory already reflects the corresponding version of perl, |
2524 |
and @INC takes into account binary compatibility with older version. |
2525 |
Starting from C<5.6.2> the name mangling scheme is fixed to be the |
2526 |
same as for Perl 5.005_53 (same as in a popular binary release). Thus |
2527 |
new Perls will be able to I<resolve the names> of old extension DLLs |
2528 |
if @INC allows finding their directories. |
2529 |
|
2530 |
However, this still does not guarantee that these DLL may be loaded. |
2531 |
The reason is the mangling of the name of the I<Perl DLL>. And since |
2532 |
the extension DLLs link with the Perl DLL, extension DLLs for older |
2533 |
versions would load an older Perl DLL, and would most probably |
2534 |
segfault (since the data in this DLL is not properly initialized). |
2535 |
|
2536 |
There is a partial workaround (which can be made complete with newer |
2537 |
OS/2 kernels): create a forwarder DLL with the same name as the DLL of |
2538 |
the older version of Perl, which forwards the entry points to the |
2539 |
newer Perl's DLL. Make this DLL accessible on (say) the C<BEGINLIBPATH> of |
2540 |
the new Perl executable. When the new executable accesses old Perl's |
2541 |
extension DLLs, they would request the old Perl's DLL by name, get the |
2542 |
forwarder instead, so effectively will link with the currently running |
2543 |
(new) Perl DLL. |
2544 |
|
2545 |
This may break in two ways: |
2546 |
|
2547 |
=over |
2548 |
|
2549 |
=item * |
2550 |
|
2551 |
Old perl executable is started when a new executable is running has |
2552 |
loaded an extension compiled for the old executable (ouph!). In this |
2553 |
case the old executable will get a forwarder DLL instead of the old |
2554 |
perl DLL, so would link with the new perl DLL. While not directly |
2555 |
fatal, it will behave the same as new executable. This beats the whole |
2556 |
purpose of explicitly starting an old executable. |
2557 |
|
2558 |
=item * |
2559 |
|
2560 |
A new executable loads an extension compiled for the old executable |
2561 |
when an old perl executable is running. In this case the extension |
2562 |
will not pick up the forwarder - with fatal results. |
2563 |
|
2564 |
=back |
2565 |
|
2566 |
With support for C<LIBPATHSTRICT> this may be circumvented - unless |
2567 |
one of DLLs is started from F<.> from C<LIBPATH> (I do not know |
2568 |
whether C<LIBPATHSTRICT> affects this case). |
2569 |
|
2570 |
B<REMARK>. Unless newer kernels allow F<.> in C<BEGINLIBPATH> (older |
2571 |
do not), this mess cannot be completely cleaned. (It turns out that |
2572 |
as of the beginning of 2002, F<.> is not allowed, but F<.\.> is - and |
2573 |
it has the same effect.) |
2574 |
|
2575 |
|
2576 |
B<REMARK>. C<LIBPATHSTRICT>, C<BEGINLIBPATH> and C<ENDLIBPATH> are |
2577 |
not environment variables, although F<cmd.exe> emulates them on C<SET |
2578 |
...> lines. From Perl they may be accessed by |
2579 |
L<Cwd::extLibpath|/Cwd::extLibpath([type])> and |
2580 |
L<Cwd::extLibpath_set|/Cwd::extLibpath_set( path [, type ] )>. |
2581 |
|
2582 |
=head2 DLL forwarder generation |
2583 |
|
2584 |
Assume that the old DLL is named F<perlE0AC.dll> (as is one for |
2585 |
5.005_53), and the new version is 5.6.1. Create a file |
2586 |
F<perl5shim.def-leader> with |
2587 |
|
2588 |
LIBRARY 'perlE0AC' INITINSTANCE TERMINSTANCE |
2589 |
DESCRIPTION '@#perl5-porters@perl.org:5.006001#@ Perl module for 5.00553 -> Perl 5.6.1 forwarder' |
2590 |
CODE LOADONCALL |
2591 |
DATA LOADONCALL NONSHARED MULTIPLE |
2592 |
EXPORTS |
2593 |
|
2594 |
modifying the versions/names as needed. Run |
2595 |
|
2596 |
perl -wnle "next if 0../EXPORTS/; print qq( \"$1\") |
2597 |
if /\"(\w+)\"/" perl5.def >lst |
2598 |
|
2599 |
in the Perl build directory (to make the DLL smaller replace perl5.def |
2600 |
with the definition file for the older version of Perl if present). |
2601 |
|
2602 |
cat perl5shim.def-leader lst >perl5shim.def |
2603 |
gcc -Zomf -Zdll -o perlE0AC.dll perl5shim.def -s -llibperl |
2604 |
|
2605 |
(ignore multiple C<warning L4085>). |
2606 |
|
2607 |
=head2 Threading |
2608 |
|
2609 |
As of release 5.003_01 perl is linked to multithreaded C RTL |
2610 |
DLL. If perl itself is not compiled multithread-enabled, so will not be perl's |
2611 |
malloc(). However, extensions may use multiple thread on their own |
2612 |
risk. |
2613 |
|
2614 |
This was needed to compile C<Perl/Tk> for XFree86-OS/2 out-of-the-box, and |
2615 |
link with DLLs for other useful libraries, which typically are compiled |
2616 |
with C<-Zmt -Zcrtdll>. |
2617 |
|
2618 |
=head2 Calls to external programs |
2619 |
|
2620 |
Due to a popular demand the perl external program calling has been |
2621 |
changed wrt Andreas Kaiser's port. I<If> perl needs to call an |
2622 |
external program I<via shell>, the F<f:/bin/sh.exe> will be called, or |
2623 |
whatever is the override, see L</"C<PERL_SH_DIR>">. |
2624 |
|
2625 |
Thus means that you need to get some copy of a F<sh.exe> as well (I |
2626 |
use one from pdksh). The path F<F:/bin> above is set up automatically during |
2627 |
the build to a correct value on the builder machine, but is |
2628 |
overridable at runtime, |
2629 |
|
2630 |
B<Reasons:> a consensus on C<perl5-porters> was that perl should use |
2631 |
one non-overridable shell per platform. The obvious choices for OS/2 |
2632 |
are F<cmd.exe> and F<sh.exe>. Having perl build itself would be impossible |
2633 |
with F<cmd.exe> as a shell, thus I picked up C<sh.exe>. This assures almost |
2634 |
100% compatibility with the scripts coming from *nix. As an added benefit |
2635 |
this works as well under DOS if you use DOS-enabled port of pdksh |
2636 |
(see L</Prerequisites>). |
2637 |
|
2638 |
B<Disadvantages:> currently F<sh.exe> of pdksh calls external programs |
2639 |
via fork()/exec(), and there is I<no> functioning exec() on |
2640 |
OS/2. exec() is emulated by EMX by an asynchronous call while the caller |
2641 |
waits for child completion (to pretend that the C<pid> did not change). This |
2642 |
means that 1 I<extra> copy of F<sh.exe> is made active via fork()/exec(), |
2643 |
which may lead to some resources taken from the system (even if we do |
2644 |
not count extra work needed for fork()ing). |
2645 |
|
2646 |
Note that this a lesser issue now when we do not spawn F<sh.exe> |
2647 |
unless needed (metachars found). |
2648 |
|
2649 |
One can always start F<cmd.exe> explicitly via |
2650 |
|
2651 |
system 'cmd', '/c', 'mycmd', 'arg1', 'arg2', ... |
2652 |
|
2653 |
If you need to use F<cmd.exe>, and do not want to hand-edit thousands of your |
2654 |
scripts, the long-term solution proposed on p5-p is to have a directive |
2655 |
|
2656 |
use OS2::Cmd; |
2657 |
|
2658 |
which will override system(), exec(), C<``>, and |
2659 |
C<open(,'...|')>. With current perl you may override only system(), |
2660 |
readpipe() - the explicit version of C<``>, and maybe exec(). The code |
2661 |
will substitute the one-argument call to system() by |
2662 |
C<CORE::system('cmd.exe', '/c', shift)>. |
2663 |
|
2664 |
If you have some working code for C<OS2::Cmd>, please send it to me, |
2665 |
I will include it into distribution. I have no need for such a module, so |
2666 |
cannot test it. |
2667 |
|
2668 |
For the details of the current situation with calling external programs, |
2669 |
see L<Starting OSE<sol>2 (and DOS) programs under Perl>. Set us mention a couple |
2670 |
of features: |
2671 |
|
2672 |
=over 4 |
2673 |
|
2674 |
=item * |
2675 |
|
2676 |
External scripts may be called by their basename. Perl will try the same |
2677 |
extensions as when processing B<-S> command-line switch. |
2678 |
|
2679 |
=item * |
2680 |
|
2681 |
External scripts starting with C<#!> or C<extproc > will be executed directly, |
2682 |
without calling the shell, by calling the program specified on the rest of |
2683 |
the first line. |
2684 |
|
2685 |
=back |
2686 |
|
2687 |
=head2 Memory allocation |
2688 |
|
2689 |
Perl uses its own malloc() under OS/2 - interpreters are usually malloc-bound |
2690 |
for speed, but perl is not, since its malloc is lightning-fast. |
2691 |
Perl-memory-usage-tuned benchmarks show that Perl's malloc is 5 times quicker |
2692 |
than EMX one. I do not have convincing data about memory footprint, but |
2693 |
a (pretty random) benchmark showed that Perl's one is 5% better. |
2694 |
|
2695 |
Combination of perl's malloc() and rigid DLL name resolution creates |
2696 |
a special problem with library functions which expect their return value to |
2697 |
be free()d by system's free(). To facilitate extensions which need to call |
2698 |
such functions, system memory-allocation functions are still available with |
2699 |
the prefix C<emx_> added. (Currently only DLL perl has this, it should |
2700 |
propagate to F<perl_.exe> shortly.) |
2701 |
|
2702 |
=head2 Threads |
2703 |
|
2704 |
One can build perl with thread support enabled by providing C<-D usethreads> |
2705 |
option to F<Configure>. Currently OS/2 support of threads is very |
2706 |
preliminary. |
2707 |
|
2708 |
Most notable problems: |
2709 |
|
2710 |
=over 4 |
2711 |
|
2712 |
=item C<COND_WAIT> |
2713 |
|
2714 |
may have a race condition (but probably does not due to edge-triggered |
2715 |
nature of OS/2 Event semaphores). (Needs a reimplementation (in terms of chaining |
2716 |
waiting threads, with the linked list stored in per-thread structure?)?) |
2717 |
|
2718 |
=item F<os2.c> |
2719 |
|
2720 |
has a couple of static variables used in OS/2-specific functions. (Need to be |
2721 |
moved to per-thread structure, or serialized?) |
2722 |
|
2723 |
=back |
2724 |
|
2725 |
Note that these problems should not discourage experimenting, since they |
2726 |
have a low probability of affecting small programs. |
2727 |
|
2728 |
=head1 BUGS |
2729 |
|
2730 |
This description is not updated often (since 5.6.1?), see F<./os2/Changes> |
2731 |
for more info. |
2732 |
|
2733 |
=cut |
2734 |
|
2735 |
OS/2 extensions |
2736 |
~~~~~~~~~~~~~~~ |
2737 |
I include 3 extensions by Andreas Kaiser, OS2::REXX, OS2::UPM, and OS2::FTP, |
2738 |
into my ftp directory, mirrored on CPAN. I made |
2739 |
some minor changes needed to compile them by standard tools. I cannot |
2740 |
test UPM and FTP, so I will appreciate your feedback. Other extensions |
2741 |
there are OS2::ExtAttr, OS2::PrfDB for tied access to EAs and .INI |
2742 |
files - and maybe some other extensions at the time you read it. |
2743 |
|
2744 |
Note that OS2 perl defines 2 pseudo-extension functions |
2745 |
OS2::Copy::copy and DynaLoader::mod2fname (many more now, see |
2746 |
L</Prebuilt methods>). |
2747 |
|
2748 |
The -R switch of older perl is deprecated. If you need to call a REXX code |
2749 |
which needs access to variables, include the call into a REXX compartment |
2750 |
created by |
2751 |
REXX_call {...block...}; |
2752 |
|
2753 |
Two new functions are supported by REXX code, |
2754 |
REXX_eval 'string'; |
2755 |
REXX_eval_with 'string', REXX_function_name => \&perl_sub_reference; |
2756 |
|
2757 |
If you have some other extensions you want to share, send the code to |
2758 |
me. At least two are available: tied access to EA's, and tied access |
2759 |
to system databases. |
2760 |
|
2761 |
=head1 AUTHOR |
2762 |
|
2763 |
Ilya Zakharevich, cpan@ilyaz.org |
2764 |
|
2765 |
=head1 SEE ALSO |
2766 |
|
2767 |
perl(1). |
2768 |
|
2769 |
=cut |
2770 |
|