Elimination of Unified Drivers

The HFS process has another cost involved with it. Most hardware vendors have (thankfully) moved to unified driver models instead of the plethora of individual drivers that abounded some years ago (in the bad old days it used to be necessary to identify individual device types and download specific drivers for them, something that was more or less impossible for non-geek users).

Most hardware vendors? The major graphics card vendors perhaps. I can't think of much else  in the way of unified drivers. (If only they could make a unified webcam driver...It'd save me a lot of grief helping newbies track down drivers to their obscure brand webcams they lost the driver discs to.) And the last time I installed drivers for Nvidia and ATI hardware on a Vista box, they supported a plethora of different GPU's, just like XP's unified drivers do. You will have to accept our apologies if we didn't take a decompiler and examine ATI's Catalyst 7.2 drivers at the assembly level for Vista x64 to see *how* they made it *seem* unified. It's unified as far as the end user is concerned. Bottom line, the "HFS process" is being dealt with responsibly by manufacturers, at least so far.

Since HFS requires unique identification and handling of not just each device type (for example each graphics chip) but each variant of each device type (for example each stepping of each graphics chip) to handle the situation where a problem is found with one variation of a device, it's no longer possible to create one-size-fits-all drivers for an entire range of devices like the current Catalyst/Detonator/ForceWare drivers. Every little variation of every device type out there must now be individually accommodated in custom code in order for the HFS process to be fully effective, resulting in a re-balkanisation of drivers that have only just become available in a clean, unified form in the last few years. This is more a concern for device vendors and driver developers than users, since they don't see any of this artifically-created extra complexity. As far as the user is aware it's still a "unified" driver since the internal re-balkanisation isn't visible in the driver bundle (although the "unified" driver suddenly becomes a lot larger). The indirect cost to the user (longer driver development cycles and higher cost) is mostly hidden from them.

If a graphics chip is integrated directly into the motherboard and there's no easy access to the device bus then the need for bus encryption (see Unnecessary CPU Resource Consumption below) is removed. Because the encryption requirement is so onerous, it's quite possible that this means of providing graphics capabilities will suddenly become more popular after the release of Vista. However, this leads to a problem: It's no longer possible to tell if a graphics chip is situated on a plug-in card or attached to the motherboard, since as far as the system is concerned they're both just devices sitting on the AGP/PCIe bus. The solution to this problem is to make the two deliberately incompatible, so that HFS can detect a chip on a plug-in card vs. one on the motherboard. Again, this does nothing more than increase costs and driver complexity.

And the industry has had to bear the burden of additional development costs to play in the industry since.....the birth of the industry. When has it been anything but? Whether they can "pass along" these additional costs directly to the consumer in an industry so competitive that 1-2% net margins are the norm we might take exception with.

An even more complex situation occurs with DVI paddle boards, in which the graphics device is on the motherboard but the DVI output is provided through a card that goes into the AGP slot. This means that the graphics device meets the requirements for a non user-accessible bus device (see the section Increased Hardware Costs) but the DVI output portion doesn't. Does this mean that your graphics output gets disabled or not? Either option is unpalatable, because Vista's content-protection design never anticipated such situations.

DVI and HDMI paddle boards can work just fine under Vista.  This is an issue easily resolved by and within the scope of driver implementation.  Indeed many new motherboards that have been released using the AMD690 chipset just recently are implementing HDMI in this very same fashion. And this is only one example that comes easily to mind for us, because we happen to have an upcoming review of one of these AMD690 boards.

Further problems occur with audio drivers. To the system, HDMI audio looks like S/PDIF, a deliberate design decision to make handling of drivers easier. In order to provide the ability to disable output, it's necessary to make HDMI codecs deliberately incompatible with S/PDIF codecs, despite the fact that they were specifically designed to appear identical in order to ease driver support and reduce development costs.

But wait, there's more! In order to provide the audio channel for HDMI, some manufacturers redirect the not-OK S/PDIF into the OK HDMI. So even if you go out of your way to get premium content-capable hardware, Vista can still disable it even though it's supposed to be approved for premium-content playback.

Microsoft has made it clear that this potential aspect of the driver revocation process will be one handled with IHV's before it actually would become an issue.