Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
The theme of “choice and control” has been applied in many aspects of how we have designed Windows 7. We’ve certainly received lots of positive feedback about the theme and about the choices we’ve made in the design, and we’ve also received a few suggestions for how we might continue to implement this theme in the future. We’ve received feedback for features that should be even more customizable (such as Explorer or the logon screen) or features that should be added to Windows (such as a PDF format reader, security tools, or disk utilities). And we’ve received feedback that some users might prefer to run Windows without certain features. This post is about a point of choice and control in the Windows 7 control panel called “Windows Features” which is where you can choose to turn various features of Windows on or off. This continues our discussion of changes we have made based on feedback from the Beta as we progress to the Release Candidate. This post is by Jack Mayo who is the group program manager for our Documents and Printing team and also worked on Internet Explorer 8. --Steven
“Turning Windows Features On or Off” has a long history in Windows, going back to the earliest days of the 32-bit code base. We’ve received a lot of suggestions about features that you would like to turn on or off using your own criteria for choice. For Windows 7 we’ve engineered a more significant list of features and worked to balance that list in light of the needs of the broad Windows platform as well. We want to provide choice while also making sure we do not compromise on compatibility by removing APIs provided for developers. We also want to strike the right balance for consumers in providing choice and balancing compatibility with applications and providing a consistent Windows experience.
We know many have specific ideas of what constitutes a “feature” or a “program” in Windows and what constitutes an identifiable “part” of the operating system, and yet we also know different people can have different points of view, often strongly held. Some might take an end-user approach and identify a feature based on a window or start menu shortcut. Some might take an approach based on one perspective of architectural subsystems, such as storage or security. Some might take an approach based on what to some are alternate choices to some similar functionality. All of these are valid in some context, but would not result in consistently identifying “features” considering these varied points of view. As engineers we know that no software system can be decomposed into an arbitrary set of layers or parts and any decomposition is likely to change over time.
We don’t want the discussion about this feature or these choices to digress into a philosophical discussion about the definition of an operating system, which is ultimately a challenging exercise (judging by the revision history on the community page), but we do want to improve a feature centered on helping to meet the feedback expressed by some over the summer when this blog started.
In the Release Candidate for Windows 7 we have extended the control panel called “Windows Features” which is available from the standard “Programs and Features” control panel (we often call this ARP, for the original name of Add/Remove Programs). This location is unchanged from Vista and XP, though the wording has been clarified. In Windows 7 if you bring up the Windows Features control panel by clicking on “Turn Windows Features on or off” (or just typing “Windows features” in the start menu) you will see the following in the Release Candidate (by default the hierarchy is not fully expanded, but in this screen shot I’ve expanded some elements for additional information):
For those familiar with the Vista version or the Beta version of this dialog you will notice the list has grown. Let’s talk about what we’ve added and briefly how it works.
If a feature is deselected, it is not available for use. This means the files (binaries and data) are not loaded by the operating system (for security-conscious customers) and not available to users on the computer. These same files are staged so that the features can easily be added back to the running OS without additional media. This staging is important feedback we have received from customers who definitely do not like to dig up the installation DVD.
For any of the features listed you can change the state to enable it or disable it. The Vista and Windows 7 beta control panel lists a wide range of features. Some are targeted towards Developers working on a client workstation (IIS, MSMQ, etc.), others are utilities for network administrators and enthusiasts (RSM, SNMP, Telnet, etc.), and some are features customers have asked us to make optional (Games, Fax and Scan, Tablet PC components).
In Windows 7 we are expanding the number of features you have control over in this regard, giving customers more control, flexibility and choice in managing the features available in this version of Windows. In addition to the features that were already available to turn on or off in Windows Vista, we’ve added the following features to the list in Windows 7:
It is worth describing the details of “remove” since this too is a place where there are engineering and customer decisions to be made. We’ve already seen one decision which is to make sure we keep the features staged for future use so that a DVD is not required. A second decision is that we also continue to support the APIs available for features where these APIs are necessary to the functionality of Windows or where there are APIs that are used by developers that can be viewed as independent of the component. As many of you know these are often referred to as “dependencies” and with Windows the dependencies can run both internal to Windows and external for ISVs.
It should be no surprise, but when we develop new features in Windows we tend to use the underlying infrastructure and associated APIs rather than duplicate code which would create extra working set, slow performance, and increase the surface area that needs to be secured, etc. We all know code reuse is a good engineering practice. As a platform, Windows tends to emphasize the creation of APIs for many systems, even when those subsystems are viewed as part of a larger system. When we have APIs that are used, we faced the choice of breaking software that just expected those APIs to be there or to continue to support the API. When we continued to support the API our approach was to remove a feature by making sure that an end-user could not invoke the feature via traditional end-user mechanisms. These are often difficult decisions as we work to balance the expectations of developers, the shared desire to deliver a robust release of Windows 7, and to maintain the goals set out by the feature “Turn Windows Features On or Off”. Because there are so many combinations of dependencies just represented in this list, selecting some options might provide you with some explanation as to the challenges in selecting a combination (for example Windows Media Player and Windows Media Center share a lot of code so turning one off might introduce a pretty complex situation for the average end-user).
Finally, we know some have suggested that this set of choices be a “setup option”. Some operating systems do provide this type of setup experience. As we balanced feedback, the vast majority of feedback we have received was to streamline setup and to reduce the amount of potential complexity in getting a PC running. We chose to focus this feature on the post-setup experience for Windows 7.
Some folks have asked about other places to manage the settings in this list. For enterprises, our group policy and setup and imaging tools, make these choices just as straight forward as other choices in creating your image. Group policy permits control of this user interface and the setup and imaging tools allow the creation and imaging of Windows however you prefer.
Many have asked about developers that rely on MSHTML and the browser control in IE, codecs and media APIs in media player, and other APIs such as winsock and networking elements of the system and how those relate to this feature. As we said, maintaining the APIs both from a compatibility perspective and from a desire to continue to offer APIs at many levels of the OS, not just the user interface level, is a core tenet of Windows and so these will continue to remain even if you check the remove option. This applies to components that have such APIs, as we described in the post.
Windows 7 in various places is example of very good engineer job, but numbers are numbers, facts are facts and they show, that in some areas there are MANY places for improvements.
Creating posts with explanations will not resolve some things/issues and will not make some things less controversial.
I was writing a lot about separating applications/decentralizing Registry and similar things. You should really think about it for Windows 8 - currently system seems to have mix of everything with everything. Looking into build 7000 (system with antivirus, FireFox, Flash Player):
winsxs - with sandboxing each application can have own copy of DLL in own real directory and it would be not required...
windows directory - if we have windows\log directory, what does windowsupdate.log make inside windows directory ? why not move twain into system32 ? (and why not allow user to resign from it)
windows\web - IE missed files
windows\offline web pages - why it isn't inside user files directory ?
system32 - too many files: files from MS-DOS could be moved to separate directory, national files could be moved to separate directory
windows\en-us - if there is subdirectories with national files inside system32, what does this one make here ? and if there are so many national files for all national languages in many directories, isn't possible to move not used into some cab and unpack them, if necessary ?
system32\macromed\flash - uninstalls for Flash Player. in my opinion system shouldn't allow to put uninstallers here (and please don't blame "wrong" developers)
system32\setup - once again national files, en-us directory inside empty
windows\prefetch - are you deleting files from it, when exe/com file is removed ?
windows\modemlogs - sic, created even without modem in system
windows\addins - one file connected with fax...
windows\assembly\temp and tmp directories - what for, if we have windows\temp ?
windows\system32\tasks - we have windows\tasks
etc. etc. Of course it's possible to say, that it's because of compatibility, but...system could be much smaller and faster, when it will be cleaned (but really cleaned). Add some proposed things and you will get much bigger security...
Shortly: it can be much better...
if user want to remove something from his own HDD, he should have such ability - this is his HDD. If you're afraid of removing some APIs (which could be used by other user apps), you can always make this way:
in Windows features (almost) each option will have two states: uinstalled, available after first use, installed. Something like in the Office, nobody will blame you, people will only like more you.
For example: user doesn't want help engine ? This is his choice.
I wanted to write three states of course ;)
I wanted to write "one of three states" of course ;)
I just want to be clear on a few things.
I dont mean to sound as if I think these changes are useless. Allowing us to lower the memory footprint by disabling features that are not needed is certainly a huge step in the right direction, and should be applauded. I hope this functionality is even further extended from where it is now.
I've always been against the common enthusiast practice of disabling services to lower the memory footprint, as it tends to inevitably break something that a program expects to find. Allowing us to do this through an approved tool where the APIs are left intact is the right way to go about this, and when it's flexible to the point that will satisfy most enthusiasts (as I believe it most is at present), they'll be less likely to "break" the previously inflexible system.
I also think the decision to "stage" the files is a good idea, and should be the default. My only gripe is that its not optional. Even if 16GB is the minimum, which is a reasonable amount, every bit counts on a small SSD.
Even if it isnt a matter of cramming into a small place, or performance issues, I believe a lot of users just want this kind of thing under their control. A clean PC is like a clean house. It just feels....right.
On some more specific requests for items that should be removable from this UI:
The sample media files that are installed by default.
Lesser used fonts. I dont speak or read arabic, japanese or chinese, and don't plan on doing so any time soon.
Backup and restore center, defender, firewall, defrag, etc as many of us have our own maintenance and security suites.
Ease of access tools - fortunately, most of us are not disabled.
Applets such as wordpad and paint, and well...just about every applet.
I think you're dead on with your approach of starting large and paring down from there. It's very important not to make it difficult from the start for everyone.
I still hold to belief that for the majority of users for which any of this discussion is even relevant, that theyre most likely up to the task of making these decisions for themselves, and that they should be limited to the least possible degree.
As long as the defaults are sane and the configuration is relatively hidden from the less experienced users, then you dont need to agonize over balancing feedback from various groups with various needs. The right solution would remind me of the two tiers of control panel access - simplified on top, but you havent taken away the "real" CP applets underneath.
"We all know code reuse is a good engineering practice. As a platform, Windows tends to emphasize the creation of APIs for many systems, even when those subsystems are viewed as part of a larger system."
A reasonable solution is to break off the parts that are used externally into independent libraries. Just as Konqueror made KTHML and KJS separate libraries, Internet Explorer can break off Trident into a independent library.
Anyone prepared to "switch off" windows features is probably doing so in the knowledge that they won't use them.
As he states, I see no benefit to me to "switch off" a feature I never wanted in the first place if it's still sitting there hogging disk space on the off chance I'll change my mind.
nLite/vLite, you are a wonderful wonderful tool.
People asking for removing the stuff which has been turned off have not developed any software (or people are developing only web enabled stuff now a days). As Jack mentioned windows API's dlls are used by numerous softwares, tools. There might be lot of softwares out there which instead of writing there own HTML rendering engine, used web browser control to render html pages in there software. Similarly there might be 100's of softwares tools which create web browser object internally which maps to IE objects irrespective of your "default web browser". They use it because IE supports automation to a level which firefox or other can only dream. IE is not just a browser for the end user, but rather it is a collection of UI controls, APIs which can enable any software (i mean desktop applications, not web based ones)to be able to communicate with web.
So if might not want IE for the day to day browsing but all fire fox users out there you guys are still using IE one way or the other.
I hope only that this great effort of Microsoft does not increase Bloatware from manufacturers OEM.
See for Example Google toolbar in DELL Notebook replaced by Windows Sidebar .
I know the bloatware also serves to lower the cost of a PC , But OEM manufacturers have already ruined the image of VISTA with this method intrusive
"Install after first use" is resolving this issue - if application is searching for mshtml.dll (or other parts), display for user info, whether he want or not installing IE rendering engine.
This is very simple, works quite good with Office and info about broken apps is a little excuse for me (of course CHM files and some other are using IE engine, but there are users, who haven't opened any of them since long time...)
Hey Windows 7 Magnifer is AMAZING with 6 Monitor :-)
BTW, about disabling features in 7000:
1. set UAC to highest level
2. set "Application Information" service to Disabled
3. restart system
You can't do any UAC action, can't install software, etc. etc.
Oh drats I had hope that this wouldn't happen...Now the OEM's are going to screw up the best OS that I have ever used.
1. Shades of Real Player
2. I gots the Opera Blues...
3. Da Skype just connected me to Ek-Bay!
Come On what I really want is Internet Exporer for Unix!
Firefox really doesn't do it for me.
Essentially, your argument in this case is:
"Some developers can't be bothered to write their own code so they re-use inappropriate code from Windows that doesn't need to be there to save time."
This isn't an argument that wins a lot of support from me.
It's certainly strange that before IE, developers were perfectly capable of writing high quality, robust code to display different types of content, or interface with the internet, without the need for automated hand holding, or the install of bloated apps like WMP for DLL support. I have yet to use a desktop app that uses IE processes that left me thinking "Hmm, there's clearly no other way they could have designed that", or "Oh what a high quality, speedy, well developed app." I'm not having a go at Microsoft here, but I have never in my many decades with computers seen any benefit to the end user from lowering the intellectual cost of entry to new developers who aren't prepared to put some effort into their code, or are desperate for the "good for me, screw the End User" shortcut which things like this promote.
IE is one of the major infection vectors out there and there is really no reason for a developer to use it in a desktop app when the OS has more than enough ways of helping you display and organise content already. Even assuming there WAS a need to use the code, there's no reason why ALL end users should have to bend over and tailor their systems to suit a developer that needs a specific bit of code for a specific app that the user might not ever want, need, or find a viable alternative for. It's another example of Microsoft designing something that suits developers and OEMs, not the end user.
And the final nail in the coffin is this:
Microsoft is already forced to sell versions of Windows that have IE and WMP removed. So the argument that they are "required" for compatibility purposes is void.