Inside the New Perl Resource Kit

Quantum leaps of functionality in well-established technologies, especially programming languages, aren't common. However, Perl Resource Kit--Win32 Edition is a quantum leap for Perl on the Win32 platform. The Perl resource kit is a product of O'Reilly & Associates, but ActiveState Tool contributed the new Win32 Perl software on the kit's CD-ROM. The resource kit contains advances in functionality that will significantly affect the Windows NT and Perl communities. These advancements include a new release of Perl, new tools and utilities, and extensive documentation.

New Release of Perl
The most significant advancement in the Perl resource kit is the release of Perl 5.005. This version consolidates the two most popular Win32 builds of Perl: CORE and Perl for Win32. Before version 5.005, users chose between these Win32 Perl implementations because the two builds offered different functions in some areas and implemented the same functions differently in others. Their disparity resulted in code that ran under one build but not the other. Version 5.005 effectively merges the two builds into one comprehensive package that eliminates past incompatibilities.

Fortunately, there are only minor code incompatibilities between version 5.005 and previous versions of CORE and Perl for Win32. The area primarily affected deals with Object Linking and Embedding (OLE) support. People who used ActiveState's OLE implementation will need to change the way they instantiate and access objects. This incompatibility and the other minor incompatibilities are well documented in the resource kit's release notes.

New Tools and Utilities
Perl 5.005 isn't the only software in the Perl resource kit. The kit also includes ActiveState's Perl Debugger, Perl for Internet Server API (ISAPI), Perl for Website, PerlScript, and Perl2Exe. Three new commercial software packages that I like are Perl Package Manager (PPM), PerlCOM, and PerlCtrl.

PPM. With PPM, users easily install, manage, and remove add-on Perl packages. Packages are third-party libraries, such as modules and extensions, that extend Perl's capabilities. For example, the Win32::AdminMisc module I discussed in last month's column ("How to Manage Your Enterprise's Passwords the Easy Way," August 1998) is a package.

If you are a long-time Perl user, you probably know about the hassles involved with installing, managing, and removing packages. For example, if you install a new version of Perl, you must verify that the code in your existing modules doesn't break. If problems arise, you must find a module update that is compatible with the new version of Perl. If an update module isn't available, you remove the Perl upgrade and wait until the module developer releases an updated version. Another problem users encounter when installing packages is that some packages require numerous installation steps, including a compilation phase that is beyond the scope of many Perl users.

With PPM, configuring third-party Perl packages is a snap. PPM comes in two versions: a console-based version, which retains the name PPM, and a browser-based version, Visual Package Manager (VPM). PPM and VPM have three primary functions: Install, which installs a new package from a specified repository URL; Remove, which removes a currently installed package; and Verify, which verifies whether an installed package is up-to-date and optionally updates the package if it's not.

Installing packages with VPM takes only a few mouse clicks. You select the URL repository, select which packages you want to download, and click Install, as Screen 1, page 196, shows.

Only time will tell how useful VPM and PPM will be. However, my prediction is that these two management tools will reduce the complexity and frustration with using third-party packages.

PerlCOM. With PerlCOM, you create instances of Perl and Perl modules from within any programming environment that supports Microsoft's component object model (COM), including Windows Scripting Host (WSH), Visual Basic (VB), Visual Basic for Applications (VBA), and Delphi. A PerlCOM.Script object makes PerlCOM's magic possible.

PerlCtrl. With PerlCtrl, you build COM automation servers in Perl. A COM automation server is a self-contained reusable .dll file that exposes methods and properties that any COM controller can instantiate and use.

With the Perl resource kit, using third-party packages is a snap.

The difference between PerlCOM and PerlCtrl is that PerlCOM is a COM automation server that exposes the PerlCOM.Script object and associated methods. PerlCtrl lets you build your own COM servers complete with their unique GUIDs and ProgIDs. ProgIDs are the friendly names you use to refer to an object class. For example, PerlCOM.Script and WScript.Shell are ProgIDs. Let's look at a PerlCOM example. I'll demonstrate PerlCtrl in a future column.

PerlCOM in Action
Suppose you want to use WSH with Visual Basic Script (VBScript) to execute an external command and capture the command's standard output. Although you can use WSH's Run method via the Shell object to execute the command, no simple method exists to capture the command's output. Instead, you must redirect the command's output to a file, open the file, parse it, close it, and finally delete the file.

Executing a command and capturing its output are much easier with the Perl resource kit because you can execute the Perl code via the PerlCOM object. The example BackTicks.vbs script in Listing 1 shows you how to create and use a PerlCOM object. Let's examine how this script works.

Like other objects used from within a WSH script, you first need to create an object of type "PerlCOM.Script" to execute Perl code. At callout A in Listing 1, the PerlCOM object is objPerlCOM. You use the EvalScript method to execute standard Perl code. With EvalScript, you can create Perl variables that become properties of the PerlCOM object, or define Perl subroutines that become methods of the object.