Moonchilde

You're right. I didn't think about the folder containing the .sys and the folder being deleted. Over in the vLite forum they have this issue covered. There is an update that "fixes" updatability while "removing" the WinSxS folder. Most stuff will update fine. I think when people were using vLite to remove WinSxS or RT7Lite they were removing stuff that shouldn't have been removed. Of course, that's why I feel this method of removal that takes things component by component will keep Windows safe, because we aren't simply deleting the "garbage" from WinSxS. It simply happens as the components are removed. As long as the component we remove doesn't break Windows, that is, and of course, if that happens, then it's all moot anyway. I didn't realize it before, but we actually don't even have to check thefiledb for component names. Inside every .inf file is usually a name for any drivers and such, and for other components there is usually something mentioned in the random files if we forcefully open them up in notepad. I should have known better having edited .inf files plenty of times during the XP days when you could run unsigned drivers easily.

I think the only accurate way to search for the building blocks of the OS is being forced to do it file by file in the WinSxS folder. Yeah, it's huge, but a lot of stuff is repeated for compatibility layers and components are broken up into "parts" so it isn't like each and every manifest is a new component. At first, I was extremely overwhelmed, especially prior to the release of xml creator. There was no way I was going to be able to create xml files manually, it was just way over my head. I've noticed each component has at least 2 manifests, one for the original xxx.inf, one for inf.resources at minimum. Some include language variations and other stuff as well. This also significantly cuts down the amount of folders we have to browse through in WinSxS, which can be easily overwhelming when you first browse to the manifest folder and see over 12,000 individual files. Also, when searching for string -k atiriol6 it builds an xml file but doesn't for some reason find the .sys file associated with the inf. If you check thefiledb.com, you'll see that the atinavrr.sys has a path of atiriol6.inf. Is xml creator missing something? If so, then it's possible we may think a component is completely removed, such as the ATI video capture drivers but they really aren't fully removed. However, if you search for -k atiilhag it will find the associated .sys, atikmdag.sys. The one thing I LOVE about this method of component removal is that after the component is removed, the WinSxS folder is removed too, which will greatly reduce the footprint of the OS. It's sad when the WinSxS folder for XP x64 edition is only about 128 mbs in size and Win 7 is gbs larger. I never had a problem with Win XP x64 and had a very small nLite install, sadly, my audio hardware device drivers decided to go with the Vista architecture and rendered it useless for the Server 2003/XP x64 architecture. Either way, for this to really take off we're going to need help, and blue needs to come around more often.

BTW guys, an easy way to search for stuff is to look at the names of the manifest files. amd64_adpu320.inf.resources_31bf3856ad364e35_6.1.7600.16385_en-us_6a45a05a6afc0a79 Search -k adpu320 and it compile an xml based on the inf information. Usually within the .xml there are keys to finding out what exactly the component is. For example, in adpu320 there is a file called adpu320.sys which you can cross reference with http://www.thefiledb.com/filedatabase/windows7x64/ which has a list of all the files within the OS. Under the file adpu320.sys is the description Adaptec StorPort Ultra320 SCSI Driver which you can use in your .xml to help detail it. To make searching thefiledb.com easier, just google "thefiledb.com adpu320.sys" or whatever other device you're looking for and it should bring the page up as the first hit. WinSxS seems to be divided into several catagories. Anything that is simply amd64_xxxxxx.inf seems to be the basic foundation of the system such as drivers, services, and a few other lower level items. Anything that is amd64_microsoft-windows seems to be software components in the native x64 format. Anything that is wow64_microsoft-windows is the 32 bit version of the native software components. Anything that is x86_xxxxxx.inf seems to be 32 bit versions of the basic OS foundation. And then there is a 5th catagory, msil_xxxxxxx which I'm not sure exactly what it falls under. Anyway, it makes looking for stuff easier. Good thing is, a lot of stuff is repeated over the categories so you don't actually have to search through 12000+ manifests. Maybe, only 4000, lol! It seems it really is possible to create a fully modular Windows 7, something that didn't really seem possible before. Sadly, I doubt this would go anywhere, as it doesn't seem there are many people really interested in a OS with only the stuff you want in it and not the bunch of junk it comes with. Oh yeah, another benefit of this is that by searching this way, you can remove components of components... for example: amd64_desktop_shell-gettingstarted.resources_31bf3856ad364e35_6.1.7600.16385_en-us_985b8b2af38a6a1a amd64_desktop_shell-gettingstarted_31bf3856ad364e35_6.1.7601.17514_none_5d1e01379f4d67ed amd64_desktop_shell-search-srchadmin.resources_31bf3856ad364e35_7.0.7600.16385_en-us_805a99c7c2e587d5 amd64_desktop_shell-search-srchadmin_31bf3856ad364e35_7.0.7601.17514_none_a9f0ab75af7a5b5c Would all be compiled under the same xml if you did a search for desktop_shell but if you did desktop_shell-gettingstarted you could separate the component and you could remove part of it rather than the whole thing. One problem though is that stuff that gets too long in file name, such as: amd64_microsoft.windows.d..eshootingpackmodule_31bf3856ad364e35_6.1.7600.16385_none_7d19911b0fafbb5f Part of it is cut off so knowing exactly what the component is, is a little questionable without time consuming file browsing. It's actually diagnostic troubleshooting pack module, which if you'd only find out by opening the manifest in an editor. Ah well...

