Win+7+Missing+bits


 * This is not my work but felt it relevant enough to incorporate it**

** Win 7 Missing bits **

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]. []


 * SteadyState Helps Make it Easier to Manage Your Shared Computers ** Shared computers are commonly found in schools, Internet and gaming cafés, libraries, and community centers. It is increasingly common for owners, teachers, or non-technical personnel to manage shared computers in addition to their many other responsibilities.

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. 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. When Windows 7 came out, administrators were dismayed to learn SteadyState did not 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] []

Windows SteadyState does not support Windows 7; however, many of its features can be replicated by using native Windows 7 features and free tools from Microsoft. This document is intended primarily for IT pros who configure shared-computer access in business environments, but partners who support shared-computer access in schools, libraries, and Internet cafes will also find the information useful. The document set includes:• Creating a Steady State by Using Microsoft Technologies (this document), which describes the native Windows 7 features and free tools from Microsoft that you can use to create a steady state on computers running Windows 7.• Group Policy Settings for Creating a Steady State, which is a reference that describes Group Policy settings that you can use to configure computer and user settings and prevent users from changing those settings.• The SteadyState Reference worksheet (.xlsx file), which you can use to look up and filter settings that this document and the reference describe. For example, you can quickly find information about settings that are related to Start Menu restrictions.

in which they described how administrators could use many of the native technologies in Windows 7 to emulate the behaviors of SteadyState.

Worse, one of the biggest and most crucial functions -- disk protection – is not provided except through workarounds like System Restore. These do not work in remotely the same fashion as SteadyState's own disk protection, which required little or no intervention or downtime. The startup manages large-scale Web infrastructures to prevent downtime related to configuration changes What is 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. But in the long run, Microsoft owes it to their users to put SteadyState -- or something like it -- back in. 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 will 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 is often just faster to provide them directly to the end user -- especially if they are only being provided for a small subset of the total user population that's running Windows.

WildPackets brand new packet capture system at 11.6 Gbps will make your enterprise 10 Gig-ready. Of course, this does not come cheap. 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. 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 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 do not 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. More Windows Insights White Papers Likewise Software Lets You Take Advantage of Active Directory Infrastructure Across Linux, Windows and Mac Systems The brunt of the work would fall to Microsoft first, though. They would 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 would not 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 is a whole OS upgrade away, at the very least. 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.
 * Proper Touch Support**

What is 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 was not 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 is 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.

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 is not 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.