A Second Shot: Windows Vista SP1

What’s New In SP1

Traditionally Microsoft has focused nearly exclusively on fixes in their service packs, with new features being few and definitely not the focus of a service pack - new features instead usually come with a different OS. When SP2 for Windows XP was released in 2004, it broke this mold with a highly atypical number of new and long-needed features to go along with the fixes it integrated. Although at the time Microsoft called it an exception to the rule, Vista SP1 makes for a tradition of exceptions, bringing a large number of new features to Vista.

For new features, we’ll start with EFI. Vista x64 was previously scheduled to get Extensible Firmware Interface (EFI) support, but this was pulled before the launch of Vista for reasons that were never made clear. Microsoft does have a working EFI implementation for the Itanium versions of Windows, so it was not a case of them being completely unprepared. With SP1 having been released we finally have a good hunch what this reason was: it appears Microsoft was waiting for the Unified EFI Forum to complete their 2.1 specification.  Microsoft’s previous implementations were for Intel’s EFI implementation prior to Intel releasing the specification to the UEFI Forum, and while the first UEFI specification was completed in early 2006, the Forum made a number of small but significant changes for the 2.1 specification which didn’t come until early 2007.

The end result is that the long-promised support for EFI (or rather UEFI; the original EFI 1.xx isn’t supported due to issues with x64) is finally here. As was originally going to be the case, UEFI support is limited to the x64 editions of Vista. Microsoft continues to justify this by claiming that EFI support for 32-bit x86 systems is a dead end, an argument that is particularly convincing a year and a half later now that systems are finally shipping with 4GB of RAM and need to/should be run in 64-bit mode anyhow.

