Cari di Perl 
     Perl User Manual
Daftar Isi ☛
(Sebelumnya) Perl for Stratus VOSAnyDBM_File - provide framewor ... (Berikutnya)
Platform Specific

Perl under Windows

Daftar Isi

NAME

perlwin32 - Perl under Windows

SYNOPSIS

These are instructions for building Perl under Windows 2000 and later.

DESCRIPTION

Before you start, you should glance through the README filefound in the top-level directory to which the Perl distributionwas extracted. Make sure you read and understand the terms underwhich this software is being distributed.

Also make sure you read BUGS AND CAVEATS below for theknown limitations of this port.

The INSTALL file in the perl top-level has much information that isonly relevant to people building Perl on Unix-like systems. Inparticular, you can safely ignore any information that talks about"Configure".

You may also want to look at one other option for building a perl thatwill work on Windows: the README.cygwin file, which give a differentset of rules to build a perl for Windows. This method will probablyenable you to build a more Unix-compatible perl, but you will alsoneed to download and use various other build-time and run-time supportsoftware described in that file.

This set of instructions is meant to describe a so-called "native"port of Perl to the Windows platform. This includes both 32-bit and64-bit Windows operating systems. The resulting Perl requires noadditional software to run (other than what came with your operatingsystem). Currently, this port is capable of using one of thefollowing compilers on the Intel x86 architecture:

  1.   Microsoft Visual C++ version 6.0 or later
    2.  
  2.   Gcc by mingw.org gcc version 3.2 or later
    3.  
  3.   Gcc by mingw-w64.sf.net gcc version 4.4.3 or later
    4.

Note that the last two of these are actually competing projects bothdelivering complete gcc toolchain for MS Windows:

  • http://mingw.org

    Delivers gcc toolchain targeting 32-bit Windows platform.

  • http://mingw-w64.sf.net

    Delivers gcc toolchain targeting both 64-bit Windows and 32-bit Windowsplatforms (despite the project name "mingw-w64" they are not only 64-bitoriented). They deliver the native gcc compilers and cross-compilersthat are also supported by perl's makefile.

The Microsoft Visual C++ compilers are also now being given away free. They areavailable as "Visual C++ Toolkit 2003" or "Visual C++ 2005/2008/2010 ExpressEdition" (and also as part of the ".NET Framework SDK") and are the samecompilers that ship with "Visual C++ .NET 2003 Professional" or "Visual C++2005/2008/2010 Professional" respectively.

This port can also be built on IA64/AMD64 using:

  1.   Microsoft Platform SDKNov 2001 (64-bit compiler and tools)
    2.  
  2.   MinGW64 compiler (gcc version 4.4.3 or later)
    3.

The Windows SDK can be downloaded from http://www.microsoft.com/.The MinGW64 compiler is available at http://sourceforge.net/projects/mingw-w64.The latter is actually a cross-compiler targeting Win64. There's also a trimmeddown compiler (no java, or gfortran) suitable for building perl available at:http://strawberryperl.com/package/kmx/64_gcctoolchain/

NOTE: If you're using a 32-bit compiler to build perl on a 64-bit Windowsoperating system, then you should set the WIN64 environment variable to "undef".Also, the trimmed down compiler only passes tests when USE_ITHREADS *= define(as opposed to undef) and when the CFG *= Debug line is commented out.

This port fully supports MakeMaker (the set of modules thatis used to build extensions to perl). Therefore, you should beable to build and install most extensions found in the CPAN sites.See Usage Hints for Perl on Windows below for general hints about this.

