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 Windows
\r
11 These are instructions for building Perl under Windows 9x/NT/2000/XP
\r
12 on the Intel x86 and Itanium architectures.
\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. This includes both 32-bit and
\r
39 64-bit Windows operating systems. The resulting Perl requires no
\r
40 additional software to run (other than what came with your operating
\r
41 system). Currently, this port is capable of using one of the
\r
42 following compilers on the Intel x86 architecture:
\r
44 Borland C++ version 5.02 or later
\r
45 Microsoft Visual C++ version 4.2 or later
\r
46 Mingw32 with GCC version 2.95.2 or better
\r
48 The last of these is a high quality freeware compiler. Support
\r
49 for it is still experimental. (Older versions of GCC are known
\r
52 This port can also be built on the Intel IA64 using:
\r
54 Microsoft Platform SDK Nov 2001 (64-bit compiler and tools)
\r
56 The MS Platform SDK can be downloaded from http://www.microsoft.com/.
\r
58 This port fully supports MakeMaker (the set of modules that
\r
59 is used to build extensions to perl). Therefore, you should be
\r
60 able to build and install most extensions found in the CPAN sites.
\r
61 See L<Usage Hints for Perl on Win32> below for general hints about this.
\r
63 =head2 Setting Up Perl on Win32
\r
69 You need a "make" program to build the sources. If you are using
\r
70 Visual C++ or the Platform SDK tools under Windows NT/2000/XP, nmake
\r
71 will work. All other builds need dmake.
\r
73 dmake is a freely available make that has very nice macro features
\r
74 and parallelability.
\r
76 A port of dmake for Windows is available from:
\r
78 http://www.cpan.org/authors/id/GSAR/dmake-4.1pl1-win32.zip
\r
80 (This is a fixed version of the original dmake sources obtained from
\r
81 http://www.wticorp.com/ As of version 4.1PL1, the original
\r
82 sources did not build as shipped and had various other problems.
\r
83 A patch is included in the above fixed version.)
\r
85 Fetch and install dmake somewhere on your path (follow the instructions
\r
86 in the README.NOW file).
\r
88 There exists a minor coexistence problem with dmake and Borland C++
\r
89 compilers. Namely, if a distribution has C files named with mixed
\r
90 case letters, they will be compiled into appropriate .obj-files named
\r
91 with all lowercase letters, and every time dmake is invoked
\r
92 to bring files up to date, it will try to recompile such files again.
\r
93 For example, Tk distribution has a lot of such files, resulting in
\r
94 needless recompiles every time dmake is invoked. To avoid this, you
\r
95 may use the script "sync_ext.pl" after a successful build. It is
\r
96 available in the win32 subdirectory of the Perl source distribution.
\r
100 Use the default "cmd" shell that comes with NT. Some versions of the
\r
101 popular 4DOS/NT shell have incompatibilities that may cause you trouble.
\r
102 If the build fails under that shell, try building again with the cmd
\r
105 The nmake Makefile also has known incompatibilities with the
\r
106 "command.com" shell that comes with Windows 9x. You will need to
\r
107 use dmake and makefile.mk to build under Windows 9x.
\r
109 The surest way to build it is on Windows NT/2000/XP, using the cmd shell.
\r
111 Make sure the path to the build directory does not contain spaces. The
\r
112 build usually works in this circumstance, but some tests will fail.
\r
116 If you are using the Borland compiler, you will need dmake.
\r
117 (The make that Borland supplies is seriously crippled and will not
\r
118 work for MakeMaker builds.)
\r
120 See L</"Make"> above.
\r
122 =item Microsoft Visual C++
\r
124 The nmake that comes with Visual C++ will suffice for building.
\r
125 You will need to run the VCVARS32.BAT file, usually found somewhere
\r
126 like C:\MSDEV4.2\BIN. This will set your build environment.
\r
128 You can also use dmake to build using Visual C++; provided, however,
\r
129 you set OSRELEASE to "microsft" (or whatever the directory name
\r
130 under which the Visual C dmake configuration lives) in your environment
\r
131 and edit win32/config.vc to change "make=nmake" into "make=dmake". The
\r
132 latter step is only essential if you want to use dmake as your default
\r
133 make for building extensions using MakeMaker.
\r
135 =item Microsoft Platform SDK 64-bit Compiler
\r
137 The nmake that comes with the Platform SDK will suffice for building
\r
138 Perl. Make sure you are building within one of the "Build Environment"
\r
139 shells available after you install the Platform SDK from the Start Menu.
\r
141 =item Mingw32 with GCC
\r
143 GCC-2.95.2 binaries can be downloaded from:
\r
145 ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/
\r
147 You also need dmake. See L</"Make"> above on how to get it.
\r
149 The GCC-2.95.2 bundle comes with Mingw32 libraries and headers.
\r
151 Make sure you install the binaries that work with MSVCRT.DLL as indicated
\r
152 in the README for the GCC bundle. You may need to set up a few environment
\r
153 variables (usually ran from a batch file).
\r
155 There are a couple of problems with the version of gcc-2.95.2-msvcrt.exe
\r
156 released 7 November 1999:
\r
162 It left out a fix for certain command line quotes. To fix this, be sure
\r
163 to download and install the file fixes/quote-fix-msvcrt.exe from the above
\r
168 The definition of the fpos_t type in stdio.h may be wrong. If your
\r
169 stdio.h has this problem, you will see an exception when running the
\r
170 test t/lib/io_xs.t. To fix this, change the typedef for fpos_t from
\r
171 "long" to "long long" in the file i386-mingw32msvc/include/stdio.h,
\r
176 A potentially simpler to install (but probably soon-to-be-outdated) bundle
\r
177 of the above package with the mentioned fixes already applied is available
\r
180 http://downloads.ActiveState.com/pub/staff/gsar/gcc-2.95.2-msvcrt.zip
\r
181 ftp://ftp.ActiveState.com/pub/staff/gsar/gcc-2.95.2-msvcrt.zip
\r
191 Make sure you are in the "win32" subdirectory under the perl toplevel.
\r
192 This directory contains a "Makefile" that will work with
\r
193 versions of nmake that come with Visual C++ or the Platform SDK, and
\r
194 a dmake "makefile.mk" that will work for all supported compilers. The
\r
195 defaults in the dmake makefile are setup to build using the GCC compiler.
\r
199 Edit the makefile.mk (or Makefile, if you're using nmake) and change
\r
200 the values of INST_DRV and INST_TOP. You can also enable various
\r
201 build flags. These are explained in the makefiles.
\r
203 You will have to make sure that CCTYPE is set correctly and that
\r
204 CCHOME points to wherever you installed your compiler.
\r
206 The default value for CCHOME in the makefiles for Visual C++
\r
207 may not be correct for some versions. Make sure the default exists
\r
210 If you have either the source or a library that contains des_fcrypt(),
\r
211 enable the appropriate option in the makefile. des_fcrypt() is not
\r
212 bundled with the distribution due to US Government restrictions
\r
213 on the export of cryptographic software. Nevertheless, this routine
\r
214 is part of the "libdes" library (written by Eric Young) which is widely
\r
215 available worldwide, usually along with SSLeay ( for example,
\r
216 ftp://ftp.funet.fi/pub/crypt/mirrors/dsi/libdes/ ). Set CRYPT_SRC to the
\r
217 name of the file that implements des_fcrypt(). Alternatively, if
\r
218 you have built a library that contains des_fcrypt(), you can set
\r
219 CRYPT_LIB to point to the library name. The location above contains
\r
220 many versions of the "libdes" library, all with slightly different
\r
221 implementations of des_fcrypt(). Older versions have a single,
\r
222 self-contained file (fcrypt.c) that implements crypt(), so they may be
\r
223 easier to use. A patch against the fcrypt.c found in libdes-3.06 is
\r
224 in des_fcrypt.patch.
\r
226 An easier alternative may be to get the pre-patched and ready-to-use
\r
227 fcrypt.c that can be found here:
\r
229 http://downloads.ActiveState.com/pub/staff/gsar/fcrypt.c
\r
230 ftp://ftp.ActiveState.com/pub/staff/gsar/fcrypt.c
\r
232 Perl will also build without des_fcrypt(), but the crypt() builtin will
\r
235 Be sure to read the instructions near the top of the makefiles carefully.
\r
239 Type "dmake" (or "nmake" if you are using that make).
\r
241 This should build everything. Specifically, it will create perl.exe,
\r
242 perl58.dll at the perl toplevel, and various other extension dll's
\r
243 under the lib\auto directory. If the build fails for any reason, make
\r
244 sure you have done the previous steps correctly.
\r
248 =head2 Testing Perl on Win32
\r
250 Type "dmake test" (or "nmake test"). This will run most of the tests from
\r
251 the testsuite (many tests will be skipped).
\r
253 There should be no test failures when running under Windows NT/2000/XP.
\r
254 Many tests I<will> fail under Windows 9x due to the inferior command shell.
\r
256 Some test failures may occur if you use a command shell other than the
\r
257 native "cmd.exe", or if you are building from a path that contains
\r
258 spaces. So don't do that.
\r
260 If you are running the tests from a emacs shell window, you may see
\r
261 failures in op/stat.t. Run "dmake test-notty" in that case.
\r
263 If you're using the Borland compiler, you may see a failure in op/taint.t
\r
264 arising from the inability to find the Borland Runtime DLLs on the system
\r
265 default path. You will need to copy the DLLs reported by the messages
\r
266 from where Borland chose to install it, into the Windows system directory
\r
267 (usually somewhere like C:\WINNT\SYSTEM32) and rerun the test.
\r
269 If you're using Borland compiler versions 5.2 and below, you may run into
\r
270 problems finding the correct header files when building extensions. For
\r
271 example, building the "Tk" extension may fail because both perl and Tk
\r
272 contain a header file called "patchlevel.h". The latest Borland compiler
\r
273 (v5.5) is free of this misbehaviour, and it even supports an
\r
274 option -VI- for backward (bugward) compatibility for using the old Borland
\r
275 search algorithm to locate header files.
\r
277 Please report any other failures as described under L<BUGS AND CAVEATS>.
\r
279 =head2 Installation of Perl on Win32
\r
281 Type "dmake install" (or "nmake install"). This will put the newly
\r
282 built perl and the libraries under whatever C<INST_TOP> points to in the
\r
283 Makefile. It will also install the pod documentation under
\r
284 C<$INST_TOP\$VERSION\lib\pod> and HTML versions of the same under
\r
285 C<$INST_TOP\$VERSION\lib\pod\html>. To use the Perl you just installed,
\r
286 you will need to add two components to your PATH environment variable,
\r
287 C<$INST_TOP\$VERSION\bin> and C<$INST_TOP\$VERSION\bin\$ARCHNAME>.
\r
290 set PATH c:\perl\5.6.0\bin;c:\perl\5.6.0\bin\MSWin32-x86;%PATH%
\r
292 If you opt to comment out INST_VER and INST_ARCH in the makefiles, the
\r
293 installation structure is much simpler. In that case, it will be
\r
294 sufficient to add a single entry to the path, for instance:
\r
296 set PATH c:\perl\bin;%PATH%
\r
298 =head2 Usage Hints for Perl on Win32
\r
302 =item Environment Variables
\r
304 The installation paths that you set during the build get compiled
\r
305 into perl, so you don't have to do anything additional to start
\r
306 using that perl (except add its location to your PATH variable).
\r
308 If you put extensions in unusual places, you can set PERL5LIB
\r
309 to a list of paths separated by semicolons where you want perl
\r
310 to look for libraries. Look for descriptions of other environment
\r
311 variables you can set in L<perlrun>.
\r
313 You can also control the shell that perl uses to run system() and
\r
314 backtick commands via PERL5SHELL. See L<perlrun>.
\r
316 Perl does not depend on the registry, but it can look up certain default
\r
317 values if you choose to put them there. Perl attempts to read entries from
\r
318 C<HKEY_CURRENT_USER\Software\Perl> and C<HKEY_LOCAL_MACHINE\Software\Perl>.
\r
319 Entries in the former override entries in the latter. One or more of the
\r
320 following entries (of type REG_SZ or REG_EXPAND_SZ) may be set:
\r
322 lib-$] version-specific standard library path to add to @INC
\r
323 lib standard library path to add to @INC
\r
324 sitelib-$] version-specific site library path to add to @INC
\r
325 sitelib site library path to add to @INC
\r
326 vendorlib-$] version-specific vendor library path to add to @INC
\r
327 vendorlib vendor library path to add to @INC
\r
328 PERL* fallback for all %ENV lookups that begin with "PERL"
\r
330 Note the C<$]> in the above is not literal. Substitute whatever version
\r
331 of perl you want to honor that entry, e.g. C<5.6.0>. Paths must be
\r
332 separated with semicolons, as usual on win32.
\r
334 =item File Globbing
\r
336 By default, perl handles file globbing using the File::Glob extension,
\r
337 which provides portable globbing.
\r
339 If you want perl to use globbing that emulates the quirks of DOS
\r
340 filename conventions, you might want to consider using File::DosGlob
\r
341 to override the internal glob() implementation. See L<File::DosGlob> for
\r
344 =item Using perl from the command line
\r
346 If you are accustomed to using perl from various command-line
\r
347 shells found in UNIX environments, you will be less than pleased
\r
348 with what Windows offers by way of a command shell.
\r
350 The crucial thing to understand about the Windows environment is that
\r
351 the command line you type in is processed twice before Perl sees it.
\r
352 First, your command shell (usually CMD.EXE on Windows NT, and
\r
353 COMMAND.COM on Windows 9x) preprocesses the command line, to handle
\r
354 redirection, environment variable expansion, and location of the
\r
355 executable to run. Then, the perl executable splits the remaining
\r
356 command line into individual arguments, using the C runtime library
\r
357 upon which Perl was built.
\r
359 It is particularly important to note that neither the shell nor the C
\r
360 runtime do any wildcard expansions of command-line arguments (so
\r
361 wildcards need not be quoted). Also, the quoting behaviours of the
\r
362 shell and the C runtime are rudimentary at best (and may, if you are
\r
363 using a non-standard shell, be inconsistent). The only (useful) quote
\r
364 character is the double quote ("). It can be used to protect spaces
\r
365 and other special characters in arguments.
\r
367 The Windows NT documentation has almost no description of how the
\r
368 quoting rules are implemented, but here are some general observations
\r
369 based on experiments: The C runtime breaks arguments at spaces and
\r
370 passes them to programs in argc/argv. Double quotes can be used to
\r
371 prevent arguments with spaces in them from being split up. You can
\r
372 put a double quote in an argument by escaping it with a backslash and
\r
373 enclosing the whole argument within double quotes. The backslash and
\r
374 the pair of double quotes surrounding the argument will be stripped by
\r
377 The file redirection characters "<", ">", and "|" can be quoted by
\r
378 double quotes (although there are suggestions that this may not always
\r
379 be true). Single quotes are not treated as quotes by the shell or
\r
380 the C runtime, they don't get stripped by the shell (just to make
\r
381 this type of quoting completely useless). The caret "^" has also
\r
382 been observed to behave as a quoting character, but this appears
\r
383 to be a shell feature, and the caret is not stripped from the command
\r
384 line, so Perl still sees it (and the C runtime phase does not treat
\r
385 the caret as a quote character).
\r
387 Here are some examples of usage of the "cmd" shell:
\r
389 This prints two doublequotes:
\r
391 perl -e "print '\"\"' "
\r
393 This does the same:
\r
395 perl -e "print \"\\\"\\\"\" "
\r
397 This prints "bar" and writes "foo" to the file "blurch":
\r
399 perl -e "print 'foo'; print STDERR 'bar'" > blurch
\r
401 This prints "foo" ("bar" disappears into nowhereland):
\r
403 perl -e "print 'foo'; print STDERR 'bar'" 2> nul
\r
405 This prints "bar" and writes "foo" into the file "blurch":
\r
407 perl -e "print 'foo'; print STDERR 'bar'" 1> blurch
\r
409 This pipes "foo" to the "less" pager and prints "bar" on the console:
\r
411 perl -e "print 'foo'; print STDERR 'bar'" | less
\r
413 This pipes "foo\nbar\n" to the less pager:
\r
415 perl -le "print 'foo'; print STDERR 'bar'" 2>&1 | less
\r
417 This pipes "foo" to the pager and writes "bar" in the file "blurch":
\r
419 perl -e "print 'foo'; print STDERR 'bar'" 2> blurch | less
\r
422 Discovering the usefulness of the "command.com" shell on Windows 9x
\r
423 is left as an exercise to the reader :)
\r
425 One particularly pernicious problem with the 4NT command shell for
\r
426 Windows NT is that it (nearly) always treats a % character as indicating
\r
427 that environment variable expansion is needed. Under this shell, it is
\r
428 therefore important to always double any % characters which you want
\r
429 Perl to see (for example, for hash variables), even when they are
\r
432 =item Building Extensions
\r
434 The Comprehensive Perl Archive Network (CPAN) offers a wealth
\r
435 of extensions, some of which require a C compiler to build.
\r
436 Look in http://www.cpan.org/ for more information on CPAN.
\r
438 Note that not all of the extensions available from CPAN may work
\r
439 in the Win32 environment; you should check the information at
\r
440 http://testers.cpan.org/ before investing too much effort into
\r
441 porting modules that don't readily build.
\r
443 Most extensions (whether they require a C compiler or not) can
\r
444 be built, tested and installed with the standard mantra:
\r
451 where $MAKE is whatever 'make' program you have configured perl to
\r
452 use. Use "perl -V:make" to find out what this is. Some extensions
\r
453 may not provide a testsuite (so "$MAKE test" may not do anything or
\r
454 fail), but most serious ones do.
\r
456 It is important that you use a supported 'make' program, and
\r
457 ensure Config.pm knows about it. If you don't have nmake, you can
\r
458 either get dmake from the location mentioned earlier or get an
\r
459 old version of nmake reportedly available from:
\r
461 ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
\r
463 Another option is to use the make written in Perl, available from
\r
466 http://www.cpan.org/modules/by-module/Make/
\r
468 You may also use dmake. See L</"Make"> above on how to get it.
\r
470 Note that MakeMaker actually emits makefiles with different syntax
\r
471 depending on what 'make' it thinks you are using. Therefore, it is
\r
472 important that one of the following values appears in Config.pm:
\r
474 make='nmake' # MakeMaker emits nmake syntax
\r
475 make='dmake' # MakeMaker emits dmake syntax
\r
476 any other value # MakeMaker emits generic make syntax
\r
477 (e.g GNU make, or Perl make)
\r
479 If the value doesn't match the 'make' program you want to use,
\r
480 edit Config.pm to fix it.
\r
482 If a module implements XSUBs, you will need one of the supported
\r
483 C compilers. You must make sure you have set up the environment for
\r
484 the compiler for command-line compilation.
\r
486 If a module does not build for some reason, look carefully for
\r
487 why it failed, and report problems to the module author. If
\r
488 it looks like the extension building support is at fault, report
\r
489 that with full details of how the build failed using the perlbug
\r
492 =item Command-line Wildcard Expansion
\r
494 The default command shells on DOS descendant operating systems (such
\r
495 as they are) usually do not expand wildcard arguments supplied to
\r
496 programs. They consider it the application's job to handle that.
\r
497 This is commonly achieved by linking the application (in our case,
\r
498 perl) with startup code that the C runtime libraries usually provide.
\r
499 However, doing that results in incompatible perl versions (since the
\r
500 behavior of the argv expansion code differs depending on the
\r
501 compiler, and it is even buggy on some compilers). Besides, it may
\r
502 be a source of frustration if you use such a perl binary with an
\r
503 alternate shell that *does* expand wildcards.
\r
505 Instead, the following solution works rather well. The nice things
\r
506 about it are 1) you can start using it right away; 2) it is more
\r
507 powerful, because it will do the right thing with a pattern like
\r
508 */*/*.c; 3) you can decide whether you do/don't want to use it; and
\r
509 4) you can extend the method to add any customizations (or even
\r
510 entirely different kinds of wildcard expansion).
\r
512 C:\> copy con c:\perl\lib\Wild.pm
\r
513 # Wild.pm - emulate shell @ARGV expansion on shells that don't
\r
516 my @g = File::DosGlob::glob($_) if /[*?]/;
\r
521 C:\> set PERL5OPT=-MWild
\r
522 C:\> perl -le "for (@ARGV) { print }" */*/perl*.c
\r
524 p4view/perl/perlio.c
\r
525 p4view/perl/perly.c
\r
526 perl5.005/win32/perlglob.c
\r
527 perl5.005/win32/perllib.c
\r
528 perl5.005/win32/perlglob.c
\r
529 perl5.005/win32/perllib.c
\r
530 perl5.005/win32/perlglob.c
\r
531 perl5.005/win32/perllib.c
\r
533 Note there are two distinct steps there: 1) You'll have to create
\r
534 Wild.pm and put it in your perl lib directory. 2) You'll need to
\r
535 set the PERL5OPT environment variable. If you want argv expansion
\r
536 to be the default, just set PERL5OPT in your default startup
\r
539 If you are using the Visual C compiler, you can get the C runtime's
\r
540 command line wildcard expansion built into perl binary. The resulting
\r
541 binary will always expand unquoted command lines, which may not be
\r
542 what you want if you use a shell that does that for you. The expansion
\r
543 done is also somewhat less powerful than the approach suggested above.
\r
545 =item Win32 Specific Extensions
\r
547 A number of extensions specific to the Win32 platform are available
\r
548 from CPAN. You may find that many of these extensions are meant to
\r
549 be used under the Activeware port of Perl, which used to be the only
\r
550 native port for the Win32 platform. Since the Activeware port does not
\r
551 have adequate support for Perl's extension building tools, these
\r
552 extensions typically do not support those tools either and, therefore,
\r
553 cannot be built using the generic steps shown in the previous section.
\r
555 To ensure smooth transitioning of existing code that uses the
\r
556 ActiveState port, there is a bundle of Win32 extensions that contains
\r
557 all of the ActiveState extensions and most other Win32 extensions from
\r
558 CPAN in source form, along with many added bugfixes, and with MakeMaker
\r
559 support. This bundle is available at:
\r
561 http://www.cpan.org/authors/id/GSAR/libwin32-0.18.zip
\r
563 See the README in that distribution for building and installation
\r
564 instructions. Look for later versions that may be available at the
\r
567 =item Notes on 64-bit Windows
\r
569 Windows .NET Server supports the LLP64 data model on the Intel Itanium
\r
572 The LLP64 data model is different from the LP64 data model that is the
\r
573 norm on 64-bit Unix platforms. In the former, C<int> and C<long> are
\r
574 both 32-bit data types, while pointers are 64 bits wide. In addition,
\r
575 there is a separate 64-bit wide integral type, C<__int64>. In contrast,
\r
576 the LP64 data model that is pervasive on Unix platforms provides C<int>
\r
577 as the 32-bit type, while both the C<long> type and pointers are of
\r
578 64-bit precision. Note that both models provide for 64-bits of
\r
581 64-bit Windows running on Itanium is capable of running 32-bit x86
\r
582 binaries transparently. This means that you could use a 32-bit build
\r
583 of Perl on a 64-bit system. Given this, why would one want to build
\r
584 a 64-bit build of Perl? Here are some reasons why you would bother:
\r
588 A 64-bit native application will run much more efficiently on
\r
593 There is no 2GB limit on process size.
\r
597 Perl automatically provides large file support when built under
\r
602 Embedding Perl inside a 64-bit application.
\r
606 =head2 Running Perl Scripts
\r
608 Perl scripts on UNIX use the "#!" (a.k.a "shebang") line to
\r
609 indicate to the OS that it should execute the file using perl.
\r
610 Win32 has no comparable means to indicate arbitrary files are
\r
613 Instead, all available methods to execute plain text files on
\r
614 Win32 rely on the file "extension". There are three methods
\r
615 to use this to execute perl scripts:
\r
621 There is a facility called "file extension associations" that will
\r
622 work in Windows NT 4.0. This can be manipulated via the two
\r
623 commands "assoc" and "ftype" that come standard with Windows NT
\r
624 4.0. Type "ftype /?" for a complete example of how to set this
\r
625 up for perl scripts (Say what? You thought Windows NT wasn't
\r
630 Since file associations don't work everywhere, and there are
\r
631 reportedly bugs with file associations where it does work, the
\r
632 old method of wrapping the perl script to make it look like a
\r
633 regular batch file to the OS, may be used. The install process
\r
634 makes available the "pl2bat.bat" script which can be used to wrap
\r
635 perl scripts into batch files. For example:
\r
639 will create the file "FOO.BAT". Note "pl2bat" strips any
\r
640 .pl suffix and adds a .bat suffix to the generated file.
\r
642 If you use the 4DOS/NT or similar command shell, note that
\r
643 "pl2bat" uses the "%*" variable in the generated batch file to
\r
644 refer to all the command line arguments, so you may need to make
\r
645 sure that construct works in batch files. As of this writing,
\r
646 4DOS/NT users will need a "ParameterChar = *" statement in their
\r
647 4NT.INI file or will need to execute "setdos /p*" in the 4DOS/NT
\r
648 startup file to enable this to work.
\r
652 Using "pl2bat" has a few problems: the file name gets changed,
\r
653 so scripts that rely on C<$0> to find what they must do may not
\r
654 run properly; running "pl2bat" replicates the contents of the
\r
655 original script, and so this process can be maintenance intensive
\r
656 if the originals get updated often. A different approach that
\r
657 avoids both problems is possible.
\r
659 A script called "runperl.bat" is available that can be copied
\r
660 to any filename (along with the .bat suffix). For example,
\r
661 if you call it "foo.bat", it will run the file "foo" when it is
\r
662 executed. Since you can run batch files on Win32 platforms simply
\r
663 by typing the name (without the extension), this effectively
\r
664 runs the file "foo", when you type either "foo" or "foo.bat".
\r
665 With this method, "foo.bat" can even be in a different location
\r
666 than the file "foo", as long as "foo" is available somewhere on
\r
667 the PATH. If your scripts are on a filesystem that allows symbolic
\r
668 links, you can even avoid copying "runperl.bat".
\r
670 Here's a diversion: copy "runperl.bat" to "runperl", and type
\r
671 "runperl". Explain the observed behavior, or lack thereof. :)
\r
672 Hint: .gnidnats llits er'uoy fi ,"lrepnur" eteled :tniH
\r
674 =item Miscellaneous Things
\r
676 A full set of HTML documentation is installed, so you should be
\r
677 able to use it if you have a web browser installed on your
\r
680 C<perldoc> is also a useful tool for browsing information contained
\r
681 in the documentation, especially in conjunction with a pager
\r
682 like C<less> (recent versions of which have Win32 support). You may
\r
683 have to set the PAGER environment variable to use a specific pager.
\r
684 "perldoc -f foo" will print information about the perl operator
\r
687 If you find bugs in perl, you can run C<perlbug> to create a
\r
688 bug report (you may have to send it manually if C<perlbug> cannot
\r
689 find a mailer on your system).
\r
693 =head1 BUGS AND CAVEATS
\r
695 Norton AntiVirus interferes with the build process, particularly if
\r
696 set to "AutoProtect, All Files, when Opened". Unlike large applications
\r
697 the perl build process opens and modifies a lot of files. Having the
\r
698 the AntiVirus scan each and every one slows build the process significantly.
\r
699 Worse, with PERLIO=stdio the build process fails with peculiar messages
\r
700 as the virus checker interacts badly with miniperl.exe writing configure
\r
701 files (it seems to either catch file part written and treat it as suspicious,
\r
702 or virus checker may have it "locked" in a way which inhibits miniperl
\r
703 updating it). The build does complete with
\r
707 but that may be just luck. Other AntiVirus software may have similar issues.
\r
709 Some of the built-in functions do not act exactly as documented in
\r
710 L<perlfunc>, and a few are not implemented at all. To avoid
\r
711 surprises, particularly if you have had prior exposure to Perl
\r
712 in other operating environments or if you intend to write code
\r
713 that will be portable to other environments. See L<perlport>
\r
714 for a reasonably definitive list of these differences.
\r
716 Not all extensions available from CPAN may build or work properly
\r
717 in the Win32 environment. See L</"Building Extensions">.
\r
719 Most C<socket()> related calls are supported, but they may not
\r
720 behave as on Unix platforms. See L<perlport> for the full list.
\r
722 Signal handling may not behave as on Unix platforms (where it
\r
723 doesn't exactly "behave", either :). For instance, calling C<die()>
\r
724 or C<exit()> from signal handlers will cause an exception, since most
\r
725 implementations of C<signal()> on Win32 are severely crippled.
\r
726 Thus, signals may work only for simple things like setting a flag
\r
727 variable in the handler. Using signals under this port should
\r
728 currently be considered unsupported.
\r
730 Please send detailed descriptions of any problems and solutions that
\r
731 you may find to <F<perlbug@perl.com>>, along with the output produced
\r
738 =item Gary Ng E<lt>71564.1743@CompuServe.COME<gt>
\r
740 =item Gurusamy Sarathy E<lt>gsar@activestate.comE<gt>
\r
742 =item Nick Ing-Simmons E<lt>nick@ing-simmons.netE<gt>
\r
746 This document is maintained by Gurusamy Sarathy.
\r
754 This port was originally contributed by Gary Ng around 5.003_24,
\r
755 and borrowed from the Hip Communications port that was available
\r
756 at the time. Various people have made numerous and sundry hacks
\r
759 Borland support was added in 5.004_01 (Gurusamy Sarathy).
\r
761 GCC/mingw32 support was added in 5.005 (Nick Ing-Simmons).
\r
763 Support for PERL_OBJECT was added in 5.005 (ActiveState Tool Corp).
\r
765 Support for fork() emulation was added in 5.6 (ActiveState Tool Corp).
\r
767 Win9x support was added in 5.6 (Benjamin Stuhl).
\r
769 Support for 64-bit Windows added in 5.8 (ActiveState Corp).
\r
771 Last updated: 20 April 2002
\r
projects / p5sagit/p5-mst-13.2.git / blob