Jan 29, 2011 (01:01 AM EST)
What Windows 7 Is Still Missing
Read the Original Article at InformationWeek
There's little question Windows 7 has been received with open arms by users and admins. It fixed many of the problems that plagued earlier versions of Windows, made good on the promises that seemed only half-fulfilled with Vista, and introduced a slew of new functions -- big and small -- that were also warmly received.
But there's still a great deal missing from the operating system (OS). Some things from previous editions of Windows were dropped entirely. Other things, which people have asked for time and again, still haven't shown up. Here's a review of a few major features that Microsoft could have introduced in Windows 7, or even earlier -- but that, for whatever reason, have not materialized.
When Windows 7 was released, Microsoft made a major blunder by not updating a free offering that had been previously available for Windows XP and Vista: SteadyState.
Windows does not have, by default, a single all-encompassing mechanism for returning the entire system -- user settings, data on disk, etc. -- to a given state. There are plenty of scenarios where this is useful, from rent-by-the-hour PCs to computers in institutional environments like schools or libraries. But for a long time the only way to accomplish something like that was through a not-very-elegant combination of native Windows features and third-party products.
Microsoft eventually introduced SteadyState, a free add-on for Windows XP and Windows Vista. This was designed to corral together all the disparate ways Windows' state could be preserved and make them centrally manageable. After installing the SteadyState package, an admin could set up a user account and assign a great many management behaviors to that account, including what persistent changes the user could make to any aspect of the system. Admins loved it: it drastically cut down the amount of time needed to set up a system in one of the above-mentioned environments.
When Windows 7 came out, admins were dismayed to learn SteadyState didn't work reliably with it, and begged to have SteadyState updated for the new OS. Instead, Microsoft announced that support for SteadyState was being discontinued. The download for the program would continue to be available through the end of 2010, with support continuing until the end of 2011 -- but no Windows 7 update was in the pipeline.
Instead, Microsoft released a white paper in which they described how admins could use many of the native technologies in Windows 7 to emulate the behaviors of SteadyState. It isn't hard to guess the reaction: people booed Microsoft roundly for ignoring a much-requested feature from its customers.
To be honest, many individual SteadyState features are native to Windows 7. It's just that they require the admin to dig about under the hood to enable them; they're not exposed in a single, central place. SteadyState provided an integrated, administrative-console way to edit all those features at once.
Worse, one of the biggest and most crucial functions -- disk protection -- isn't provided except through workarounds like System Restore. These don't work in remotely the same fashion as SteadyState's own disk protection, which required little or no intervention or downtime.
What's doubly ironic is that while Windows 7 was still in its public beta test phase, word surfaced of a feature called Guest Mode (alternately, PC Safeguard) that did in fact directly replicate much of the missing SteadyState functionality. Paul Thurrott of WinSupersite.com wrote about it in detail back in 2009, back when it still appeared in Windows 7's beta builds.
It's still not clear why Guest Mode was removed, although one possibility is that it introduced bugs which couldn't be resolved properly before 7 was due to ship, and so it was eliminated as a way to get Windows 7 to meet its street date. But in the long run, Microsoft owes it to their users to put SteadyState -- or something like it -- back in.
Seamless Third-Party Hardware Support
Most of us are all too familiar with this scenario. You install a copy of Windows on a newly-minted PC, or perhaps reinstall a clean copy on an existing one. Unfortunately, a great many things simply don't work -- your Bluetooth module, for instance, or your memory card reader. Or the whole system just seems weirdly sluggish for a fresh install.
It's only after some searching and pounding your head against the wall that you discover a number of key drivers for your system are only available through your manufacturer's Web site. Depending on the manufacturer, it might be pretty easy to find them... or not. Or, you can download a utility that'll download and apply the system-appropriate software for you -- at the cost of having yet another program running on top of everything else.
Why, when Windows has long had the mechanisms for detecting and installing hardware drivers on its own, is any of this ferreting around and installing by hand needed? Much of it has to do with the way original equipment manufacturers (OEMs) choose to provide updates to components in their systems. Since they have to do their own integration testing, it's often just faster to provide them directly to the end user -- especially if they're only being provided for a small subset of the total user population that's running Windows.
Jake Whitman of Dell global communications put it this way: "Dell tests/validates drivers to provide a higher level of granularity, and providing fully qualified drivers via Dell Support offers customers a stable computing experience. Recently, customers of a particular notebook experienced an issue and if that component driver was installed directly from the vendor, it would have resulted in an impact on OS performance. However, if the same driver was used from Dell, everything would function correctly."
This makes sense -- but given that every OEM seems to be dealing with this problem in a different way (their own native update utility, their own Web site), it would make sense for Microsoft to provide more tools that close the gap.
One idea is an OEM-only toolkit, provided by Microsoft, which extends Windows Update in such a way that the needed drivers can be obtained directly from the OEM. This add-on wouldn't be in conventional boxed copies of Windows, but could be obtained directly from the OEM itself. If this sounds like the same problem all over again, keep in mind this would be a Microsoft-provided component, with only such customizations as needed by the OEM -- e.g., a manifest of files and download locations.
Whatever the case, Microsoft and the hardware vendors -- especially the OEMs -- owe it to each other to work more closely and provide a less fragmented solution for the end user.
Universal Software Updates
In addition to a proper mechanism for universal hardware driver updates, why not something for software as well? Why not have native mechanisms within Windows for updating existing software packages -- or, for that matter, obtaining and installing software, like an "app store" for Windows? Word has it that Microsoft has been contemplating something exactly like that for future versions of Windows, but the problem as it currently stands is worth looking at in detail.
Right now, a user has a few choices when it comes to updating an application. They can go hunt for an updated version of the app themselves, or they can trust in some internal updater mechanism within the app to do that work for them. The second approach has caught on with a lot of software makers, but brings its own caveats. The biggest is how each manufacturer will often try to create an updater for all of its products -- with the end result being a slew of separate update mechanisms running in parallel.
On the very machine I am typing this, I have separate updaters for Adobe, Apple, and Java that launch periodically. Adobe itself seems to have several different update systems running side by side -- one for Flash, one for the Adobe Creative Suite, and so on. It's a hodgepodge.
A few people have attempted to create applications that function as central updaters for many products from many different families. One is the PortableApps collection, a library of free and open source applications packaged in self-contained installations. The collection includes a program launcher and organizer which can look for new versions of programs registered with it and update the apps in question.
Another is AppSnap, which can search for updates to a great many common programs currently installed in a given system. (A commercial application called OilChange, released in the Windows 95 era, attempted to do the same thing as well.)
Both of these programs also have shortcomings. They can only update applications that are registered with them. They also don't create much of an infrastructure that other app authors can hook into -- they're just one application among many others, with minimal standing. A single, unified software-update subsystem that any manufacturer could hook into would be a big timesaver for both software makers and end users.
The brunt of the work would fall to Microsoft first, though. They'd have to provide an API that is rich enough to hook into in the first place. They may well be working on such a thing for the next iteration of Windows, since it ostensibly wouldn't be that difficult to extend the existing Microsoft Update mechanism to allow third parties to make use of it.
Ideally, though, they should have been working on such a thing back in the XP days and encouraging software makers to take advantage of it, much as they told the same folks (not always very effectively) how to write applications that could run well in limited-user contexts and thus play well by default with protection mechanisms like user account control (UAC). Even if such a thing could be introduced into Windows 7 through a service pack -- which doesn't seem likely at this point -- something that major would take software makers at least one to two revisions of their own product to use the technology natively.
One other possibility is that Microsoft is planning to leapfrog over the whole issue by using virtualization -- by simply making applications and their attendant data into mini-virtual appliances that are handled by the OS in a high-level way. The application never touches the system directly, is heavily self-contained, and both the code and the data associated with it can be quarantined or jettisoned on a moment's notice. This complements Microsoft's talk of "the desktop as a service," where the user experience -- including installed apps -- is just one element among many that have been virtualized. But that's a whole OS upgrade away, at the very least.
Proper Touch Support
One major omission from Windows 7 was proper support for tablet devices. It's not like the support is entirely missing; touchscreen displays do work in 7. What's not there are the user interface (UI) behaviors that make it possible to use Windows 7 full time with a touchscreen.
This omission can probably be attributed to Windows 7's release schedule. The OS came out long before the current spate of touchscreen machines -- spurred in turn by the release of the iPad -- hit the market. Consequently, there wasn't as much pre-emptive work done to support such devices, and before the iPad came along it was harder to make a case for supporting them in the broadest possible way.
But now there's far less of an excuse. With tablet sales on the rise (and eating into the sales of other PC form factors), Microsoft owes it to users to release a truly useful touchscreen / gestural input system as a side-band release that can be applied to Windows 7. Odds are it will be something integrated completely with Windows 8, but even a basic version of something, offered soon (within, say, the next six months), is better than nothing now.
Acquisitions, Third Parties Could Be The Plan
Why would Microsoft skimp on offering features that seem in their best interest to provide natively? One possibility is that they don't feel that way -- because they're waiting for someone else to develop their own approach to the same problem.
Consider a technology like SteadyState: it's the sort of thing which could be (and to some degree is) provided by third parties, who create their own implementation of such a feature and sell it. Microsoft's next step from there might be to license the technology in a stripped-down implementation for within Windows itself, as they did with Diskeeper for their own disk defragmenter utility. Or they might acquire the technology in question entirely, as they did with the LookOut search add-on for Outlook. (LookOut was eventually deprecated in favor of the indexing technology in Vista and Windows 7.)
Microsoft has two reasons for doing this. One, the fact that certain features are not available in Windows is an incentive for third-party makers to create them in the first place, and the presence of that much more software for Windows in any form is always a plus for them. Two, there's always the chance a third-party implementation of an idea may be more comprehensive or elegantly executed than something Microsoft develops in-house.
This philosophy isn't always bad, but there are certain aspects of Windows where a native Microsoft approach to improving the system simply makes more sense. System protection and integrity, device-driver distribution, software management, user-interface handling -- these are functions close enough to the heart of Windows that Microsoft owes it to themselves and their customers to top themselves when developing these features. That and it's easier to use a sanctioned, native solution to a problem than to pick through the offerings by multiple vendors.
There are encouraging signs that the overall design of Windows 8 will help transcend many of these individual concerns. I see this as being analogous to how Microsoft attempted to deal with many individual security issues in Windows by moving to a model where the user -- even the administrative user -- ran with reduced privileges by default. That by itself made a great deal of difference, although better engineering overall and responding quickly to known security holes also certainly helps.
But Windows 8 is two years or more away, and most people will not wait that long for solutions to the problems described above. They want some sign, sooner rather than later, that the right thing is being done.
And if it Microsoft doesn't provide it, someone else will.