Kill WinSxS on XP?

[GrofLuigi]

Hi,

I don't think Microsoft's solution to The Dll Hell is effective. In fact, as I'm not a programmer, I can't see how many times it has saved my a$$, but I can clearly see the overhead it creates on my system. Some even say it creates new problem(s). BTW I don't understand much from that link, so I might be wrong. But there are many others.

For starters, I'd expect they would put most work on correcting the problems created by rogue programs from some big $$$ companies I (and most normal users) rarely use, or created by their Visual *** compilers, which are just bloating like a baloon over time. Not the problems of small/freeware applications that are most common.

So: Can I clean the WinSxS mess on XP and how? Has someone tried it? Is someone working on that? Will a simple delete (+move the DLL to System32) do? I see there is something done on Vista, can it be applied on XP?

I don't care about versioning problem, I think it's overrated. I think it can be solved in at least three ways:

1. Find out the Dll file with largest version number and stick with that. Most of the time, features are added in programs, not removed.

2. Find out that speciffic app needs speciffic dll. Put it in the app's folder.

3. For hopeless cases, find another app that does the same job.

And so on... Comments? Suggestions?

GL

[kz26]

in an ideal world, DLL hell wouldn't be a problem and so WinSXS wouldn't be needed.

However, I don't think the bloat problem is as big as you make it out to be. I have Adobe CS3, Office 2007, and the full VS2005 pro installed and my WinSXS folder is only 42.7 MB. Perfectly reasonable. I think the WinSXS thing makes you better safe than sorry. After all, with today's big HDDs and fast multi-core processors it isn't much of an issue at all.

[GrofLuigi]

It's not only size that bothers me, it's all overhead that's associatied with it. I think it's a complication that doesn't solve the problem it was created for and additionally it creates other problems.

Just use Process Monitor to see how much calls and queries it creates when running a simple .exe that's not even using it. It's potential point of entry for malware. It's potential breakdown point if it decides it doesn't like you (can't start cryptographic service, can't revocate certificates...).

From glancing over them, it seems they could be removed from the registry (by searching for their unique IDs and removing them and all references that they are associated with), but what about the calls that are hardcoded in (very few) system DLLs and decoding/modifying Policies and Manifests? I'm afraid I don't have enough knowledge for that.

GL

*Edit: I knew there must be others that came up with the idea, but that's not finished... Besides, it's hard to eliminate all Vista sufferers in the search... Their plight is bigger.

Edited August 4, 2008 by GrofLuigi

[spacesurfer]

i've seen some many posts about peoples winsxs being > 1 gb! i don't understand. mines always been < 50 mb even with > 20 programs.

[GrofLuigi]

i've seen some many posts about peoples winsxs being > 1 gb! i don't understand. mines always been < 50 mb even with > 20 programs.

That's on Vista and Server2008, and that's different. From what I've read, some say it's mostly (hard/soft) links to other folders, some say there's even movies (dreamscene) inside, but all agree WinSXS is more heavily protected on those OSs and the OSs are liberal at filling it, but very conservative at cleaning it...

I'm talking about XP/Server2003, where it supposedly hasn't grown too much roots, and examining it might help Vista/Server2008 users.

The direction this is heading, it seems to me it's a battle for control - soon we won't be able to decide what code we want to run on our computers. Imagine future DRM/WGA implementations you won't be able to get rid of if you wanted to (legal issues aside).

GL

Edited August 4, 2008 by GrofLuigi

[GrofLuigi]

Some more info (and tool?): The End of DLL Hell

What p***ess me off is that it's like police taking you to paradise - no way to resist. You can't go to hell even if you wanted to.

But I'm still searching...

GL

[Tripredacus]

Some more info (and tool?): The End of DLL Hell

What p***ess me off is that it's like police taking you to paradise - no way to resist. You can't go to hell even if you wanted to.

But I'm still searching...

GL

Reading through this document, I am beginning to think of how Windows goes about sharing DLLs (or other files) in the first place. If anyone has ever run filemon, you notice that programs spend a large amount of time trying to find the files they need. They first look in the app dir, then they look in c: and then they look in c:\windows. Typically, most of the shared (or system) files programs try to use are sitting in c:\windows but they will constantly search other places first. And programs don't seem to learn where these files are, so next time you open that program, it goes through its searching all over again. When I worked as a desktop applications programmer, is when I first found this behaviour. After checking with our other programmers and the source code, it was determined that this behaviour either comes from the compiler's instructions or Windows itself. In the idea of speeding up application calls, don't you think that this could be something that could be also fixed? I know this borders on a System bug or inadequacy and not so much related to DLL Hell, but I figured I'd post it.

[GrofLuigi]

Reading through this document, I am beginning to think of how Windows goes about sharing DLLs (or other files) in the first place. If anyone has ever run filemon, you notice that programs spend a large amount of time trying to find the files they need. They first look in the app dir, then they look in c: and then they look in c:\windows. Typically, most of the shared (or system) files programs try to use are sitting in c:\windows but they will constantly search other places first. And programs don't seem to learn where these files are, so next time you open that program, it goes through its searching all over again. When I worked as a desktop applications programmer, is when I first found this behaviour. After checking with our other programmers and the source code, it was determined that this behaviour either comes from the compiler's instructions or Windows itself. In the idea of speeding up application calls, don't you think that this could be something that could be also fixed? I know this borders on a System bug or inadequacy and not so much related to DLL Hell, but I figured I'd post it.

If I understood you right, I think that's another thing. Search order for plain DLLs is controlled by PATH variable, several registry entries (SafeDllSearchMode*, SafeProcessSearchMode), KnownDlls**, SharedDlls (maybe)... and of course compiler instructions.

My take (which is oversimplified, and probably completely wrong) on WinSxS is that those are dlls protected by policies and cryptographic catalogs. That's enough to wake up the (healthy) paranoid in me.

I tried on a clean XP installation in a virtual machine to move the dlls from their folders to system32 and delete the manifests, cats and ALL relevant entries in the registry*** - the system wouldn't boot (or booted with severe problems). The least I can say about that is that it brings their argument of "Dll Hell" down - either they ship their OS defective by design (with DLL hell dependencies) or the solution is worse than the problem.

GL

* which, after XP SP2, by default is exactly the oposite of what you'd need to run older (DllHell's Angels ) applications. Another sabotage.

** I always disable all KnownDlls with Autoruns for several years now, on many computers, and have noticed NO ill effects whatsoever. System stability is always greater.

*** now I remembered I didn't delete/unregister sxs.dll - back to the drawing board

GL

[cdob]

I tried on a clean XP installation in a virtual machine to move the dlls from their folders to system32 and delete the manifests, cats and ALL relevant entries in the registry*** - the system wouldn't boot (or booted with severe problems).

Keep WinSxS *Windows.Common-Controls* files.

[GrofLuigi]

Keep WinSxS *Windows.Common-Controls* files.

Yeah, I know, they brought the OS down....

As another experiment, on one live machine, I noticed I had several hotfixes for gdiplus installed. So I tried to remove them manually (didn't know which they were, didn't use hotfix uninstall files since they are long gone), keeping just the highest and the lowest version. Success, no problems so far, but that doesn't mean much because they were introduced later as hotfixes.

I learned the places they populate (my fingers slipped to write pollute ) by installing the latest gdiplus hotfix. There are three registry branches and three locations inside WinSxS, apart from the usual stuff (registry entries and the global .cat file) for the hotfix.

GL