in reply to Printers (NT)
I recently went through a similiar process, however I also needed to know if it was a specifically named printer, and the form type loaded in the printer. I ended up writing a daemon that runs on the NT systems with a socket interface. My perl script on the Linux box connects to the daemon and can issue commands to request a list of attached printers, determine the form type, etc.
Printers can be attached several different ways: as a local connection (LPT or COM on the back of the PC), a share to a remote server (such as NT), and a share to a non-server (such as a printer on a Win95/98 box). Depending on where the printer is attached will determine where it will show up in the registry. Start by looking at HKEY_LOCAL_MACHINE | SYSTEM | CurrentControlSet | Control | Print | Printers. There is where the shares that the NT box has to the Win95 shares. Look in ... | Control | Print | Providers | LanMan Print Services for the others. You'll see the same printers that are in the previous leaf there, but the only information is where the spool directory is.
One of the problems is determining how the keys are to be interpeted. Some are meant to be used by the print spoolers within NT, and some are meant to be used by the print driver. I never did figure out exactly how NT enumerated the printers that show up when you click Start | Settings | Printers.
What my daemon ended up doing was using the EnumPrinters API call, with PRINTER_ENUM_LOCAL | PRINTER_ENUM_CONNECTIONS as flags. I then look for the printer name I specifically need in the name of the printer that's returned. If someone has renamed the printer, then I'm hosed.
I can e-mail you the source for the daemon if you like (jcwren@jcwren.com), but you'll need VisualStudio to compile it.
I spent a lot of time hacking the registry and cruising MSDN, trying to avoid writing something using the printer API. It can stall for a short time if the printer that the connection in your Printers folder is supposed to be connected to isn't there (someone turns the machine off, whatever).
I feel like what I did was a compromise, but it does work. 'Course, if we had a real network that wasn't polluted with NetBUI, and everyone had TCP/IP installed, it might be a different matter.
Sorry I can't be of more help. Maybe this, combined with some other elightened soul out here can get a solution that's reliable.
--Chris
Oh yea, when using the registry, you may have to be concerned about whether any of the connections are 'dead' printers or not (points to a no-longer existent printer). If this is the case, and you try to talk to it, you may end up hanging, or worse yet, generating a system dialog box that your perl script can't do anything about. This is one of the reasons that I took the approach I did. When you interrogate the printer for their forms data, there are certain flags that specify the amount of information returned by the API call. If you pick the wrong ones, you can end up with system dialog boxes, or taking an incredibly long time to figure out the printer isn't really there.
Printers can be attached several different ways: as a local connection (LPT or COM on the back of the PC), a share to a remote server (such as NT), and a share to a non-server (such as a printer on a Win95/98 box). Depending on where the printer is attached will determine where it will show up in the registry. Start by looking at HKEY_LOCAL_MACHINE | SYSTEM | CurrentControlSet | Control | Print | Printers. There is where the shares that the NT box has to the Win95 shares. Look in ... | Control | Print | Providers | LanMan Print Services for the others. You'll see the same printers that are in the previous leaf there, but the only information is where the spool directory is.
One of the problems is determining how the keys are to be interpeted. Some are meant to be used by the print spoolers within NT, and some are meant to be used by the print driver. I never did figure out exactly how NT enumerated the printers that show up when you click Start | Settings | Printers.
What my daemon ended up doing was using the EnumPrinters API call, with PRINTER_ENUM_LOCAL | PRINTER_ENUM_CONNECTIONS as flags. I then look for the printer name I specifically need in the name of the printer that's returned. If someone has renamed the printer, then I'm hosed.
I can e-mail you the source for the daemon if you like (jcwren@jcwren.com), but you'll need VisualStudio to compile it.
I spent a lot of time hacking the registry and cruising MSDN, trying to avoid writing something using the printer API. It can stall for a short time if the printer that the connection in your Printers folder is supposed to be connected to isn't there (someone turns the machine off, whatever).
I feel like what I did was a compromise, but it does work. 'Course, if we had a real network that wasn't polluted with NetBUI, and everyone had TCP/IP installed, it might be a different matter.
Sorry I can't be of more help. Maybe this, combined with some other elightened soul out here can get a solution that's reliable.
--Chris
Oh yea, when using the registry, you may have to be concerned about whether any of the connections are 'dead' printers or not (points to a no-longer existent printer). If this is the case, and you try to talk to it, you may end up hanging, or worse yet, generating a system dialog box that your perl script can't do anything about. This is one of the reasons that I took the approach I did. When you interrogate the printer for their forms data, there are certain flags that specify the amount of information returned by the API call. If you pick the wrong ones, you can end up with system dialog boxes, or taking an incredibly long time to figure out the printer isn't really there.
In Section
Seekers of Perl Wisdom