I take it your code does something like
require Win32::Process::Info;
my $info = Win32::Process::Info->new( undef, $variant );
with the requested variant being in $variant.
If so, you will need to call Win32::Process::Info->import() after you
require Win32::Process::Info, but before you instantiate. The import()
method is where Win32::Process::Info determines what variants it is
allowed to use. Until 1.007 I did this when the module was loaded, but
it turned out I needed a way for the user to make certain variants
unavailable even if the underlying modules were available.
The import method should be passed the names of the variants you want to
be able to use. If you pass nothing, it assumes any variant it can load
is OK.
So the proposed code is
require Win32::Process::Info;
Win32::Process::Info->import();
my $info = Win32::Process::Info->new( undef, $variant );
The problems with the Win32::OLE and fork() are documented under NOTICE,
fairly early in the POD. The fact that you must call import() explicitly
if you require Win32::Process::Info should probably be there too. At
present it is buried in the documentation for the import() method
itself. A more explicit error message if import() was never called would
be nice, too. I have added these to my 'TODO' list, but will keep this
ticket open at least until I commit the changes locally, and probably
until I release an update.
In addition, there used to be problems with a 'require
Win32::Process::Info' if you were loading the NT variant. This variant
uses Win32::API, and at least for a while that module used an INIT
block, which meant you could not 'require Win32::Process::Info' unless
you did it in a BEGIN block. I do not know the current status of this.
Please let me know if calling import() fixes your problem.
Tom Wyant
PS - The 'PT' variant relies on the Proc::ProcessTable package. This
builds under a number of operating system, but the last I looked Windows
was not one of them. It does no damage to try to load it, though.
