Although Windows 10 is a modern operating system, there are bits and pieces of the Windows architecture that could only be described as legacy. Windows device drivers, for example, have adhered to the same basic structure for many years.
At its most basic, a legacy Windows device driver consists of an INF file and a SYS file. The SYS file is the main component of the device driver. It is actually a Dynamic Link Library (DLL) file that has been given a .SYS file extension. The INF file is a text file that tells Windows how to set up the device. You can see what these files look like in the figure below. When you install a device driver, the INF file gets copied to the %SYSTEMROOT%\INF folder. There is usually a separate sub folder for each device driver. The .SYS file is copied to %SYSTEMROOT%\System32\Drivers folder.
It is worth noting that there may be other files associated with a legacy device driver, such as a driver catalog (.CAT) file. If a driver catalog file is used, then its job is to store a hash for each of the files within the device driver. Windows can use this hash information to verify that the driver files have not been tampered with. Modern driver files may also have localization files (.MUI files) that set the driver’s language. Those files are stored in the %SYSTEMROOT%\System32\Drivers\EN-US folder, or the folder that corresponds to your language of choice. Keep in mind that this is by no means a comprehensive list. Drivers can incorporate additional file types.
Late last year, Microsoft finally began to transition away from these legacy device drivers into something called the Universal Driver Architecture. The concept of a Universal Driver Architecture is loosely based on Microsoft’s approach to applications. Windows 10 runs legacy Windows applications, but it also runs a newer type of application. These applications have been rebranded many times over the years, and have been called by names such as Metro apps, Modern apps, and Universal apps.
Universal applications are designed to allow a developer to create a single application, and compile it to run on a variety of platforms. Similarly, universal drivers allow developers to create a single driver package that works across a variety of systems.
Universal applications and universal drivers also have another similarity to one another. As I’m sure you know, one of the things that differentiates universal applications from legacy applications is that universal applications are typically acquired and installed through the Windows Store, whereas legacy applications can conceivably come from just about anywhere. The same basic principle is also going to apply to universal drivers. According to Microsoft, “universal drivers are distributed through Windows Update, and hardware support apps are distributed through the Store”.
There are several different components that make up universal device drivers. Somewhat surprisingly, Microsoft has not abandoned the use of .INF files. Directives within an .INF file are still used for installing device drivers.
The drivers themselves consist of a base driver, an optional component package, and an optional hardware support app. The base driver is the heart and soul of the device. The base driver can exist in Kernel Mode Driver Format (KMDF), User Mode Driver Format, or it can be based on the Windows Driver Model.
The component package is optional, and allows for driver customizations to be made, or for additional settings to be implemented. Typically it is the hardware manufacturer that creates the base driver. The base driver includes all of the code that is necessary to make the hardware work. In contrast, a component package might be provided by an OEM or by a systems integrator as a way of adding additional functionality or branding to the device driver. It is also possible that an OEM or a systems integrator might use a component package as a way of forcing a driver to use a particular configuration that does not interfere with other hardware within the system.
A universal device driver can also include an optional hardware support app. Not every piece of hardware has or needs a hardware support app. Hardware support apps are used in situations in which the device manufacturer wants to give the end user a high degree of control over the hardware’s configuration.
These types of hardware support applications are especially popular among video card manufacturers. In the next figure for example, you can see an example of the Nvidia Control Panel. Nvidia bundles its control panel with graphics drivers in an effort to give users a way of adjusting various display related settings.
Right now universal hardware drivers are still relatively new. Many hardware vendors are still issuing legacy drivers for their products. Windows 10 will continue to support these legacy drivers for the foreseeable future. Just as most of the world still uses legacy Windows applications, it is going to take a long time for universal drivers to catch on.
Universal drivers: Plan carefully before migrating
The best advice that I can give you regarding the adoption of universal drivers is to take your time, carefully plan your migration to the new driver type, and most importantly be sure to thoroughly test any drivers that you are considering deploying. According to several sources, deploying a universal driver is a semi-permanent process. If you install a universal driver and find that the driver does not work correctly, there is no supported method for reverting the system back to using a legacy driver. You would likely have to restore a backup, or roll back a snapshot.
Because of this, I would recommend waiting for the Universal Driver Architecture to mature before making an effort to replace your device drivers. I haven’t heard of anyone having major problems with universal drivers, but given the difficulty of a system rollback, a bit of caution is certainly warranted.
Featured image: Pixabay