Setting Up Perl on Windows

  • Make

    You need a "make" program to build the sources. If you are usingVisual C++ or the Windows SDK tools, nmake will work. Builds usingthe gcc need dmake.

    dmake is a freely available make that has very nice macro featuresand parallelability.

    A port of dmake for Windows is available from:

    http://search.cpan.org/dist/dmake/

    Fetch and install dmake somewhere on your path.

  • Command Shell

    Use the default "cmd" shell that comes with Windows. Some versions of thepopular 4DOS/NT shell have incompatibilities that may cause you trouble.If the build fails under that shell, try building again with the cmdshell.

    Make sure the path to the build directory does not contain spaces. Thebuild usually works in this circumstance, but some tests will fail.

  • Microsoft Visual C++

    The nmake that comes with Visual C++ will suffice for building.You will need to run the VCVARS32.BAT file, usually found somewherelike C:\Program Files\Microsoft Visual Studio\VC98\Bin.This will set your build environment.

    You can also use dmake to build using Visual C++; provided, however,you set OSRELEASE to "microsft" (or whatever the directory nameunder which the Visual C dmake configuration lives) in your environmentand edit win32/config.vc to change "make=nmake" into "make=dmake". Thelatter step is only essential if you want to use dmake as your defaultmake for building extensions using MakeMaker.

  • Microsoft Visual C++ 2008/2010 Express Edition

    These free versions of Visual C++ 2008/2010 Professional contain the samecompilers and linkers that ship with the full versions, and also containeverything necessary to build Perl, rather than requiring a separate downloadof the Windows SDK like previous versions did.

    These packages can be downloaded by searching in the Download Center athttp://www.microsoft.com/downloads/search.aspx?displaylang=en. (Providing exactlinks to these packages has proven a pointless task because the links keep onchanging so often.)

    Install Visual C++ 2008/2010 Express, then setup your environment using, e.g.

    1. C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat
      2.

    (assuming the default installation location was chosen).

    Perl should now build using the win32/Makefile. You will need to edit thatfile to set CCTYPE to MSVC90FREE or MSVC100FREE first.

  • Microsoft Visual C++ 2005 Express Edition

    This free version of Visual C++ 2005 Professional contains the same compilerand linker that ship with the full version, but doesn't contain everythingnecessary to build Perl.

    You will also need to download the "Windows SDK" (the "Core SDK" and "MDACSDK" components are required) for more header files and libraries.

    These packages can both be downloaded by searching in the Download Center athttp://www.microsoft.com/downloads/search.aspx?displaylang=en. (Providing exactlinks to these packages has proven a pointless task because the links keep onchanging so often.)

    Try to obtain the latest version of the Windows SDK. Sometimes these packagescontain a particular Windows OS version in their name, but actually work onother OS versions too. For example, the "Windows Server 2003 R2 Platform SDK"also runs on Windows XP SP2 and Windows 2000.

    Install Visual C++ 2005 first, then the Platform SDK. Setup your environmentas follows (assuming default installation locations were chosen):

    1. SET PlatformSDKDir=C:\Program Files\Microsoft Platform SDK
      2.  
    2.  
    3. SET PATH=%SystemRoot%\system32;%SystemRoot%;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;C:\Program Files\Microsoft Visual Studio 8\VC\BIN;C:\Program Files\Microsoft Visual Studio 8\Common7\Tools;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;%PlatformSDKDir%\Bin
      4.  
    4.  
    5. SET INCLUDE=C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE;%PlatformSDKDir%\include
      6.  
    6.  
    7. SET LIB=C:\Program Files\Microsoft Visual Studio 8\VC\LIB;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\lib;%PlatformSDKDir%\lib
      8.  
    8.  
    9. SET LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
      10.

    (The PlatformSDKDir might need to be set differently depending on which versionyou are using. Earlier versions installed into "C:\Program Files\Microsoft SDK",while the latest versions install into version-specific locations such as"C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2".)

    Perl should now build using the win32/Makefile. You will need to edit thatfile to set

    1. CCTYPE = MSVC80FREE
      2.

    and to set CCHOME, CCINCDIR and CCLIBDIR as per the environment setup above.

  • Microsoft Visual C++ Toolkit 2003

    This free toolkit contains the same compiler and linker that ship withVisual C++ .NET 2003 Professional, but doesn't contain everythingnecessary to build Perl.

    You will also need to download the "Platform SDK" (the "Core SDK" and "MDACSDK" components are required) for header files, libraries and rc.exe, and".NET Framework SDK" for more libraries and nmake.exe. Note that the latter(which also includes the free compiler and linker) requires the ".NETFramework Redistributable" to be installed first. This can be downloaded andinstalled separately, but is included in the "Visual C++ Toolkit 2003" anyway.

    These packages can all be downloaded by searching in the Download Center athttp://www.microsoft.com/downloads/search.aspx?displaylang=en. (Providing exactlinks to these packages has proven a pointless task because the links keep onchanging so often.)

    Try to obtain the latest version of the Windows SDK. Sometimes these packagescontain a particular Windows OS version in their name, but actually work onother OS versions too. For example, the "Windows Server 2003 R2 Platform SDK"also runs on Windows XP SP2 and Windows 2000.

    Install the Toolkit first, then the Platform SDK, then the .NET Framework SDK.Setup your environment as follows (assuming default installation locationswere chosen):

    1. SET PlatformSDKDir=C:\Program Files\Microsoft Platform SDK
      2.  
    2.  
    3. SET PATH=%SystemRoot%\system32;%SystemRoot%;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;%PlatformSDKDir%\Bin;C:\Program Files\Microsoft.NET\SDK\v1.1\Bin
      4.  
    4.  
    5. SET INCLUDE=C:\Program Files\Microsoft Visual C++ Toolkit 2003\include;%PlatformSDKDir%\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include
      6.  
    6.  
    7. SET LIB=C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib;%PlatformSDKDir%\lib;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib
      8.

    (The PlatformSDKDir might need to be set differently depending on which versionyou are using. Earlier versions installed into "C:\Program Files\Microsoft SDK",while the latest versions install into version-specific locations such as"C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2".)

    Several required files will still be missing:

    • cvtres.exe is required by link.exe when using a .res file. It is actuallyinstalled by the .NET Framework SDK, but into a location such as thefollowing:

      1. C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
        2.

      Copy it from there to %PlatformSDKDir%\Bin

    • lib.exe is normally used to build libraries, but link.exe with the /liboption also works, so change win32/config.vc to use it instead:

      Change the line reading:

      1. ar='lib'
        2.

      to:

      1. ar='link /lib'
        2.

      It may also be useful to create a batch file called lib.bat inC:\Program Files\Microsoft Visual C++ Toolkit 2003\bin containing:

      1. @echo off
        2.  
      2. link /lib %*
        3.

      for the benefit of any naughty C extension modules that you might want to buildlater which explicitly reference "lib" rather than taking their value from$Config{ar}.

    • setargv.obj is required to build perlglob.exe (and perl.exe if the USE_SETARGVoption is enabled). The Platform SDK supplies this object file in source formin %PlatformSDKDir%\src\crt. Copy setargv.c, cruntime.h andinternal.h from there to some temporary location and build setargv.obj using

      1. cl.exe /c /I. /D_CRTBLD setargv.c
        2.

      Then copy setargv.obj to %PlatformSDKDir%\lib

      Alternatively, if you don't need perlglob.exe and don't need to enable theUSE_SETARGV option then you can safely just remove all mention of $(GLOBEXE)from win32/Makefile and setargv.obj won't be required anyway.

    Perl should now build using the win32/Makefile. You will need to edit thatfile to set

    1. CCTYPE = MSVC70FREE
      2.

    and to set CCHOME, CCINCDIR and CCLIBDIR as per the environment setup above.

  • Microsoft Platform SDK 64-bit Compiler

    The nmake that comes with the Platform SDK will suffice for buildingPerl. Make sure you are building within one of the "Build Environment"shells available after you install the Platform SDK from the Start Menu.

  • MinGW release 3 with gcc

    Perl can be compiled with gcc from MinGW release 3 and later (using gcc 3.2.xand later). It can be downloaded here:

    http://www.mingw.org/

    You also need dmake. See Make above on how to get it.

