Peter Bright of ArsTechnica posted the below article about the new Windows 8 File History, a method of saving multiple copies of your data that can be recovered easily. It’s one of the more exciting features of Windows 8.

Backing up your data is an important task that most of us neglect to do. Windows has included backup software of some kind for a long time now, but few people actually use it, because they forget, don’t understand it, don’t know it’s there, or simply can’t be bothered.

Microsoft’s latest attempt to get Windows users to back up their files is Windows 8′s File History. File History is an automatic point-in-time backup system that periodically saves snapshots of your data to a separate location (either a network file share or a directly attached hard disk).

Every hour, by default, any modified data files get safely archived away, and there’s a reasonably simple user interface to browse all the different versions of a file or folder that the system has stored, and from there they can be opened or restored.

If this backup concept sounds familiar, that’s not entirely surprising. Apple’s Time Machine backup system works in an almost identical manner, the only major difference being that Time Machine has a rather more whimsical user interface for restoring files.

What may surprise people, however, is that Windows 8 is not the first Windows version to include a file history feature. Since Windows Server 2003, Windows has had the ability to automatically store historic file versions in a feature known as Shadow Copies. Windows Vista (Business, Enterprise, and Ultimate editions) and Windows 7 (all versions) both include the same capability, calling it Previous Versions.

This makes File History a new version of an old feature; it’s being done in a new way, using old technology. Is this the solution to all our backup woes?

A trip down memory lane

File History (and Time Machine) work in a very different way to Previous Versions/Shadow Copies, and this has both good and bad aspects. Microsoft has blogged about File History, and how it works, paying particular attention to some of its performance characteristics.

Previous Versions depended on a file system feature called the Volume Snapshot Service (VSS). VSS was designed to solve a handful of common problems faced by backup applications: how do you back up a file that an application has open and is actively modifying, and how do you copy files that have been locked open? To ensure that the backed up file is actually useful, the backup software has to guarantee that it never makes a copy in the “middle” of a write. The same problem also occurs across multiple files: if two files have to be updated to save a piece of information, the backup software must be sure that it records both updated files.

VSS solves the problem by letting the file system make static snapshots that freeze the file system at a given point in time. This allows multiple “views” of the file system: the current, live, modifiable view that regular applications see and use, and the frozen snapshots that backup software can safely copy. In tandem with this snapshot capability are hooks to let applications know when a snapshot is being made. Software such as SQL Server and Exchange use these hooks to solve the multiple file problem: they make sure that all the different files that make up their databases are updated and consistent before the snapshot can be made.

The locking issue is solved by dint of the fact that applications only ever open (and lock) “live” files; the frozen versions in the snapshot aren’t opened and hence aren’t locked.

VSS is integrated deep into the file system, and works at the block level. When tracking space on a physical disk, file systems generally divide that space into small units called blocks or clusters (on NTFS, usually 4096 bytes per block) to make the bookkeeping easier. When snapshots aren’t being used, modifications to files are simply made in-place: the blocks are directly changed. When volume snapshots exist, modifications to files are no longer made in-place. Instead, the original blocks are saved safely away, and a new block is used as the target of the write.

This system is quite efficient, because the snapshots only need to store the blocks that change. A small write to the end of a large file, for example, will only change the blocks at the end of the file.

In the first version of VSS, which made its debut in Windows XP, the snapshots were all temporary. Reboot the computer and they’d disappear. This was fine for their original purpose, since you normally wouldn’t want to make a backup across a system reboot. Shadow Copies, in Windows Server 2003, extended VSS to allow persistent snapshots to be made. They’re the same as the temporary snapshots in every way, except one: they don’t disappear when you reboot.

Shadow Copies would take a snapshot on a periodic basis; typically about twice a day. Each snapshot would show the entire filesystem as it existed at that point in time, and the system would carefully preserve any blocks that get modified.

