7Customizer components XML

[blue4603]

Hi,

The components removal feature in 7Customizer uses XML files to determine how a component should be removed. These files are located in the folder "components" inside the folder "work".

7Customizer reads these XMLs and build the tree in the components tab, display information about the component from the XML and remove the component based on the information present in the XML.

I chose this method because I wanted everyone to contribute to the component removal feature. So, in this guide I will explain everything related to the components XML.

If you can contribute to 7Customizer, then create your XML and put it in a zip file and upload it. Make sure it is tested on an untouched Windows 7 installation source. Also make sure you test the installation.

Request for mods: Kindly, make this post as sticky.

Note: This guide requires basic knowledge of XML and knowledge of the components in Windows 7 and how they are structured. Also, some knowledge of Windows registry and how to manipulate it is required.

To learn about XML: read about it here.

Note: Never ask questions about XML, read first about it.

Note: I will explain the XML with stickynotes.xml as an example.

Tip: I recommend using Notepad++ with the plugin XML tools installed.

Download Notepad++ here.

The XMLTools here.

Table of Contents:

1. XML Layout

2. Component element

3. Description element

4. DespendantComponent

5. NeededFor

6. Files

7. File

8. Directories

9. Directory

10. Registry

11. Keys

12. Key

13. Values

14. Value

15. How to identify files, directories and registry keys and values for a certain component.

16. Not implemented parts

17. Features to add

18. Tips

1. XML Layout

The XML must first start with the root _7Customizer. Then the "Component" which has the following children:

Description, DependantComponenets ,NeededFor, Files,Directories,Registry.

2. Component element

The component tag has the following attributes:

name: The name of the component

requiredForStableSystem: a true or false value that states whether the component is required for a stable system.

size: The size in MB.

group: The group which the component belongs to.

3. Description element

The Description element contains the description of the component.

4.DependantComponenets element

The DependantComponenets element lists the components that depend on this component.

5. NeededFor element

The NeededFor element lists the software that require this component to function properly.

6. Files element

The Files element contains a list of the files to be deleted.

7. File element

The File element contains the following attributes:

path: the path to the file to be deleted. It is relative to the location where the image is mounted.

Wildcard can be used here with the character “*" which must be placed before the extension of the file and at the end of the file name.

method: either "delete" or "deleteLine" string: the String to be matched with the lines in the file. this means that every line that contains the string will be deleted.

8. Directories element

The Directories element contains a list of the directories to be deleted.

9. Directory element

The Directory element contains the following attributes: path: The path of the directory. Wildcard can be used here with the character "*" which must be placed at the end of the directory name.

10. Registry element

The Registry element contains a list of the keys and values to be removed.

11. Keys element

The keys element contains a list of keys to be deleted

12. Key element

The key element contains the following attributes:

path: The path to the key. . Wildcard can be used here with the character "*" which must be placed at the end of the key name.

Note: The "*" is allowed in a regestry key name. Rarely you will find a registry key that contains "*".

part: The registry part which the key is located. The parts are:

components: Represents the registry hive "components"

system: Represents the registry hive "HKEY_LOCAL_MACHINE\SYSTEM"

default: Represents the registry hive "default"

software: Represents the registry hive "HKEY_LOCAL_MACHINE\SOFTWARE"

13. Values element

The Values element contains a list of registry values to be deleted.

14. Value element

The value element contains the following attributes:

path: The path to the key which holds the value

part: the registry part which the key is located

value: the name of the value to b deleted

15. How to identify files, directories and registry keys and values for a certain component.

Note: It is recommended to use a Windows 7 x64 image because it will have the files for both the x86 and x64.

To do so follow these steps:

15.1. Know the name of the component e.g. Sticky Notes.

15.2. Go to the folder Windows\winsxs\Manifests in Windows 7.

15.3. Search for the files that their name contains the name of the component.

15.4. Open these files (which have the extension .manifest) with a text editor (Notepad++ recommended) and inspect the content. You will find some file, directory and registry elements.

15.5. Map these to your XML.

15.6. Add the names of the manifests files you found to the XML also. (Wildcards are recommended)

15.7. Go to the folder Windows\winsxs and find the directories which have the component name. Add thier names to your XML.(Wildcards are recommended)

15.8. Open Windows\winsxs\pending.xml with a text editor and look if there are lines that contain the component name and add them to your XML.

15.9. Load the hive "components" located in Windows\System32\config to your registry and go to the key "DerivedData\Components" and search for keys that contain the component name and add them to your XML.

15.10. Place the XML in the components folder with a name that does not have white spaces and only small letters.

15.11. Test the XML.

16. Not implemented parts

