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