The technology behind VSS was all quite clever. But it was let down by its user interface, and this is the main reason that most people have never heard of it. Tucked away in Explorer’s properties for files and folders is a tab called Previous Versions. The cramped dialog box shows the various snapshot copies that exist of a file or folder, and they can be opened or restored. While the user interface does work, it’s not at all user friendly and it’s awkward to use.

Back to the future

File History leverages an even older file system feature, called both the USN Journal (USN standing for Update Sequence Number) or the Change Journal (they mean the same thing, but Microsoft uses both terms in different documents). The USN Journal was introduced in Windows 2000, and it stores a very simple record of every change made to the file system. Specifically, whenever a file is created, modified, deleted, or renamed (or has certain other special things done to it), an entry is made in the USN Journal to record that the specific operation was made to the file. Each entry is given a number, the Update Sequence Number, hence the name.

The USN Journal doesn’t include information about what was actually changed; it will note that a file was written to, for example, but doesn’t specify what the new data is. It just tracks the list of changes.

The USN Journal was introduced to allow applications such as virus scanners and content indexers to wake up periodically and see in a quick and efficient way all the changes that had been made to a file system since they last ran. A content indexer, for example, might wake up every hour and examine the USN Journal. If the USN Journal has had entries added since the indexer last ran, the indexer can read each entry to see if any files have been modified. If they have, the indexer can then reindex them as necessary.

It’s easy to see how this is useful for something like File History. It allows the File History service to lie dormant in the background (Microsoft says it uses less than 10MB RAM when inactive), waking occasionally to check the USN Journal. If the USN Journal says there are changes, File History can quickly see if any of the files that it has backed up are among the changes, and if so, make a new backup copy.

Unlike Shadow Copies and their block-level operation, File History works with whole files. You nominate a disk or network share to be the File History repository, and it creates a replica of all your backed-up locations. Each time a new version of a file is copied to the replica, it gets renamed to include a timestamp in its name. This allows multiple versions of the same file to coexist within the same folder. Files are stored whole, so a minor change to a large file will result in a lot of disk usage.

Alongside these copies, a database is maintained that records which files were visible at each given point in time. It also maintains information for files which can’t be stored in the replicated directory tree, such as those with very long filenames. Apart from that, the system seems very naive: if you rename a file, it gets detached from its history (the history still exists, under the old name, but is no longer shown as an older version of the renamed file). Conversely, if you delete a file and then at a later date create a new file with the same name as the deleted file, the histories are joined, as if the newer file were a later version of the older one.

Two implementations, one OS

File History and Previous Versions use very different technology to achieve a very similar goal. So why has Microsoft thrown out the old system and reinvented Apple’s Time Machine?

The biggest single difference between the systems is where they store the information. For Shadow Copies, the old snapshot blocks are almost always stored on the same volume as the current, up-to-date file. Technically, it is possible to store them on different volumes, but in practice, this is rarely done (and, in any case, was only ever possible on server versions of Windows).

This has two important repercussions, one very good, one very bad. The good repercussion is that the system is self-contained. The only thing you need is a hard disk; it can contain its own historic versions. The bad repercussion is that it’s self-contained: if that hard disk should stop working, you lose both the current files and all the previous versions too.

File History, on the other hand, never uses the same disk to store historic versions—it requires the use of either a network share or a separate physical disk. (Again, technically that’s not quite true, as you can use a file share hosted on the same physical disk as the one being backed up, but this defeats the purpose). This means that if the disk should fail, the backups should all be safe. You can recover the backups simply by installing the operating system to a new hard disk, giving the system the same name as the broken one, and using the same location for File History; the history will pick up exactly where it left off.

One consequence of this is that the File History storage location might not be available—if you use network storage on a laptop computer, for example. To cope with that, the system can additionally use a portion of the local disk as a cache into which it will make replicas whenever the history location is unavailable. As soon as the history becomes available (so as soon as you return to your home network or plug in your history USB disk) the cache will be copied to the history location.

File History only tracks files in certain locations; Libraries, the Desktop, and a couple of other places. Shadow Copies, in contrast, track almost the entire disk. This means that if you keep your files in an unusual location, File History won’t protect them. While files in the protected locations can be excluded (to, for example, avoid burning lots of space on podcasts or other readily re-downloaded data), there’s no provision to include extra locations.

