| Working with re-factored components in Windows XPe FP2007 |
by Lynda Allen (Dec. 21, 2006)
Foreword: Windows XP Embedded team member Lynda Allen takes a detailed look at reducing XPe's footprint by taking advantage of the re-factored components in Feature Pack 2007. There are several ways to go about it, resulting in varying degrees of reduction, depending on how much effort you're willing to invest.
Working with Re-factored Components in Windows XPe FP2007
by Lynda Allen
As part of the componentization changes we made to XPe for Feature Pack 2007, various components were re-factored into multiple, smaller and more granular components. The benefit of this is footprint savings. Components that, in the past, depended on one or two files owned by e.g. the Internet Explorer component had to take the footprint hit of the whole of Internet Explorer in order to use these files. But in FP2007 they do not have to take the same footprint hit.
By creating separate components to own these files the feature that depended on IE can now just depend on the new component in order to bring those files into the runtime and function correctly. This can lead to smaller overall footprint, depending on the kind of runtime you are building.
For example, if you look at Outlook Express in SP2 you will see that running check dependencies in Target Designer brings in the full Internet Explorer component (and all its subsequent dependencies) -- see figure 1.
Figure 1
Now in FP 2007 the 3 files that Outlook Express needs in order to function correctly have been pulled out of Internet Explorer (in other words are no longer file resources listed in the Internet Explorer component) and are now "owned" by entirely new components. These new components are "Primitive" components, which mean they have usually only one file resource, any registry keys associated with that file resource, and perhaps an FBA Registration resource.
Figure 2 below shows OE depending on only primitive components and not on IE. Note that IE will also depend on the primitive components that own the files that used to be part of IE – this is so that customers who need the whole of the IE feature are guaranteed to get all the same files in their runtime that they would have in SP2 before the re-factoring, and the IE feature will function as before.
Figure 2
This article will be the first in a series where I will gradually get more and more detailed into how to reap benefits of all the re-factoring work done, depending on how much time and effort you are prepared to invest in tweaking configurations that have been upgraded to FP2007.
Firstly, I must emphasize that in order to get the FULL advantage of this re-factoring work, you should build your configurations from scratch with Feature Pack 2007. This ensures that your dependency check will only bring in the new, smaller components for the features that were re-factored. However, if you choose not to rebuild your configuration there are still other ways that you can tweak your configuration to obtain some footprint benefit from this re-factoring work. In the next articles I will delve into details on how you can do this.
For now, here is a list of components that were re-factored so you can see if any of these are even brought into your configurations through a dependency check (because another component you may have added had a dependency on one of these components), and also the way they are now structured in FP2007:
1. Internet Explorer
Re-factored into: Internet Explorer - Primitive: Actxprxy.dll
- Primitive: Browsewm
- Primitive: Cryptdlg.dll
- Primitive: hlink.dll
- Primitive: iedkcd32.dll
- Primitive: ieinfo5.ocx
- Primitive: iexplore.exe
- Primitive: imgutil.dll
- Primitive: inetcpl.cpl
- Primitive: inseng.dll
- Primitive: jsproxy.dll
- Primitive: mshta.exe
- Primitive: msident.dll
- Primitive: msidntld.dll
- Primitive: msrating.dll
2. Volume Shadow Copy Service
Re-factored into: Volume Shadow Copy Service 3. Outlook Express
Re-factored into: Outlook Express - Primitive: msoert2
- Primitive: wab32
4. Simple Network Management Protocol (SNMP)
Re-factored into: Simple Network Management Protocol (SNMP) 5. Windows Firewall/Internet Connection Sharing (ICS)
Re-factored into: Windows Firewall/Internet Connection Sharing (ICS) It may not seem that re-factoring only 5 components would have much of an impact to footprint but there are two aspects to the savings you see here -- one is the that you no longer have the footprint hit of the files owned by that large component and, secondly, you no longer have the footprint hit of all the dependent components the large component would have brought in.
For some users it may not be practical in terms of time and effort to re-create a configuration from scratch with FP 2007. These users may be willing to trade less of a footprint savings for less work to optimize their configuration.
The first step in reducing footprint is to upgrade your SP2 configuration to FP2007, and then simply delete the re-factored components from your configuration if you know that you do not specifically need them (i.e. you did not specifically add them to your configuration when you first created them, but rather they were bought in by a dependency check).
To illustrate the process I am going to use the Internet Explorer component as an example of a re-factored component in my runtime. I have built a Winlogon Sample macro configuration in SP2 and added Outlook Express to it, then run satisfied all dependencies. You can see that Internet Explorer has been brought into the runtime by the dependency check, and that Target Designer estimates the footprint to be 92689 KB/128736 KB (roughly 90MB/125MB).
SP2 configuration
(Click image for larger view)
Now, after installing FP2007 I upgrade that slx, and delete Internet Explorer from it. After running a dependency check you can see that one or more Primitive components have been added, but that IE is no longer brought into the runtime. The footprint estimate is also somewhat lower - 89579 KB/124416 KB (roughly 87MB/121MB).
SP upgrade configuration
(Click image for larger view)
This may be an adequate savings for some customers, but for those customers who want to dig a little deeper to further reduce footprint we can start walking down the dependency chain of the IE component. Just because IE was deleted from the configuration does not mean that any of dependencies it originally brought in (in SP2) are also removed. This chain of dependencies can be where the real footprint hit is noticeable. Admittedly it is not very intuitive in Target Designer to identify a component's dependencies, however there are a few ways of tackling this task: - One way is to add the the component to a blank configuration, turn off auto-resolve dependencies (Tools > Options > Dependency Check > uncheck "auto-resolve dependencies") and run a dependency check. The task pane at the bottom of TD will show you the first level of dependencies that IE has. NOTE: This should be done on an SP2 database in order to identify the original dependencies that IE brought into your original SP2 configuration).
- Secondly, you can XPeCMD to list out the dependencies of the SP2 version of the IE component (all versions of a component reside in your database, but only the most recent vesion in visible in Target Designer). Using XPeCMD we can view all versions of the component, and their properties and dependencies. To do this, use XPeCMD to open a connection to your database, find all versions of IE, then selct the SP2 version and view its dependencies. The syntax is as follows:
- dbopen
- deptree /2 'comp:^Internet Explorer|R2890'
(the |Rxxxx after the component name indicates the specific version of the component you want to view - in this case the SP2 version, 2890)
XPeCMD output
(Click image for larger view)
The output from XPeCMD shows that the SP2 version of IE has a number of first-level dependencies. I can now go back and delete all of these first level dependency components from my Winlogon + OE config. After running a check dependency again (to verify that no other component in FP2007 requires any of the components I just deleted) the footprint estimate is now 84850KB/117848KB (roughly 83MB/115MB).
If more footprint savings is required you an walk through the next level of dependencies (i.e the dependencies brought in by the first level dependency components) as far down the chain as you wish to go. Naturally, the further down the chain you go the more effort is involved, until you may come a point where it would be just as easy to rebuild the config from scratch in FP2007.
As a final comparison, I rebuilt my Winlogon + OE config from scratch using FP2007- the size in TD is 77613 KB/107796 KB (roughly 76MB/105MB). You can see it quite a bit smaller than the SP2 configuration.
FP 2007 configuration from scratch
(Click image for larger view)
Copyright (c) 2006 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published in two parts on the Windows XP Embedded Team Blog, here and here
 About the author: Lynda Allen has been a member of Microsoft's Windows XP Embedded Test team for about two years, where her primary responsibility is testing of component integration. This involves ensuring that the components can be deployed on a minimal embedded runtime without any errors, and that the various components "play nicely" together. Lynda is originally from South Africa.
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed