was extracted. Make sure you read and understand the terms under
which this software is being distributed.
-Also make sure you read the L<BUGS AND CAVEATS> section below for the
+Also make sure you read L<BUGS AND CAVEATS> below for the
known limitations of this port.
The INSTALL file in the perl top-level has much information that is
extension dll's under the lib\auto directory. If the build fails for
any reason, make sure you have done the previous steps correctly.
+The build process may produce "harmless" compiler warnings (more or
+less copiously, depending on how picky your compiler gets). The
+maintainers are aware of these warnings, thankyouverymuch. :)
+
When building using Visual C++, a perl95.exe will also get built. This
executable is only needed on Windows95, and should be used instead of
perl.exe, and then only if you want sockets to work properly on Windows95.
perl -e "print 'foo'; print STDERR 'bar'" 2> blurch | less
-Discovering the usage of the "command.com" shell on Windows95
+Discovering the usefulness of the "command.com" shell on Windows95
is left as an exercise to the reader :)
=item Building Extensions
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.06.tar.gz
+ http://www.perl.com/CPAN/authors/id/GSAR/libwin32-0.08.tar.gz
See the README in that distribution for building and installation
instructions. Look for later versions that may be available at the
the 5.004 release of perl, at which point the need for a dedicated
bundle such as the above should diminish.
+=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
changes in any of these areas: build process, installation structure,
supported utilities/modules, and supported perl functionality.
In particular, functionality specific to the Win32 environment may
-ultimately be supported as either core modules or extensions. This
-means that you should be prepared to recompile extensions when binary
-incompatibilites arise due to changes in the internal structure of
-the code.
-
-The DLLs produced by the two supported compilers are incompatible
-with each other due to the conventions they use to export symbols,
-and due to differences in the Runtime libraries that they provide.
-This means that extension binaries built under either compiler will
-only work with the perl binaries built under the same compiler.
-If you know of a robust, freely available C Runtime that can
-be used under win32, let us know.
+ultimately be supported as either core modules or extensions. The
+beta status implies, among other things, that you should be prepared
+to recompile extensions when binary incompatibilites arise due to
+changes in the internal structure of the code.
+
+An effort has been made to ensure that the DLLs produced by the two
+supported compilers are compatible with each other (despite the
+best efforts of the compiler vendors). Extension binaries produced
+by one compiler should also coexist with a perl binary built by
+a different compiler. In order to accomplish this, PERL.DLL provides
+a layer of runtime code that uses the C Runtime that perl was compiled
+with. Extensions which include "perl.h" will transparently access
+the functions in this layer, thereby ensuring that both perl and
+extensions use the same runtime functions.
If you have had prior exposure to Perl on Unix platforms, you will notice
this port exhibits behavior different from what is documented. Most of the
=item *
-The following functions are currently unavailable: C<fork()>, C<exec()>,
+The following functions are currently unavailable: C<fork()>,
C<dump()>, C<chown()>, C<link()>, C<symlink()>, C<chroot()>,
C<setpgrp()>, C<getpgrp()>, C<setpriority()>, C<getpriority()>,
C<syscall()>, C<fcntl()>. This list is possibly very incomplete.
=item *
+crypt() is not available due to silly export restrictions. It may
+become available when the laws change. Meanwhile, look in CPAN for
+extensions that provide it.
+
+=item *
+
Various C<socket()> related calls are supported, but they may not
behave as on Unix platforms.
=item *
Signal handling may not behave as on Unix platforms (where it
-doesn't exactly "behave", either :).
+doesn't exactly "behave", either :). For instance, calling C<die()>
+or C<exit()> from signal handlers will cause an exception, since most
+implementations of C<signal()> on Win32 are severely crippled.
+Thus, signals may work only for simple things like setting a flag
+variable in the handler. Using signals under this port should
+currently be considered unsupported.
=item *
=back
+This document is maintained by Gurusamy Sarathy.
+
=head1 SEE ALSO
L<perl>
Borland support was added in 5.004_01 (Gurusamy Sarathy).
-Last updated: 11 June 1997
+Last updated: 25 July 1997
=cut
projects / p5sagit/p5-mst-13.2.git / blobdiff