Optimizing the XPe Image Size

  • Thread starter Thread starter arun.gr
  • Start date Start date
A

arun.gr

Hi,

I am trying to create a new XPe Image for my target device and planning
to have a custom shell for the same. I imported the .PMQ, ran the
auto-dependency and generated a new XPe image. But the size of the
image is around 167 MB before the FBA and after the FBA I am getting
around 230 MB. I need some suggestions to optimize the size of the
image. When I browse through the list of components I see IE getting
included and I think it is getting included because of the DialUp
Networking Common Libraries(not sure yet on this). Can some one throw
some light on why we need to this component and what is the purpose of
this component. Also where can I get detailed information on each and
every component.

Thanks in Advance,
Arun G R

P.S: I am new to Win XPe
 
There are many methods and tools to reduce the footprint. Here are some
suggestions:

1. Starting off with PMQ file - do you need all the drivers found by TAP?
Taking out some of the items you don't need is the first place to start.
2. Firewall - do you need the Windows Firewall? Before you run dependency
check, add the Core Networking component and in it's settings uncheck the
Windows Firewall?
3. Finally what are the needs of the image - what is the logon method, what
is the boot media, what are the components that are necessary for the
application to run, etc.

There are a couple of tools to help tracking down component relationships:
A. CMIEXP.WSF - CMIEXP.WSF available on the XPe CD - command line tool that
interacts with the database.
B. Component Hunter - A tool I developed to find component relationships,
and track down components.

The XPe SP2 help files has good details on each component and groups of
components.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit
 
Hi Sean,

Thanks for your reply.
1. I have removed few of the drivers found by TAP which I don't need.
2. Is the Core Networking Component a replacement to Dial-Up Networking
component?
3. We have a custom application which will be launched when the device
boots up. We are using a 512 MB CF as the boot media.

You mentioned about a tool which you have written. Where and how can I
get that tool?

Regards,
Arun G R
 
Hi Arun

You're right about the Dial-Up Networking Common Libraries. To remove
Internet Explorer component, you will need to remove all the related
dependencies. Here is a little diagram of some of these :

Shell Namespace Extension <----> IE <----> HTML Rendering Engine
Internet Connection Wizard ----> HTML Rendering Engine
HTML Help Engine ----> HTML Rendering Engine
Microsoft Management Console (MMC) ----> HTML Rendering Engine
Simple Network Management Protocol (SNMP)---->Microsoft Management
Console (MMC)
Dial-Up Networking Common Libraries ----> Simple Network Management
Protocol (SNMP)
Direct Parallel ----> Dial-Up Networking Common Libraries
RAS Async Adapter ----> Dial-Up Networking Common Libraries
WAN Miniport (IP) ----> Dial-Up Networking Common Libraries
WAN Miniport (L2TP) ----> Dial-Up Networking Common Libraries

You can also remove IE and it's near dependencies and don't accept the
check dependencies at your next build.

Regards,

Jonathan Proulx
 
Hi Jonathan,

Thanks for the information. Its really useful. But I wanted to know
whether I can get away with the Direct Parallel which is including
dial-up networking common libraries. what kind of support dial-up
networking common library will provide me?

Thanks,
Arun G R
 
Legacy devices related component :
-Communications port
-Printer port
-ECP printer port
-Direct parallel ****************
-Printer port logical interface
-Standard 101/102-key or Microsoft Natural® PS/2 keyboard
-Microsoft® PS/2 mouse
-Floppy disk drive
-Standard floppy disk controller
-PCI to ISA bridge (chip-set specific in most cases)
-ISAPNP read data port
-.........

You can remove the legacy devices you don't have or you don't need on
your target system.

Essential components to keep in your configuration :
-System timer
-Direct memory access controller
-System CMOS/real-time clock
-System board
-Numeric data processor
-Programmable interrupt controller
-"Processor" component
-Microcode update device

Direct Parallel is for LPT port, useless if you don't use it...

Dial-up networking common libraries includes support for lots of
functionnalities :
- PPTP and L2TP provides secure access of a private, remote network
through a virtual private network (VPN). (Raspptp.sys, Rasl2tps.sys)
- Modem communications...
- I think this component is necessary to do Remote Desktop Connection

Lots of components depend on this library and this library depends also
on lots of components.

Jonathan
 
Arun,

Here are two other tips related to your situation.

* I have found that going into the Settings for every component in
Target Designer and checking the box for NOT copying help files,
and unchecking the multi-language support checkbox, appears to reduce
the final post-FBA disk requirements for some components. Of
course if you need multi-lanuage support or help in your
embedded device, you wouldn't want to do this.

* If you build in NTFS file system support rather than FAT, then you
can turn on NTFS compression for all your files (except for NTLDR)
and this significantly reduces the amount of disk space taken up
by your kernel files. In my own project, doing this reduced my
physical footprint (originally around 350MB, I had added DirectX
and .NET) by over 100MB. The tradeoff is speed...my experiments
appeared to show disk access slowing by 50% to 100% when files
were compressed. But this is still good for a temporary situation
(see below) or for compressing particular files that are seldom
read or written. NTFS supports compression on a per-file,
per-directory, or per-disk basis.

* I also had a problem of the disk space requirements *during FBA*
exceeding my disk size, due--I assume--to lots of temporary files
that later get deleted. In other words, my initial image prior to FBA
would fit on my disk, and my final image after FBA completed would
also fit on my disk, but during FBA execution I would run out of disk
space, causing the FBA to break. I got around this problem by
using NTFS, initially compressing my image files until FBA was
completed, then uncompressing the resulting files for my final
image (thus avoiding the speed hit of leaving things compressed).

Mark Bearden
Applied Global Technologies, Inc.
 
Back
Top