The following elements are still not handled by 7Customizer:

DependantComponenets ,NeededFor

So do not bother yourself with them and wait for a release that supports them.

17. Features to add

The ability to insert registry keys and values to the image registry, which means custom registry tweaks.

The ability to delete part of a registry value (Not the whole value). (thanks Schemek for the suggestion).

18. Tips

1. The HKEY_CLASSES_ROOT is a hive that points to HKEY_LOCAL_MACHINE\SOFTWARE\Classes.

2. Always remember that XML elements and attributes are case sensitive.

3. Check your XML for errors using the XML tools in Notepad++.

If you have any question about components XML, please ask them here. For questions about 7Customizer post it in the main thread of 7Customizer.

Regards

Edited March 26, 2011 by blue4603

[mrookie]

Very useful guide, Blue.

Thanks B)

[Schemek]

Hi,

Well done with the guide, but I still didn't find the answer how to delete some data from particular value. I will try to explain it with an example:

<Value path="Microsoft\Windows NT\CurrentVersion\Svchost" value="LocalServiceAndNoImpersonation" part="software" />

<!-- Only  word "SensrSvc" needs to be removed from value "LocalServiceAndNoImpersonation"  not whole value!-->

Also is there any naming conventions for each components we create? I mean for example sticky notes: "stickynotes" or "sticky_notes" or it doesn't matter?

Finally you didn't specify names for each components group i.e. media, system, services, accessories and what else?

Thanks

[maxXPsoft]

When I was looking at this myself I found Windows Search sucks and is slow.

Free Agent Ransack 2010 (Build 762) is available in both 32-bit and 64-bit versions

Will allow file contents search and is faster than Windows search

Edited March 25, 2011 by maxXPsoft

[blue4603]

@ mrookie

Very useful guide, Blue.

Thanks

You are most welcome.

Hi,

Well done with the guide, but I still didn't find the answer how to delete some data from particular value. I will try to explain it with an example:

OK. I understood. I will add it on the to do list. Thank you for the suggestion.

Also is there any naming conventions for each components we create? I mean for example sticky notes: "stickynotes" or "sticky_notes" or it doesn't matter?

Hmmmm. Actually it doesn't matter. However, I recommend that the names should be small letters and contains only letters (No _ , - , space , ... etc). I will update the guide. Thank you.

Finally you didn't specify names for each components group i.e. media, system, services, accessories and what else?

Hmmmmm. These will be decided later as the number of components increases.

Thank you for your helpful feedback.

@maxXPsoft

I don't see any relationship between your post and the components XML.

Regards

[Moonchilde]

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.

[blue4603]

@Moonchilde

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

Exactly. Also, if removing a certain component causes the system to be unstable we will be able to modify the XML of that components so that it will be safe to remove.

Only thing is, with little over 12,000 manifest files this is a massive undertaking.

For one guy yes. However, I am not the only guy who will work on the XMLs. Everyone could help.

Regards

[Moonchilde]

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

[Moonchilde]

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!

[justibus]

Hi blue,

I have a few questions:

First, when I have a directory and all files and directories within this directory have to be deleted, do I have to put each file in the files element or is it enough, if I put that directory only in the directories element?

Secondly, how can I find out from the manifest files, if I can delete a whole registry key or if I can only delete some value(s) from a key? I searched, but I didn't find any reference to these manifest files.

And thanks by the way for this great app!

Cheers

[Moonchilde]

Hi blue,

I have a few questions:

First, when I have a directory and all files and directories within this directory have to be deleted, do I have to put each file in the files element or is it enough, if I put that directory only in the directories element?

Secondly, how can I find out from the manifest files, if I can delete a whole registry key or if I can only delete some value(s) from a key? I searched, but I didn't find any reference to these manifest files.

And thanks by the way for this great app!

Cheers

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.

[justibus]

I have tried to remove a few components. It seems to work quite well.

There is one feature though I would really like to see. Instead of just allowing a wildcard at the end of a file name, directory, or registry key, it would be good to have the same fuctionality at the beginning. For example something like the following would be great if it worked:

<File path="Windows\winsxs\Manifests\*microsoft-windows-zipfldr*.manifest" method="delete"/>

This would remove all manifest files with microsoft-windows-zipfldr in the name. This way, we could remove a component for all architectures by simply putting one line in the xml file. Also, a component with multiple manifest files could be deleted much easier.

As a side note, I think that the amd64 version of windows does not have all manifest files for the x86 version. For example, for windows defender, I only found manifests for amd64 and wow64 (which probably is the equivalent of x86 on a 32bit windows).