This could be a big problem for some people. Outlook, for example, defaults to saving PSTs in a location that File History doesn’t track, so if you’re using a PST to archive mail, you’d better make sure to move it. Similarly, I keep my source code in a separate folder that is not part of any of my Libraries so that I can avoid filenames with spaces (as to this day they prove an inconvenience for many software build scripts). Again, File History can’t protect these files.

Update: It appears that the Outlook behavior is a consequence of my Outlook install being an upgrade from Office 2007. A fresh Outlook 2010 installation will put PSTs into the Documents Library. Still, many applications continue to put important information in places that aren’t included in Libraries.

There is a workaround, as you can create custom libraries that include all the random locations where important files might be kept. But this means creating pointless libraries whose sole purpose is to make the backup tool do its job, which greatly undermines the simplicity and elegance that File History should have.

Time Machine, by way of comparison, tracks whole disks.

File History can store more snapshots, and can make them more frequently, than Shadow Copies. The frequency at which it copies your files can be varied, from once every ten minutes, to once a day, with numerous intervals in between. It can also keep historic versions “forever,” or at least until the volume used to store them is full. In comparison, you can only create 512 concurrent snapshots of a single volume.

Shadow Copies work “automatically” insofar as once a snapshot has been created, the file system itself will always maintain the integrity of that snapshot (until and unless it needs to reclaim the space used by the snapshot). File History relies on a service to work. If the service is stopped or broken, no backups are made. More vexingly, the service is designed to pause if it detects that the system is busy, meaning that it will defer making backups when the system is under load.

Whether File History is better or worse than Shadow Copies is going to depend on how exactly you use your system. The ability to create networked backups is obviously very valuable, at least for systems that can rely on the presence of a suitable network connection. For systems that can’t rely on network storage, the situation is less satisfactory. Plugging in a USB disk does work, but it’s not especially elegant, and Shadow Copies feel like a better fit for that scenario. File History’s inability to track arbitrary locations is also a significant flaw for some usage patterns.

On the other hand, the “infinite” history that File History makes possible is highly desirable. In particular, it plays very nicely with Storage Spaces, as they provide an easy facility to create near-infinite volumes to store backups on.

Unfortunately, even if Shadow Copies are a better fit for how you use your system, they’re not an option in Windows 8. Citing unspecified “performance issues,” the ability to make persistent snapshots has been removed from Windows 8 and Windows Server 2012 (though temporary snapshots, for use by backup software, remain supported). The performance of Shadow Copies has been good enough for the past 9 years, since they were introduced with Windows Server 2003, so it’s a little difficult to see where the performance problem is, but the feature is now gone.

Update: The wording on MSDN that said that persistent snapshots have been removed from Windows 8 and Windows Server “8″ (as it was once known) appears to have been removed. This is encouraging, as it implies that the underlying capability will be retained, even if the user interface is no longer available. Not a perfect solution, but better than outright removal.

As someone who used Shadow Copies regularly, and whose usage pattern doesn’t fit well with File History, this is a great pity. The old system image-based backup tool is still a part of Windows 8, so there is some alternative for usage patterns that don’t play well with File History, but it’s not ideal.

The weakest link

Ultimately, the real challenge for any backup system isn’t technological; it’s human. File History is off by default (as it rather has to be, since it cannot rely on the presence of a network location or separate hard disk), and so will do nothing for most users, most of the time. For those who are a good fit for its capabilities, and who choose to enable it, it will serve as an effective and easy-to-use backup system.

Nonetheless, I find it difficult to regard it as a step forward. A whole-disk system, like Shadow Copies and Time Machine, and a system that is at least optionally self-contained, as in Shadow Copies, can do more things for more people, and I suspect that most Windows 8 users, like most Windows 7 users before them, will end up with no backups at all.

Printing is one of the most commonly used tasks by anyone that uses a computer. Microsoft has gone to great lengths to make printing easier with the upcoming Windows 8 operating system. Below is blog post from Steven Sinofsky of Microsoft about the improved printing capabilities of Windows 8.

Of all the peripheral devices that you can connect to your Windows PC, printers are one of the most popular, and have been supported for the longest time. In fact, Windows 1.0 (shipped in 1985) supported “a number of printers and plotters” and included a “Print Spooler [which] allows the user to work on one file while printing on another” according to the Windows 1.0 Press Kit. The screenshot of Windows 1.0 below shows the files included with that version of Windows – Epson.drv, lots of font files, and the print spooler process. Some parts of the print system are older than the people who work on it.

Over the years, the print system has evolved into a complex architecture that supports printing to a huge variety of printers, and can scale from a simple $50 inkjet at home to a high-availability print server hosting thousands of print queues for hundreds of thousands of users, driving printers that cost tens of thousands of dollars each.

The print system touches many layers and facets of Windows. It shows UI, and it hosts drivers that also show UI. It performs intensive graphics operations, since printing is essentially re-drawing your on-screen content onto paper. It encompasses lower-level communications, mainly USB or network (the majority of printers bought in the US today are network-capable, but our telemetry data tells us that over 75% of the printers installed with the Windows 8 Consumer Preview are plugged into a USB port). The print system needs to scale to very large, mission-critical deployments in large businesses but also run efficiently on small systems.

In this blog post I’m going to talk about the work that we’ve done in Windows 8 to re-imagine how the print system can best providegood device support to our customers. I’ll show you how it works on ARM-based PCs and in Metro style apps. And I’ll talk about what we’ve done to ensure that the maximum number of existing printers “just work”—whether you’re accessing them from the desktop, from a Metro style app, or on a device running Windows RT.

Reimagining the print system for Windows 8

In Windows 8 we’ve introduced a new printer driver architecture, which we call version 4, or v4. The v4 architecture produces smaller, faster printer drivers, and it supports the idea of a print class driver framework–a system that allows people to install their printers without having to locate a driver for that device, in many cases.

As you’ve probably guessed, V4 is the fourth iteration of the printer driver architecture in Windows. V3 was the architecture used from Windows 2000 to Windows 7, and it’s actually still fully supported in Windows 8 for device compatibility reasons. So if you only have an existing driver available for your current printer, then it should still work in Windows 8. Versions 1 and 2 were the driver architectures for Windows 1.0 through Windows ME.

Before I explain how the print system works, I’d like to talk about some of the requirements that we worked to address with the Windows 8 print system.

Printing from Metro style apps

One of the things that we needed to figure out was how to give Metro app developers the ability to print. Printing from win32 applications requires knowledge of graphics programming, either GDI (Graphics Device Interface) or XPS (XML Paper Specification). When we looked at how we could make printing possible from Windows 8 apps, we completely reinvented how we enable printing from the Windows Runtime, and we made printing very easy to use from HTML5/JavaScript and XAML/C# apps.

Integrating printing into Metro style apps

Printing from a Metro style app should naturally be a Metro style experience. I’m sure that when most of you have printed something, you’ve seen a little applet pop up to tell you that the printer is out of paper, or to offer you the opportunity to purchase ink.

These pop-ups are very common with inkjet printers. Some pop up only when relevant (you have low ink), while others pop up every time you print. These pop-ups come from the printer driver software itself, and they are all desktop UI, of course. But when printing from the Metro style Photos app, for example, we don’t want you to have to switch over to the desktop just to see UI that tells you that printing is in progress.

Printing in Windows RT

Printer drivers have evolved over time to include a lot of functionality— some install services, some install numerous little applications, and many are now quite large. The v3 printer driver model in use since Windows 2000 evolved into a highly complex and highly extensible model, which allowed printer manufacturers a lot of freedom in what is installed with their driver software. When we thought about how this would work on some of the devices that are going to run Windows RT, we knew that we had to make some significant architectural changes. We really wanted to ensure that we didn’t negatively impact ARM systems by running unnecessary services, and we wanted to reduce system resource usage, while still providing support for as many devices as possible.

