separate 64 and 32-bit

Sobi

New Member
Hello,

in some component the removal is separate 64 and 32-bit.
I only install 64bit Windows10.

Need i the 32bit variant or can i remove it?
I don't no why microsoft implement 32bit componente in a 64bit iso
When i need the 32 bit version component?

Thanks for help an happy easter
 
Others here know the answer to your question better than I. However, my understanding is that the 32-bit variants are left in Windows for legacy purposes. For example, I have WordPefect X6 installed on my Win10 64 bit. But WP X6 is a 32-bit program.

There are many other 32-bit programs on my computer too. And even in my 64-bit programs, I know of one that uses old 32-bit code for some components!

It's almost impossible to know when you'll need an old 32-bit component for legacy reasons. If you're sure you won't need 32-bit components, then remove them. But really, we're back to my philosophy that "you CAN be too thin." I mean, the only reason that I can see for removing 32-bit components is to slim down the size of Windows on disk. The 32-bit components don't harm anything by waiting in reserve if needed.
 
Mainly 32-bit application support, APIs, like IE Engine 32-bit, you might need most of the time in the next few years.
But something like MMC controls (new beta components), I see no reason to have. It all comes down to the applications you use and what they rely on, some are still 32-bit.

As time goes, more and more applications have true 64-bit versions, we'll nibble more and more of the 32-bit compatibility layer.
And MS will release a pure 64-bit OS in a few years no doubt, or the Windows X will become that in a way, as it can emulate/virtualise on per-app basis.

Also if there is a component that you keep and want to split the 32-bit to keep just the 64-bit version, let me know.
 
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.))
 
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?
 
So #4 is like Black Viper's preference? I'm willing to place my bets with nuhi. (I suppose, after time, ppl would report what they removed, but then found was needed in the forum. (As I have done here for running WMC.))
 
So #4 is like Black Viper's preference? I'm willing to place my bets with nuhi. (I suppose, after time, ppl would report what they removed, but then found was needed in the forum. (As I have done here for running WMC.))
Yes.

I think #3 is plenty like a lite recommendation.

First need to make a switch/prompt to decide WU or no WU, makes a big difference in further choices and final size.
Currently it's too complex to switch those modes, one needs to Disable Servicing Stack compatibility and remove Windows Update to trigger deep removals.
And it does not remember if it was done so in the previous session.
 
Back
Top