It occurred to me, after listening to the SecurityNow! podcast, that another good reason for removing 32-bit Windows components is security. (IIRC, they were talking about yet another bug in the Windows subsystem, and this one was in old (32-bit) legacy code from way back.)
There are a lot of security holes in Windows, and some of them are in the (old) 32-bit code. Any time that you remove a component, you are reducing the attack surface of Windows.
So maybe I'll start thinking about removing 32-bit apps. (I wonder if NTLite can perform a survey of a user's system and lock out 32-bit compoents that have been in use? (Something like "Compatibility" where it prevents you from removing something that you need.))
True, security is always increased by reducing the attack surface.
Detecting which components you use...maybe by NTFS file access times, but some users disable that and it's unreliable - who know what can trigger it (antiviruses come to mind).
Then maybe registry cache, it has traces on what we use, still it's not something that would be straightforward and it's science (of spying) on its own.
There are not that many 32-bit splits for now to warrant any kind of automated selection, and as time goes all of them should go anyway. Let's say other than Internet Explorer core (not UI), it is not needed by many.
On a tangent, maybe derailing the topic a bit:
Starting to think about adding tags to components, in a sense allowing for the dreadful built-in presets.
For example a 3-level system, to indicate:
1-mostly needed component, current "Recomended All" compatibility
2-read description of this component, you might need it
3-mostly not needed, uncheck all of these and hope that we have the same pattern of use
(Maybe under 4th tag - the author does not keep this
)
Then a button to uncheck all under #3 or #2, never #1 or it would be identical to uncheck all.
Thoughts?