Building

  • Make sure you are in the "win32" subdirectory under the perl toplevel.This directory contains a "Makefile" that will work withversions of nmake that come with Visual C++ or the Windows SDK, anda dmake "makefile.mk" that will work for all supported compilers. Thedefaults in the dmake makefile are setup to build using MinGW/gcc.

  • Edit the makefile.mk (or Makefile, if you're using nmake) and changethe values of INST_DRV and INST_TOP. You can also enable variousbuild flags. These are explained in the makefiles.

    Note that it is generally not a good idea to try to build a perl withINST_DRV and INST_TOP set to a path that already exists from a previousbuild. In particular, this may cause problems with thelib/ExtUtils/t/Embed.t test, which attempts to build a test program andmay end up building against the installed perl's lib/CORE directory ratherthan the one being tested.

    You will have to make sure that CCTYPE is set correctly and thatCCHOME points to wherever you installed your compiler.

    If building with the cross-compiler provided bymingw-w64.sourceforge.net you'll need to uncomment the line that setsGCCCROSS in the makefile.mk. Do this only if it's the cross-compiler - ieonly if the bin folder doesn't contain a gcc.exe. (The cross-compilerdoes not provide a gcc.exe, g++.exe, ar.exe, etc. Instead, all of theseexecutables are prefixed with 'x86_64-w64-mingw32-'.)

    The default value for CCHOME in the makefiles for Visual C++may not be correct for some versions. Make sure the default existsand is valid.

    You may also need to comment out the DELAYLOAD = ... line in theMakefile if you're using VC++ 6.0 without the latest service pack andthe linker reports an internal error.

    If you want build some core extensions statically into perl's dll, specifythem in the STATIC_EXT macro.

    Be sure to read the instructions near the top of the makefiles carefully.

  • Type "dmake" (or "nmake" if you are using that make).

    This should build everything. Specifically, it will create perl.exe,perl516.dll at the perl toplevel, and various other extension dll'sunder the lib\auto directory. If the build fails for any reason, makesure you have done the previous steps correctly.

Testing Perl on Windows

Type "dmake test" (or "nmake test"). This will run most of the tests fromthe testsuite (many tests will be skipped).

There should be no test failures.

Some test failures may occur if you use a command shell other than thenative "cmd.exe", or if you are building from a path that containsspaces. So don't do that.

If you are running the tests from a emacs shell window, you may seefailures in op/stat.t. Run "dmake test-notty" in that case.

If you run the tests on a FAT partition, you may see some failures forlink() related tests (op/write.t, op/stat.t ...). Testing onNTFS avoids these errors.

Furthermore, you should make sure that during make test you do nothave any GNU tool packages in your path: some toolkits like Unixutilsinclude some tools (type for instance) which override the Windowsones and makes tests fail. Remove them from your path while testing toavoid these errors.

Please report any other failures as described under BUGS AND CAVEATS.

Installation of Perl on Windows

Type "dmake install" (or "nmake install"). This will put the newlybuilt perl and the libraries under whatever INST_TOP points to in theMakefile. It will also install the pod documentation under$INST_TOP\$INST_VER\lib\pod and HTML versions of the same under$INST_TOP\$INST_VER\lib\pod\html.

To use the Perl you just installed you will need to add a new entry toyour PATH environment variable: $INST_TOP\bin, e.g.

  1.  set PATH=c:\perl\bin;%PATH%
    2.

If you opted to uncomment INST_VER and INST_ARCH in the makefilethen the installation structure is a little more complicated and you willneed to add two new PATH components instead: $INST_TOP\$INST_VER\bin and$INST_TOP\$INST_VER\bin\$ARCHNAME, e.g.

  1.  set PATH=c:\perl\5.6.0\bin;c:\perl\5.6.0\bin\MSWin32-x86;%PATH%
    2.

Usage Hints for Perl on Windows

  • Environment Variables

    The installation paths that you set during the build get compiledinto perl, so you don't have to do anything additional to startusing that perl (except add its location to your PATH variable).

    If you put extensions in unusual places, you can set PERL5LIBto a list of paths separated by semicolons where you want perlto look for libraries. Look for descriptions of other environmentvariables you can set in perlrun.

    You can also control the shell that perl uses to run system() andbacktick commands via PERL5SHELL. See perlrun.

    Perl does not depend on the registry, but it can look up certain defaultvalues if you choose to put them there. Perl attempts to read entries fromHKEY_CURRENT_USER\Software\Perl and HKEY_LOCAL_MACHINE\Software\Perl.Entries in the former override entries in the latter. One or more of thefollowing entries (of type REG_SZ or REG_EXPAND_SZ) may be set:

    1.  lib-$]version-specific standard library path to add to @INC
      2.  
    2.  libstandard library path to add to @INC
      3.  
    3.  sitelib-$]version-specific site library path to add to @INC
      4.  
    4.  sitelibsite library path to add to @INC
      5.  
    5.  vendorlib-$]version-specific vendor library path to add to @INC
      6.  
    6.  vendorlibvendor library path to add to @INC
      7.  
    7.  PERL*fallback for all %ENV lookups that begin with "PERL"
      8.

    Note the $] in the above is not literal. Substitute whatever versionof perl you want to honor that entry, e.g. 5.6.0. Paths must beseparated with semicolons, as usual on Windows.

  • File Globbing

    By default, perl handles file globbing using the File::Glob extension,which provides portable globbing.

    If you want perl to use globbing that emulates the quirks of DOSfilename conventions, you might want to consider using File::DosGlobto override the internal glob() implementation. See File::DosGlob fordetails.

  • Using perl from the command line

    If you are accustomed to using perl from various command-lineshells found in UNIX environments, you will be less than pleasedwith what Windows offers by way of a command shell.

    The crucial thing to understand about the Windows environment is thatthe command line you type in is processed twice before Perl sees it.First, your command shell (usually CMD.EXE) preprocesses the commandline, to handle redirection, environment variable expansion, andlocation of the executable to run. Then, the perl executable splitsthe remaining command line into individual arguments, using theC runtime library upon which Perl was built.

    It is particularly important to note that neither the shell nor the Cruntime do any wildcard expansions of command-line arguments (sowildcards need not be quoted). Also, the quoting behaviours of theshell and the C runtime are rudimentary at best (and may, if you areusing a non-standard shell, be inconsistent). The only (useful) quotecharacter is the double quote ("). It can be used to protect spacesand other special characters in arguments.

    The Windows documentation describes the shell parsing rules here:http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=trueand the C runtime parsing rules here:http://msdn.microsoft.com/en-us/library/17w5ykft%28v=VS.100%29.aspx.

    Here are some further observations based on experiments: The C runtimebreaks arguments at spaces and passes them to programs in argc/argv.Double quotes can be used to prevent arguments with spaces in them frombeing split up. You can put a double quote in an argument by escapingit with a backslash and enclosing the whole argument within double quotes.The backslash and the pair of double quotes surrounding the argument willbe stripped by the C runtime.

    The file redirection characters "<", ">", and "|" can be quoted bydouble quotes (although there are suggestions that this may not alwaysbe true). Single quotes are not treated as quotes by the shell orthe C runtime, they don't get stripped by the shell (just to makethis type of quoting completely useless). The caret "^" has alsobeen observed to behave as a quoting character, but this appearsto be a shell feature, and the caret is not stripped from the commandline, so Perl still sees it (and the C runtime phase does not treatthe caret as a quote character).

    Here are some examples of usage of the "cmd" shell:

    This prints two doublequotes:

    1.  perl -e "print '\"\"' "
      2.

    This does the same:

    1.  perl -e "print \"\"\"\" "
      2.

    This prints "bar" and writes "foo" to the file "blurch":

    1.  perl -e "print 'foo' print STDERR 'bar'" > blurch
      2.

    This prints "foo" ("bar" disappears into nowhereland):

    1.  perl -e "print 'foo'; print STDERR 'bar'" 2> nul
      2.

    This prints "bar" and writes "foo" into the file "blurch":

    1.  perl -e "print 'foo'; print STDERR 'bar'" 1> blurch
      2.

    This pipes "foo" to the "less" pager and prints "bar" on the console:

    1.  perl -e "print 'foo' print STDERR 'bar'" | less
      2.

    This pipes "foo\nbar\n" to the less pager:

    1.  perl -le "print 'foo'; print STDERR 'bar'" 2>&1 | less
      2.

    This pipes "foo" to the pager and writes "bar" in the file "blurch":

    1.  perl -e "print 'foo'; print STDERR 'bar'" 2> blurch | less
      2.

    Discovering the usefulness of the "command.com" shell on Windows 9xis left as an exercise to the reader :)

    One particularly pernicious problem with the 4NT command shell forWindows is that it (nearly) always treats a % character as indicatingthat environment variable expansion is needed. Under this shell, it istherefore important to always double any % characters which you wantPerl to see (for example, for hash variables), even when they arequoted.

  • Building Extensions

    The Comprehensive Perl Archive Network (CPAN) offers a wealthof extensions, some of which require a C compiler to build.Look in http://www.cpan.org/ for more information on CPAN.

    Note that not all of the extensions available from CPAN may workin the Windows environment; you should check the information athttp://testers.cpan.org/ before investing too much effort intoporting modules that don't readily build.

    Most extensions (whether they require a C compiler or not) canbe built, tested and installed with the standard mantra:

    1.  perl Makefile.PL
      2.  
    2.  $MAKE
      3.  
    3.  $MAKE test
      4.  
    4.  $MAKE install
      5.

    where $MAKE is whatever 'make' program you have configured perl touse. Use "perl -V:make" to find out what this is. Some extensionsmay not provide a testsuite (so "$MAKE test" may not do anything orfail), but most serious ones do.

    It is important that you use a supported 'make' program, andensure Config.pm knows about it. If you don't have nmake, you caneither get dmake from the location mentioned earlier or get anold version of nmake reportedly available from:

    http://download.microsoft.com/download/vc15/Patch/1.52/W95/EN-US/nmake15.exe

    Another option is to use the make written in Perl, available fromCPAN.

    http://www.cpan.org/modules/by-module/Make/

    You may also use dmake. See Make above on how to get it.

    Note that MakeMaker actually emits makefiles with different syntaxdepending on what 'make' it thinks you are using. Therefore, it isimportant that one of the following values appears in Config.pm:

    1.  make='nmake'# MakeMaker emits nmake syntax
      2.  
    2.  make='dmake'# MakeMaker emits dmake syntax
      3.  
    3.  any other value# MakeMaker emits generic make syntax
      4.  
    4.  (e.g GNU make, or Perl make)
      5.

    If the value doesn't match the 'make' program you want to use,edit Config.pm to fix it.

    If a module implements XSUBs, you will need one of the supportedC compilers. You must make sure you have set up the environment forthe compiler for command-line compilation.

    If a module does not build for some reason, look carefully forwhy it failed, and report problems to the module author. Ifit looks like the extension building support is at fault, reportthat with full details of how the build failed using the perlbugutility.

  • Command-line Wildcard Expansion

    The default command shells on DOS descendant operating systems (suchas they are) usually do not expand wildcard arguments supplied toprograms. They consider it the application's job to handle that.This is commonly achieved by linking the application (in our case,perl) with startup code that the C runtime libraries usually provide.However, doing that results in incompatible perl versions (since thebehavior of the argv expansion code differs depending on thecompiler, and it is even buggy on some compilers). Besides, it maybe a source of frustration if you use such a perl binary with analternate shell that *does* expand wildcards.

    Instead, the following solution works rather well. The nice thingsabout it are 1) you can start using it right away; 2) it is morepowerful, because it will do the right thing with a pattern like*/*/*.c; 3) you can decide whether you do/don't want to use it; and4) you can extend the method to add any customizations (or evenentirely different kinds of wildcard expansion).

    1. C:\> copy con c:\perl\lib\Wild.pm
      2.  
    2. # Wild.pm - emulate shell @ARGV expansion on shells that don't
      3.  
    3. use File::DosGlob;
      4.  
    4. @ARGV = map {
      5.  
    5.   my @g = File::DosGlob::glob($_) if /[*?]/;
      6.  
    6.   @g ? @g : $_;
      7.  
    7.  } @ARGV;
      8.  
    8. 1;
      9.  
    9. ^Z
      10.  
    10. C:\> set PERL5OPT=-MWild
      11.  
    11. C:\> perl -le "for (@ARGV) { print }" */*/perl*.c
      12.  
    12. p4view/perl/perl.c
      13.  
    13. p4view/perl/perlio.c
      14.  
    14. p4view/perl/perly.c
      15.  
    15. perl5.005/win32/perlglob.c
      16.  
    16. perl5.005/win32/perllib.c
      17.  
    17. perl5.005/win32/perlglob.c
      18.  
    18. perl5.005/win32/perllib.c
      19.  
    19. perl5.005/win32/perlglob.c
      20.  
    20. perl5.005/win32/perllib.c
      21.

    Note there are two distinct steps there: 1) You'll have to createWild.pm and put it in your perl lib directory. 2) You'll need toset the PERL5OPT environment variable. If you want argv expansionto be the default, just set PERL5OPT in your default startupenvironment.

    If you are using the Visual C compiler, you can get the C runtime'scommand line wildcard expansion built into perl binary. The resultingbinary will always expand unquoted command lines, which may not bewhat you want if you use a shell that does that for you. The expansiondone is also somewhat less powerful than the approach suggested above.

  • Notes on 64-bit Windows

    Windows .NET Server supports the LLP64 data model on the Intel Itaniumarchitecture.

    The LLP64 data model is different from the LP64 data model that is thenorm on 64-bit Unix platforms. In the former, int and long areboth 32-bit data types, while pointers are 64 bits wide. In addition,there is a separate 64-bit wide integral type, __int64. In contrast,the LP64 data model that is pervasive on Unix platforms provides intas the 32-bit type, while both the long type and pointers are of64-bit precision. Note that both models provide for 64-bits ofaddressability.

    64-bit Windows running on Itanium is capable of running 32-bit x86binaries transparently. This means that you could use a 32-bit buildof Perl on a 64-bit system. Given this, why would one want to builda 64-bit build of Perl? Here are some reasons why you would bother:

    • A 64-bit native application will run much more efficiently onItanium hardware.

    • There is no 2GB limit on process size.

    • Perl automatically provides large file support when built under64-bit Windows.

    • Embedding Perl inside a 64-bit application.

