1 If you read this file _as_is_, just ignore the funny characters you
\r
2 see. It is written in the POD format (see pod/perlpod.pod) which is
\r
3 specially designed to be readable as is.
\r
7 perlwin32 - Perl under Win32
\r
11 These are instructions for building Perl under Windows (9x, NT and
\r
16 Before you start, you should glance through the README file
\r
17 found in the top-level directory to which the Perl distribution
\r
18 was extracted. Make sure you read and understand the terms under
\r
19 which this software is being distributed.
\r
21 Also make sure you read L<BUGS AND CAVEATS> below for the
\r
22 known limitations of this port.
\r
24 The INSTALL file in the perl top-level has much information that is
\r
25 only relevant to people building Perl on Unix-like systems. In
\r
26 particular, you can safely ignore any information that talks about
\r
29 You may also want to look at two other options for building
\r
30 a perl that will work on Windows NT: the README.cygwin and
\r
31 README.os2 files, each of which give a different set of rules to
\r
32 build a Perl that will work on Win32 platforms. Those two methods
\r
33 will probably enable you to build a more Unix-compatible perl, but
\r
34 you will also need to download and use various other build-time and
\r
35 run-time support software described in those files.
\r
37 This set of instructions is meant to describe a so-called "native"
\r
38 port of Perl to Win32 platforms. The resulting Perl requires no
\r
39 additional software to run (other than what came with your operating
\r
40 system). Currently, this port is capable of using one of the
\r
41 following compilers:
\r
43 Borland C++ version 5.02 or later
\r
44 Microsoft Visual C++ version 4.2 or later
\r
45 Mingw32 with GCC version 2.95.2 or better
\r
47 The last of these is a high quality freeware compiler. Support
\r
48 for it is still experimental. (Older versions of GCC are known
\r
51 This port currently supports MakeMaker (the set of modules that
\r
52 is used to build extensions to perl). Therefore, you should be
\r
53 able to build and install most extensions found in the CPAN sites.
\r
54 See L<Usage Hints for Perl on Win32> below for general hints about this.
\r
56 =head2 Setting Up Perl on Win32
\r
62 You need a "make" program to build the sources. If you are using
\r
63 Visual C++ under Windows NT or 2000, nmake will work. All other
\r
66 dmake is a freely available make that has very nice macro features
\r
67 and parallelability.
\r
69 A port of dmake for Windows is available from:
\r
71 http://www.cpan.org/authors/id/GSAR/dmake-4.1pl1-win32.zip
\r
73 (This is a fixed version of the original dmake sources obtained from
\r
74 http://www.wticorp.com/dmake/. As of version 4.1PL1, the original
\r
75 sources did not build as shipped and had various other problems.
\r
76 A patch is included in the above fixed version.)
\r
78 Fetch and install dmake somewhere on your path (follow the instructions
\r
79 in the README.NOW file).
\r
81 There exists a minor coexistence problem with dmake and Borland C++
\r
82 compilers. Namely, if a distribution has C files named with mixed
\r
83 case letters, they will be compiled into appropriate .obj-files named
\r
84 with all lowercase letters, and every time dmake is invoked
\r
85 to bring files up to date, it will try to recompile such files again.
\r
86 For example, Tk distribution has a lot of such files, resulting in
\r
87 needless recompiles everytime dmake is invoked. To avoid this, you
\r
88 may use the script "sync_ext.pl" after a successful build. It is
\r
89 available in the win32 subdirectory of the Perl source distribution.
\r
93 Use the default "cmd" shell that comes with NT. Some versions of the
\r
94 popular 4DOS/NT shell have incompatibilities that may cause you trouble.
\r
95 If the build fails under that shell, try building again with the cmd
\r
98 The nmake Makefile also has known incompatibilities with the
\r
99 "command.com" shell that comes with Windows 9x. You will need to
\r
100 use dmake and makefile.mk to build under Windows 9x.
\r
102 The surest way to build it is on Windows NT, using the cmd shell.
\r
104 Make sure the path to the build directory does not contain spaces. The
\r
105 build usually works in this circumstance, but some tests will fail.
\r
109 If you are using the Borland compiler, you will need dmake.
\r
110 (The make that Borland supplies is seriously crippled and will not
\r
111 work for MakeMaker builds.)
\r
113 See L</"Make"> above.
\r
115 =item Microsoft Visual C++
\r
117 The nmake that comes with Visual C++ will suffice for building.
\r
118 You will need to run the VCVARS32.BAT file, usually found somewhere
\r
119 like C:\MSDEV4.2\BIN. This will set your build environment.
\r
121 You can also use dmake to build using Visual C++; provided, however,
\r
122 you set OSRELEASE to "microsft" (or whatever the directory name
\r
123 under which the Visual C dmake configuration lives) in your environment
\r
124 and edit win32/config.vc to change "make=nmake" into "make=dmake". The
\r
125 latter step is only essential if you want to use dmake as your default
\r
126 make for building extensions using MakeMaker.
\r
128 =item Mingw32 with GCC
\r
130 GCC-2.95.2 binaries can be downloaded from:
\r
132 ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/
\r
134 You also need dmake. See L</"Make"> above on how to get it.
\r
136 The GCC-2.95.2 bundle comes with Mingw32 libraries and headers.
\r
138 Make sure you install the binaries that work with MSVCRT.DLL as indicated
\r
139 in the README for the GCC bundle. You may need to set up a few environment
\r
140 variables (usually ran from a batch file).
\r
142 There are a couple of problems with the version of gcc-2.95.2-msvcrt.exe
\r
143 released 7 November 1999:
\r
149 It left out a fix for certain command line quotes. To fix this, be sure
\r
150 to download and install the file fixes/quote-fix-msvcrt.exe from the above
\r
155 The definition of the fpos_t type in stdio.h may be wrong. If your
\r
156 stdio.h has this problem, you will see an exception when running the
\r
157 test t/lib/io_xs.t. To fix this, change the typedef for fpos_t from
\r
158 "long" to "long long" in the file i386-mingw32msvc/include/stdio.h,
\r
163 A potentially simpler to install (but probably soon-to-be-outdated) bundle
\r
164 of the above package with the mentioned fixes already applied is available
\r
167 http://downloads.ActiveState.com/pub/staff/gsar/gcc-2.95.2-msvcrt.zip
\r
168 ftp://ftp.ActiveState.com/pub/staff/gsar/gcc-2.95.2-msvcrt.zip
\r
178 Make sure you are in the "win32" subdirectory under the perl toplevel.
\r
179 This directory contains a "Makefile" that will work with
\r
180 versions of nmake that come with Visual C++, and a dmake "makefile.mk"
\r
181 that will work for all supported compilers. The defaults in the dmake
\r
182 makefile are setup to build using the GCC compiler.
\r
186 Edit the makefile.mk (or Makefile, if you're using nmake) and change
\r
187 the values of INST_DRV and INST_TOP. You can also enable various
\r
188 build flags. These are explained in the makefiles.
\r
190 You will have to make sure that CCTYPE is set correctly and that
\r
191 CCHOME points to wherever you installed your compiler.
\r
193 The default value for CCHOME in the makefiles for Visual C++
\r
194 may not be correct for some versions. Make sure the default exists
\r
197 If you have either the source or a library that contains des_fcrypt(),
\r
198 enable the appropriate option in the makefile. des_fcrypt() is not
\r
199 bundled with the distribution due to US Government restrictions
\r
200 on the export of cryptographic software. Nevertheless, this routine
\r
201 is part of the "libdes" library (written by Eric Young) which is widely
\r
202 available worldwide, usually along with SSLeay (for example,
\r
203 "ftp://fractal.mta.ca/pub/crypto/SSLeay/DES/"). Set CRYPT_SRC to the
\r
204 name of the file that implements des_fcrypt(). Alternatively, if
\r
205 you have built a library that contains des_fcrypt(), you can set
\r
206 CRYPT_LIB to point to the library name. The location above contains
\r
207 many versions of the "libdes" library, all with slightly different
\r
208 implementations of des_fcrypt(). Older versions have a single,
\r
209 self-contained file (fcrypt.c) that implements crypt(), so they may be
\r
210 easier to use. A patch against the fcrypt.c found in libdes-3.06 is
\r
211 in des_fcrypt.patch.
\r
213 Perl will also build without des_fcrypt(), but the crypt() builtin will
\r
216 Be sure to read the instructions near the top of the makefiles carefully.
\r
220 Type "dmake" (or "nmake" if you are using that make).
\r
222 This should build everything. Specifically, it will create perl.exe,
\r
223 perl56.dll at the perl toplevel, and various other extension dll's
\r
224 under the lib\auto directory. If the build fails for any reason, make
\r
225 sure you have done the previous steps correctly.
\r
229 =head2 Testing Perl on Win32
\r
231 Type "dmake test" (or "nmake test"). This will run most of the tests from
\r
232 the testsuite (many tests will be skipped).
\r
234 There should be no test failures when running under Windows NT 4.0 or
\r
235 Windows 2000. Many tests I<will> fail under Windows 9x due to the inferior
\r
238 Some test failures may occur if you use a command shell other than the
\r
239 native "cmd.exe", or if you are building from a path that contains
\r
240 spaces. So don't do that.
\r
242 If you are running the tests from a emacs shell window, you may see
\r
243 failures in op/stat.t. Run "dmake test-notty" in that case.
\r
245 If you're using the Borland compiler, you may see a failure in op/taint.t
\r
246 arising from the inability to find the Borland Runtime DLLs on the system
\r
247 default path. You will need to copy the DLLs reported by the messages
\r
248 from where Borland chose to install it, into the Windows system directory
\r
249 (usually somewhere like C:\WINNT\SYSTEM32) and rerun the test.
\r
251 If you're using Borland compiler versions 5.2 and below, you may run into
\r
252 problems finding the correct header files when building extensions. For
\r
253 example, building the "Tk" extension may fail because both perl and Tk
\r
254 contain a header file called "patchlevel.h". The latest Borland compiler
\r
255 (v5.5) is free of this misbehaviour, and it even supports an
\r
256 option -VI- for backward (bugward) compatibility for using the old Borland
\r
257 search algorithm to locate header files.
\r
259 Please report any other failures as described under L<BUGS AND CAVEATS>.
\r
261 =head2 Installation of Perl on Win32
\r
263 Type "dmake install" (or "nmake install"). This will put the newly
\r
264 built perl and the libraries under whatever C<INST_TOP> points to in the
\r
265 Makefile. It will also install the pod documentation under
\r
266 C<$INST_TOP\$VERSION\lib\pod> and HTML versions of the same under
\r
267 C<$INST_TOP\$VERSION\lib\pod\html>. To use the Perl you just installed,
\r
268 you will need to add two components to your PATH environment variable,
\r
269 C<$INST_TOP\$VERSION\bin> and C<$INST_TOP\$VERSION\bin\$ARCHNAME>.
\r
272 set PATH c:\perl\5.6.0\bin;c:\perl\5.6.0\bin\MSWin32-x86;%PATH%
\r
274 If you opt to comment out INST_VER and INST_ARCH in the makefiles, the
\r
275 installation structure is much simpler. In that case, it will be
\r
276 sufficient to add a single entry to the path, for instance:
\r
278 set PATH c:\perl\bin;%PATH%
\r
280 =head2 Usage Hints for Perl on Win32
\r
284 =item Environment Variables
\r
286 The installation paths that you set during the build get compiled
\r
287 into perl, so you don't have to do anything additional to start
\r
288 using that perl (except add its location to your PATH variable).
\r
290 If you put extensions in unusual places, you can set PERL5LIB
\r
291 to a list of paths separated by semicolons where you want perl
\r
292 to look for libraries. Look for descriptions of other environment
\r
293 variables you can set in L<perlrun>.
\r
295 You can also control the shell that perl uses to run system() and
\r
296 backtick commands via PERL5SHELL. See L<perlrun>.
\r
298 Perl does not depend on the registry, but it can look up certain default
\r
299 values if you choose to put them there. Perl attempts to read entries from
\r
300 C<HKEY_CURRENT_USER\Software\Perl> and C<HKEY_LOCAL_MACHINE\Software\Perl>.
\r
301 Entries in the former override entries in the latter. One or more of the
\r
302 following entries (of type REG_SZ or REG_EXPAND_SZ) may be set:
\r
304 lib-$] version-specific standard library path to add to @INC
\r
305 lib standard library path to add to @INC
\r
306 sitelib-$] version-specific site library path to add to @INC
\r
307 sitelib site library path to add to @INC
\r
308 vendorlib-$] version-specific vendor library path to add to @INC
\r
309 vendorlib vendor library path to add to @INC
\r
310 PERL* fallback for all %ENV lookups that begin with "PERL"
\r
312 Note the C<$]> in the above is not literal. Substitute whatever version
\r
313 of perl you want to honor that entry, e.g. C<5.6.0>. Paths must be
\r
314 separated with semicolons, as usual on win32.
\r
316 =item File Globbing
\r
318 By default, perl handles file globbing using the File::Glob extension,
\r
319 which provides portable globbing.
\r
321 If you want perl to use globbing that emulates the quirks of DOS
\r
322 filename conventions, you might want to consider using File::DosGlob
\r
323 to override the internal glob() implementation. See L<File::DosGlob> for
\r
326 =item Using perl from the command line
\r
328 If you are accustomed to using perl from various command-line
\r
329 shells found in UNIX environments, you will be less than pleased
\r
330 with what Windows offers by way of a command shell.
\r
332 The crucial thing to understand about the Windows environment is that
\r
333 the command line you type in is processed twice before Perl sees it.
\r
334 First, your command shell (usually CMD.EXE on Windows NT, and
\r
335 COMMAND.COM on Windows 9x) preprocesses the command line, to handle
\r
336 redirection, environment variable expansion, and location of the
\r
337 executable to run. Then, the perl executable splits the remaining
\r
338 command line into individual arguments, using the C runtime library
\r
339 upon which Perl was built.
\r
341 It is particularly important to note that neither the shell nor the C
\r
342 runtime do any wildcard expansions of command-line arguments (so
\r
343 wildcards need not be quoted). Also, the quoting behaviours of the
\r
344 shell and the C runtime are rudimentary at best (and may, if you are
\r
345 using a non-standard shell, be inconsistent). The only (useful) quote
\r
346 character is the double quote ("). It can be used to protect spaces
\r
347 and other special characters in arguments.
\r
349 The Windows NT documentation has almost no description of how the
\r
350 quoting rules are implemented, but here are some general observations
\r
351 based on experiments: The C runtime breaks arguments at spaces and
\r
352 passes them to programs in argc/argv. Double quotes can be used to
\r
353 prevent arguments with spaces in them from being split up. You can
\r
354 put a double quote in an argument by escaping it with a backslash and
\r
355 enclosing the whole argument within double quotes. The backslash and
\r
356 the pair of double quotes surrounding the argument will be stripped by
\r
359 The file redirection characters "<", ">", and "|" can be quoted by
\r
360 double quotes (although there are suggestions that this may not always
\r
361 be true). Single quotes are not treated as quotes by the shell or
\r
362 the C runtime, they don't get stripped by the shell (just to make
\r
363 this type of quoting completely useless). The caret "^" has also
\r
364 been observed to behave as a quoting character, but this appears
\r
365 to be a shell feature, and the caret is not stripped from the command
\r
366 line, so Perl still sees it (and the C runtime phase does not treat
\r
367 the caret as a quote character).
\r
369 Here are some examples of usage of the "cmd" shell:
\r
371 This prints two doublequotes:
\r
373 perl -e "print '\"\"' "
\r
375 This does the same:
\r
377 perl -e "print \"\\\"\\\"\" "
\r
379 This prints "bar" and writes "foo" to the file "blurch":
\r
381 perl -e "print 'foo'; print STDERR 'bar'" > blurch
\r
383 This prints "foo" ("bar" disappears into nowhereland):
\r
385 perl -e "print 'foo'; print STDERR 'bar'" 2> nul
\r
387 This prints "bar" and writes "foo" into the file "blurch":
\r
389 perl -e "print 'foo'; print STDERR 'bar'" 1> blurch
\r
391 This pipes "foo" to the "less" pager and prints "bar" on the console:
\r
393 perl -e "print 'foo'; print STDERR 'bar'" | less
\r
395 This pipes "foo\nbar\n" to the less pager:
\r
397 perl -le "print 'foo'; print STDERR 'bar'" 2>&1 | less
\r
399 This pipes "foo" to the pager and writes "bar" in the file "blurch":
\r
401 perl -e "print 'foo'; print STDERR 'bar'" 2> blurch | less
\r
404 Discovering the usefulness of the "command.com" shell on Windows 9x
\r
405 is left as an exercise to the reader :)
\r
407 One particularly pernicious problem with the 4NT command shell for
\r
408 Windows NT is that it (nearly) always treats a % character as indicating
\r
409 that environment variable expansion is needed. Under this shell, it is
\r
410 therefore important to always double any % characters which you want
\r
411 Perl to see (for example, for hash variables), even when they are
\r
414 =item Building Extensions
\r
416 The Comprehensive Perl Archive Network (CPAN) offers a wealth
\r
417 of extensions, some of which require a C compiler to build.
\r
418 Look in http://www.cpan.org/ for more information on CPAN.
\r
420 Note that not all of the extensions available from CPAN may work
\r
421 in the Win32 environment; you should check the information at
\r
422 http://testers.cpan.org/ before investing too much effort into
\r
423 porting modules that don't readily build.
\r
425 Most extensions (whether they require a C compiler or not) can
\r
426 be built, tested and installed with the standard mantra:
\r
433 where $MAKE is whatever 'make' program you have configured perl to
\r
434 use. Use "perl -V:make" to find out what this is. Some extensions
\r
435 may not provide a testsuite (so "$MAKE test" may not do anything or
\r
436 fail), but most serious ones do.
\r
438 It is important that you use a supported 'make' program, and
\r
439 ensure Config.pm knows about it. If you don't have nmake, you can
\r
440 either get dmake from the location mentioned earlier or get an
\r
441 old version of nmake reportedly available from:
\r
443 ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
\r
445 Another option is to use the make written in Perl, available from
\r
448 http://www.cpan.org/authors/id/NI-S/Make-0.03.tar.gz
\r
450 You may also use dmake. See L</"Make"> above on how to get it.
\r
452 Note that MakeMaker actually emits makefiles with different syntax
\r
453 depending on what 'make' it thinks you are using. Therefore, it is
\r
454 important that one of the following values appears in Config.pm:
\r
456 make='nmake' # MakeMaker emits nmake syntax
\r
457 make='dmake' # MakeMaker emits dmake syntax
\r
458 any other value # MakeMaker emits generic make syntax
\r
459 (e.g GNU make, or Perl make)
\r
461 If the value doesn't match the 'make' program you want to use,
\r
462 edit Config.pm to fix it.
\r
464 If a module implements XSUBs, you will need one of the supported
\r
465 C compilers. You must make sure you have set up the environment for
\r
466 the compiler for command-line compilation.
\r
468 If a module does not build for some reason, look carefully for
\r
469 why it failed, and report problems to the module author. If
\r
470 it looks like the extension building support is at fault, report
\r
471 that with full details of how the build failed using the perlbug
\r
474 =item Command-line Wildcard Expansion
\r
476 The default command shells on DOS descendant operating systems (such
\r
477 as they are) usually do not expand wildcard arguments supplied to
\r
478 programs. They consider it the application's job to handle that.
\r
479 This is commonly achieved by linking the application (in our case,
\r
480 perl) with startup code that the C runtime libraries usually provide.
\r
481 However, doing that results in incompatible perl versions (since the
\r
482 behavior of the argv expansion code differs depending on the
\r
483 compiler, and it is even buggy on some compilers). Besides, it may
\r
484 be a source of frustration if you use such a perl binary with an
\r
485 alternate shell that *does* expand wildcards.
\r
487 Instead, the following solution works rather well. The nice things
\r
488 about it are 1) you can start using it right away; 2) it is more
\r
489 powerful, because it will do the right thing with a pattern like
\r
490 */*/*.c; 3) you can decide whether you do/don't want to use it; and
\r
491 4) you can extend the method to add any customizations (or even
\r
492 entirely different kinds of wildcard expansion).
\r
494 C:\> copy con c:\perl\lib\Wild.pm
\r
495 # Wild.pm - emulate shell @ARGV expansion on shells that don't
\r
498 my @g = File::DosGlob::glob($_) if /[*?]/;
\r
503 C:\> set PERL5OPT=-MWild
\r
504 C:\> perl -le "for (@ARGV) { print }" */*/perl*.c
\r
506 p4view/perl/perlio.c
\r
507 p4view/perl/perly.c
\r
508 perl5.005/win32/perlglob.c
\r
509 perl5.005/win32/perllib.c
\r
510 perl5.005/win32/perlglob.c
\r
511 perl5.005/win32/perllib.c
\r
512 perl5.005/win32/perlglob.c
\r
513 perl5.005/win32/perllib.c
\r
515 Note there are two distinct steps there: 1) You'll have to create
\r
516 Wild.pm and put it in your perl lib directory. 2) You'll need to
\r
517 set the PERL5OPT environment variable. If you want argv expansion
\r
518 to be the default, just set PERL5OPT in your default startup
\r
521 If you are using the Visual C compiler, you can get the C runtime's
\r
522 command line wildcard expansion built into perl binary. The resulting
\r
523 binary will always expand unquoted command lines, which may not be
\r
524 what you want if you use a shell that does that for you. The expansion
\r
525 done is also somewhat less powerful than the approach suggested above.
\r
527 =item Win32 Specific Extensions
\r
529 A number of extensions specific to the Win32 platform are available
\r
530 from CPAN. You may find that many of these extensions are meant to
\r
531 be used under the Activeware port of Perl, which used to be the only
\r
532 native port for the Win32 platform. Since the Activeware port does not
\r
533 have adequate support for Perl's extension building tools, these
\r
534 extensions typically do not support those tools either and, therefore,
\r
535 cannot be built using the generic steps shown in the previous section.
\r
537 To ensure smooth transitioning of existing code that uses the
\r
538 ActiveState port, there is a bundle of Win32 extensions that contains
\r
539 all of the ActiveState extensions and most other Win32 extensions from
\r
540 CPAN in source form, along with many added bugfixes, and with MakeMaker
\r
541 support. This bundle is available at:
\r
543 http://www.cpan.org/authors/id/GSAR/libwin32-0.151.zip
\r
545 See the README in that distribution for building and installation
\r
546 instructions. Look for later versions that may be available at the
\r
549 =item Running Perl Scripts
\r
551 Perl scripts on UNIX use the "#!" (a.k.a "shebang") line to
\r
552 indicate to the OS that it should execute the file using perl.
\r
553 Win32 has no comparable means to indicate arbitrary files are
\r
556 Instead, all available methods to execute plain text files on
\r
557 Win32 rely on the file "extension". There are three methods
\r
558 to use this to execute perl scripts:
\r
564 There is a facility called "file extension associations" that will
\r
565 work in Windows NT 4.0. This can be manipulated via the two
\r
566 commands "assoc" and "ftype" that come standard with Windows NT
\r
567 4.0. Type "ftype /?" for a complete example of how to set this
\r
568 up for perl scripts (Say what? You thought Windows NT wasn't
\r
573 Since file associations don't work everywhere, and there are
\r
574 reportedly bugs with file associations where it does work, the
\r
575 old method of wrapping the perl script to make it look like a
\r
576 regular batch file to the OS, may be used. The install process
\r
577 makes available the "pl2bat.bat" script which can be used to wrap
\r
578 perl scripts into batch files. For example:
\r
582 will create the file "FOO.BAT". Note "pl2bat" strips any
\r
583 .pl suffix and adds a .bat suffix to the generated file.
\r
585 If you use the 4DOS/NT or similar command shell, note that
\r
586 "pl2bat" uses the "%*" variable in the generated batch file to
\r
587 refer to all the command line arguments, so you may need to make
\r
588 sure that construct works in batch files. As of this writing,
\r
589 4DOS/NT users will need a "ParameterChar = *" statement in their
\r
590 4NT.INI file or will need to execute "setdos /p*" in the 4DOS/NT
\r
591 startup file to enable this to work.
\r
595 Using "pl2bat" has a few problems: the file name gets changed,
\r
596 so scripts that rely on C<$0> to find what they must do may not
\r
597 run properly; running "pl2bat" replicates the contents of the
\r
598 original script, and so this process can be maintenance intensive
\r
599 if the originals get updated often. A different approach that
\r
600 avoids both problems is possible.
\r
602 A script called "runperl.bat" is available that can be copied
\r
603 to any filename (along with the .bat suffix). For example,
\r
604 if you call it "foo.bat", it will run the file "foo" when it is
\r
605 executed. Since you can run batch files on Win32 platforms simply
\r
606 by typing the name (without the extension), this effectively
\r
607 runs the file "foo", when you type either "foo" or "foo.bat".
\r
608 With this method, "foo.bat" can even be in a different location
\r
609 than the file "foo", as long as "foo" is available somewhere on
\r
610 the PATH. If your scripts are on a filesystem that allows symbolic
\r
611 links, you can even avoid copying "runperl.bat".
\r
613 Here's a diversion: copy "runperl.bat" to "runperl", and type
\r
614 "runperl". Explain the observed behavior, or lack thereof. :)
\r
615 Hint: .gnidnats llits er'uoy fi ,"lrepnur" eteled :tniH
\r
619 =item Miscellaneous Things
\r
621 A full set of HTML documentation is installed, so you should be
\r
622 able to use it if you have a web browser installed on your
\r
625 C<perldoc> is also a useful tool for browsing information contained
\r
626 in the documentation, especially in conjunction with a pager
\r
627 like C<less> (recent versions of which have Win32 support). You may
\r
628 have to set the PAGER environment variable to use a specific pager.
\r
629 "perldoc -f foo" will print information about the perl operator
\r
632 If you find bugs in perl, you can run C<perlbug> to create a
\r
633 bug report (you may have to send it manually if C<perlbug> cannot
\r
634 find a mailer on your system).
\r
638 =head1 BUGS AND CAVEATS
\r
640 Norton AntiVirus interferes with the build process, particularly if
\r
641 set to "AutoProtect, All Files, when Opened". Unlike large applications
\r
642 the perl build process opens and modifies a lot of files. Having the
\r
643 the AntiVirus scan each and every one slows build the process significantly.
\r
644 Worse, with PERLIO=stdio the build process fails with peculiar messages
\r
645 as the virus checker interacts badly with miniperl.exe writing configure
\r
646 files (it seems to either catch file part written and treat it as suspicious,
\r
647 or virus checker may have it "locked" in a way which inhibits miniperl
\r
648 updating it). The build does complete with
\r
652 but that may be just luck. Other AntiVirus software may have similar issues.
\r
654 Some of the built-in functions do not act exactly as documented in
\r
655 L<perlfunc>, and a few are not implemented at all. To avoid
\r
656 surprises, particularly if you have had prior exposure to Perl
\r
657 in other operating environments or if you intend to write code
\r
658 that will be portable to other environments. See L<perlport>
\r
659 for a reasonably definitive list of these differences.
\r
661 Not all extensions available from CPAN may build or work properly
\r
662 in the Win32 environment. See L</"Building Extensions">.
\r
664 Most C<socket()> related calls are supported, but they may not
\r
665 behave as on Unix platforms. See L<perlport> for the full list.
\r
667 Signal handling may not behave as on Unix platforms (where it
\r
668 doesn't exactly "behave", either :). For instance, calling C<die()>
\r
669 or C<exit()> from signal handlers will cause an exception, since most
\r
670 implementations of C<signal()> on Win32 are severely crippled.
\r
671 Thus, signals may work only for simple things like setting a flag
\r
672 variable in the handler. Using signals under this port should
\r
673 currently be considered unsupported.
\r
675 Please send detailed descriptions of any problems and solutions that
\r
676 you may find to <F<perlbug@perl.com>>, along with the output produced
\r
683 =item Gary Ng E<lt>71564.1743@CompuServe.COME<gt>
\r
685 =item Gurusamy Sarathy E<lt>gsar@activestate.comE<gt>
\r
687 =item Nick Ing-Simmons E<lt>nick@ing-simmons.netE<gt>
\r
691 This document is maintained by Gurusamy Sarathy.
\r
699 This port was originally contributed by Gary Ng around 5.003_24,
\r
700 and borrowed from the Hip Communications port that was available
\r
701 at the time. Various people have made numerous and sundry hacks
\r
704 Borland support was added in 5.004_01 (Gurusamy Sarathy).
\r
706 GCC/mingw32 support was added in 5.005 (Nick Ing-Simmons).
\r
708 Support for PERL_OBJECT was added in 5.005 (ActiveState Tool Corp).
\r
710 Support for fork() emulation was added in 5.6 (ActiveState Tool Corp).
\r
712 Win9x support was added in 5.6 (Benjamin Stuhl).
\r
714 Last updated: 1 April 2001
\r
https://perl5.git.perl.org / perl5.git / blob