Jump to content

Turn windows features on or off


wcology
 Share

Recommended Posts


Yeah, they replaced "Dll Hell" (in my opinion, a small problem, but they didn't like to be nagged to do tech support) with "Bloat Hell" (a big problem for users in so many ways - let's say just as something that obviously isn't right). 10 times the code, a lot less functionality than 10X. Inefficient. Waste. Not "green". :realmad:

Now that I vented off :rolleyes: , here is a potentially useful link: What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large?. The information I didn't know before is that the files are stored in there and outside files are linked to them (I thought it was the other way around, like Dllcache folder on previous Windows versions).

GL

Link to comment
Share on other sites

Yeah, they replaced "Dll Hell" (in my opinion, a small problem, but they didn't like to be nagged to do tech support) with "Bloat Hell" (a big problem for users in so many ways - let's say just as something that obviously isn't right). 10 times the code, a lot less functionality than 10X. Inefficient. Waste. Not "green". :realmad:

I would have to politely disagree - using hard drive space or not using it doesn't make the device any more or less 'green'. Also, if Windows doesn't use it, meaning *you* want to use it for storage, that's only an argument for more space for your stuff (you're still going to use the space). I just fail to understand the complaints of people with 500+GB HDDs complaining that Wndows uses 4 - 8% of the drive. Why buy a 500GB (or larger) drive if you aren't going to use it?

Also, the complaints about WinSXS only benefitting tech support are largely just flamebait. DLL hell affected EVERYONE using .dll files, users and developers alike (partly because the darn developers would write to a specific version, and then install that version - rather than using the one that shipped with the OS and use those features). It means users no longer have to worry about what apps they have installed when installing another app, and worry if this version is going to overwrite that version, and cause one or the other to fail (or both). It's not perfect, but with 500GB HDD standard on most new PCs (and even 160 and 320GB HDDs standard on most newer laptops), this is probably the best solution all around until something better comes along (if at all).

Again, you are free to your opinion, but this is like complaining that Vista caches up to 90% of the available RAM in the box to make the system faster, rather than leaving it unused. You paid for the resource (RAM or HDD space), why not use it for something constructive rather than let it sit fallow and have some other OS problems go unsolved? I have to disagree with your complaints.

Link to comment
Share on other sites

Hmmm... Again those discussions that I try to stay away from, but from time to time I just can't stand it... No hard feelings I hope, just an exchange of opinions... :whistle:

1. Not green - uses more electricity to move HDD heads further up/down/left/right. Or in general to do things that nobody needs except the OS. If that feature was not implemented in the OS, no program or user would ever miss it.

2. Dll hell was created by Shared DLLs - when RAM was scarce. Shared Dlls are still in use today for compatibility reasons, but that contradicts the argument and philosophy of the OS - to waste RAM and HDD.

3. How to solve Dll Hell? Very easy. Prohibit shared DLLs. Today, RAM is cheap and HDD space is cheap - let all installations put their dlls in their own directory. For old applications, put some kind of virtualization (redirection) in place - preferably during installation.

4. I buy HDDs and RAM for me to use, not Microsoft for their bureaucratic purposes.

I'll stop here...

GL

Link to comment
Share on other sites

2. Dll hell was created by Shared DLLs - when RAM was scarce. Shared Dlls are still in use today for compatibility reasons, but that contradicts the argument and philosophy of the OS - to waste RAM and HDD.

3. How to solve Dll Hell? Very easy. Prohibit shared DLLs. Today, RAM is cheap and HDD space is cheap - let all installations put their dlls in their own directory. For old applications, put some kind of virtualization (redirection) in place - preferably during installation.

DLL hell was caused by two things - one, dll stomping (replacing a .dll file in \system32, and later also in dllcache, with a different version than is shipped with the OS and service pack and hotfix level), and two, shared in-memory .dll mapping. Registry corruption can also cause it, but that was relatively rare.

WFP sort of stopped this by not allowing an app to overwrite a system protected .dll without using the APIs to do so, but nothing stopped an application from calling said APIs and creating dll hell, even on a 2000 or XP system with WFP enabled.

As to your answer of solving .dll hell, you have shared .dll files so that standard Win32 APIs are available and expected, based on OS, service pack, and even perhaps hotfix level. Your suggestion of local .dll files solves nothing (in fact, you end up with the same as WinSXS, but not centralized) and still does nothing to address memory mapping issues. You argue not to waste space on disk with WinSXS, yet you suggest the *exact* same scheme. Also, WinSXS *is* virtualization for *all* apps - they call an API in a .dll they expect in system32, but the OS instead redirects that call to one in WinSXS depending on what they called and what version of the .dll was expected, if it differed from the one in \system32 (or another system location). So, WinSXS does both of the things you describe as "fixes" to the dll hell problem. Coincidence? I think not ;).

