US 20050052660 A1
A method and apparatus for updating print drivers is described. The described system includes a port monitor that monitors the configuration and status of a printer. When changes occur to the configuration of a printer, the port monitor updates a print driver registry on the print server. The port monitor also wakes the print driver on the print server and informs the print driver of the configuration changes. Depending on the client operating system used, a client device connected to the server's shared print queue may either directly read or request the configuration data from the print server. In some client operating systems, the client device may also update a local registry on the client device to reflect the changes in configuration of the printer. The described system allows print drivers to have a consistent interface to printer configuration and status data regardless of which version of the Microsoft Windows Operating System is used by the client.
1. A computer code to update printer data comprising:
a first code section to periodically poll a printer that outputs data from client devices, the first code section to compare the results from the poll to a server registry that maintains the configuration states of the printer, the first code section to determine changes in configuration states;
a second code section that transmits the changes in configuration states to a plurality of client devices coupled to the server to allow the client devices to update a local registry.
2. The computer code of
3. The computer code of
a third code section to interact with a first client device of the client devices, the third code section to instruct the first client device to update a local print registry in the first client device, the local print registry of the first client device to maintain the configuration state of the printer.
4. The computer code of
5. The computer code of
This is a divisional of U.S. application Ser. No. 09/631,869 filed Aug. 2, 2000 by the same inventors, and claims priority therefrom.
Print drivers have long been used to format and transfer computer data from a source of data such as a computer to an output device such as a printer. However, because printers from different manufactures typically have different software and hardware configurations, print drivers typically need to be customized to match the particular printer configuration. Users enter relevant data into the computer to customize the print drivers.
User entry of printer customization data can be time consuming, and is prone to user error. Thus bi-directional drivers that are capable of receiving and processing printer status and configuration data have been implemented.
However, the most widely used operating system, the Windows operating system from Microsoft Corporation of Redmond, Wash., are not designed to support bi-directional drivers. Current implementations of bi-directional drivers in Microsoft OS systems circumvent the spooler to enable data flow in two directions. Circumventing the spooler does not conform to Microsoft specifications. Failure to conform to Microsoft specifications creates problems regardless of the Windows operating system used. In Windows NT systems where many clients communicate to printers through a print server, the avoidance of the print spooler prevents the updating of printer information in the print server because typically, only a system administrator may change the printer configuration settings in the printer server. In Windows 95 and Windows 98 systems that utilize a print server, the print server data is not updated because Windows assumes that the print configuration data is local client data and thus fails to update the print server.
Thus an improved bi-directional print driver is needed.
In order to control the flow of data, a local spooler program runs in each client 108, 112, 116. In one embodiment, the spooler program is part of an operating system such as Windows 98 or Windows NT from Microsoft Corporation of Redmond Wash. A user installed port driver in a port monitor interfaces with the print spooler to convert the data from the print spooler into a format suitable for a corresponding printer. For example, when communicating with printers made by Xerox Corporation of Stamford, Conn., a Xerox TCP/IP port monitor may be installed on the server computer to enable formatting of documents to conform to a LPR or Port 9100 protocol. The print monitor maintains data on printer configuration and printer status. Examples of printer configuration data include information on printer set ups such as duplex information, tray and envelope information that may indicate paper sizes and colors, preprinted header information on the paper and the like. Examples of printer status data include information on whether the toner is low or whether a paper jam exists in the printer. For purposes of this application, the term “summary printer data” will be used to include both printer configuration data and printer status data.
Single direction print monitors only allow data flow from the client computer to the printer. Thus updates to printer configuration or status are manually entered by the end user. As previously discussed, such data entry is prone to errors. Bi-directional print monitors enable a printer to automatically update monitor data. However, the Microsoft spooler architecture in Windows NT and Windows 98 was not designed to support bi-directional print monitors. Thus, in current embodiments of bi-directional print monitors operating in a Microsoft operating systems, the print device driver obtains the IP address of the printer and directly addresses the printer circumventing the operating system print spooler.
Circumventing the operating system print spooler breaks operating system protocols for the current generation of Microsoft Windows operating systems. Furthermore, circumventing the operating system print spooler creates additional problems in Windows NT networks that utilize print servers to maintain and monitor printer settings. In particular, when a print server is used to maintain printer settings, client computers connected to the print server are unable to change or otherwise update the stored printer configuration settings because typically only a print server administrator is authorized to change print server local configurations.
In order to implement a bi-directional print driver in a Microsoft Windows operating system and allow upgrading of printer configurations in a print server, one embodiment of the current invention utilizes a polling method of updating data.
In block 212, a processor compares the printer data received in response to the poll request with stored data from previous poll requests. If the polled data matches the stored data, no change has occurred, no control flags are set, and the system waits a preset time interval in block 214 before transmitting another poll request. However, if the received data does not match the stored data, then a change in either printer status or printer configuration has occurred, and corresponding control flags are set in block 216. In one embodiment, a port monitor manager uses the control flag settings and the stored settings to direct future printer instructions. In an alternate embodiment, the port monitor manager may wake up the print driver to effect the configuration changes as shown in block 220.
When the polling device is implemented in a print server, the change in printer configuration or status may be “pushed” through the system. As used herein, the term “push” refers to transferring data back through the system from the printer to a print server, and from the print server to the client. In block 224, the print sever transmits printer configuration and printer status data changes to the client computers that originate printer instructions. One method of communicating such changes is by transmitting control flags.
In Windows NT operating systems from Microsoft, the preferred method of informing the print driver of configuration changes is by using the Print Driver Event API which is defined and described in the Windows NT DDK (Device Driver Kit) published by Microsoft of Redmond Wash. and which is hereby incorporated by reference. In operating systems in which the server registry is not assumed to be the local registry clients request that a Pipe Server thread be used to transfer the control flags or updated printer data from the server registry to the client computers. Examples of operating systems in which the server registry is not assumed to be the local registry include Windows 95 and Windows 98. Thus, in the previously described embodiment, client computers connected to the print server or a print queue automatically receive the updated settings.
Most functions defined by print providers require a printer handle as input. In an example Windows NT operating environment, the client spooler obtains a printer handle by calling a command OpenPrinter in the client Winspool.drv 322. The calling of the OpenPrinter command causes Winspool.drv 322 to call API server 324 (spoolsv.exe). The capabilities of the spooler are defined by the API functions available.
A client spooler router 326 (spoolss.dll in Windows NT) calls each print provider's OpenPrinter function until one of the print providers supplies a printer handle and a return value indicating the print provider recognizes the specified printer name. The printers called may be either local printers, remote printers running Windows NT and remote printers running other operating systems. Local printers are called via a local connection using localspl.dll 328. Windows NT print servers may be called via a remote connection using Win32spl.dll 330. Print servers that utilize non Windows compatible operating systems may be called using other Provider DLLs 332. Examples of Non windows DLLs supported by a Windows NT and/or Windows 2000 client system include, but are not limited to, nwprovau.dll for Novell NetWare print servers and inetpp.dll for HTTP print providers that handle print jobs sent to a URL.
A Kernel-mode or Port Driver stack 334 directs the open printer call from the client system 304 to local printer 306, to remote printer 307, to networked servers 336, 338 coupled to corresponding printers 308, 310, and to Windows NT server system 340 coupled to corresponding printer 312. Windows NT server system 340 receives the remote procedure call interface (RPC) signal 342 from the client system 304 at the remote print server router 344. The printer server router 344 generates its own OpenPrinter function 346 that propagates through server Localspl.dll 348 and the print server Kernel-mode Port Driver Stack 350 to printer 312.
The printer spooler router 344 calls each printer's 312 OpenPrinter function until one of them supplies a printer handle and a return value indicating the print 312 recognizes the specified printer name. The printer spooler router 344 then returns its own handle to the client system 304. The print router handle includes both the printer handle and the print server handle. This print router handle is returned to the application 314. The transferred handles allow application 314 to direct subsequent calls to the correct print server and printer.
Block 402 includes protocol support 404 hardware and software that receives streams of print data from each port cell such as a first port 406 and a second port 408. Protocol support 404 converts the data into a print data stream that matches an acceptable printer protocol for output to a printer. Typical IEEE accepted protocols include LPR (Line print protocol), LPR with byte counting and AP Socket 9100 although other protocols may also be possible.
Because the print system is a dynamic system, printers and clients may be added to the network. Block 410 of
Port device data manager 426 includes a shared locked memory 430 that maintains configuration data, status data and control data for each printer coupled to the print server. A port manager API 440 manages communications with a printer using a standard communications protocol such as SNMP. SNMP communication is controlled by a text based file containing printer information. An example of such a text base file is included in
One method of maintaining status and configuration data is to continuously replace the stored configuration data and status data in memory location 438 with newly received configuration data and status data. However, constant retransmission of all printer configuration and status data to all clients consumes excessive network bandwidth. In order to minimize retransmission of configuration and status data from the print server to client devices, changes in configuration data and status data may be summarized by setting appropriate control flags 444 that represent any changes in the configuration or status data. In one embodiment of the invention, shared locked memory 430 also stores the control flags 444.
The described communications network or first port thread 432 may be replicated for each port coupled to a printer. For example,
Printer manger 428 includes a multi-tasking printer manger thread 454 that receives data from shared locked memory 430 of device port manager 426. The data may include configuration data, status data and/or control flags. Printer change notification thread 456 tracks changes in printers coupled to respective ports of the print server. When the printer notification thread 456 is implemented in a Microsoft Windows environment, the printer change notification thread 456 may use standard Microsoft APIs to detect printer changes. Port printer manager 428 coordinates information from printer change notification thread 456 and Printer manager thread 454 with available printer data stored in printer list 458 and available port data stored in port list 460. Printers identified in list 458 typically have a corresponding entry in registry 468 corresponding to the printer. Each printer entry in printer list 458 may include, but is not limited to, printer names, device ids, port names, port handles, configuration Ids, status Ids, and printer events. Port list 460 may include, but is not limited to data pertaining to each port such as port handles and previous control states.
Print manager thread 454 summarizes data received from printer list 458, port list 460 and shared locked memory 430 and forwards the summarized data to a summarized data 469 area in printer registry 468. In addition, print manager thread 454 alerts printer driver 462 of the changes. The print driver converts the summarized data 469 to an internal format 471 compatible with the print driver. The internal format data 471 is stored in a corresponding area of printer registry 468. The operation of a typical print driver is described in the Microsoft Windows NT DDK which has been incorporated by reference.
When client 464 is a client that maintains a local print driver and thus does not automatically assume use of a server print driver, (examples of such operating systems include Windows 9×clients referring to clients computers that operate using Microsoft Windows 95 and/or Windows 98) the client 464 requests that pipe server thread 466 retrieve summarized data 469. Pipe server thread 466 may perform or facilitate both client transmission of data request commands as well as pipe server thread 466 generated responses of configuration and status information.
Some clients may utilize operating systems that assume the use of a print server driver as the local driver. One example of such an operating system is a Windows NT operating system. Each Windows NT client, such as client 470, may directly access data from registry 468.
Additional details of configuring the port are illustrated in Screen 516 of
It will be appreciated that the foregoing description is intended to be illustrative. Variations and modifications of the descriptions provided herein will present themselves to those skilled in the art. For example, the focus of the descriptions has been on the transfer of data between printers and clients running specific Windows operating systems. However, other operating systems which use architecture similar to the described operating systems may also implement the described invention. As a further example, different types of printer data besides the examples of printer status and printer configuration data described may be transferred. Accordingly, the present description should not be read as limiting the scope of the claims except and unless indicated to the contrary.