With that said this change won’t make much of an immediate difference for Vista, but it finally gives PC manufacturers the ability to use UEFI if they desire, without having to resort to BIOS compatibility modules for Windows. We’re still waiting for someone besides Apple to start shipping consumer machines (or motherboards) with UEFI support, so this will be an issue we’ll pick up another day. (Ed: We did see a few demonstrations of UEFI boards at CES, though they're not yet publicly available.) For now we’re still looking forward to what motherboard manufacturers can do when freed from the ancient 16-bit real-mode for the startup/configuration abilities, along with the new features like GUID Partition Tables that offer a nearly unlimited number of partitions and better partition resizing.

With the addition of UEFI support, Microsoft has also made a few tweaks to the Windows pre-installation environment that should be more immediately useful. For anyone that has attempted to install Vista with a disc containing both the x86 and x64 versions of the operating system, they will have first-hand experience with the fact that two pre-installation environments were required – one for each version of the OS as an environment could not install the other version of the OS. That experience has been unified somewhat with SP1; now the x86 environment can install the x64 version of the OS (but not the other way around, interestingly enough). This effectively fixes one of the more annoying quirks in the Vista installation process, although the combined size of both the x86 and x64 installers means such disks still aren’t the default since their contents can’t fit on a single-layer DVD. For now Microsoft is targeting this towards IT administrators who roll their own custom installer images and who now will only need one image no matter what their machine is (x86, x64, or x64-UEFI).

AMD’s graphics division is also getting a pick-me-up with SP1, with the inclusion of Direct3D 10.1 support. AMD’s HD3000 series cards are still the only cards to support D3D 10.1, but this has mattered little since D3D 10.1 wasn’t out at the time that AMD released those cards. This allows AMD to push the issue harder although we’re not sure it will make much of a difference. Given the slow adaptation of DirectX/Direct3D 10 by game developers, we haven’t seen any real momentum towards D3D 10.1. Developers may simply skip Direct3D 10.1 and go for Direct3D 11 when it is finally released, otherwise sticking with 10.0 for the time being. (Ed: We've heard from Microsoft and several game developers that DX10.1 is not a major update and that they will do exactly that.)

Hotpatching support has also finally been added to Vista, which like UEFI is another one of those features that was on the drawing board at one point but disappeared before Vista was released. The lack of hotpatching support, otherwise known as the ability to patch running software without a reboot, has long been an irksome issue with Windows. As Microsoft has implemented it, this support is limited to Windows components (as opposed to any dreams of driver hotpatching), and we’re eager to see some patches for Vista SP1 to see this feature in action and to judge whether Microsoft really is able to reduce the amount of reboots required in patching.

Also new to SP1 are a few security related APIs for application developer use. The first API is for Data Execution Prevention (DEP, aka the NX/XD bit), a buffer-overflow prevention feature that was introduced with XP SP2. By default DEP is only enabled for certain Microsoft services because of its unpredictable performance with applications not built and tested against it. With the addition of this API, developers will be able to control how DEP functions, so that if their code isn’t completely DEP-safe, they may disable certain parts of DEP for their specific application, allowing some protection from DEP without the need to rewrite the offending code or require that DEP be disabled for that program entirely. This is effectively a precursor towards Windows being globally DEP enabled at some later point.

The second security API is for security software vendors, some of whom were caught off guard by Vista x64’s Kernel Patch Protection feature. Certain security/anti-virus software patches the Windows kernel in order to enact their defensive operations, and with KPP this was prevented. The issue turned into a big enough political quagmire that the European Commission was looking in to the matter as an anticompetitive action. As a result Microsoft has developed an API to allow applications to exert some control over KPP and allow those (and only those) applications to patch the kernel. Allowing any patching seems like a poor idea that goes against the goals and security offered by KPP, but this is an issue that has long since been decided on, and the vendors requesting the ability to continue patching the kernel have won out.

Rounding out the major additions to Vista SP1 are items to support new technology. The more pressing of these is full support for 802.11n Draft 2.0 wireless networking, which in spite of not being a final version of the 802.11n standard has quickly become a de-facto standard. While it is possible for a pre-SP1 machine to use 802.11n, it requires an additional level of work by the hardware developer to write more driver code and applications to compensate for the lack of native support - the OS has such support for 802.11a/b/g, thus handling most of the work. In effect SP1 brings 802.11n support to the same level as a/b/g.

Finally we come to exFAT, the next-generation successor to the ubiquitous FAT32 file system. For anyone that has used FAT32 in recent times on a large drive, you should be familiar with its limitations in terms of files allowed in a single directory, a lack of security permissions/access control lists, and a particularly harsh 4GB limit for file sizes. The last two items in particular have been making FAT32 more difficult to use as file sizes continue to increase, and the move to Windows XP gave home users real file system security through a file system with ACL support (NTFS). exFAT in turn is designed to be FAT32’s successor, implementing a modern but still light file system design that supports all of these missing features (although Vista SP1 doesn’t appear to support ACLs, even though it’s part of the standard).

At this point in time exFAT exists in an odd space between FAT32 and NTFS that makes it hard to determine if Microsoft is going give exFAT a reasonable foothold. With the continuing perfection of NTFS drivers for non-Windows operating systems and Microsoft’s own fixes to NTFS removable disk support in SP1, NTFS has been slowly becoming the de-facto standard file system for cross-OS disk access, and like exFAT NTFS is a modern file system that doesn’t suffer from the problems posed by FAT32. Furthermore Microsoft has been successful in securing patents for FAT32 (a standard that was previously treated as an open one), making some groups leery of exFAT. exFAT does have an advantage over NTFS thanks to being a lighter weight file system. It's easier to deal with exFAT on devices with limited processing power and memory, and exFAT possesses a much smaller data structure overhead (we measured NTFS at 30MB vs. <1MB for exFAT on a 512MB flash drive), but this may not be enough.

exFAT as the common cross-OS file system seems unlikely at this point (as a result Microsoft is wisely not targeting it towards this use), so what support it does pick up will be limited to mobile devices. But how many mobile devices are in immediate need of ACLs? Or support for files over 4GB? There’s a somewhat convincing argument for using exFAT with digital picture frames if you can gather a large enough number of photos (roughly sixty-five thousand), but that’s the extent of "good" reasons to use exFAT at the moment. We’re not convinced Microsoft is going to see much use of exFAT outside of Windows Mobile 6 devices given the high degree of overlap with NTFS; if the time comes for mobile devices where FAT32 is too little, they may very well switch to NTFS due to the much wider base of support.