这是一个在安装Windows Vista和Windows Server 2008时候经常被提及的问题.为了解答这个问题,首先我们要了解“组件化”这个词的含义,然后再谈一谈Vista里面的组件们是如何被管理的.
Vista相比于前任的重大变化之一就是从用“安装配置”(INF文件)描述的操作系统过渡到组件化的系统.Windows中的所谓“组件”就是一或多个二进制文件,一个索引文件,还有一个描述安装过程如何进行的XML格式文档.这个文档描述了可能的注册表操作或者安全权限需求.组件们以逻辑单元分组,这些单元的不同就是Windows不同版本的区别.
WinSxS这个文件夹存放了Windows所需要的所有组件。每一个组件都有属于自己的命名，可以看出它属于何种版本、语言，以及是32位还是64位的Windows。每当系统需要任何一种文件的时候，都会从这个文件夹找到相应的文件，再拷贝到需要的路径里面，或者直接创建一个映射，指向winsxs文件夹里的源文件（显然这么做对硬盘空间仁慈多了）。也就是说，实际上Winsxs这个文件夹和Windows完全安装一次所需的磁盘空间一样大。
这样一来，我们便不能完全从硬盘上删除某种Windows功能，就像我们刚刚在xp里还能做到的那样。（你也许注意到了，控制面板“程序和功能”里有一个“打开或关闭Windows功能”选项——而不是“添加或删除Windows功能”。）
也是因为如此，理论上winsxs这个文件夹并不会随着时间推移越来越臃肿，塞进一些天知道是什么的东西（很不幸，很多Windows文件夹都有自动增肥的功能）。但有一个例外——就是如果你安装了一项功能的更新（例如通过Windows Update），那么为了方便你回滚有问题的更新，新旧两种文件副本会同时存放在Winsxs文件夹里！（看来要双手合十祈祷微软能一次性更新尽可能多的补丁，而不是一次一个，一次一个……）
微软这么做显然能大大提高产品的稳定性。因为每个更新版本都有副本保存，所以当我们回滚一个更新时，会退回到次新的版本，不会出现版本号混乱的局面。而且，如果要添加一个新功能，系统会检查是否已经有了版本号更新的组件，而不是直接插入光盘，因为那样只会装上RTM的旧版本。
最后，安全的削减Winsxs文件夹的大小，只有一个办法，就是尽可能去掉自己不用的组件及其更新。虽然微软没有提供官方的整合SP1到Vista RTM ISO的办法，但是SP1中的一个小程序VSP1CLN.EXE可以永久整合SP1到系统，删除一切用于回滚的版本备份，这样便不能回退到RTM。
（在现在硬盘容量向TB迈进的时候，牺牲一部分硬盘空间来换取比以往更高的安全性，也许是比较划算的办法。看来Vista的确是面向未来而设计的一款系统。）
文章作者Joseph Conway，微软企业级平台支持高级工程师。
cnBeta编译自微软TechNet LonelyJames译注
What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large?
A commonly asked question among people looking at a Windows Vista or Windows Server 2008 installation is “why is the WinSxS folder so big?!” To answer that question I need to first describe componentization, and how components are managed in Windows Vista.
One of the largest changes between previous versions of Windows and Windows Vista was a move from an INF described OS to componentization. A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have. Components are grouped into logical units, and these units are used to build the different Windows editions.
All of the components in the operating system are found in the WinSxS folder – in fact we call this location the component store. Each component has a unique name that includes the version, language, and processor architecture that it was built for. The WinSxS folder is the only location that the component is found on the system, all other instances of the files that you see on the system are “projected” by hard linking from the component store. Let me repeat that last point – there is only one instance (or full data copy) of each version of each file in the OS, and that instance is located in the WinSxS folder. So looked at from that perspective, the WinSxS folder is really the entirety of the whole OS, referred to as a "flat" in down-level operating systems. This also accounts for why you will no longer be prompted for media when running operations such as System File Checker (SFC), or when installing additional features and roles.
That explains why the folder starts off big, but not why it gets larger over time – the answer to that question is servicing. In previous versions of Windows the atomic unit of servicing was the file, in Windows Vista it’s the component. When we update a particular binary we release a new version of the whole component, and that new version is stored alongside the original one in the component store. The higher version of the component is projected onto the system, but the older version in the store isn’t touched. The reason for that is the third part of why the component store gets so large.
Not every component in the component store is applicable, meaning that not every component should be projected onto the system. For example, on systems where IIS is available but has not been installed, the IIS components are present in the store, but not projected into any location on the system where they might be used. If you’re familiar with how multi-branch servicing works in previous versions of Windows then it’ll make sense to you that we have a different version of the component for each distribution branch and service pack level, and that all these different versions are also stored in the WinSxS folder, even if they’re not immediately applicable. So a single Post SP1 GDR package that contains an update to one component will end up installing four versions of that component in the WinSxS folder – double that on a 64 bit operating system for some components.
Now that you know why the store can grow to be so large, your next question is probably to ask why we don’t remove the older versions of the components. The short answer to that is reliability. The component store, along with other information on the system, allows us to determine at any given time what the best version of a component to project is. That means that if you uninstall a security update we can install the next highest version on the system – we no longer have an “out of order uninstall” problem. It also means that if you decide to install an optional feature, we don’t just choose the RTM version of the component, we’ll look to see what the highest available version on the system is. As each component on the system changes state that may in turn trigger changes in other components, and because the relationships between all the components are described on the system we can respond to those requirements in ways that we couldn’t in previous OS versions.
The only way to safely reduce the size of the WinSxS folder is to reduce the set of possible actions that the system can take – the easiest way to do that is to remove the packages that installed the components in the first place. This can be done by uninstalling superseded versions of packages that are on your system. Service Pack 1 contains a binary called VSP1CLN.EXE, a tool that will make the Service Pack package permanent (not removable) on your system, and remove the RTM versions of all superseded components. This can only be done because by making the Service Pack permanent we can guarantee that we won’t ever need the RTM versions.
So yes, the WinSXS folder is very large, and it will continue to grow as the OS ages. I hope that this clears up some of the questions about why that is, and what you can do about it. Note that the Windows servicing structure and the layout of the store is subject to change.
Joseph Conway
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support
What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large?
A commonly asked question among people looking at a Windows Vista or Windows Server 2008 installation is “why is the WinSxS folder so big?!” To answer that question I need to first describe componentization, and how components are managed in Windows Vista.
One of the largest changes between previous versions of Windows and Windows Vista was a move from an INF described OS to componentization. A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have. Components are grouped into logical units, and these units are used to build the different Windows editions.
All of the components in the operating system are found in the WinSxS folder – in fact we call this location the component store. Each component has a unique name that includes the version, language, and processor architecture that it was built for. The WinSxS folder is the only location that the component is found on the system, all other instances of the files that you see on the system are “projected” by hard linking from the component store. Let me repeat that last point – there is only one instance (or full data copy) of each version of each file in the OS, and that instance is located in the WinSxS folder. So looked at from that perspective, the WinSxS folder is really the entirety of the whole OS, referred to as a "flat" in down-level operating systems. This also accounts for why you will no longer be prompted for media when running operations such as System File Checker (SFC), or when installing additional features and roles.
That explains why the folder starts off big, but not why it gets larger over time – the answer to that question is servicing. In previous versions of Windows the atomic unit of servicing was the file, in Windows Vista it’s the component. When we update a particular binary we release a new version of the whole component, and that new version is stored alongside the original one in the component store. The higher version of the component is projected onto the system, but the older version in the store isn’t touched. The reason for that is the third part of why the component store gets so large.
Not every component in the component store is applicable, meaning that not every component should be projected onto the system. For example, on systems where IIS is available but has not been installed, the IIS components are present in the store, but not projected into any location on the system where they might be used. If you’re familiar with how multi-branch servicing works in previous versions of Windows then it’ll make sense to you that we have a different version of the component for each distribution branch and service pack level, and that all these different versions are also stored in the WinSxS folder, even if they’re not immediately applicable. So a single Post SP1 GDR package that contains an update to one component will end up installing four versions of that component in the WinSxS folder – double that on a 64 bit operating system for some components.
Now that you know why the store can grow to be so large, your next question is probably to ask why we don’t remove the older versions of the components. The short answer to that is reliability. The component store, along with other information on the system, allows us to determine at any given time what the best version of a component to project is. That means that if you uninstall a security update we can install the next highest version on the system – we no longer have an “out of order uninstall” problem. It also means that if you decide to install an optional feature, we don’t just choose the RTM version of the component, we’ll look to see what the highest available version on the system is. As each component on the system changes state that may in turn trigger changes in other components, and because the relationships between all the components are described on the system we can respond to those requirements in ways that we couldn’t in previous OS versions.
The only way to safely reduce the size of the WinSxS folder is to reduce the set of possible actions that the system can take – the easiest way to do that is to remove the packages that installed the components in the first place. This can be done by uninstalling superseded versions of packages that are on your system. Service Pack 1 contains a binary called VSP1CLN.EXE, a tool that will make the Service Pack package permanent (not removable) on your system, and remove the RTM versions of all superseded components. This can only be done because by making the Service Pack permanent we can guarantee that we won’t ever need the RTM versions.
So yes, the WinSXS folder is very large, and it will continue to grow as the OS ages. I hope that this clears up some of the questions about why that is, and what you can do about it. Note that the Windows servicing structure and the layout of the store is subject to change.
Joseph Conway Senior Support Escalation Engineer Microsoft Enterprise Platforms Support