I've read everything I could find under "USB language monitor" in this
newgroup.. I've also read the XP DDK. I will first describe what I
want to do, and then place my thoughts on what I've gathered here in
the newgroup. I would greatly appreciate any clarifications or
corrections to this information:
I want my language monitor to work on both USB and LPT printers without
modication. I've noticed others have wanted to, but I have slightly
differing symptoms. (1) in one case, my monitor is called and opens
USB001, but never gets a reply on xxxReadPort(...); (2) I'm listed as a
monitor for a USB printer, but it never initializes the monitor.
What I've learned:
USBMON.DLL is the * PORT * monitor for USB printers.
LOCALMON.DLL is the * LPT * monitor for LPT printers.
In order to install oneself as a language monitor there are two
registry keys (with some values) that need to be modified:
(1)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows
NT x86\Drivers\Version-3\<Printer Name>\Monitor
This value must be set to the KEY name under the following registry
tree:
(2) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors
For instance, to install myMonitor.dll, I would create a key under (2)
called "MyMonitor". The value in this key is "Driver" and its data
value is "myMonitor.dll". Next I choose a printer from (1) and change
the "Monitor" value to contain this data, "MyMonitor".
-------------------------------------
InitializePrintMonitor is deprecated in favour of the new
InitializePrintMonitor2 (and newer methods). From what I've read, it
doesn't matter which you use, as long as you write it correctly.
There is no special requirement for using the newer xxxMonitor2
functions for USB language monitors.
------------------------------------
>From the DDK, the reference to a driver only using the ReadPort,
WritePort, and IOCTL_PAR_QUERY_DEVICE_ID interfaces is in relation to
an actual printer driver, NOT for the language monitor that sits
between.
----------------------------------
The design of the spooler architecture, specifically language monitors,
does not care about the port monitor involved. Thus I write a properly
spec'd language monitor and it doesn't give a hoot about which port
monitor is in place.
----------------------------------
LOCALMON.DLL implements GetPrinterDataFromPort
USBMON.DLL implements GetPrinterDataFromPort
----------------------------------
As an example (which should work) --
ASSUMPTIONS: There are no other print jobs pending, conflicting, or
currently printing.
The user calls win32 API GetPrinterData on a USB connected printer.
The language monitor gets called which in turn calls xxxWritePort to
request the data. A moment later (or via another means) calls
xxxReadPort(...) to obtain the response. All is well.
----------------------------------
Have I got all this information correct?
If you reply and have additional information that is more correct, or
explains things more thoroughtly than the DDK, please provide a link.
Ciao
RDB