Ah ok.. I'm just working my way through the WinSxS folder looking for stuff. Started on the driver stuff and worked my way down a bit.

Hey, do you have a zip file with stuff to remove? Has anyone helped by adding XML files yet?

I've been very interested in component removal, I just don't know what to look for even with the guide. I guess I'm not really up to the task. Maybe the new tool will make it easier.

Yeah, fork over hundreds of dollars or customize your current image? Man I wish I could just use Windows Embedded 7 at the drop of a hat, but not everyone has that kind of money.

How are you going about making your XML files? For example, when you open a manifest what are the key words you look for and such?

Yeah W7T has very good component removal, but the amount of components you can remove is relatively small. 7Customizer has a very high potential to give us much more control over what can be removed and what can't. But that is only potential, until people can start making XML files detailing the stuff to be removed.

This is thread about 7Customizer, so why don't you take your Legolas and talk about it elsewhere? You're right, this thread is about 7Customizer. Blue hasn't replied in a while, and some of us have questions so we can help progress the program forward. Blue is working on 7Customizer live according to one of his most recent topics, however, without some help from blue we can't help him work on regular 7Customizer component removal. He can't do it alone! I've used W7T, it's a very awesome program, but the component removal is lacking and with more info, 7Customizer could potentially give us complete control over Windows 7, way more so than W7T.

An update and some more info on component removal so people can help would be appreciated. I wish he'd check the component removal thread, maybe I'm just too dumb to figure it out on my own but I need some stuff clarified. At this point, I'm ready to just give up on ever having a custom Windows 7, Windows 8 will probably be out by then and I think RT7 is just the slowest most awful program I've ever used.

This is similar to my question I think. Maybe a sample manifest and a sample pending would be of great service? I mean, if we can all get every component documented, pretty much ANYTHING can be removed, and we'd finally have a truly customizable Windows install. I've been waiting years and years for this, and I'm definitely willing to put out a helping hand. However, without more interest, this is a hugely daunting task for a single person, or three, to do themselves.

How do you do that without a membership? From what I saw, membership to use the Windows 7 Embedded was quite high, and customizing a Win7 OEM is much, much cheaper.

Hey blue, I hope this isn't a stupid question, but how do I tell what the size is supposed to be? How can I tell what has a dependency and what doesn't? Simply test the image afterwards and see what's broken? If something has a manifest file and the manifest details files, but isn't in the pending.xml, it can still be deleted right? What exactly are we looking for in the pending.xml? Do we absolutely have to have a component within pending.xml and do we have to load the hive from the folder system32\config? I guess I'm a little unsure about steps 15.8 and 15.9. If not, it means we can slim down 7 much more, since I think I didn't see some stuff from the manifests in the pending.xml. I guess I'm asking, do we really need steps 15.8 and 15.9, or can we work solely off the manifests themselves? I had some more questions but I'm lacking sleep, so I can't think of them at the moment. Also, I may not be thinking 100%, so hopefully this is clear. Thanks!

