[justibus]

You mean xmls for 7Customizer? Just download the current version. The xmls contained therein are all that are available right now. I haven't had much time recently to test more components and there have been quite a few changes in xml creator since I released those. I hope to get back to more testing in a week or two.
Also, tommyp was working on some batch files that create xml files.

Cheers!

[Moonchilde]

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.

[Moonchilde]

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...se/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...

This post has been edited by Moonchilde: 14 January 2012 - 08:02 AM

[justibus]

Thanks for that little tutorial!
Your last comment is actually a pretty important one. Xml creator first searches all manifest files for the strings you give with the -k option. Then it selects all manifest files that contain any search string in the name element of the assemblyIdentity element (that is usually the first element of the manifest file). So searching for those name attributes actually improves accurancy but it also makes it hard to discover new components. That requires a lot of work browsing through the manifest file directory and looking at the manifest files individually.

Cheers!

[Moonchilde]

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.

This post has been edited by Moonchilde: 16 January 2012 - 12:43 AM

[justibus]

Moonchilde, on 16 January 2012 - 12:34 AM, said:

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.

If it can't find the .sys file, then it's not in your sources. If you look at the manifest file for atiriol6 the line for the .sys file looks like this:

<file name="atinavrr.sys" sourceName="atinavrr.sys" importPath="$(build.nttree)\">

There is no destination path xml creator can use. So xml creator has to search for the file. And if it can't find it, it's not there (unless there is a bug in xml creator, of course; but I doubt it, because I can't find that file either). The only location where the file is located is in the winsxs\amd64_atiriol6.inf... folder. And that one gets deleted.

Moonchilde, on 16 January 2012 - 12:34 AM, said:

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.

Removing stuff from winsxs can also create problems. For one thing, windows update won't work correctly anymore, at least when you remove too much stuff. The problem is that the windows component store (which is basically the winsxs folder and some registry entries) is left in a slightly corrupted state. There are still references to certain components (and their manifest files) that are not there anymore. That produces errors which windows update tries to fix by installing the components again. Since they are not there anymore, it fails.

There is also a problem of integrating updates into an offline wim image and then removing stuff. I'm not quite sure, but I think the updates are not integrated fully but only added to the winsxs folder for installation during windows setup. So even if you remove components for which you have updates they get installed anyway which might in turn produce errors because the installed update can't find its dependencies. So, it's all a bit complicated.

The solution would be to use the internal cbs and trustedInstaller from windows 7 itself, because they have a complete picture and maintain the component store. The problem is, there is no public api to use them. I've searched for hours for some useful documentation on how the component store gets maintained with these two programs. I didn't find anything. And reverse engineering this is beyond me.

Moonchilde, on 16 January 2012 - 12:34 AM, said:

Either way, for this to really take off we're going to need help, and blue needs to come around more often.

I hear you there!

[Moonchilde]

justibus, on 16 January 2012 - 04:04 AM, said:

If it can't find the .sys file, then it's not in your sources. If you look at the manifest file for atiriol6 the line for the .sys file looks like this:

<file name="atinavrr.sys" sourceName="atinavrr.sys" importPath="$(build.nttree)\">

There is no destination path xml creator can use. So xml creator has to search for the file. And if it can't find it, it's not there (unless there is a bug in xml creator, of course; but I doubt it, because I can't find that file either). The only location where the file is located is in the winsxs\amd64_atiriol6.inf... folder. And that one gets deleted.

You're right. I didn't think about the folder containing the .sys and the folder being deleted.

justibus, on 16 January 2012 - 04:04 AM, said:

Removing stuff from winsxs can also create problems. For one thing, windows update won't work correctly anymore, at least when you remove too much stuff. The problem is that the windows component store (which is basically the winsxs folder and some registry entries) is left in a slightly corrupted state. There are still references to certain components (and their manifest files) that are not there anymore. That produces errors which windows update tries to fix by installing the components again. Since they are not there anymore, it fails.

There is also a problem of integrating updates into an offline wim image and then removing stuff. I'm not quite sure, but I think the updates are not integrated fully but only added to the winsxs folder for installation during windows setup. So even if you remove components for which you have updates they get installed anyway which might in turn produce errors because the installed update can't find its dependencies. So, it's all a bit complicated.

The solution would be to use the internal cbs and trustedInstaller from windows 7 itself, because they have a complete picture and maintain the component store. The problem is, there is no public api to use them. I've searched for hours for some useful documentation on how the component store gets maintained with these two programs. I didn't find anything. And reverse engineering this is beyond me.

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.

[justibus]

Moonchilde, on 16 January 2012 - 06:16 PM, said:

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.

Do you have a link to that thread? I'd like to read up on it.

[Moonchilde]

http://www.msfn.org/...-batch-removal/

dead0's' batch files that automatically remove stuff.

The whole vLite forum is pretty much about removing stuff from Win7 using a combination of vLite and batch files. I think it's an extremely poor way of doing it. Having component packages so we can make our own OS spins would be a much more elegant solution.

The update you want is this http://www.microsoft...s.aspx?id=20858 It will allow WinSxS removal using shoddy methods like RT7Lite and vLite and will fix Win7 updates that these tools break by removing WinSxS. Maybe checking what exactly the tool does will help us wrap our heads around it.

Honestly, the best way to shrink WinSxS is to remove the garbage we don't want, which will take care of all the stuff that doesn't need to be in WinSxS and keep the stuff that does. Future testing will allow us to know what we really can and can't remove. And of course, we can also selectively keep the WinSxS files if it turns out that for whatever reason, them missing breaking the system.

I'm also uploading the first super alpha untested Drivers/A-D zip file if you're interested. I still have a lot of work to do on these but if you want to have a quick look at them, have a shot. I have yet to make a solid decision on their organization, but I'm starting to get a uniform idea on how I want to do it.

Attached File(s)

•  Drivers.7z (17.57K)
  Number of downloads: 8

This post has been edited by Moonchilde: 18 January 2012 - 02:29 AM

[justibus]

I've just released a new version. It's now hosted on sourceforge.net.
The biggest change is in the xml format. The xmls look a little different. The change was necessary so that all architectures of Windows are properly supported. Unfortunately, this renders xmls created with the new version incompatible with 7Customizer 0.5.0c for the moment. That might change in the future.

I'm also working on a command line removal tool that is compatible with the new xml format. But I need to do some more testing before I can release it.

[justibus]

I had to upload a new version. The binary distribution was missing a dll.
There are also a few bug fixes.

https://sourceforge....latest/download

[justibus]

Hi all,

there is a new version with a few minor adjustments. I also wrote a companion tool that removes components based on these xmls. It's compatible with the old and the new xml format.

Cheers!

[justibus]

I uploaded a new version that adds a <Packages> element to the xml. For an explanation and a summary of all the other changes to the xml after v0.9.20, have a look here.