- Shopping Bag ( 0 items )
Ships from: Avenel, NJ
Usually ships in 1-2 business days
This book is a guide to Perl¿s most common Win32 extensions, grouped by their functionality. The new edition updates coverage from Perl 5.05 to current Perl version 5.6. It also includes new chapters offering critical, badly-needed information regarding security for Win32Perl, the topic most highly requested by reviewers. The appendices have descriptions and syntax of each function in the extensions covered. Each chapter makes extensive use of code segments to illustrate the use of specific functions and real world scenarios in which these functions can be used.
The command processor is the default shell for various versions of Microsoft DOS. This shell has had minimal functions for processing hatched commands. This has forced administrators to write slightly complex programs in some languages such as C, Pascal, and BASIC. Only the most simple of tasks can be automated using the command processor's batching capabilities.
Not only did Hip Communications' Win32 Perl provide most of the functionality of the UNIX flavors of Perl, it also extended itself into the Win32 API. This provided an interface into the Win32-specific world of administration. Now it was possible not only to process Perl scripts, but also to access the computer's Registry, event logs, user databases, and various other features that are found only on Windows 95 and NT.
Since the Win32 Perl debut there have been many so-called builds, with each one fixing bugs and adding more functionality to its predecessor. Hip Communications continued to develop its version of Perl build by build. To be sure, there were other versions of Perl that would run on the Win32 platform. Some were ingenious enough to implement things that eluded Hip's port, like the fork() command (as the Win32 port from Mortice Kern Systems [MKS] provided).
The Hip port finally gained the acceptance of the group of programmers committed to developing different ports of Perl (the Perl Porters group). There were technical differences between the original version of Perl and the Win32 version (for example, Hip's port used C++ classes to encapsulate Perl's functionality). These differences kept the two versions of Perl (the original "core distribution" and Hip's Win32 Port) from merging together.
More information regarding the Perl Porters group can he found at
Since Hip Communications released the original version of Win32 Perl, much has changed. Hip changed its name from Hip Communications, Inc., to ActiveWare. Then O'Reilly & Associates teamed with ActiveWare to create the ActiveState Tool Corporation. The Perl Porters group worked together with Hip (which later became ActiveWare and then even later yet renamed itself to ActiveState) to make the core distribution compile and run on the Win32 platform.
Beginning with Perl 5.005, ActiveState dubbed its Win32 build of Perl as ActivePerl. Basically, this was the core distribution version of Perl 5.005 but with the Win32 library of extensions included with the distribution package. Additionally, there are some built-in functions that are native to Win32 platforms only.
Starting with Perl v5.6 (aka Perl 5.006), both the ActiveState version of Perl and the core distribution have merged into one code base. This means that anyone can download the Perl v5.6 source code and compile it for Solaris, Macintosh, or Win32 (among other platforms). The Perl Porters group has done some incredible work to provide true crossplatform compatibility for version 5.6. This includes the much-sought-after features such as fork() emulation.
There are drawbacks, however, to manually compiling Perl. If you choose to compile Perl yourself, there could be complications. You need to keep in mind that any modifications you make (such as changing the standard C macro definitions) might result in binary incompatibility. This means that extensions that were compiled for the standard ActivePerl distribution might not work with your compiled version. You would have to recompile each extension you want to use.
Another problem with compiling your own copy of Perl is that there are a couple of extra components that ActivePerl distributes with its precompiled packages that are not available in source code form. These valueadded components extend Perl beyond a simple scripting tool. These additions consist of an Information Server API (ISAPI) application called PerlIS.DLL and a Windows Shell Host engine known as PerlScript.
The PerlIS.DLL file is a clever ISAPI application that enables an ISAPI server (such as a Microsoft's IIS Web server) to quickly load and run Perl scripts. This application does not cause the script to run any more quickly than it normally would, but it does speed up the loading of the script because it can cache Perl scripts in memory. On busy Web servers, this extension can make a noticeable difference in CPU use.
PerlIS performs its magic by executing scripts in the same process as the Web server itself. Therefore, there is no new process created for each script that is run, resulting in less memory use and a smaller performance hit (because there is no overhead for creating new processes). Additionally, Perl scripts are cached in memory, so there is less time overhead to load the script from disk. What is even greater is that the script is cached in its compiled state; there is no need to recompile, so even that overhead is minimized.
Even though PerlIS is a wonderfully useful tool, there are some slight limitations. See Chapter 12, "Common Mistakes and Troubleshooting," for more details.
Because a WSH engine is really a COM server, any application that can interact directly with COM (for example, Visual Basic, C, Pascal, and so on) can create instances of PerlScript. For example, a C++ program could create an instance of a PerlScript object so that it can utilize Perl's regular expression capability and even interact with Perl extensions. Such functionality could be used to provide a program with awesome macro functionality (in the form of Perl scripts). An application can use a WSH engine for scripting like macros. Consider that Microsoft Word's macro language (Visual Basic for Applications) can instantiate a Perl script by utilizing the Perl WSH engine. This also means that an application could execute Perl scripts on remote machines by using DCOM....
1. Why Perl on your Win32 machine?
2. Network Administration.
3. Administration of Machines.
4. File Management.
9. Console, Sound, and Administrative Win32 Extensions.
10. Writing Your Own Extension.
12. Common Mistakes and Troubleshooting.