All,
Yes, the potential new module is fairly small - only five public methods, counting the "new". There are already enough Perl modules floating around that it's hard to tell what functionality is actually out there. On the other hand, so far there seems to me not a great deal of consensus on where the functionality should go. What little I can find out about Win32::Procctrl (a new module to me until Jenda's note!) makes it look like a good fit, but I can't actually find the module - it's not in the JHELBERG directory on CPAN, and I can't find it on the top of Jenda's pages (though Jens' Win32::Lanman is there). My current thoughts on trying to merge this with another module are: PRO: * We have too many similar modules as it is * Like functionality should be in the same module * No temptation to extend this module to do process management CON: * It's too late to solve the "too many modules" problem * Harder to administer: need to find willing and compatible "host", work out maint. details. The reason I said "NT _or_ WMI" is that this code will work under Windows NT version 4, without WMI installed (it's an add-on under NT 4). I do not (thank heaven!) have any way to test under Windows NT 3.51. If you actually have WMI, you can almost do it without a separate module - all I have done is hide a few of the gory details. If you don't have WMI, it's a real pain in the glutaeus maximus. For my personal needs, I wanted to hide the absence of WMI from the calling script. The design actually uses three modules: Win32::ProcInfo - superclass Win32::ProcInfo::WMI - WMI implementation Win32::ProcInfo::NT - Non-WMI NT implementation The "new" is in the superclass; it tries WMI first, and then NT. The "NT" implementation won't get information from another node; the WMI one will. A short, short example of use would be: $piobj = Win32::ProcInfo->new (); # With node name as optional arg. @pilist = $piobj->ListPids (); @piinfo = $piobj->GetProcInfo (); The last two methods take an optional list of PIDs as input, and return information only on those which actually exist. I can't really think what good this is in the case of ListPids. The list returned by GetProcInfo contains one anonymous hash per process; the keys depend on what information is available, which in turn depends on whether you're using the WMI version, and if not what version of Windows NT you're using. The other two methods (I said "five public methods" in the first paragraph) are an accessor and a permutor (a.k.a. "Get" and "Set"). Tom Wyant _______________________________________________ Perl-Win32-Admin mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
