| Store | Cart

ActiveState Docs

PDK 7.3 Documentation


Perl Dev Kit: Release Notes


ActiveState's Perl Dev Kit gives Perl developers tools to build stand-alone executables, check code coverage, and intuitively create filters for searching and replacing text in files. Additional tools are included on Windows for creating system tray applications, ActiveX components, Windows services, MSI installers and .NET compliant objects in Perl; converting VBScript into Perl; and graphically debugging your Perl programs.

The Perl Dev Kit requires ActivePerl build 638 or later.

If you have problems downloading Perl Dev Kit, please contact webmaster@ActiveState.com.

What's New in Perl Dev Kit 7.3?

All Command-Line Tools - PerlApp, PerlCtrl, PerlNET, PerlSvc, PerlTray

  • New --warnings option will display all warnings produced during a build without showing all the included files that --verbose does.

  • Heuristics have been added to completely suppress some build-time errors and warnings that are known to be incorrect (e.g. it is impossible that the VMS::Stdio module might be required because it cannot even be compiled anywhere except on VMS). Previous versions just downgraded these error messages to warnings.

    The tools will also display a summary count of all errors and warnings to make sure this information doesn't get lost in the potentially long verbose output.

  • Module heuristcs have been improved for Class::C3, DBIx::Class and others.

  • Heuristics for external libraries have been improved. For example on Windows Crypt::SSLeay would always trigger an additional dependency on ssleay32.dll and libeay32.dll if they could be found on the PATH because the PPM versions of Crypt::SSLeay from popular repositories depended on these libraries. The Crypt::SSLeay version included with the latest releases of ActivePerl however doesn't need these additional libraries (it statically includes the parts of OpenSSL it needs). The updated heuristics make sure that the additional libraries are only bundled when they are actually referenced by the module.

  • Heuristics for bundling Unicode support have been improved. Previous versions would often incorrectly detect a dependency on Unicode support, especially on Windows, where the Win32 module would trigger it.

  • ActivePerl 824 for Unix had to make some changes that made it incompatible with earlier PDK 7.x releases. Compatibility has been restored in PDK 7.3.

  • The 64-bit software for Solaris Sparc now works on Solaris 8 and later (earlier versions required Solaris 10).

Graphical Debugger

  • The Graphical Debugger in the PDK 7.1 and 7.2 releases did not work with a locally generated 21-day trial license. This has been fixed.

Known Issues in PDK 7.3


  • The 64-bit releases of the PDK contain only the commandline version of PerlApp. Therefore only the PDK Deployment Tools packages are available in 64-bit versions; these packages however can be used with PDK Pro and ActivePerl Pro Studio licenses.

  • On Windows installation of the Perl Dev Kit fails if attempted on a network mapped drive.

  • The .NET Framework needs to be installed before the PDK. Otherwise PerlNET can not be installed.