And the answers to my questions from my post above are: 1) directories element is enough and 2) trial and error. Usually, it's the whole key that can be remove, but sometimes only certain values. I use the following rule of thumb: If a key has only values in connection with the component to be removed, it's save to delete the whole key.

Cheers

p.s.: Another feature request. Maybe it would be beneficial to devise some kind of versioning system so that we know, if the xml at hand is the latest one. The only problem with standard linear version numbers is that, if several people work on one xml file, there might be a confusion what the latest version is. So, maybe we could include the initials of the author or some unique id in there.

I will post the few xml files once I have tested them a little.

p.p.s.: I noticed that a lot of manifest files use short names in the form of amd64-microsoft-windows-t..-something*.manifest. This complicates things because many components don't just use one manifest file but multiple ones. And sometimes, I guess when the file name is too long, a short form is used. If you search for manifest files just using the component name, you might not find all of them. So it's best, if you use some kind of search tool that can search within text files (currently I use findstr since it comes with windows, but windows search will do just fine, if you configure it correctly).

I also just noticed that some components have references in other manifest files (ex. wordpad is referenced in amd64_microsoft-windows-c..features-deployment*.manifest). So here is another feature request: Some way of deleting an element from a specific manifest file.

Edited June 2, 2011 by justibus

[Moonchilde]

I have tried to remove a few components. It seems to work quite well.

There is one feature though I would really like to see. Instead of just allowing a wildcard at the end of a file name, directory, or registry key, it would be good to have the same fuctionality at the beginning. For example something like the following would be great if it worked:

<File path="Windows\winsxs\Manifests\*microsoft-windows-zipfldr*.manifest" method="delete"/>

This would remove all manifest files with microsoft-windows-zipfldr in the name. This way, we could remove a component for all architectures by simply putting one line in the xml file. Also, a component with multiple manifest files could be deleted much easier.

As a side note, I think that the amd64 version of windows does not have all manifest files for the x86 version. For example, for windows defender, I only found manifests for amd64 and wow64 (which probably is the equivalent of x86 on a 32bit windows).

And the answers to my questions from my post above are: 1) directories element is enough and 2) trial and error. Usually, it's the whole key that can be remove, but sometimes only certain values. I use the following rule of thumb: If a key has only values in connection with the component to be removed, it's save to delete the whole key.

Cheers

p.s.: Another feature request. Maybe it would be beneficial to devise some kind of versioning system so that we know, if the xml at hand is the latest one. The only problem with standard linear version numbers is that, if several people work on one xml file, there might be a confusion what the latest version is. So, maybe we could include the initials of the author or some unique id in there.

I will post the few xml files once I have tested them a little.

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?

[justibus]

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?

Well, the most important xml elements in the manifest files are <file>, <registryKey>. If you analyse the destinationPath= in the <file> element, you can usually easily decide wether to delete the whole directory or just the file.

Another element of interest is <memberships>. This one usually holds information for shortcuts in the Start menu. These you can usually find in \ProgramData\Microsoft\Windows\Start Menu\...

As for making the xml files, I take one (ex. stickynotes.xml) and just manually edit it and afterwards validate it. So it's a lot of manual work. I think most of it could be automated. Unfortunately, my programming skills are very basic. If I find the time and inspiration, I might embark on such an endeavour to wirte a tool that constructs the xml automatically. But currently it's beyond me.

[justibus]

Good evening.

I actually did embark on the endeavor of writing a tool for creating the xml files in a semi automatic way. The result can be seen here: xml creator for 7Customizer

Maybe this will give this thread a little boost.

During coding, I stumbled upon a few uncertainties that should be resolved (one also on the 7Customizer side) before continuing work on xml files:

1. Where does HKEY_CURRENT_USER in manifest files get mapped to? There is no such key in an offline registry but I found a few in manifest files.
   
2. What about localized folder names (such as "Program Files")? In the current xml format they are hard coded so we would need a different xml file for every localization. [This has been resolved.]
   
3. for the pending.xml: wouldn't it be safer to include shortended manifest file names instead of just one word in the deleteLine attribute? For example, if we want to remove net.exe which is defined in amd64_microsoft-windows-net-command-line-tool_31bf3856ad364e35_6.1.7600.16385_none_ae2743278c281682.manifest (in my sources), then it would be best to use deleteLine="Microsoft-Windows-Net-Command-Line-Tool" which is the name attribute of the first <assemblyIdentity> element in the manifest file. This one is (I think) always unique so we don't accidentally delete needed lines from pending.xml. The downside is, that we have sometimes a lot more <File> elements in the xml. The current version of the above tool is implemented that way.
   

Cheers

Edited October 14, 2011 by justibus