Running Perl Scripts

Perl scripts on UNIX use the "#!" (a.k.a "shebang") line toindicate to the OS that it should execute the file using perl.Windows has no comparable means to indicate arbitrary files areexecutables.

Instead, all available methods to execute plain text files onWindows rely on the file "extension". There are three methodsto use this to execute perl scripts:

1

There is a facility called "file extension associations". This can bemanipulated via the two commands "assoc" and "ftype" that comestandard with Windows. Type "ftype /?" for a complete example of howto set this up for perl scripts (Say what? You thought Windowswasn't perl-ready? :).

2

Since file associations don't work everywhere, and there arereportedly bugs with file associations where it does work, theold method of wrapping the perl script to make it look like aregular batch file to the OS, may be used. The install processmakes available the "pl2bat.bat" script which can be used to wrapperl scripts into batch files. For example:

  1. pl2bat foo.pl
    2.

will create the file "FOO.BAT". Note "pl2bat" strips any.pl suffix and adds a .bat suffix to the generated file.

If you use the 4DOS/NT or similar command shell, note that"pl2bat" uses the "%*" variable in the generated batch file torefer to all the command line arguments, so you may need to makesure that construct works in batch files. As of this writing,4DOS/NT users will need a "ParameterChar = *" statement in their4NT.INI file or will need to execute "setdos /p*" in the 4DOS/NTstartup file to enable this to work.

3

Using "pl2bat" has a few problems: the file name gets changed,so scripts that rely on $0 to find what they must do may notrun properly; running "pl2bat" replicates the contents of theoriginal script, and so this process can be maintenance intensiveif the originals get updated often. A different approach thatavoids both problems is possible.

A script called "runperl.bat" is available that can be copiedto any filename (along with the .bat suffix). For example,if you call it "foo.bat", it will run the file "foo" when it isexecuted. Since you can run batch files on Windows platforms simplyby typing the name (without the extension), this effectivelyruns the file "foo", when you type either "foo" or "foo.bat".With this method, "foo.bat" can even be in a different locationthan the file "foo", as long as "foo" is available somewhere onthe PATH. If your scripts are on a filesystem that allows symboliclinks, you can even avoid copying "runperl.bat".

Here's a diversion: copy "runperl.bat" to "runperl", and type"runperl". Explain the observed behavior, or lack thereof. :)Hint: .gnidnats llits er'uoy fi ,"lrepnur" eteled :tniH

Miscellaneous Things

A full set of HTML documentation is installed, so you should beable to use it if you have a web browser installed on yoursystem.

perldoc is also a useful tool for browsing information containedin the documentation, especially in conjunction with a pagerlike less (recent versions of which have Windows support). You mayhave to set the PAGER environment variable to use a specific pager."perldoc -f foo" will print information about the perl operator"foo".

One common mistake when using this port with a GUI library like Tkis assuming that Perl's normal behavior of opening a command-linewindow will go away. This isn't the case. If you want to start a copyof perl without opening a command-line window, use the wperlexecutable built during the installation process. Usage is exactlythe same as normal perl on Windows, except that options like -hdon't work (since they need a command-line window to print to).

If you find bugs in perl, you can run perlbug to create abug report (you may have to send it manually if perlbug cannotfind a mailer on your system).

BUGS AND CAVEATS

Norton AntiVirus interferes with the build process, particularly ifset to "AutoProtect, All Files, when Opened". Unlike large applicationsthe perl build process opens and modifies a lot of files. Having thethe AntiVirus scan each and every one slows build the process significantly.Worse, with PERLIO=stdio the build process fails with peculiar messagesas the virus checker interacts badly with miniperl.exe writing configurefiles (it seems to either catch file part written and treat it as suspicious,or virus checker may have it "locked" in a way which inhibits miniperlupdating it). The build does complete with

  1.    set PERLIO=perlio
    2.

but that may be just luck. Other AntiVirus software may have similar issues.

Some of the built-in functions do not act exactly as documented inperlfunc, and a few are not implemented at all. To avoidsurprises, particularly if you have had prior exposure to Perlin other operating environments or if you intend to write codethat will be portable to other environments, see perlportfor a reasonably definitive list of these differences.

Not all extensions available from CPAN may build or work properlyin the Windows environment. See Building Extensions.

Most socket() related calls are supported, but they may notbehave as on Unix platforms. See perlport for the full list.

Signal handling may not behave as on Unix platforms (where itdoesn't exactly "behave", either :). For instance, calling die()or exit() from signal handlers will cause an exception, since mostimplementations of signal() on Windows are severely crippled.Thus, signals may work only for simple things like setting a flagvariable in the handler. Using signals under this port shouldcurrently be considered unsupported.

Please send detailed descriptions of any problems and solutions thatyou may find to <[email protected]>, along with the outputproduced by perl -V.

ACKNOWLEDGEMENTS

The use of a camel with the topic of Perl is a trademarkof O'Reilly and Associates, Inc. Used with permission.

AUTHORS

This document is maintained by Jan Dubois.

SEE ALSO

perl

HISTORY

This port was originally contributed by Gary Ng around 5.003_24,and borrowed from the Hip Communications port that was availableat the time. Various people have made numerous and sundry hackssince then.

GCC/mingw32 support was added in 5.005 (Nick Ing-Simmons).

Support for PERL_OBJECT was added in 5.005 (ActiveState Tool Corp).

Support for fork() emulation was added in 5.6 (ActiveState Tool Corp).

Win9x support was added in 5.6 (Benjamin Stuhl).

Support for 64-bit Windows added in 5.8 (ActiveState Corp).

Last updated: 10 September 2011

Page index
 
Source : perldoc.perl.org - Official documentation for the Perl programming language
Site maintained by Jon Allen (JJ)     See the project page for more details
Documentation maintained by the Perl 5 Porters
(Sebelumnya) Perl for Stratus VOSAnyDBM_File - provide framewor ... (Berikutnya)