All Command-Line Tools - PerlApp, PerlCtrl, PerlNET, PerlSvc, PerlTray

  • A bug in Ubuntu 8.0 Live CDs prevents it from loading applications generated by PerlApp. This bug has been fixed for Ubuntu 8.10. A workaround for 8.0 Live CDs is to manually create a link between the / and /cowdirectories (#79884 ):
        sudo ln -s / /cow

  • If, at runtime, you find that certain modules have not been included in your application, you must explicitly add those modules on the command line. Use the --add option to force the inclusion of a module. This is usually only needed for scripts using extensions that execute 'require' or 'do' operations at runtime.

  • When you try to build a freestanding executable that relies on an extension that in turn relies on libraries not loaded by Perl's standard dynamic loading mechanism (i.e. DynaLoader or XSLoader), these additional libraries are not included in the freestanding executable. For example, this is often the case with database client libraries. Since these libraries are not part of the freestanding executable, they must be present on the target machine and be accessible via the PATH environment variable. Alternatively (on Windows), you can bind such libraries into the executable using the --bind option.

  • Attempting to save files with high-bit characters in their names via the Perl Dev Kit's graphical interface causes the PDK to crash.

  • The Perl Dev Kit does not support modules using source filters (e.g. Switch, Filter::Util, and Filter::cpp). See perlfilter in the ActivePerl documentation or 'perldoc perlfilter' for more information on source filters in perl.

  • The Perl Dev Kit does not currently support the use of any options in conjunction with the --interactive option.

  • The Perl Dev Kit's graphical interface cannot reference icons with paths containing the ! character. However, if you run a PDK tool, the executable or control that is produced will contain the icon.


  • There may be unexpected effects when using fork() on Unix with either a Tk application or the --clean option (extracted files are deleted once the first process terminates; additional files may not be extracted because directories are already deleted, etc).


  • When a freestanding control is instantiated from either Perl itself (via Win32::OLE) or a process that has loaded a Perl interpreter, then that version of Perl must be ActivePerl 638 or later. The perl dll bundled with the control is ignored. It is not possible to load two different perl libraries into the same process.


  • The PDK contains two builds of PerlMSI; one that is compatible with both Perl 5.6 and 5.8, and one that is compatible with Perl 5.10. The former is installed in the lib directory in the Perl Dev Kit tree, and the latter in the lib58 directory. Please make sure you use the correct version depending on the Perl version you are working with.

  • The -o and -h command-line switches are not functional in this release.


  • --freestanding is still not completely freestanding; you also need to deploy perlXX.dll (where XX is 56, 58, or 510), perlXXnh73.dll and perlXXrt73.dll.

  • Callbacks from unmanaged code are not supported because PerlNET doesn't support the definition of new delegates.

  • This release of PerlNET does not allow you to define new .NET interfaces.

  • This release of PerlNET does not support:
    • the definition of properties with parameters

    • the definition of indexed properties

    • the definition of enumeration types

    • delegates on pure Perl types

    • the definition of delegates

Filter Builder

  • Some filter variables created with the Filter Builder may return errors when run from the command line.

  • When attempting to replace any character(s) with @ or $ using the Filter Builder, these characters will appear in the output with preceding backslashes (i.e. \@, \$). In addition, if the specified replacement is a dollar sign followed by an "and" sign (i.e. $&), the Filter Builder returns an error message.

VBScript Converter

  • The VBScript Converter does not handle multi-dimensional arrays correctly. It will assume that VB variables with more than one argument are function calls, not arrays, and try to generate function-call type code.

    For example, the following VBScript code:

      dim test_array(3, 3)
      test_string = test_array(2, 1)

    ...is converted by VBSPerl into:

      my @test_array;
      $test_string = @test_array(2,1);

    The Perl equivalent is actually:

      my @test_array;
      $test_string = $test_array[2 * (3 + 1) + 1];

  • Unbound accessors in VBScript are currently not converted in all situations. See the Limitations in VBA Code for an example.

  • If the VBScript loaded into the VBScript Converter contains high-bit characters, a 'wide character' warning message is generated. No data is lost, but the strings in the converted Perl code become UTF-8-encoded.

  • The VBScript Converter cannot load files with high-bit characters in their names.

  • The VBScript Converter does not support the conversion of VBScript embedded in ASP code.

What's New in Perl Dev Kit 7.2?

PerlNET support

PerlNET has been added back to the PDK.

  • PerlNET now supports ActivePerl 5.6, 5.8 and 5.10. There are 2 sets of runtime libraries: Perl58RT72.dll and Perl58NH72.dll are used by PerlNET assemblies built using ActivePerl 5.6 or 5.8. The libraries for ActivePerl 5.10 are called Perl510RT72.dll and Perl510NH72.dll.

    Please make sure you deploy the correct libraries with your projects!

  • The assembly loader in the .NET Framework 2.0 SP1 has a problem loading images with certain characteristics of the resources section. This prevents some assemblies created by earlier releases of PerlNET to be loaded by the latest version of .NET. PerlNET 7.2 will no longer create resource sections that trigger this problem in the .NET loader.

  • A memory leak has been fixed that happened when .NET code was accessing Perl variables that had overloaded string and number semantics. This includes accessing fields of PerlNET objects that have been implemented as pure .NET types (#73167 ).

  • PerlNET 7.2 and all assemblies generated by it now require the .NET 2.0 Framework (earlier versions of PerlNET used the .NET 1.1 Framework).

  • The installer will now automatically deselect the PerlNET feature when there is no .NET Framework installation on the target computer.

Enhancements and Bug Fixes

  • There have been several improvements in how additional bundled libraries are being loaded, both while using --dyndll, and without. This includes finding additional libraries automatically that are residing in the same directory as a Perl module (#73572 ).

  • PerlApp on OS X will now always use ActivePerl 5.10 and only fall back to ActivePerl 5.8 if 5.10 is not installed. You can force PerlApp to always use 5.8 by creating a symlink from /usr/local/ActivePerl-5.8/bin/perl to /usr/local/PDK/etc/pdk-perl.

  • Module heuristics have been updated.

What's New in Perl Dev Kit 7.1?

Perl 5.10 support

All tools included in PDK 7.1 support ActivePerl 5.6, 5.8 and 5.10.

Enhancements and Bug Fixes

  • The GUI tools now work correctly on OS X 10.5.

  • Unicode chars in login names used to confuse temp dir creation (#43697 ).

  • Additional installed Math::BigInt calculation engines will now be bundled automatically.

  • The value of $0 is now set correctly even when the application is executed by IIS.

  • Tooltips and balloons in PerlTray can now display Unicode strings (#69952 ).

  • Programs using the --dyndll option would sometimes crash on Windows Vista. This affected especially Win32::GUI applications. This problem has been fixed (#73717 ).

  • Support for pod2usage() function has been added (#20990 ).

  • A regression in PerlTray 7.0 has been fixed. The bug would terminate a PerlTray application early if it didn't define a ToolTip() callback (#68885 ).

Changed System Requirements

The only supported Perl 5.6 version is ActivePerl

The Linux release of PDK 7.1 now requires glibc version 2.3 or later.

The Solaris release of PDK 7.1 now requires Solaris 8 or later.

The Windows release of PDK 7.1 now requires Windows 2000 or later. Earlier Windows versions may continue to work for now, but are no longer supported.

What's New in Perl Dev Kit 7.0?

Coverage and Hotspot Analyzer

PerlCov is a new tool for analyzing code coverage and hotspots in Perl programs and test suites. Check out the overview!

Mac OS X support

PDK 7 includes PerlApp, Filter Builder and the new Coverage and Hotspot Analyzer for OS X. ActivePerl 816 or later is required for universal binary support in PerlApp.

New 64 bit support

64 bit commandline versions of PerlApp are now included for Linux (x64), Solaris (Sparc) and Windows (x64). 64 bit commandline versions of PerlCtrl, PerlSvc and PerlTray are also included in the Windows builds.

The 64 bit tools are available in a separate download. They must not be installed into the same directory as the 32 bit tools if both versions are installed on the same machine.

Improved 32 bit platform support

PDK 7 supports Solaris 10 on Intel (x86) hardware with the GUI interface to PerlApp, Filter Builder, and the Coverage and Hotspot Analyzer.

The PerlApp GUI and Filter Builder are now available for AIX 5.x too.

The commandline version of PerlApp is now available for HP-UX on Itanium.


  • The PDK now uses a dynamically linked libperl.so on Unix instead of including statically linked libperl.a in each generated executable. This allowed implementation of the --xclude option for Unix, and --dependent and --xclude applications are much smaller now.

    Only libperl.so from ActivePerl 819 and later is fully compatible with the new mechanism. PerlApp will use its own bundled libperl.so for older versions of ActivePerl. It also bundles a special libperl.so to use with Perl 5.6.

  • It is now possible to load the perl runtime (perlXX.dll or libperl.so) from a shared library specified with --use (#35829 ).

  • The --clean option now works on all platforms.

  • The --runlib option has always been documented to add the $PerlApp::RUNLIB directory to the PATH, but didn't actually do it. This has been fixed.

  • Applications built with the --dyndll option now work on systems that have the DEP (Data Execution Prevention) feature enabled (#36715 ).

  • Executables built using the --dyndll option no longer refuse to run on Windows 9X. Instead they operate as if they had been built without the --dyndll option, writing bundled DLL files to disk as necessary.

  • Various module dependency heuristics have been updated.

    For example PerlApp will now bind the required data files for Unicode::UCD and PDF::API2 automatically (#45710 ).

    On Windows ssleay32.dll and libeay32.dll are bound automatically when the Net::SSLeay or Cryt::SSLeay modules are being used.

    ALso on Windows the VC++ runtime libraries MSVCR70.dll and MSVCR71.dll will be included if an extension module has been linked against them (#67313 ).

  • PerlApp no longer includes the big Encode::XX modules (CN, JP, KR, and TW) by default in every application that uses the Encode module. They need to be requested explicitly by either a "use Encode::XX" statement in the source, or by an --add commandline option.

    Similarly modules from the PDF::API2::Resource::CJKFont and PDF::API2::Resource::CMap hierarchies are not included by default and must be requested explicitly.

  • PerlApp in PDK 6 failed on some systems with an error message like "No perl found at C:\perl\bin\perl.exe" even though that executable was a perfectly fine and working version of ActivePerl. This did happen when the directory containing cmd.exe was not on the PATH. PerlApp will now always add the Windows system directory to the end of the PATH (#67034 ).


  • Controls generated by PerlCtrl no longer require administrator privileges to register on a target system. If the registration code does not have write access to the HKEY_CLASSES_ROOT hive then it will automatically register the control only for the current user (in HKEY_CURRENT_USER\Software\Classes).


  • PerlNET assmblies are now always marked as x86-platform specific. This guarantees that they will be loaded in 32-bit mode even on a 64-bit Windows installation.


  • The installer no longer adds the .../ActiveState Perl Dev Kit x.y/lib directory to PERL5LIB. You need to add this directory explicitly to either PERL5LIB, a -I commandline option, or a use lib statement when you want to use the MSI module.


  • PerlTray now invokes the new TimeChange() callback whenever the system clock changes. This is important because changes to the system clock does not change the expiration time for any running timers.

  • The ToolTip() callback was broken in PDK 6.0.2. The documented behavior has been restored. (#42035 ).

  • The Execute() function used to fail when Win32::OLE was used in a PerlTray application. This has been fixed by making sure that PerlTray always runs code in a single threaded apartment (#45885 ).

  • It used to be impossible to die() or exit() from inside a Download(), PopupMenu() or ToolTip() callback. These exceptions are no longer trapped and ignored, but will shut down the application now (#43802 ).

Filter Builder

  • Filter Builder now supports a mode where all selectors must match ("AND/OR" radiobutton in the pane title).

  • Filter Builder can now load data from a URL directly instead of just from a local file ("File > Open > Input Location").

Visual Package Manager

  • VPM has been superseded by the native PPM4 GUI included in ActivePerl 819 and later.

Release History

What's New in Perl Dev Kit 6.0.2?

Perl Dev Kit 6.0.2 is a bug fix release. The following bugs has been fixed:

  • PerlApp and the other deployment tools will try to honor the saved build directory in project files.

  • PerlApp and the other deployment tools will automatically set the build directory to the directory of the selected script.

  • The build directory of PerlApp and the other deployment tools now persists between sessions.

  • PerlApp and the other deployment tools have updated heuristics for HTTP::Message, Net::POP3, Regexp::Common, Test.pm, Tk::DropSite and utf8.pm.

  • It is now possible to add "." to the Module Search Path of PerlApp and the other deployment tools (#35492 ).

  • The Perl debugger will no longer try to use Term::ReadKey when using remote debugging (#39245 ).

  • Improved diagnostic when detecting a perl that is not binary compatible.

  • Under very rare circumstances the executables generated on Windows were not valid Win32 images. This has been fixed.

  • msiwiz.pl argument checking has been fixed (it has only 5 required arguments).

  • Avoid warning for perlapp --info "language = unknown" (#38581 ).

  • Make sure Perltray will always look for callback functions in the PerlTray:: namespace and not in the "current" package.

  • Prevent Tk from redefining exit() when running inside PerlTray (#35330 ).

A tutorial that demonstrates how to use Filter Builder has been added.

The Deployment Tools are now supported in a limited edition (only PerlApp command line version) for Solaris 10+ on x86.

What's New in Perl Dev Kit 6.0.1?

Perl Dev Kit 6.0.1 is a bug fix release to restore compatibility with ActivePerl and later. The Deployment Tools in Perl Dev Kit 6.0 did not properly detect and bundle the complete set of Unicode support files in Perl 5.8.6, creating spurious warnings and failures at runtime of the generated executables.

This change does not affect any of the Productivity Tools, nor the Deployment Tools when used with ActivePerl or earlier.

The Deployment Tools are now supported in a limited edition (only PerlApp command line version) for AIX.

What's New in Perl Dev Kit 6.0?

Multiple Perl Dev Kit packages

The Perl Dev Kit is now available in three different packages to better accommodate the differing needs of developers. All available features are included in the Perl Dev Kit Pro Pack. Users also have the option of purchasing the Perl Dev Kit Deployment Tools, which includes PerlApp, PerlCtrl, PerlMSI, PerlNET, PerlSvc and PerlTray, or the Perl Dev Kit Productivity Tools, which includes the new Filter Builder and VBScript Converter tools along with the Graphical Debugger.

Filter Builder

The Filter Builder is a graphical tool used to construct filters that match strings or Perl5 regular expressions in text based input files, such as log and XML files. You can also alter the contents of files by using the Filter Builder to specify replacement criteria to apply to the input. Filters created with the Filter Builder can be saved as Perl scripts and run from the command line.

VBScript Converter

The VBScript Converter is a graphical tool that translates VBScript code to its functional equivalent in Perl. The converter, which can also be run from the command line as vbsperl, simplifies tasks such as generating Perl code from VBScript snippets found on the internet and converting snippets of Visual Basic for Applications (VBA) code generated by macro recorders in Microsoft Office programs to Perl code for use in a separate application.

Graphical Interface for PDK Tools

Prior to this release, all of the Perl Dev Kit components, with the exception of the Graphical Debugger, could only be run from the command line. PerlApp, PerlCtrl, PerlNET, PerlSvc and PerlTray can all now be launched as graphical applications that offer all of the functionality available through the command-line interface. For more information, see the documentation for the individual PDK component.

Dynamic DLL Loader

The PDK now provides an internal library loader to load libraries directly into the process space without writing them to a temporary directory. This avoids cluttering the hard disk with temporary files, prevents problems that occur when two applications try to extract the same file at the same time, and improves application security. Enable this option in PerlApp, PerlSvc and PerlTray by selecting Use the in-memory dynamic DLL-loader at runtime on the Options 2 tab or using the --dyndll command-line option.

Shared Library Options

Options have been added to PerlApp, PerlCtrl, PerlSvc and PerlTray that make it possible to share executables and controls and specify run libraries. The command-line options include --runlib, --scan, --shared and --use. For more information, see the command-line reference for the specific tool. These features are also accessible via the Options 1 and Options 2 tabs in the graphical interface for these tools.

Perl Dev Kit Release: November 2003

All Command-Line Tools

  • Perl scripts can now be written in Unicode as long as they contain a BOM (byte order mark).

  • The Encode module is now supported for Perl 5.8. You may want to use the --trim option to remove encoding modules not needed by your application, as some of these encodings are large (about 800KB each for Encode::CN, Encode::JP, Encode::KR and Encode::TW).

  • The special :komodo port argument for the --debug option now uses port 9011 instead of 9010 to be compatible with the defaults of Komodo 2.5.

  • This applies to all tools except PerlApp: If during the runtime (not compilation) of the script body additional modules were compiled, and those modules defined additional END blocks, then those END blocks were executed as soon as the execution of the main script ended. At the time any PerlCtrl method, or any PerlSvc or PerlTray callback is executed, the END cleanup action has already happened.

    This problem does not apply to modules that are included directly or indirectly by the main script via "use" statements. The processing of their END blocks would properly be delayed until final Perl interpreter destruction.

    This problem has been fixed for Perl 5.8. For Perl 5.6 you must "use" the necessary modules in your main script to work around the problem.

  • When used with an evaluation license, all tools display a warning that the generated executables will stop working once the evaluation license expires.


  • The new type library format introduced with PDK 5.1 had a bug affecting property setter functions as well as all methods not returning a value. The generated type library could not be used from, for example, VB6. This has been corrected.

  • A memory leak has been fixed that affected all method calls on "factory" generated objects.

  • PerlCtrl now correctly handles return values of the Win32::OLE::Variant type correctly.

  • This release implements the passing of "by reference" arguments. Whenever a parameter is passed by reference to a control build using the --byref option, PerlCtrl passes it as a Win32::OLE::Variant object and does not convert it to a native Perl data type. The control method can now use the Put() instance method of this parameter to change the value of the caller's variable.

    If the version of Win32::OLE is greater than 0.17 (ActivePerl build 807 and later), then the "Variant" option is set implicitly by the --byref command-line option:

      Win32::OLE->Option(Variant => 1);

    The effect of this is that VT_CY and VT_DECIMAL values are always kept as Win32::OLE::Variant objects, even when they are not passed by reference.

  • PerlCtrl now correctly implements "by value" property assignments. If the assigned value is an object, PerlCtrl implicitly calls the object's default method to determine the value.

    Previously, the following VB statements had the same effect on the PerlCtrl object:

    perlobj.prop = obj Set perlobj.prop = obj

    Now the first statement invokes the default method, and the second does not.

  • Previously, PerlCtrl would not handle "factory" objects correctly if they weren't implemented as hash references. This has been fixed, and references to any kind of Perl object can now be returned by PerlCtrl.


  • Prior to this release, the AddLicenseText() method was used to replace all single quotes in the RTF text with the \rquote escape. This was incorrect if the quote was already part of a hex escape \'hh. These escapes will now be retained correctly.


  • PerlNET used to convert Perl strings into .NET Currency or Decimal types using the Windows system settings. For example, on a German or Danish setting it would ignore the '.' as a thousands separator and would expect the ',' as a decimal point. This has been changed to always use the '.' for the decimal point character because, internally, Perl doesn't use the Windows system settings for number/string autoconversion.

    In this release PerlNET does not pick up locale changes by, for example, POSIX::setlocale. This may be implemented in a future release. If you need full control over the conversion process, please use the System.Convert component of the .NET framework.

  • The destruction order of PerlNET objects was not deterministic, resulting in unexpected exceptions thrown during destruction, and some destructors not being executed at all. This has been fixed.

  • PDK 5.2 changed the way PerlNET implemented the IDisposable interface, but the code samples were not adjusted for this. The Babelfish and WordCount samples have been fixed to no longer assume that PerlNET would always generate an IDisposable implementation automatically.


  • Under Perl 5.8, a Perl service would automatically be stopped when the foreground user logged off. This is no longer the case.


  • PerlTray did not detect when the system was being shut down and didn't execute proper cleanup code in that situation. This release fixes the problem and also adds a ShutDown() callback to inform the application that the system is shutting down or that the user is logging off.

  • If the first argument to a PerlTray application started with a '-', then the parameter would be passed to the embedded Perl interpreter instead of the application. Now all parameters are passed correctly.

Graphical Debugger

  • High-bit characters in tooltips and watch values are no longer translated to hex notation. This makes it easier to read variable values containing text in languages using high-bit characters.


  • VPM now displays an error message and aborts if the HTTP_PROXY environment variable doesn't specify either of the http: or the https: protocol schemes.

Perl Dev Kit Release: July 2003

All Command-line Tools

  • The DATA filehandle is now supported.

  • The module dependency heuristics have been updated.

  • Capturing errors from STDERR on Windows 95/98/Me has been fixed.

  • The command-line tools would sometimes fail to work with error messages like:
      Died at perlxxx line yyy. myapp.pl had compilation errors.

    This problem seems to be related to shells not inheriting the current working directory, but setting a fixed startup directory, for example, via AutoRun for the cmd.exe shell. This problem has been fixed.

  • Applications using the threads module could not be syntax-checked with PDK 5.1 tools. This is due to a bug in Perl 5.8. PDK 5.2 contains a workaround for this problem.

  • Various bugs in handling version resources have been fixed (used by the --info command-line option). Also some defaults have changed: Language is now "Neutral" instead of "US English", and product and file versions are instead of

  • The return code of generated applications in PDK 5.1 was always either 0 or 255. Now they return again the value specified in the call to the exit() function.


  • Strings are now marshalled correctly as Unicode strings if Win32::OLE 0.16 or later is being used. Previous versions of PerlCtrl always coerced strings into the Latin1 codepage. Note that using Perl 5.8 is strongly recommended for any Perl operations involving Unicode.


  • Methods expected to return a string would throw an exception if the Perl code returned anything else, like a number or an object. PerlNET now generates code that makes sure that the return value is transformed into a string.

  • Previously, methods whose names started with "get" or "set" were treated as property accessors by PerlNET. This was an undocumented artifact from the time when PerlNET didn't have property support. These special cases have been removed, and methods starting with these prefixes now operate normally.

  • PerlNET would not create assemblies with strong names. You had to resign the assembly immediately after creation. This is no longer the case.

  • Custom attributes are now documented. Applying attributes to the assembly or to the type itself has been simplified. The attribute parameters now support all types supported by C#. With these enhancements it is now also possible to define new attributes in PerlNET.

  • PerlNET methods can now return single-dimensional arrays of arbitrary .NET types, including arrays of arrays.

  • PerlNET now implements "typed" null references to help with selecting the right version of overloaded methods.

  • The DESTROY methods of PerlNET objects were not receiving a reference to the object itself (making them quite useless). Now PerlNET supports an [interface: disposable] attribute to automatically generate the code to implement the IDisposable interface.

  • The exclamation mark after the "wantarray!" method modifier is no longer needed.


  • A new MyBackup.pl sample service from the PerlSvc webcast included.


  • The Win32::GUI module doesn't set up the Perl context correctly in Windows procedure callbacks. PerlTray now makes sure that the context is always set up.

  • Applications started via Execute() were hidden. Now they are created visible.

  • Runtime exceptions are now displayed to STDERR instead of being silently ignored. They are still not visible unless the application is built using the --nogui option for debugging.


  • Displays a warning if the installed version of ActivePerl is too old to run the VPM. The previous version of VPM would just silently hang forever if ActivePerl wasn't build 633 or later.

Perl Dev Kit Release: April 2003

All Command-Line Tools

  • The module dependency heuristics have been updated.

  • Error messages are improved.

  • Files from the Tk/demos directory are now always excluded, reducing the size of freestanding executables using Tk.


  • PerlCtrl now supports context sensitive help for the generated controls. The %TypeLib hash supports the new attributes HelpFileName, DocString and HelpContext. Each method and property can have a DocString and HelpContext attribute too. Check out the "Linking to Compiled HTML Help" page in the user guide for more information. The 'MyControl' sample has also been updated to show how this works.

  • The ReadOnly attribute on properties is now enforced at runtime. Previously, this was advisory only (listed in the type library), and you could still assign to a read only property at runtime. Now this generates an error.

  • Properties are now encoded differently in the generated type library (via accessor functions, and not as variables). This makes sure that they show up correctly in type library browsers, such as the OLE-Browser included with ActivePerl.

  • You can now specify additional properties of an exception by providing a hash reference instead of a string. For example:
      die { Source => "My.Control", Code => 42, Description => "Oh no!",
      HelpFile => "c:\\path\\to\\MyHelpFile.chm", HelpContext => 10 };

    A normal die "My fault" is equivalent to:

      die { Source => "My.Control", Code => 9, Description => "My fault" };

    The Source element defaults to the ProgID of your control and should normally not be changed. Code defaults to 9 for historical reasons. Note that VB recommends using codes above 1000 for custom errors. The HelpFile is automatically set to your control help file if you specify just the HelpContext.

  • Some host applications (e.g. KiXtart) don't clear the exception record before calling a PerlCtrl. This would sometimes result in an access violation if the control threw an exception. This bug has been fixed.

  • A small memory leak has been fixed. Every time you created and destroyed a PerlCtrl object, it used to leak about 260 bytes.

  • Calling "factory" objects in list context had been broken since PDK 5.0. This has been fixed.


  • PerlNET::extract_bound_file() and PerlNET::get_bound_file() were previously only available through the PerlApp:: namespace. They are now in PerlNET:: too.


  • The $Config{Dependencies} setting allows the specification of prerequisite services that must be started before this service can run. The value should be either a string or a reference to an array of strings.

  • $Config{StartNow} specifies if the service should be started immediately as part of the --install process. By default only services with an "auto" StartType are started immediately.

  • When the Startup() function is called, $Config{StartType} is now filled in correctly.


  • The new --singleton option specifies that only a single instance of the application is allowed to run. Additional instances forward their command-line parameters to the Singleton() callback of the already running instance, and then terminate immediately.

  • The new --nogui option marks the executable as a console application. This is useful for debugging because the output to STDOUT and STDERR is visible in the console window.

  • The Click() callback has been documented.

  • The new DisplayMenu() function displays the popup menu at the current cursor position. This function is typically invoked via a hotkey callback.

  • The new RegisterHotKey() function registers a global Windows hotkey and invokes a callback whenever the hotkey is pressed.

  • PerlTray now always uses the first icon specified via the --icon option as the default icon. All icons are available by name too (for SetAnimation() and SetIcon()).

  • Using Tk in a PerlTray application seems to unhide the hidden top level PerlTray window. Now PerlTray hides it again after parsing the Perl source.

  • The Download() function used to leak a handle and a little memory. It would also crash under certain circumstances. This has been fixed.

  • The Fortune sample program has been removed as the corresponding web service has become unavailable.

Graphical Debugger

  • For some modules (e.g. SOAP::Lite), the debugger would not display the source code. This has been fixed.

  • The debugger would sometimes crash when you clicked on a source code line longer than about 100 characters. This should no longer happen.

  • The Graphical Debugger used to be called the Visual Debugger. It has been renamed to reduce confusion for people using both the Perl Dev Kit and the Visual Perl plug-in for Microsoft Visual Studio .NET.


  • The VPM now supports proxies requiring a username and password. Please set up the corresponding environment variables as described in the PPM documentation.

  • The VPM is now more robust. The previous version wouldn't accept some valid repository specifications and also crashed when the repositories delivered inconsistent data (e.g. reporting a module in a search result that did not actually exist in the repository).

  • This version of VPM does not support ASPN profiles. Profile tracking is disabled inside VPM and any changes to the local installation will not be reported to the profile server.

Perl Dev Kit Release: December 2002

All Command-Line Tools:

  • On Perl 5.8, the XML::Parser module loads the utf8 module at runtime. This rule has been added to the dependency analyzer.


  • The links to MSI documentation on MSDN have been updated.


  • The plc command printed syntax errors to STDOUT. It now prints them to STDERR.


  • The Install() and Remove() callbacks were not called when using old-style configuration via $PerlSvc::Name. With new-style configuration via %PerlSvc::Config, Install() would be called twice, both before and after the installation. These errors have been corrected.


  • The Homeland Security sample application used the perlsvc instead of the perltray command in the build.bat file. This has been fixed.

  • The SlashTray sample needed to be built with the --add utf8 command-line option on Perl 5.8. Now PerlTray automatically recognizes that XML::Parser needs the utf8 module on Perl 5.8.

Perl Dev Kit Release: December 2002

Perl Dev Kit 5.0 supports both Perl 5.6 (ActivePerl build 6xx) and Perl 5.8 (ActivePerl build 8xx). It contains the following changes compared to Perl Dev Kit 4.1.

All Command-Line Tools - PerlApp, PerlCtrl, PerlNET, PerlSvc, PerlTray

  • All tools work with both ActivePerl 5.6 and ActivePerl 5.8. On Windows, dependent executables built with these tools will work with either version of Perl, as long as they don't bundle any DLLs.

  • All command-line tools now run a syntax check on the input script before building the executable.


  • The PerlCOM control has been discontinued in Perl Dev Kit 5.0, as PerlCtrl offers a more effective and flexible way to achieve the same results. PerlCOM is limited in that it only works on the machine that the PDK is installed on. It cannot be redistributed to other machines without acquiring a PDK license for those machines as well. Controls generated by PerlCtrl can be redistributed without restriction.


  • PerlNET now supports most of the same options as PerlApp. It also supports the same built-in variables and functions too, e.g. $PerlNET::VERSION or PerlNET::exe().

  • In PDK 4.0, the plc command would always overwrite an already existing output file. In PDK 5.0, you need to specify the --force option.

  • The variable $0 now contains the command-line command that started the application. Use PerlNET::exe() to determine the fully qualified path.

  • PerlNET now requires ActivePerl build 633 or later.


  • All Perl code is now executed within the same thread. This eliminates the problems with modules that need per-thread initialization, like Win32::ODBC or Win32::OLE.

  • PerlSvc now supports PAUSE and CONTINUE commands and corresponding callbacks.

  • The new Sleep(DELAY) method suspends the service for DELAY seconds, but returns early if the service receives a PAUSE, STOP or SHUTDOWN command. The ContinueRun() function now takes an optional DELAY argument to suspend execution for DELAY seconds, except for the very first time it is called. The new RunningAsService() function returns true when running as a service, and false otherwise.

  • The new InterActive() callback is invoked when the service is invoked from the command line, but without any of the --install, --remove, or --help options.

  • Instead of setting $PerlSvc::Name and $PerlSvc::DisplayName globally, the service can now also set up the %PerlSvc::Config hash inside the Install() and Remove() callbacks. The %Config hash supports additional options, like Parameters and Description, and allows you to install the same service multiple times using different names and parameters.

  • The PingSvc.pl sample has been changed to take advantage of the new functions. It is also now written in a style that works simultaneously as a normal Perl script, as a compiled interactive program and as a service.


  • The new PerlTray tool lets you easily write Windows system tray applications in Perl. For more information, see the associated documentation and samples.

Visual Debugger

  • There have been several bug fixes and improvements to address the way the debugger handles watch and proximity variables as well as tooltips. Previously, the debugger would sometimes hang if the variables contained binary data. The proximity window now recognizes a wider variety of indexed variables.

  • The debugger used to reset the input record separator $/ to newline "\n" on each "step" operation. This has been fixed.

Visual Package Manager - VPM

  • The Visual Package Manager has been completely rewritten. It is now based on the new Programmer's Package Manager (PPM3) and provides a much improved user interface. It supports multiple package repositories at the same time. The new VPM is available on Unix as well.

  • VPM requires ActivePerl 633 or later

Perl Dev Kit Release: August 2002

Perl Dev Kit 4.1.2 contains fixes for the following bugs in the 4.1.1 release:

  • PerlApp, PerlCtrl and PerlSvc, when used with ActivePerl build 633, would issue the following warning while building freestanding executables:

    &Digest::MD5::md5_hex function called with reference argument at /PerlApp/PerlApp/Util.pm line 252, <$f> line 1.

    A consequence of this bug is that applications not using the --clean options may still not share their version of perl56.dll.

    This bug also exists when using earlier versions of ActivePerl; they just wouldn't display the error message.

  • Modules located in the current directory were only included in --freestanding applications. Now they are added in --dependent applications as well.

  • PerlNET wouldn't work correctly if Perl itself was installed in a directory whose name contained spaces.

  • PerlCtrl didn't support multiple instances of the same component within a single process if the --clean was used.

This release also contains a reworked license agreement, which is linked directly into the HTML documentation on Windows as well as being included with the Unix tarballs.

Perl Dev Kit Release: May 2002

Perl Dev Kit 4.1.1 contains fixes for the following bugs in the 4.1 release:

  • PerlApp was broken for Tk applications.

  • The Visual Debugger didn't register itself correctly.

Perl Dev Kit Release: April 2002

Perl Dev Kit 4.1 is a free maintenance update for Perl Dev Kit 4.0; it does not require a new license. It contains the following bug fixes, enhancements and new features: PerlApp, PerlCtrl and PerlSvc

  • Additional heuristics for modules that need special treatment:

  • autouse

  • diagnostics

  • DBD::CSV

  • FindBin

  • SQL::Parser

  • Tk::Scrolled

  • Win32::SystemInfo

  • Downgraded some benign dependency errors to warnings, e.g. a missing SetDualVar module is only a warning when requested by Win32::TieRegistry.

  • --bind option accepts additional parameters. For example, to bind a text file, and extract writable:
      --bind data.txt[text,mode=0777]

    ...or to bind an executable and auto-extract on application start:

      --bind foo.exe[file=bin\myfoo.exe,extract]

    The extraction directory gets added to PATH (and LD_LIBRARY_PATH) if the application binds "auto-extract" files. It is also added to the front of @INC.

  • --gui and --help options now work even if Perl is installed in a path containing spaces.

  • --icon would only work with small icon files. Bigger icons (and version resource information) could render the executable unusable. This has been fixed.

  • --help improvements:
    • This option now supports optional parameters. For example:
          perlapp --help bind perlapp --help ENVIRONMENT

    • Help now has sections for FUNCTIONS, VARIABLES and DIAGNOSTICS.

    • Most filenames in the online help are localized to platform.

    • Options always use the '--' lead-in, even on Windows.

  • --info required 4 parts for file and version numbers. Missing elements are now assumed to be 0.

    There is no such thing as a "filenumber" or a "productnumber". They are "FileVersion" and "ProductVersion" respectively.

  • --lib now automatically adds version-specifc and architecture-specific subdirectories, just like PERL5LIB.

  • Use PERLLIB when PERL5LIB is not set.

  • The --script option is now supported for backwards compatibility with PDK 3.0

  • --trim option now supports the following wildcard notations:

    --trim Module::* will exclude Module::Foo, but neither Module itself nor Module::Foo::Bar. --trim Module::** will exclude Module::Foo and Module::Foo::Bar, but not Module. --trim Module:: works the same as --trim Module;Module::**, excluding all of Module, Module::Foo and Module::Foo::Bar. Note that you may have to quote the * character to prevent wildcard expansion by your command shell.

  • automatically assume --debug option if the #! line of the script contains -d

  • Diagnostics:
    • Filenames are now displayed in platform-native format (i.e. with backslashes on Windows)

    • An error message is produced when the spelling of file and module names don't match. For example:
        use Win32::Eventlog;

      ...instead of:

        use Win32::EventLog;

    • A warning is produced if the same (Tk) data file is embedded twice

    • PerlApp::exe() API, which returns the full path name to the application, is now documented. This function has been in PerlApp for Linux and Solaris since 3.0 and in PerlApp for Windows since 4.0. On Linux it used to return a symbolic link into the /proc file system. On Solaris it would return just a filename without a path if invoked from the current directory. Now it should return the fully resolved absolute path on all platforms.

    • New PerlApp::extract_bound_file() extracts bound files to a temporary location on the filesystem, which is automatically deleted when the process terminates.

    • All documented variables and functions are available via the PerlApp:: namespace, even from within PerlCtrl and PerlSvc. For example:

      ...can be called as:


    • New $PerlApp::BUILD variable contains PerlApp build number.

    • Applications were not in valid Win32 executable format, making it impossible to sign them with authentication information. This is now possible.

    • Some Tk configurations wouldn't work and showed an error like "...cannot write page.icon file". This has been fixed.


  • `perlapp ./hello` on Unix would overwrite the script with the "compiled" application.

  • PDK 4.0 would not be recognized by Komodo 1.2.5. PDK 4.1 works partially, but some options still won't work (e.g. bound files). Komodo 1.2 always builds freestanding executables. The outstanding issues will be fixed in an upcoming Komodo release.

  • Applications using Tk, created with PerlApp on Solaris, would sometimes coredump. This has been fixed.


  • Calling methods on Perl objects returned by a factory would only work if the caller provided a return value argument. For example:
      Retval = MyObj.Foo()

    ...but not when it was called as subroutine:

      MyObj.Foo ()

    This has been fixed. Note that this was not a problem when calling methods on the PerlCtrl object itself. Only methods on "other" Perl objects exhibited this bug.

  • Exception information wasn't properly passed back to the caller. Now the text of the die() message is returned as the exception information.

  • Stepping over a CoCreateInstance() call for a PerlCtrl inside Visual Studio produced an access violation. This has been fixed.

  • Calling c<exit()> inside a PerlCtrl method terminated the process. This has been fixed.

  • Additional callbacks: Constructor, RegisterServer and UnregisterServer.

  • PerlCtrl includes a couple of registry functions. Their interface is now documented. They are primarily useful in a RegisterServer callback.

  • Assume default values for missing %TypeLib elements. Better error checking for %TypeLib hash.

  • Using the Scalar() and List() methods on factory objects to specify a calling context didn't work. This has been fixed.

  • If the same Perl object was returned multiple times as a factory object, it would be prematurely destroyed (before it was returned the second time). This no longer happens.

  • PerlCtrl now works correctly even when PerlCOM is not installed. Dependent PerlCtrls also no longer require that PerlCOM is installed on the machine.


  • PerlMSI sometimes wouldn't extract the correct file version information. This would lead to MSI databases with missing version information, which in turn would not install correctly on machines with earlier versions of the same files already installed.


  • Modules using XS code wouldn't work in dependent assemblies.

  • Support for all "standard" value types has been added. Their full range of values can be passed back and forth between Perl and C# as method arguments, return values, and field and property values.

    As a consequence, all the value types are passed from .NET to Perl encapsulated as objects with overloaded stringification and numification rules. Otherwise they couldn't retain information about their original types.

    There are now constructors for all the basic .NET value types too. For example:

        my $ch = PerlNET::char('a');

  • All standard .NET value types support autoincrement/decrement ++/-- operators and show the same "wrap-around" behavior as the native .NET values.

  • PerlNET didn't work in non-English locales, and in the Pan-European Windows version, even when switched to the (US) English locale. This has been fixed.

  • --freestanding assemblies still needed --add overload. This has been fixed.

  • dependency detection was severely broken. This has been fixed.

  • Implemented "mixed" interfaces with both a $this and a $self argument.

  • non-private static fields didn't work at all (they were assumed to be Perl package variables). Now these package variables are automatically tied to the corresponding .NET static field.

  • The PerlNET::get() and PerlNET::set() helper functions to access static fields and properties have been documented.


  • The component was completely rewritten based on the new PerlApp codebase.

  • PerlSvc now automatically sets $PerlSvc::Name to the actual service name before calling PerlSvc::Startup().


  • The debugger no longer requires power-user privilege at runtime. However, it must still be installed by 'Administrator'.

  • In remote mode, watch variables were not updated after "Run to cursor" or "Run to Breakpoint". This has been fixed.

  • In remote mode, Quick-Eval didn't work. This has been fixed.


  • The remote package management didn't really work and has been removed. The user/password dialog box is gone too.

  • Some computers seem to have trailing '\0' characters stored in the file association for .html files. VPM wouldn't start the browser on these systems. This has been fixed.


  • On Unix, the installer now provides better error messages if PerlApp is not compatible with the version of Perl installed on the system.

  • On Windows, the installer works better when installing over a previous installation. We still recommend uninstalling any previous installation before installing PDK 4.1.

  • The Windows installer now properly recognizes .NET service packs instead of claiming that .NET is not installed when a service pack has been applied.

PDK Release: February 2002


  • PerlApp executables can now be built on Windows 95, 98 and Me.

  • PerlApp is now available on HP-UX too.

  • Custom icons can be attached to PerlApp executables.

  • Dependency determination has been improved. PerlApp now includes heuristics for popular modules like LWP and Tk. It uses a new source code analyzer to determine which Tk widgets are required at runtime.

  • Modules and libraries included by PerlApp executables are compressed, resulting in smaller distributables.

  • The --explain option provides information about why a module is being included by PerlApp.

  • The --noglob and --noerrno Linux and Solaris options have been replaced by the generalized --trim option.

  • On Windows, in addition to the command line, you can use a responsefile to pass options and parameters to PerlApp. For example:
      perlapp @MyOptions.rsp MyApp.pl

  • There are Lots of other minor changes too. Please check the documentation for additional information.


  • PerlCtrl executables can now be built on Windows 95, 98 and Me.

  • Dependency determination has been improved. PerlApp now includes heuristics for popular modules.

  • Modules and libraries included by PerlCtrl executables are compressed, resulting in smaller controls.


  • The Perl Dev Kit now includes PerlNET, the Perl component builder for the Microsoft .NET Framework. It allows you to use existing .NET objects from Perl, create new .NET components in Perl, end even inherit from and extend components written in other languages with Perl code.

Incompatible changes relative to Perl Dev Kit 3.0

A number of options in PerlApp and PerlCtrl in this release work slightly different from the way they used to work: PerlApp and PerlCtrl

  • The --bind option no longer extracts files to disk. The content of these files is available via the PerlApp::get_bound_file($filename) method (or PerlCtrl::get_bound_file($filename)).

  • Adding additional modules with the --add option works differently for dependent executables. Please check the documentation of the --add, --lib, --blib, --trim and --explain options.

  • By default, PerlApp and PerlCtrl now create freestanding executables and controls. The --dependent option switches to non-freestanding mode. The old abbreviation -f is now a shortcut for --force, which overwrites the output file without asking (this was already the case for the Linux and Solaris versions of PerlApp from PDK 3.0). These defaults can now be changed with the environment variables PERLAPP_OPT and PERLCTRL_OPT.

  • The --report option no longer exists.

  • The layout of the temporary extraction directory is different. Extension files are stored under their MD5 checksum and can be shared between multiple applications (unless they are built with the --clean option). There is a new --tmpdir option to provide hard-coded locations for these temporary files (for virtual web servers that don't have write access to the standard TEMP directory).


  • PerlControl now compiles the Perl code in the control during registration and unregistration too. Statements at filescope as well as BEGIN and END blocks are executed. The control can define PerlCtrl::RegisterServer or PerlCtrl::UnregisterServer functions to be executed as user hooks at those times.

  • Properties can now be implemented by accessor methods in addition to being just package variables. If the Perl code contains a method with the same name as the properties, this method is used as the property accessor. A simple accessor can look like:
      my $var; sub Property {
        return $var unless @_; $var = shift;

    If you implement properties via package variables, make sure you don't define Perl subs of the same name.

  • PerlCtrl no longer supports the creation of DCOM registration binaries. Please register the control itself on the client machine with the regsvr32.exe utility.

PDK Release: December 2001


  • Fixed screen refresh problem if non-English language packs were installed.

  • The Dump Variable window is now resizable.

  • Dump Variable now dumps in the correct context when in Remote mode.

  • The Dump Variable function now dumps lexicals.

PDK Release: July 2001

  • PerMSI has two new methods: FailIfProductsFound and WarnIfProductsFound.

  • PerlApp, PerlCtrl and PerlSvc now correctly bundle the File::Glob module.

  • The bug preventing the creation of freestanding PerlCtrls has been fixed.

PDK Release: May 2001

  • Debugging of freestanding applications (PerlApp/PerlCtrl/PerlSvc) as well as PerlCOM scripts is now supported using the remote debugging interface (use the -d switch to PerlApp, etc).

  • The builder for freestanding executables now automatically detects and includes all dependencies for several modules, like CGI, LWP, MLDBM, Net::FTP or URI. Tk widgets still need to be explicitly added using --add if they are not listed in a 'use' statement.

  • The debugger window displays reliably on Windows 2000.

  • Watch and proximity variables work correctly with remote debugging.

  • Performance improvement.

PDK Release: April 2001

Build 209 was the initial release of PDK 2.1. Build 210 is essentially the same software with an updated installer program. The 209 installer would not work correctly when a previous version of the PDK was already installed.

PDK Release

  • Debugger text selection bugs have been fixed

  • PerlSvc - Perl error messages are now being displayed

PDK Release: September 2000

  • Perl Debugger can now be used to debug Perl scripts running on a remote computer. The remote machine need not be running Windows, but should be running at least Perl 5.005_03. If the remote end is running a version of Perl earlier than 5.6.0, please replace perl5db.pl on the remote machine with the perl5db.pl supplied with the PDK.

  • The Perl Debugger now allows debugging of one-liners executed via Perl's -e switch.

  • PerlSvc has been added. It enables you to implement Windows services in Perl. Boasts features similar to PerlApp.

  • Enabled fork() support in PerlApp and PerlSvc. The limitations of the fork() emulation outlined in Perl's standard perlfork documentation page apply here too.

  • PerlApp, PerlCtrl and PerlSvc support an --xclude option to leave out Perl56.dll from the executable, making it much smaller. To run such executables, Perl56.dll must be made available on the target computer in the PATH.

  • PerlApp, PerlCtrl and PerlSvc support a --bind option to add additional files to the executable. These files are extracted into the filesystem when the executable runs.

  • Fixed bugs with runtime 'require' and 'do' operations in PerlApp, PerlCtrl and PerlSvc executables. Code of this type was being evaluated in the wrong package.

  • Limitations related to glob() in PerlApp, PerlCtrl and PerlSvc have been removed because Perl 5.6 now implements glob() via the standard File::Glob extension.

PDK Beta 3 Release: August 2000


  • Added DebuggerSetup.pl script (previously called PerlSockSetup.pl).

PDK Beta 2 Release: August 2000


  • A problem with creating registry entries for the debugger has been fixed.


  • Documentation for setting up remote debugging has been added.

  • Added PerlSockSetup.pl script.


  • Added lookup of HTTPS_* environment variables.

PDK 1.2.4 Release


  • No change


  • Version number is

  • PerlCtrls built with the --clean option clean up cached files in the TEMP directory. However the directory with the same name as the PerlCtrl, immediately under the TEMP directory, is not removed in case there were other versions of the PerlCtrl built without the --clean option.

    Note: Cached files are not deleted on Win95 due to a Win95 bug involving recursive calls to FreeLibrary(). This is not a problem on Win98 or WinNT.

  • Additional documentation of the PerlCtrl threading model and threading issues.

  • Fix for eval() error.

  • PerlCtrl current directory is initialized to the current directory of the client application.


  • Version number is


  • Version number is

  • Additional documentation of the PerlCOM threading model and threading issues.


  • Version number is

  • PerlApps built with the --clean option clean up cached files in the TEMP directory. However the directory with the same name as the PerlApp, immediately under the TEMP directory, is not removed in case there were other versions of the PerlApp built without the --clean option.

    Note: Cached files are not deleted on Win95 due to a Win95 bug involving recursive calls to FreeLibrary(). This is not a problem on Win98 or WinNT.

  • Fix for eval() error.

  • The file PerlApp.gui now gets installed in the /Perl/bin directory. This file enables building PerlApps that have no console window when the builder script is invoked with the --gui option.

Visual Package Manager (VPM)

  • VPM now handles standard directory pathnames and UNC pathnames for repository locations.


  • Version number is

PDK 1.2.3 Release


  • Installer stops the PerlSock service when performing and upgrade installation or uninstall in order to ensure the DLLs are not in use and can be replaced or removed.

  • Installer doesn't hang on Win9x systems.


  • Version number is

  • Added the --info option, which allows you set the version information of the resulting DLL file. See the documentation for information regarding which values may be set.

  • Extension DLL files are extracted to <TEMP>/<PerlCtrlName>/<GUID>


  • Version number is


  • Version number is


  • Version number is

  • Added the --info option, which allows you set the version information of the resulting EXE file. See the documentation for information regarding which values may be set.

  • Extension DLL files are extracted to <TEMP>/<PerlAppName>/<GUID>.

  • Additional Tk resources are bound into the EXE if your script or any module used by your script uses any of the Tk* modules.

Visual Package Manager (VPM)

  • The task bar does not disappear on Win9x systems when launching from the Start Menu.


  • Version number is

PDK 1.2 Release Candidate 1 (released 8/14/99) changes from Beta


  • No change.


  • Version number is

  • Added the --clean option, which deletes the freestanding file cache when the PerlCtrl DLL file is unloaded.

  • The file cache directory is unique for each version of a PerlCtrl. This eliminates the potential to use out-of-date DLL files.

  • The code for PerlCtrl is encrypted, as are all Perl modules.


  • Version number is


  • Version number is


  • Version number is

  • Added the --clean option, which deletes the freestanding file cache when the PerlApp DLL file is unloaded.

  • File cache directory is unique for each version of a PerlApp. This eliminates the potential to use out-of-date DLL files.

  • The code for PerlApp is encrypted, as are all Perl modules.

Visual Package Manager (VPM)

  • A problem with chdir() in PerlSock was keeping VPM from installing packages properly. This problem has been fixed.

  • Output from the install command is better formatted.

  • zlib in ActivePerl build 522 now uses PerlIO_open() instead of fopen(); this enables proper translation of pathnames, which was another issue preventing VPM from installing packages properly.


  • Version number is

  • Fix for new Win32::* functions, which, among other things, fixes File::Copy in PerlScript and Perl for ISAPI.

  • Fixed buffer overrun caused by off by one error.

PDK 1.1 Release (released 2/26/99) changes from Release Candidate 2


  • Gives you the option of installing each of the components individually.


  • Version number is

  • Added --add <list> option to force inclusion of a list of modules separated with semicolons.

  • END blocks are called before the PerlCtrl DLL is unloaded.


  • Version number is


  • Version number is

  • END blocks are called before the PerlCOM DLL is unloaded.


  • Version number is

  • END blocks are called before the script exits.

  • Added --gui option to create an executable file that has no console window.

  • Added --add <list> option to force inclusion of files specified by list.

Visual Package Manager (VPM)

  • VPM allows you to easily manage a Perl installation.

Perl WSAPI =back

  • Perl WSAPI enhances the performance of Perl scripts running under O'Reilly's WebSite web server.

PDK 1.1 Release Candidate 2 (released 2/26/99) changes from Release Candidate 1


  • Some Windows 95 users reported receiving this message upon installation:
       Could not load PerlEz.dll in GetPerlDirectories()
    This has been fixed.

  • Some users have complex multi-version Perl installs. The installer now has enhanced logic for ascertaining which versions of ActivePerl you have installed.


  • DLL version number was 1.1.00021 (build 21).


  • Memory leak fixed.

  • DLL version number was


  • Improved variable scope handling within eval() for freestanding builds.

  • A new example directory eg\TestCtrl\ has been added that demonstrates data type passing to a PerlCtrl.

  • Memory leak fixed.

  • DLL version number was


  • The PerlApp executable builder utility replaces the PerlEXE utility.

  • Improved variable handling within eval() for freestanding builds.

  • PerlApp no longer leaves behind an empty temporary subdirectory after the user runs the resulting executable.

  • PerlApp builder no longer generates 5 blank lines on the console window while building a freestanding executable.

  • Improved variable scope handling within eval() for freestanding builds.

  • Scripts that contain qx(net user $username /domain); or @userinfo = 'net user $username /domain'; now can be built properly by PerlApp.

  • DLL version number was


  • Improved documentation about data type passing, especially regarding passing parameters or return values by reference.

PDK 1.1 Release Candidate 1 (released 2/11/99) changes from Beta 3


  • Watch, proximity and special variable panels are now updated properly when not docked.

  • PlDbSync.dll is now registered properly on install. Before this bug was fixed, users would encounter error dialog box:
        SECSplashWnd: PERLDB.EXE Application Error

  • Uninstalling PLDBSync.dll now removes the TypeLib registry entry properly.


  • Minor bug fixes.


  • -drb command-line option (for building DCOM registration binaries) has been changed to -rb

  • DLL stub fixed - the DLL stub that is used to create Perl Controls did not work properly in Beta 3.

  • Creation of a hash in VB and access from DLL fixed.

  • ReadOnly property now works properly. For example:
      Properties => {
        'myProp' => {
            Type => VT_BSTR, ReadOnly => 1,

  • Improved documentation notes for Windows 95 and Windows 98 users.


  • The PerlApp executable builder tool replaces the PerlEXE utility.

  • Builds executables more robustly. Some Perl scripts would fail to build into executables in Beta 3.

  • Commands in backticks now execute in a freestanding executable. system() commands and commands in backticks would not execute in freestanding .exe files in Beta 3.

  • If a non-existent filename is used as the source script name, or if a non-existent module is referenced, the error message is more informative.

  • exit() with non-zero code now exits gracefully in .exe file.

  • There was a problem building freestanding executables with the AdminMisc module.This has been fixed.

  • Improved documentation notes for Windows 95 and Windows 98 users.

  • The TestRe.doc example now works properly: if no text is selected, text replacement occurs in the entire document.

  • require "filename.pl"; now includes the proper module. In previous versions of PDK, it was assumed that required files ended in .pm.

  • DLL stub fixed - the DLL stub that is used to create executables did not work properly in Beta 3.


  • PDK uninstall no longer deletes the bindir registry key. In previous beta PDK releases, an error message was sometimes displayed:
      Could not load PerlEz.dll in Get PerlDirectories()

PDK 1.1 Beta 3 changes from Beta 2

Requires Win32::OLE module version .1005 or higher.


Improved error checking and minor bug fixes.


In the Beta 3 release, the pl2exe utility was replaced with the PerlEXE utility. The final release of PDK 1.1 now contains a utility named PerlApp that replaces pl2exe and PerlEXE.

PerlCtrl and PerlEXE (now known as PerlApp)

It is no longer necessary to have Perl installed in order to use controls or executables that are built using these 2 tools. You now have the option of building freestanding PerlCtrl DLLs and PerlApp executables.

PDK 1.1 Beta 2 changes from Beta 1


  • Backticks now work on Windows 95, Windows 98 and WinNT.

  • system() now works on Windows 95, Windows 98 and WinNT. A parameter bug was fixed. PerlCOM now tries to find the executable if the full path is not specified.

  • File::Find now reports the correct file size.

  • Now works correctly over DCOM.


  • A new option was introduced for building DCOM Registration Binary. The PerlCtrl Builder now supports a new switch, -DRB, which stands for "DCOM Registration Binary". A DCOM Registration Binary is an executable that contains all the registration information for a PerlCtrl. The executable produced can be used to create the proper PerlCtrl registry entries on a machine where the control is not present.

PDK 1.1 Beta 1 changes from PDK 1.0


  • Type library now included. This allows the Visual Basic programmer to add a reference to the PerlCOM type library. Visual Basic variables can then be dimensioned as type PerlCOM. For example, Dim objPerlCOM As PerlCOM. This also enables code completion on the PerlCOM object itself. In addition, Visual C++ can read the type library and create a C++ wrapper class for use in VC++ projects.

  • PerlCOM now implements a minor form of case-smashing on method and property names. This was necessary because Perl is case sensitive, while host languages like Visual Basic are not. PerlCOM will successfully case smash a method or property name if there is only one occurrence of the name defined in the namespace. If there are multiple methods or properties defined with the same name but with different case, PerlCOM returns the following error:
        PerlCOM::CaseSmash() Failed: Ambiguous method or property call for ...

  • Scalar vs. List context: PerlCOM now provides a mechanism to explicitly specify the context of a method call. By default, all PerlCOM method calls are made in scalar context, which also means they can only return one value. If a method call is checking the c<$wantarray> variable or needs to return multiple return values, you need to explicitly specify List context for method call. This can be done as follows:
      $objPerlCOM->List->Method(). Scalar context can also be explicitly set by
      $objPerlCOM->Scalar->Method(). See the Arrays section in the PDK help file
      for more information regarding this topic.

  • Perl Interpreter stays alive to support SubPerlCOM objects: Perl Objects returned from PerlCOM methods are automatically packaged as PerlCOM Objects. These are technically known as SubPerlCOM object because they share the same Perl Interpreter as the PerlCOM object that created them. PerlCOM now keeps the Perl Interpreter alive as long as it is needed to support any outstanding SubPerlCOM objects.

  • Returning Win32::OLE Objects: PerlCOM now supports returning OLE Automation objects (Win32::OLE Objects) from PerlCOM methods. These objects are safe to use even after the Main PerlCOM object (which contains the Perl Interpreter) has been destroyed. This should also work over DCOM. For example, Perl can instantiate PerlCOM on a remote machine using DCOM. The remote PerlCOM object can then be used to instantiate an ADSI Object (or any other Automation Object) on the remote machine and have that object returned across machine boundaries to the local machine. The remote PerlCOM object can then be destroyed.

  • Multiple Perl Interpreters: Multiple Perl Interpreters are fully supported in this version of PerlCOM. This means that multiple PerlCOM objects can coexist in the same client process without conflicting. For example, if you create two instances of PerlCOM.Script, each one contains a separate Perl Interpreter.


  • Nesting PerlCtrls: This version of PerlCtrl supports the nesting of PerlCtrls; that is, one PerlCtrl can create and use any number of other PerlCtrls.

  • Multiple Perl Interpreters: Multiple Perl Interpreters are fully supported in this version of PerlCtrl. This means that multiple PerlCtrls can coexist in the same client process without conflicting.