Patent Application
20090307680
Driver files, such as printer driver files, are typically installed into a single folder on a particular computing device. When new versions of driver files are received, the new versions are often times installed into the same single folder. When new file versions share the same name as old file versions, as is often the case, the old file versions are typically overwritten in favor of the new file versions. Doing so, however, can change or lose functionality associated with the old file versions. This can cause undesirable system operation such as crashes and the like.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In one or more embodiments, driver files are assigned strongly-named locations in a system directory. Different versions of driver files are assigned their own different, strongly-named locations. By assigning different versions of driver files to different strongly-named locations, different versions of the same driver file can be installed, managed, and upgraded without loss of functionality associated with other installed driver file versions.
In at least some embodiments, a text file includes named sections that direct installation of a particular driver package. The text file can include a list of file dependencies that enable files to be associated with individual strongly-named locations.
The same numbers are used throughout the drawings to reference like features.
Overview
In one or more embodiments, driver files are assigned strongly-named locations in a system directory. Different versions of driver files are assigned their own different, strongly-named locations. By assigning different versions of driver files to different strongly-named locations, different versions of the same driver file can be installed, managed, and upgraded without loss of functionality associated with other installed driver file versions.
In at least some embodiments, a text file includes named sections that direct installation of a particular driver package. The text file can include a list of file dependencies that enable files to be associated with individual strongly-named locations.
The techniques described herein can be used in connection with any suitable driver files including, by way of example and not limitation, printer driver files. The discussion in this document uses printer driver files for examples. It is to be appreciated and understood that other driver files can be used without departing from the spirit and scope of the claimed subject matter.
In the discussion that follows, a section entitled “Operating Environment” describes but one operating environment that can be utilized to practice the inventive principles described herein in accordance with one or more embodiments. Following this, a section entitled “Example Embodiment” describes an example embodiment that utilizes the principles described herein. Following this, a section entitled “Implementation Example” describes an example implementation in accordance with one or more embodiments. Next, a section entitled “Example Method” describes an example method in accordance with one or more embodiments. Last, a section entitled “Example System” describes a system that can be utilized to implement one or more embodiments.
Having discussed an overview of the inventive embodiments, consider now a discussion of an example operating environment.
Operating Environment
Environment 100 includes a computing device 102 that can be used to implement various embodiments described herein. The computing device can comprise any suitably-configured computing device including, by way of example and not limitation, a print server. Print servers can be used to share printers on a network. Client computers typically connect to the print server to print to its shared printers, such as printers 120, 122, and 124.
Computing device 102 can typically include one or more processors 104, one or more computer-readable media 106, an operating system 108 and one or more applications 110 that reside on the computer-readable media and which are executable by the processor(s).
The computing device can include a print spooler service 112, a print queue 114, various drivers 116 and a driver store 118. The print spooler service 112 manages print jobs and print queues on computing device 102. Print queue 114 is a representation of a print device, for example a physical printer. Opening a print queue displays active print jobs and their statuses. Drivers 116 are used by print queues to print to a physical print device such as a printer. Drivers 116 are stored in driver store 118 in accordance with techniques described herein using strongly-named locations.
The computer-readable media 106 can include, by way of example and not limitation, all forms of volatile and non-volatile memory and/or storage media that are typically associated with a computing device. Such media can include ROM, RAM, flash memory, hard disk, removable media and the like.
The computing device can be embodied as any suitable computing device such as, by way of example and not limitation, a desktop computer, a portable computer, a handheld computer such as a personal digital assistant, and the like. One example of a computing device is shown and described below in relation to
Having discussed a general operating environment, consider now an example embodiment.
In operation, there are different layers of hardware and software between interface 204 and printer 212. For example, connectivity stack 206 can be utilized to enable connectivity using any suitable type of connectivity scheme such as line print terminal (LPT), a serial port, TCP/IP, USB, and the like. For each printing device that is available on the market, a printer driver such as printer driver 208 is utilized. When a document is printed, the document is typically sent in a format that is specific to the client or application sending the document, such as application 210. Printer 212 typically recognizes a format that is different from the application format. The application format is typically converted to a device-recognized format by the printer driver. The printer driver, which is typically a DLL, is loaded into the print spooler service process and then through various spooler methods, the driver is invoked with data received from application 210.
The printer driver then knows how to call into the print spooler service to send a representation of the document, such as a PDL representation, to the printer 212.
When a new or different printing device is connected to a client computing device, a print queue associated with the new or different printing device can be installed. When the print queue is installed, the print spooler service makes sure, through the connectivity layers, that the client computing device is connected to the printing device and that the printer driver knows how to render data for this particular printing device.
Oftentimes, operating systems provide sets of so-called core printer drivers. Core printer drivers provide standard driver functionality for different devices and operating systems. In addition, individual printing device manufacturers often look to extend or differentiate the core printer drivers through an extension model that employs so-called “dependent files” or DLLs. So, for example, a class of Hewlett-Packard printers may use a certain set of dependent files, whereas a class of Canon printers may use a different set of dependent files, both of which extend the functionality provided by the core printer drivers. In this case, one set of dependent files may be developed to work with a first operating system, and another set of dependent files may be developed to work with a second operating system.
In one or more embodiments, multiple different versions of dependent files and core files can be provided or otherwise installed in a side-by-side fashion. To accomplish this, in at least some embodiments, driver files are assigned strongly-named locations in a system directory. Different versions of driver files are assigned their own different, strongly-named locations. By assigning different versions of driver files to different strongly-named locations, different versions of the same driver file can be installed, managed, and upgraded without loss of functionality associated with other installed driver file versions. In at least some embodiments, a text file includes named sections that direct installation of a particular driver package. The text file can include a list of file dependencies that enable files to be associated with individual strongly-named locations.
In the discussion that follows, the following terminology is used. A “driver package” refers to a package that can contain driver DLLs and data files, .cat files (i.e. catalog files), an .inf file (i.e. a text file described just below), and a component.man file (i.e. a component manifest file). An “.inf file” is a text file containing named sections that direct installation of a given component or driver package. A “package published name” is the name of the .inf file that identifies the content of a package and is used as a unique identifier to search for the existence of a driver package in the driver store. A “package identifier” is a unique identifier that represents a directory created for a given version.
When a driver is to be installed, software code, such as a loader module, accesses the .inf file 308, parses the file, and ascertains which files are to be installed in which location. In the
Implementation Example
As an example of a specific implementation, consider the following. The implementation example is described in the context of a Windows® Print Spooler Service. In this particular example, print driver DLLs are installed under:
If a driver model is installed from a vendor driver package, located in the driver store at “% windir %\system32\DriverStore\FileRepository\prnlx001.inf_fl3f0471”, a sub-directory “3\pmlx001.inf_fl3f0471” is created where the driver's files are installed. In one or more embodiments, the files are created as File System hard links pointing to the actual file in the driver store to avoid the duplication of the files on the system's disk.
Likewise, the files in a core driver package, located in the driver store at “% windir %\system32\DriverStore\FileRepository\ntprint.inf—99bf01c4”, are installed under a “3\ntprint.inf—99bf01c4” sub-directory, in the same manner as the model files.
Having considered an example embodiment and an implementation example, consider now an example method in accordance with one or more embodiments.
Example Method
Step 400 receives a driver package. Any suitable driver package can be received. For example, the received driver package can comprise a driver package associated with core driver files. Alternately or additionally, the received driver package can comprise a driver package associated with dependent driver files. Step 402 locates an .inf file included in the driver package.
Step 404 processes the .inf file and ascertains whether side-by-side installation is enabled. This step can be performed in any suitable way. For example, side-by-side installation can be indicated by having a particular flag or key word in the .inf file set. If side-by-side installation is not enabled, then step 406 installs files in the driver package in a pre-defined folder. If, on the other hand, side-by-side installation is enabled, step 408 creates a new side-by-side directory and step 410 copies files in the driver package to the side-by-side directory.
Having considered an example method, consider now an example system in accordance with one or more embodiments.
Example System
Computing device 500 includes one or more processors or processing units 502, one or more memory and/or storage components 504, one or more input/output (I/O) devices 506, and a bus 508 that allows the various components and devices to communicate with one another. Bus 508 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Bus 508 can include wired and/or wireless buses.
Memory/storage component 504 represents one or more computer storage media. Component 504 can include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). Component 504 can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flash memory drive, a removable hard drive, an optical disk, and so forth).
One or more input/output devices 506 allow a user to enter commands and information to computing device 500, and also allow information to be presented to the user and/or other components or devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.
Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available medium or media that can be accessed by a computing device. By way of example, and not limitation, computer readable media may comprise “computer storage media”.
“Computer storage media” include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.
Conclusion
In one or more embodiments, driver files are assigned strongly-named locations in a system directory. Different versions of driver files are assigned their own different, strongly-named locations. By assigning different versions of driver files to different strongly-named locations, different versions of the same driver file can be installed, managed, and upgraded without loss of functionality associated with other installed driver file versions. In at least some embodiments, a text file includes named sections that direct installation of a particular driver package. The text file can include a list of file dependencies that enable files to be associated with individual strongly-named locations.
The techniques described herein can be used in connection with any suitable driver files including, by way of example and not limitation, printer driver files.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