Lots of printers supported, far fewer drivers

There’s a huge diversity in printer capabilities, and Windows supports a vast range of printers. In Windows 7 and earlier versions of Windows, each of these printers required a specific driver in order to work (there are some exceptions, such as universal printer drivers, but these tend to be large and resource hungry). This meant that the number of drivers that we included with Windows (we call these in-box drivers) was very large so as to provide good support. Of course, we have many more drivers on Windows Update, but we believe that it’s important to have a core set of in-box drivers that support popular devices, so we can still provide a good printing experience for people who can’t or won’t download a driver from Windows Update. In-box drivers are essential for Windows RT—in fact, it uses only in-box printer drivers. The challenge here is to get a relevant set of printers supported, but to also reduce the resources required to accomplish this.

Another interesting challenge in supporting lots of printers is that the support gets stale over time. The set of drivers included in Windows 7, for example, provided excellent support for devices released in 2008 and 2009, but as new devices were released over the years, and time went by, the set of drivers in Windows 7 became less relevant. One big challenge in Windows 8 then, is to ensure that Windows provides a high level of support for lots of printers, including ones that haven’t even been released yet.

Printer sharing

Anyone who has administered a print server can tell you that getting the correct drivers installed to support sharing is the most time-consuming part of managing a print server. Some of these difficulties you might encounter when you’re trying to share a printer at home too, especially if you have both 32-bit and 64-bit versions of Windows. This becomes tricky because the print “server” (which just means the PC that the printer is connected to – not actually Windows Server) has to provide the drivers to the clients that want to print to the shared printer. In Windows 7, we used HomeGroup to address this problem, and it works well much of the time. However, the requirement to load drivers for each Windows architecture becomes more problematic when you think about printing from Windows RT.

Although we expect that most people who print from Windows RT devices are likely to print to wireless printers, we didn’t want to totally exclude the possibility of printing to a USB printer. On the other hand, we didn’t want to increase the complexity of printer sharing by requiring people to add drivers for 32-bit clients, 64-bit clients, and Windows RT clients! So, with the v4 model in Windows 8, we developed a new way to share printers that doesn’t rely on putting client drivers onto the print server.

The print system in Windows 8

Applications enable you to create and view content. The purpose of the print system is to provide these apps with the means to print your content to any installed printer without having to worry about what particular device is installed. I’m going to talk a little about how the app prints, and go into more detail about how we get the content onto a printed page.

Creating printable content

For apps, adding printing support is quite straightforward. The content that you want to print from an app is in a format that the app specifies. For Metro style apps, this will often be HTML5 or XAML, but for Win32 apps such as Word or Photoshop, the content is in a format specific to each particular app.

So when you want to print from an app to your printer, one of the things that the print system needs to do is to translate the content from the app’s format to the format that the printer understands. Unfortunately, printers don’t all understand the same formats (not even close!) so this turns into quite a bit of work.

To give a real example, an app such as Word uses the GDI graphics system to draw the content both to the screen and to the printer. When possible, the print system uses a high quality intermediate format called XPS (XML Paper Specification) as its internal content format; we convert the content from Word into XPS. We chose to use XPS as the foundation of our print system because it is a very flexible format and is just like electronic paper. It supports high-fidelity color, and since it’s an XML-based description with no executable code embedded, it’s great for archival purposes and it is secure compared to other options. In addition, Microsoft has worked with ECMA International (European Computer Manufacturers Association) to make it an open standard (ECMA standard TC46, OpenXPS). Both the desktop viewer and the Reader app can display OpenXPS. I “print” all my receipts from online purchases as XPS files.

Once the content is being managed by the print system, it is then converted to the format that the printer understands (if necessary; there are lots of printers that understand XPS directly) and the print system sends this to the printer with the correct options set, and the job prints.

In Windows 8, we have a distinct improvement to this story because all Metro style apps use Direct2D as their basic drawing format, and Direct2D and XPS share the same XML-based graphics “language.” So in another real-world example, the Reader app uses Direct2D to render its content onto the screen. It also uses Direct2D to render the same content to the print system. Reader’s content can easily be submitted to the print system as XPS, without any costly conversion from GDI.

