|
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.
PerlNET has been added back to the PDK.
-
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 ).
-
Module heuristics have been updated.
-
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 will
not be installed.
-
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), perlXXnh72.dll and
perlXXrt72.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
-
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.
-
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.
All tools included in PDK 7.1 support ActivePerl 5.6, 5.8 and 5.10.
-
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 ).
The only supported Perl 5.6 version is ActivePerl 5.6.1.638.
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.
PerlCov is a new tool for analyzing code coverage and hotspots in Perl programs
and test suites. Check out the overview!
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.
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.
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 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").
-
VPM has been superseded by the native PPM4 GUI included in ActivePerl 819 and later.
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.
Perl Dev Kit 6.0.1 is a bug fix release to restore compatibility with
ActivePerl 5.8.6.811 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 5.8.4.810 or earlier.
The Deployment Tools are now supported in a limited edition (only PerlApp
command line version) for AIX.
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.
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.
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.
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.
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.
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 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.
-
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.
-
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
0.0.0.0 instead of 1.0.0.0.
-
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.
-
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.
-
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.
-
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 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 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.
-
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.
-
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 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 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 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:
-
--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:
-
`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.
-
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.
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.
-
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.
-
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.
-
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.
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.
-
Debugger text selection bugs have been fixed
-
PerlSvc - Perl error messages are now being displayed
-
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.
-
Added DebuggerSetup.pl script (previously called PerlSockSetup.pl).
-
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.
-
Version number is 1.2.4.109.
-
Version number is 1.2.4.109.
-
Additional documentation of the PerlCOM threading model and threading issues.
-
VPM now handles standard directory pathnames and UNC pathnames for repository
locations.
-
Version number is 1.2.4.109.
-
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 1.2.3.107.
-
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 1.2.3.107.
-
Version number is 1.2.3.107.
-
Version number is 1.2.3.107.
-
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.
-
The task bar does not disappear on Win9x systems when launching from the Start
Menu.
-
Version number is 1.2.3.107.
-
Version number is 1.2.1.104.
-
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 1.2.1.104.
-
Version number is 1.2.1.104.
-
Version number is 1.2.1.104.
-
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.
-
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 1.2.1.104.
-
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.
-
Gives you the option of installing each of the components individually.
-
Version number is 1.2.0.103.
-
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 1.2.0.103.
-
Version number is 1.2.0.103.
-
END blocks are called before the PerlCOM DLL is unloaded.
-
Version number is 1.2.0.103.
-
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.
-
VPM allows you to easily manage a Perl installation.
-
Perl WSAPI enhances the performance of Perl scripts running under O'Reilly's
WebSite web server.
-
DLL version number was 1.1.00021 (build 21).
-
Memory leak fixed.
-
DLL version number was 1.1.3.2
-
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 1.1.3.2
-
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 1.1.3.2
-
Improved documentation about data type passing, especially regarding passing
parameters or return values by reference.
-
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.
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.
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.
-
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.
-
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.
|
