[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

This post has been edited by blue4603: 26 March 2011 - 10:38 AM

[mrookie]

Very useful guide, Blue.
Thanks

[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:

<!-- Only  word "SensrSvc" needs to be removed from value "LocalServiceAndNoImpersonation"  not whole value!-->
<Value path="Microsoft\Windows NT\CurrentVersion\Svchost" value="LocalServiceAndNoImpersonation" part="software" /> 
 

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

This post has been edited by maxXPsoft: 25 March 2011 - 05:13 PM

[blue4603]

@ mrookie

Quote

Very useful guide, Blue.
Thanks

You are most welcome.

Quote

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.

Quote

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.

Quote

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

Quote

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.

Quote

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]

justibus, on 08 May 2011 - 12:38 AM, said:

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.

This post has been edited by justibus: 02 June 2011 - 06:55 AM

[Moonchilde]

justibus, on 01 June 2011 - 09:35 AM, said:

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]

Moonchilde, on 02 June 2011 - 05:39 AM, said:

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:

• 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.
  
• 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.]
  
• 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

This post has been edited by justibus: 14 October 2011 - 08:29 AM

[justibus]

Hi,

I've created and tested a few xml files. They work fine with 7Customizer 0.5.0a. One of them is a replacement for stickynotes.xml. It removes a few more manifest files.
I'll be making more now that 7Customizer works correctly. They were created using the tool linked in the post above.

Enjoy!

Attached File(s)

•  components.zip (4.24K)
  Number of downloads: 52

This post has been edited by justibus: 06 November 2011 - 03:42 PM

[justibus]

Here are a few more xmls. Some of them supersede the ones I have attached in the post above. Just delete them.

These xmls have undergone basic testing. This means, Windows installed correctly in a vm and everything worked fine at first glance.
Please report anything out of the ordinary, preferably with a pointer to the culprit xml file.

I have also attached xmls for all keyboard layouts (except for US because it's the default fallback layout). They are removed fine but there is a peculiar sideeffect. In the selection window where you can choose a new layout, a lot of input languages are also missing. I have not yet figured out why that is. Some help is appreciated!
Be aware, that removing all those layouts will take a huge amount of time. The problem is that 7Customizer checks each file and registry entry for deletion and that seems to be awefully slow right now. The only way around that is to crtl-c out of it and force an unmount with dism (or I use the windows 7 toolkit).
Edit: I found another way which does not break dismounting. In the 7Customizer_0.5.0a\work folder just rename "RemoveComponenetsHelper2.exe" to something else (I appended .bak). That way the command is not found and therefor not executed but the batch script continues anyway.

Cheers!


Edit: I've attached a few more components that seem to work fine.

Attached File(s)

•  components.zip (43.16K)
  Number of downloads: 65
•  keyboards.zip (107.72K)
  Number of downloads: 61
•  components_061111.zip (6.15K)
  Number of downloads: 51

This post has been edited by justibus: 08 November 2011 - 06:11 AM

[SplinteredEdge]

Great work on the component xml's. I for one definitely want to see some more xml's for additional components.

I want to spark a little food for thought.

During my first my first removal run using the XML's from this thread, I couldn't help but to notice how long it takes to parse and process each individual XML. It seems as if 7Custimizer is using the AIK tools for each XML individually and of course opening and closing the WIM image with each XML. Its not a huge thing because everything is working in the end.

Getting to the point

I was thinking of combining the Language Keyboard Layout XML's into a single XML to speed up processing. If you are removing all but the US keyboard layouts and all of the components from this thread; The results should show at least a 50% improvement on building time. I see it working like this:

It took me about 2 hours to complete my 7custimization session from start to finish. Most of that time in which was used to for removing components. Again no big deal, but I took some time to stare at the console screen as the removal took place. If i were to combine the language layouts into a single XML i ~could~ save myself 157 dialogs with the WIM image. With the other components only taking up 29 XML's they make a small impact to the processing time.
[b]
I will for certain post my combined keyboard xml when its finished. Other then that I'd like to hear what you all think.[/i] Perhaps we could request that 7custimizer can combine these xml's in memory before the actual compilation in which will have all of the work done in a single session with the wim.

[justibus]

SplinteredEdge, on 11 November 2011 - 10:45 PM, said:

Great work on the component xml's. I for one definitely want to see some more xml's for additional components.

Thanks! I'm working on more but I slowly run out of easy to remove components. It takes a lot more testing now.

SplinteredEdge, on 11 November 2011 - 10:45 PM, said:

During my first my first removal run using the XML's from this thread, I couldn't help but to notice how long it takes to parse and process each individual XML. It seems as if 7Custimizer is using the AIK tools for each XML individually and of course opening and closing the WIM image with each XML. Its not a huge thing because everything is working in the end.

Wait... for each component you select for removal, 7Customizer mounts the image, removes the component and saves and dismounts the image? Are you sure about that? If that is the case, that is very strange behaviour. On my setup, 7Customizer mounts the image in the beginning and saves and dismounts it at the end, so only once.

What version are you using? If you use a version older than 0.5.0c, try that one. It's much faster because it does not check for correct removal of the components (which takes a long time for each component, especially for keyboard layouts).

SplinteredEdge, on 11 November 2011 - 10:45 PM, said:

I was thinking of combining the Language Keyboard Layout XML's into a single XML to speed up processing. If you are removing all but the US keyboard layouts and all of the components from this thread; The results should show at least a 50% improvement on building time. I see it working like this:
[...]
Perhaps we could request that 7custimizer can combine these xml's in memory before the actual compilation

I think combining several xmls into one and shipping them is not a good idea, especially for the keyboard layouts. People need to be able to select which one(s) they need to keep an which ones they want removed. I for one absolutely need the us international layout.
But your second suggestion of 7Customizer combining the selected xmls before actually executing the removal could have some merit. Though I don't know how much faster it would go. I suspect the time winnings are negligible when the component delete verification is turned off (which is default in version 0.5.0c). This needs a test.



Another question:
Did you by chance notice random freezes while using the lited Windows? During testing I encounter time and again sudden freezes. I can move the mouse cursor and mouse over animations in the open window also still work, but I can't select anything. After waiting a few minutes, everyting works fine again. I suspect, it's virtualbox not getting along very well with my system, but I want to be sure.

[SplinteredEdge]

Justibus thanks for the feedback, I played with a few xml's and discovered that you were right about way 7custimizer is working so thank you for the feedback. I'm going to run a lited windows 7 on bare metal soon I'm just putting it off for a bit due to the build speed lol. I'll aim to post something by this evening or tomorrow. I'll attempt to report on memory usage, event logs, performance and stability of the lited system.