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