If the app requires a print layout that is different from the screen layout, then it can do this using style sheets or XAML. This means that you don’t have to “click here for a printer-friendly version of this page.” If you have a printer that supports XPS, then the path from the app to the printer involves no conversions at all, and printing is extremely fast!

Now that you understand in broad terms how an app sends print information to the print system, I’m going to talk about what the system does with that, the services it provides, and what else has changed in Windows 8.

Supporting lots of printers

One of the big benefits that Windows provides to apps is that it abstracts the specific printer from the app, so that the app’s programmer doesn’t have to worry about what printer you’ve installed. Windows supports tens of thousands of printer models in total, including printers that are supported by drivers available via Windows Update or the manufacturer’s website. When we see printers that don’t work, this is often because the manufacturer has chosen to block the installation if they don’t recognize the version of Windows that their software is being installed on. We work with printer manufacturers to get these packages updated, but this does take some time.

Ideally, when you plug a new printer into Windows, it just works, without your needing to go off and find drivers.

So how do we make that happen? In the past we’ve shipped a lot of printer drivers in Windows. Vista contained about 4500 drivers, and Windows 7 contained about 2100 drivers. Even though Windows 7 had half as many drivers as Vista, it provided better market coverage, by which I mean that there was a better chance that it had a driver for the more popular printers. Why is this? There is an incredible diversity of printers in use. In Vista, we supported a lot of devices that were old and no longer in popular use, and so the relevance of the set of devices supported was not as good as in Windows 7.

As an aside, the other thing we do when we release a new version of Windows is to take the drivers that were in the previous version and post them to Windows Update, so that even though these devices may be dropping in popularity, it’s still possible for people to automatically get the device working by just plugging it in.

Here’s a photo I took of one of the benches in one of the printer labs (we have several) where we test that this all works. You can see several small inkjets and laser printers from different manufacturers. Luckily for my ears, we don’t test with dot matrix printers very often these days.

People tend to keep printers for 5-7 years on average, so when we want to add support, we have to think “what devices are people using? Which were the most popular devices over the past several years, and what will be the most popular in the future?” This last part is tricky because, pretty soon after we release Windows, the printer manufacturers will release devices that we didn’t know anything about. This means that over time, the set of devices that we support in any particular version of Windows becomes stale.

We know that at any given moment, about 100 specific printer models make up about 50% of the installed base. If we want to support 75% of the models being used today, then we need to support about 300 models. The diagram below illustrates this.

To get to 95%, we need over 1000 models supported. But the problem is even harder because the printers that make up this set of 100, or 300, or 1000 changes all the time. The 100 printers that represent 50% of the market today are not the same 100 printers that will represent 50% next week, or next month, and especially not next year. Every day, many people buy and install new printers.

As I mentioned above, we basically took a brute-force approach to solving this in the past. We have representatives from the major printer manufacturers working directly with Microsoft, sitting in offices in Redmond, working to check their source code into Windows. They would create a completely new set of in-box drivers for each new release of Windows. This just isn’t very efficient.

In Windows 8, we took a radically different approach, and have stopped shipping lots of printer drivers with Windows. Instead, we built aprint class driver framework. This framework is extensible, as it supports printing to existing devices, but it also allows manufacturers to include support for new devices, even those that have not yet been designed.

With a print class driver framework, we can get closer to giving you an experience like driverless printing, where you don’t have to actually go and find a driver, but instead the printer just works with the Windows printing system. A true driverless printing experience requires changes to how most printers are designed, and the print class driver framework provides support for this idea, but we also feel that it’s very important to provide as much support for existing devices as possible.

With the ability to support new and planned printers, the number of printers that are supported by the Windows 8 print class driver framework will actually increase over time.

Besides the great progress in increasing the number of devices covered, we have also been able to reduce the resources that we use to achieve this coverage.