Link to comment
Share on other sites

DLL hell was caused by two things - one, dll stomping (replacing a .dll file in \system32, and later also in dllcache, with a different version than is shipped with the OS and service pack and hotfix level), and two, shared in-memory .dll mapping.[...]

WFP sort of stopped this by not allowing an app to overwrite a system protected .dll without using the APIs to do so, but nothing stopped an application from calling said APIs and creating dll hell, even on a 2000 or XP system with WFP enabled.

Half-hearted, isn't it? Prohibit both (+ the API) or prohibit none, I don't care. Just don't make a big deal out of it. This way, it's seen as another unneccesary and ineffective prohibition Microsoft has came up with.

As to your answer of solving .dll hell, you have shared .dll files so that standard Win32 APIs are available and expected, based on OS, service pack, and even perhaps hotfix level. Your suggestion of local .dll files solves nothing (in fact, you end up with the same as WinSXS, but not centralized) and still does nothing to address memory mapping issues.

Standard windows APIs - yes, in dlls in system32. Those that came with the OS/service pack. Everything else - outside. Even Visual*.* and especially .Net*.* :D

You argue not to waste space on disk with WinSXS, yet you suggest the *exact* same scheme. Also, WinSXS *is* virtualization for *all* apps - they call an API in a .dll they expect in system32, but the OS instead redirects that call to one in WinSXS depending on what they called and what version of the .dll was expected, if it differed from the one in \system32 (or another system location). So, WinSXS does both of the things you describe as "fixes" to the dll hell problem. Coincidence? I think not ;).

So why WinSXS can not be lazy and do its work (virtualize/redirect) WHEN a particular system .dll is replaced, instead of just keeping predefined tons of .dlls that I doubt will ever be used on a single system? OK, this is different in XP/Vista, and I'm talking more about the XP concept - which I am more familiar with, but I see it nowhere close to improvement. Anyway, that's the bloat and babysitting that most people complain about.

And yeah, my argument was contradictory, and I was aware of that, but that's because I responded to a contradictory premise as well - Microsoft's curse if you will - to keep compatibility from one side and to invent new things so ppl would buy their new OSs. :lol:

GL

Link to comment
Share on other sites

Half-hearted, isn't it? Prohibit both (+ the API) or prohibit none, I don't care. Just don't make a big deal out of it. This way, it's seen as another unneccesary and ineffective prohibition Microsoft has came up with.
They came up with it because it fixes the problem, and still allows for backwards compatibility so that calling an API results in the same behavior as it did in previous versions (minus deprecated functions, of course). Microsoft is not Apple and they can't just kill off the way Windows works (ala OS9 to OSX) just to make things "easier". It's done this way so things "just work" as much as possible, and the majority of Windows users care about this FAR more than they miss 1 or 2 gigabytes of disk space on their 500+GB hard drives.
Standard windows APIs - yes, in dlls in system32. Those that came with the OS/service pack. Everything else - outside. Even Visual*.* and especially .Net*.* :D
Well, that's a horse of a different color. Windows doesn't provide anything really outside except for .NET, so a change there isn't going to give you much releif, and re-use of WinSXS makes sense from a dev perspective (why do things differently when you can re-use this methodology and have things be consistent).
So why WinSXS can not be lazy and do its work (virtualize/redirect) WHEN a particular system .dll is replaced, instead of just keeping predefined tons of .dlls that I doubt will ever be used on a single system? OK, this is different in XP/Vista, and I'm talking more about the XP concept - which I am more familiar with, but I see it nowhere close to improvement. Anyway, that's the bloat and babysitting that most people complain about.
Complaining is OK, but a failure to understand why it works the way it does is where the bulk of the complaints come from. And, also, removing languages not used during install (either via the answer file or vLite) trims WinSXS down tremendously, and is a supported (well, using the answer file anyway) and documented procedure, and a way of mitigating this bloat you speak of.
Link to comment
Share on other sites

