+The crucial thing to understand about the "cmd" shell (which is
+the default on Windows NT) is that it does not do any wildcard
+expansions of command-line arguments (so wildcards need not be
+quoted). It also provides only rudimentary quoting. The only
+(useful) quote character is the double quote ("). It can be used to
+protect spaces in arguments and other special characters. The
+Windows NT documentation has almost no description of how the
+quoting rules are implemented, but here are some general observations
+based on experiments: The shell breaks arguments at spaces and
+passes them to programs in argc/argv. Doublequotes can be used
+to prevent arguments with spaces in them from being split up.
+You can put a double quote in an argument by escaping it with
+a backslash and enclosing the whole argument within double quotes.
+The backslash and the pair of double quotes surrounding the
+argument will be stripped by the shell.
+
+The file redirection characters "<", ">", and "|" cannot be quoted
+by double quotes (there are probably more such). Single quotes
+will protect those three file redirection characters, but the
+single quotes don't get stripped by the shell (just to make this
+type of quoting completely useless). The caret "^" has also
+been observed to behave as a quoting character (and doesn't get
+stripped by the shell also).
+
+Here are some examples of usage of the "cmd" shell:
+
+This prints two doublequotes:
+
+ perl -e "print '\"\"' "
+
+This does the same:
+
+ perl -e "print \"\\\"\\\"\" "
+
+This prints "bar" and writes "foo" to the file "blurch":
+
+ perl -e "print 'foo'; print STDERR 'bar'" > blurch
+
+This prints "foo" ("bar" disappears into nowhereland):
+
+ perl -e "print 'foo'; print STDERR 'bar'" 2> nul
+
+This prints "bar" and writes "foo" into the file "blurch":
+
+ perl -e "print 'foo'; print STDERR 'bar'" 1> blurch
+
+This pipes "foo" to the "less" pager and prints "bar" on the console:
+
+ perl -e "print 'foo'; print STDERR 'bar'" | less
+
+This pipes "foo\nbar\n" to the less pager:
+
+ perl -le "print 'foo'; print STDERR 'bar'" 2>&1 | less
+
+This pipes "foo" to the pager and writes "bar" in the file "blurch":
+
+ perl -e "print 'foo'; print STDERR 'bar'" 2> blurch | less
+
+
+Discovering the usefulness of the "command.com" shell on Windows95
+is left as an exercise to the reader :)
+
+=item Building Extensions
+
+The Comprehensive Perl Archive Network (CPAN) offers a wealth
+of extensions, some of which require a C compiler to build.
+Look in http://www.perl.com/ for more information on CPAN.
+
+Most extensions (whether they require a C compiler or not) can
+be built, tested and installed with the standard mantra:
+
+ perl Makefile.PL
+ $MAKE
+ $MAKE test
+ $MAKE install
+
+where $MAKE is whatever 'make' program you have configured perl to
+use. Use "perl -V:make" to find out what this is. Some extensions
+may not provide a testsuite (so "$MAKE test" may not do anything, or
+fail), but most serious ones do.
+
+It is important that you use a supported 'make' program, and
+ensure Config.pm knows about it. If you don't have nmake, you can
+either get dmake from the location mentioned earlier, or get an
+old version of nmake reportedly available from:
+
+ ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
+
+Another option is to use the make written in Perl, available from
+CPAN:
+
+ http://www.perl.com/CPAN/authors/id/NI-S/Make-0.03.tar.gz
+
+Note that MakeMaker actually emits makefiles with different syntax
+depending on what 'make' it thinks you are using. Therefore, it is
+important that one of the following values appears in Config.pm:
+
+ make='nmake' # MakeMaker emits nmake syntax
+ make='dmake' # MakeMaker emits dmake syntax
+ any other value # MakeMaker emits generic make syntax
+ (e.g GNU make, or Perl make)
+
+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 supported
+C compilers. You must make sure you have set up the environment for
+the compiler for command-line compilation.
+
+If a module does not build for some reason, look carefully for
+why it failed, and report problems to the module author. If
+it looks like the extension building support is at fault, report
+that with full details of how the build failed using the perlbug
+utility.
+
+=item Command-line Wildcard Expansion
+
+The default command shells on DOS descendant operating systems (such
+as they are) usually do not expand wildcard arguments supplied to
+programs. 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 the
+behavior of the argv expansion code differs depending on the
+compiler, and it is even buggy on some compilers). Besides, it may
+be a source of frustration if you use such a perl binary with an
+alternate shell that *does* expand wildcards.
+
+Instead, the following solution works rather well. The nice things
+about it: 1) you can start using it right away 2) it is more powerful,
+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 4) you can
+extend the method to add any customizations (or even entirely
+different kinds of wildcard expansion).
+
+ C:\> copy con c:\perl\lib\Wild.pm
+ # Wild.pm - emulate shell @ARGV expansion on shells that don't
+ use File::DosGlob;
+ @ARGV = map {
+ my @g = File::DosGlob::glob($_) if /[*?]/;
+ @g ? @g : $_;
+ } @ARGV;
+ 1;
+ ^Z
+ C:\> set PERL5OPT=-MWild
+ C:\> perl -le "for (@ARGV) { print }" */*/perl*.c
+ p4view/perl/perl.c
+ p4view/perl/perlio.c
+ p4view/perl/perly.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+
+Note there are two distinct steps there: 1) You'll have to create
+Wild.pm and put it in your perl lib directory. 2) You'll need to
+set the PERL5OPT environment variable. If you want argv expansion
+to be the default, just set PERL5OPT in your default startup
+environment.
+
+If you are using the Visual C compiler, you can get the C runtime's
+command line wildcard expansion built into perl binary. The resulting
+binary will always expand unquoted command lines, which may not be
+what you want if you use a shell that does that for you. The expansion
+done is also somewhat less powerful than the approach suggested above.
+
+=item Win32 Specific Extensions
+
+A number of extensions specific to the Win32 platform are available
+from CPAN. You may find that many of these extensions are meant to
+be used under the Activeware port of Perl, which used to be the only
+native port for the Win32 platform. Since the Activeware port does not
+have adequate support for Perl's extension building tools, these
+extensions typically do not support those tools either, and therefore
+cannot be built using the generic steps shown in the previous section.
+
+To ensure smooth transitioning of existing code that uses the
+ActiveState port, there is a bundle of Win32 extensions that contains
+all of the ActiveState extensions and most other Win32 extensions from
+CPAN in source form, along with many added bugfixes, and with MakeMaker
+support. This bundle is available at:
+
+ http://www.perl.com/CPAN/authors/id/GSAR/libwin32-0.14.zip
+
+See the README in that distribution for building and installation
+instructions. Look for later versions that may be available at the
+same location.
+
+=item Running Perl Scripts
+
+Perl scripts on UNIX use the "#!" (a.k.a "shebang") line to
+indicate to the OS that it should execute the file using perl.
+Win32 has no comparable means to indicate arbitrary files are
+executables.
+
+Instead, all available methods to execute plain text files on
+Win32 rely on the file "extension". There are three methods
+to use this to execute perl scripts:
+
+=over 8
+
+=item 1
+
+There is a facility called "file extension associations" that will
+work in Windows NT 4.0. This can be manipulated via the two
+commands "assoc" and "ftype" that come standard with Windows NT
+4.0. Type "ftype /?" for a complete example of how to set this
+up for perl scripts (Say what? You thought Windows NT wasn't
+perl-ready? :).
+
+=item 2
+
+Since file associations don't work everywhere, and there are
+reportedly bugs with file associations where it does work, the
+old method of wrapping the perl script to make it look like a
+regular batch file to the OS, may be used. The install process
+makes available the "pl2bat.bat" script which can be used to wrap
+perl scripts into batch files. For example:
+
+ pl2bat foo.pl
+
+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 to
+refer to all the command line arguments, so you may need to make
+sure that construct works in batch files. As of this writing,
+4DOS/NT users will need a "ParameterChar = *" statement in their
+4NT.INI file, or will need to execute "setdos /p*" in the 4DOS/NT
+startup file to enable this to work.
+
+=item 3
+
+Using "pl2bat" has a few problems: the file name gets changed,
+so scripts that rely on C<$0> to find what they must do may not
+run properly; running "pl2bat" replicates the contents of the
+original script, and so this process can be maintenance intensive
+if the originals get updated often. A different approach that
+avoids both problems is possible.
+
+A script called "runperl.bat" is available that can be copied
+to any filename (along with the .bat suffix). For example,
+if you call it "foo.bat", it will run the file "foo" when it is
+executed. Since you can run batch files on Win32 platforms simply
+by typing the name (without the extension), this effectively
+runs the file "foo", when you type either "foo" or "foo.bat".
+With this method, "foo.bat" can even be in a different location
+than the file "foo", as long as "foo" is available somewhere on
+the PATH. If your scripts are on a filesystem that allows symbolic
+links, 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
+
+=back
+
+=item Miscellaneous Things
+
+A full set of HTML documentation is installed, so you should be
+able to use it if you have a web browser installed on your
+system.
+
+C<perldoc> is also a useful tool for browsing information contained
+in the documentation, especially in conjunction with a pager
+like C<less> (recent versions of which have Win32 support). You may
+have to set the PAGER environment variable to use a specific pager.
+"perldoc -f foo" will print information about the perl operator
+"foo".
+
+If you find bugs in perl, you can run C<perlbug> to create a
+bug report (you may have to send it manually if C<perlbug> cannot
+find a mailer on your system).
+
+=back