First, we reduced the amount of disk space needed to support printers and imaging devices from 768MB in Windows Vista, to about 184MB in Windows 8. This number is an average across different editions and architectures of Windows 8. The following graphic illustrates the reduction in space used since Windows Vista.

Comparison of disk space needed to support printers and imaging devices in Windows 8, Windows 7, and Windows Vista

In addition, the reduction in disk space used has been accompanied by an increase in the relevance of the devices supported directly by Windows. The following table summarizes how the relevance of the inbox coverage has increased, while disk use has decreased.

This is a huge improvement in Windows 8, and this reduction in space used directly translates into more available storage space for users of hardware with limited storage capacity, which we expect will be a characteristic of some Windows RT computers.

The Windows 8 printer driver model also allows us to focus our manufacturing partners on a set of code that will not change as much from one version of Windows to the next, so we will be able to more usefully spend those resources on improving quality and performance, instead of constantly repopulating the driver set.

Print class driver architecture

Besides wanting to create an architecture that supports the needs of Windows RT and Metro style apps, we wanted to make sure the model would also work with existing devices, and would utilize technologies that were familiar to printer manufacturers, so that it would be easier for them to implement the new driver technology.

A printer driver does several key things:

• Configuration allows the user to change settings, translating the intent to turn on double-sided printing (for example) into the specific command that the printer needs for this. Configuration is presented to the user through the user interface.
• Rendering translates the printed content from the format that Windows print system uses into the format that the printer understands. In some cases, the printer may directly understand the native Windows print format (XPS), so for those devices, there is no work to do here, unless they want to do extra rendering (doing multiple pages per physical sheet of paper is an example of this case). The part of the driver that does rendering is called the render filter.
• Events allow the printer to inform the user that something has happened – a job has completed, there has been a paper jam, or the printer is out of ink.

Configuration UI

One big change between the old driver model and the Windows 8 driver model is in how the UI is provided. In the old printer driver model, the configuration UI was built into the driver. Here’s an example of some typical printer UI (taken from the Epson NX430 that is currently on my desk).

As I mentioned earlier, we needed to find a way to enable the display of Metro style UI when people wanted to change printer settings.

In the Windows 8 driver model, the manufacturer’s UI is completely separate from their driver. This is a much better architectural decision for many reasons: The UI to control the printer is now an app that can be invoked when printing from Metro style apps or desktop apps. This allows printer manufacturers to present you with a much richer experience – imagine access to video showing you how to set up your printer or install an ink cartridge.

Here is an example of a Metro style app that Epson has developed for the Epson NX430:

You can see that this UI has all the hallmarks of a Metro style app, but for your printer. It includes an attractive view of the ink levels of the printer, and is much easier to use, especially on touch-screen devices.

Windows will automatically show you the correct type of UI – desktop printer UI when you’re printing from desktop apps, and Metro style UI when you’re printing from Metro style apps.

If the manufacturer hasn’t provided any configuration UI for their device, then Windows provides some standard UI that you can use with any printer. However, when the printer manufacturer has decided to invest in providing a customized experience for their device, they can provide an app that replaces the standard Windows UI. Then, when you decide to alter the configuration of the device, or when the device configuration changes during printing (e.g. paper jam), then Windows will display the manufacturer’s customized app to you instead.

Rendering

One of the most important functions of a printer driver is to take the content that the app produces when you ask it to print, and convert that into something that the printer can understand. This was one of the most challenging areas of building the Windows 8 print class driver, so let’s look at it in a bit more detail.

As described above, desktop apps like Word or Photoshop use graphics commands to draw their content onto the screen or the printer. When they do this, the print system receives the content, converts it into XPS if necessary, and then calls the printer’s driver (or more specifically, the render filter part of the driver) to convert the content into the right format. This is sent to the printer and your file is printed out.

Probably one of the largest challenges in supporting a very wide range of printers is in dealing with the rendering portion of the problem. Some of the more expensive printers support standard “page description languages” or PDLs, such as PostScript, PCL, and XPS. However, less expensive, consumer-focused devices are manufactured with cost savings in mind, and many of these support proprietary methods of sending the page information to the printer. Some manufacturers may have only a few languages that they use across their product line, but others may tweak the language from one model to the next, trying to get the most out of their printer hardware.