English is obviously not your first language. 7Customer does NOT have the ability to shrink WinSxS YET. You can HELP by creating XML files which tell 7Customizer what to delete. My point is, why make a new program when 7Customizer already has the foundation to do so? All YOU need to do is help tell it what to delete. What language do you normally speak? Maybe someone can help translate.

7Customizer has recently added component removal support. If you are willing to help 7Customizer progress, then we can have smaller and stable WinSxS. The same amount of effort to make a new program could be put into making 7Customizer better. Why not just put the time into helping Blue out? The component removal is already programmed, all that is needed is the XML files telling it what to delete. You can help by reading the 7Customizer component removal thread.

Then 7Customizer should work just fine, right?

Bumping. Has anyone attempted to add some XML components yet?

Dude seriously, check the 7Customizer Component Removal thread. In, fact, here is a link. It has all the info you need there, and works directly from the WinSxS directory. All based on XML, which you and a few others can write and add to it. However, please note, it won't remove WinSxS entirely, but any components you don't need will be removed and deleted from the WinSxS, which should drastically shrink the size of the WinSxS folder. I'm sure blue would appreciate it and anyone else looking forward to more component removal XML files. I would make a few but I don't have the time at the moment until a few things outside of my computer time get taken care of. Also, doesn't vLite safely shrink WinSxS if you install the updatability pack? Though, I don't really like that method. Ninja Edit: No matter how good the programmer, it will take A LOT of time. There are 12000 manifests files to decipher components from. No matter what, it's going to be time consuming.

Marcus, you are a complete a**. Why do people try to help you? Acronis True Image isn't some random "ghost," and you obviously have no idea what ghosting is or how useful it can be. I guess you don't use any software made by 3rd parties on Windows since they're not directly supported by MS, right? Geeeeeeez ... Also, THIS information quoted here, needed to be specified in the 1st post in this topic. How were we supposed to know that you were putting updates into a wim image, and not a running OS? No mention of it at all, and when you did mention having a good image I'm thinking you installed from a customized wim already pre-configured and were updating a running OS. You aren't very clear in your details. Personally, I don't really care if you get any of the help you seek anymore. From your posts in other topics and this one you come off as a know it all jerk after folks have tried to suggest things based on your poorly described issues. I'm done with all this.

As long as a program images properly, it shouldn't matter what you use. I use acronis true image and have 2 images, one of a brand new clean install with nothing on it and 1 with all my software installed. Should something happen, like an update that deprecates and old one, I can roll back to one of my images. Usually for basic installs I know I'm going to keep I can just do an update of my second image, however, if I'm going to be installing and testing a bunch of junk, I just roll back to my 2nd image rather than uninstall since it never really cleans the stuff out of the system. if you don't have a backup of your good image, then you're pretty much stuck with a messed up registry even if you uninstall everything. you should have made an image of your disk before installing a bunch of updates and things you don't really need.

Install a clean version of Windows on your system, make a ghost image of it. Install your usual programs, then make another ghost image. After that, install all the test stuff, and just roll back to the more recent ghost image, and if you need to, go back to the default clean ghost image.

Sorry if this has been asked before, but is there a way to set a mount folder? My tools partition is exFAT which isn't compatible with DISM mounting, so I need to be able to set it to my NTFS partition. Any way to do this? I apologize in advance if this has already been discussed. Thank you.

Wow, from what it looks like, this method should allow pretty much a completely modular of windows? Browsing through the manifests files, it looks like we'd have complete control over everything this way, everything looks mapped out. Only thing is, with little over 12,000 manifest files this is a massive undertaking.