They came up with it because it fixes the problem, and still allows for backwards compatibility so that calling an API results in the same behavior as it did in previous versions (minus deprecated functions, of course).

Wanting both ways? That's as half-harted as it gets. ;) But it still isn't so important, if they don't try to justify another problem (bloat) as a solution to this problem (dll hell) which they created themselves in the first place.

Microsoft is not Apple and they can't just kill off the way Windows works (ala OS9 to OSX) just to make things "easier".

I wouldn't know, I stopped using macs around OS7. :D But they changed architecture a lot (68000/PPC/Intel) so maybe that was the reason? (I really don't know for sure)

It's done this way so things "just work" as much as possible, and the majority of Windows users care about this FAR more than they miss 1 or 2 gigabytes of disk space on their 500+GB hard drives.

I agree, but we who think differently (or at all :whistle: ) suffer. (I'm not trying to offend 'the majority', just saying that:

1) most often they don't know or care to know about this;

2) don't make decisions when buying computer/OS;

3) don't have a choice (OEM))

Complaining is OK, but a failure to understand why it works the way it does is where the bulk of the complaints come from.

Let's put it another way - explaining why it works that way is OK, but it doesn't solve the problem. :)

GL

Link to comment
Share on other sites

Yeah, they replaced "Dll Hell" (in my opinion, a small problem, but they didn't like to be nagged to do tech support) with "Bloat Hell" (a big problem for users in so many ways - let's say just as something that obviously isn't right). 10 times the code, a lot less functionality than 10X. Inefficient. Waste. Not "green". :realmad:

I would have to politely disagree - using hard drive space or not using it doesn't make the device any more or less 'green'. Also, if Windows doesn't use it, meaning *you* want to use it for storage, that's only an argument for more space for your stuff (you're still going to use the space). I just fail to understand the complaints of people with 500+GB HDDs complaining that Wndows uses 4 - 8% of the drive. Why buy a 500GB (or larger) drive if you aren't going to use it?

Also, the complaints about WinSXS only benefitting tech support are largely just flamebait. DLL hell affected EVERYONE using .dll files, users and developers alike (partly because the darn developers would write to a specific version, and then install that version - rather than using the one that shipped with the OS and use those features). It means users no longer have to worry about what apps they have installed when installing another app, and worry if this version is going to overwrite that version, and cause one or the other to fail (or both). It's not perfect, but with 500GB HDD standard on most new PCs (and even 160 and 320GB HDDs standard on most newer laptops), this is probably the best solution all around until something better comes along (if at all).

Again, you are free to your opinion, but this is like complaining that Vista caches up to 90% of the available RAM in the box to make the system faster, rather than leaving it unused. You paid for the resource (RAM or HDD space), why not use it for something constructive rather than let it sit fallow and have some other OS problems go unsolved? I have to disagree with your complaints.

i have 64 gig SSD. so what about me?

but i think the arguements are those of us who dont use 90% of what Vista has. i dont use windows mail, natural language or media center. some of that stuff is nearly a gig in size alone. it just sits there, does nothing but take space if you dont ever use it. some people store videos on drives and 500 gigs isnt much for that. so yes the OS taking 4-8% can be a big deal to some.

so i vlite and now instead of 13 gigs for a fresh install, its now 5 gigs, works great and does what i want....quite a difference.

Link to comment
Share on other sites

is there a way i can delete the dreamscene packs without vliteing?

To anwser your question, no. Vlite would the only way to remove dreamscene from the installation of vista.

Guys lets try and keep on topic :) no post hijacking, as much i would be interested in a nice down home disscusion on the WinSXS folder and the pro's and Con's of that. Start up a new topic on it and we can argue there.

i have 64 gig SSD. so what about me?

I agree with you, but people have griped for years when they had to put in there windows CD to install X function and app, Microsoft finally fixed that issue and now people complain that windows take up too much space by doing that exact thing.... i use a 64 gig SSD for work as well and even though it is 70% used, it really isn't such a big deal, i have growth room and i am not impacting preformance. it is also still easy to expand space and have an external HD as well (which truly is not a bad idea for all your personal or important docs) but that is just my 2 cents

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...