This leads to a 1:1 mapping between printer driver and printer hardware.

Imagine each PDL as being a complete printer driver and it’s easy to see that increasing support involves a steadily increasing number of drivers. Of course, this is a bit of a simplification and it is possible to create a driver that supports a number of devices, and we have often seen drivers that support a series of printers. But the key point here is that Windows 7 and earlier versions of Windows didn’t do anything to support this design approach.

The printer driver model in Windows 8 supports the idea that a PDL (or driver) can be associated with multiple devices.

We’ve been working with our printer manufacturer partners to have them include an identifier in their device that describes how they are supported more generically. We call this a compatible ID. So for example, if a device has a compatible ID that says that the device supports XPS, then the print system knows that it doesn’t need to find a model-specific driver for that device, it can just install a generic XPS driver for the device. Windows understands that the device is a generic XPS printer and can treat it that way. Of course, Windows also understands that this is a Fabrikam 1000 printer (or whatever), so if there is a model-specific driver, then Windows will install it. But if there is no driver available, then Windows can still print to the printer using the class driver.

So in this example, we have a set of render filters in-box as part of the class driver model, and these can be installed for any device that implements a matching compatible ID. The logical extension of this idea is that it’s quite possible for future devices, devices not yet designed or built, to be compatible with the print class driver in Windows 8. We’ve been working with the printer manufacturers and they all plan to implement compatible IDs in their devices (many already do). Because of this capability, the number of printers that are supported in Windows 8 will increase over time, rather than decrease, and more and more people will get the experience of being able to use their printers instantaneously from Windows 8 without the need to go and find a driver.

But what about all the devices that have proprietary rendering languages? The print class driver supports that model too, but with the disadvantage that we do need to have a separate rendering filter for each small set of models that speak each unique language. There is no way around this, and in Windows 8 we’ve taken a number of filters that address a set of popular models. However, once again, we’ve been working with the printer manufacturers to improve this position, and we expect to see manufacturers produce printers that can more easily utilize the class driver in the future.

Printing from Windows RT

The reduction in the resources used by the print class driver contributes directly to a smaller footprint for Windows, which is especially valuable on Windows RT. In addition, the V3 printer driver architecture was highly extensible and had evolved over many years into a model that encouraged the development of large, complex printer drivers. Some drivers install services that run all the time, exhausting battery power and using processor time. I’ve seen some drivers that support only one device but that are larger than the complete printer driver set in Windows 8!

The need to support printing in Windows RT, and a general desire to make printing more efficient, led us to develop an architecture that more tightly controls what the driver can do. I’ve already mentioned that the UI portion of the print experience is now a completely separate component, an app instead of being part of the driver. This means that it’s also optional, and drivers will work well with the standard Microsoft printing UI. We’ve also simplified the driver architecture to be more power-efficient, by removing service dependencies and reducing the likelihood that additional software will be included with the driver.

With the Windows 8 driver model, we also made significant changes to how printer drivers are installed. In Windows 7 and earlier versions of Windows, all printer drivers are stored in the “Driver Store,”—sort of like a database for all types of drivers. When you plugged in a printer, we would find the correct driver in the driver store, and copy it to a special location where the spooler could use it with your printer. In Windows 8, we have eliminated this extra copying, which removed quite a bit of disk I/O. The print spooler now just knows how to find the driver in the driver store.

For a real world example, we compared the installation times for an Epson Artisan on Windows 7 versus Windows 8 (using a relatively small driver on Windows 7): the install time on Windows 7 was 14 seconds, compared to under 2 seconds on Windows 8.

Final thoughts

As you can see, the Windows 8 printer driver architecture is big step forward. It provides good support for a lot of the printers that people already own, and supports future devices with a small, fast, built-in class driver framework. The performance is great and the disk footprint is small.

What’s New in Windows 8