| Customizing Windows XP Embedded thin clients |
by Sean Liming and John Malin (Apr. 13, 2005)
Foreword: This tutorial by Sean Liming and John Malin examines the issues involved in customizing thin client devices based on Windows XP Embedded. The authors note that there have been several requests on the Windows XP Embedded newsgroups asking about modifying either thin client hardware or the underlying operating system.
Things like changing the TCP/IP address or domain name are relatively easy, as they can be handled within the existing OS image, according to the authors. However, many other types of changes require reconfiguring and rebuilding the XPe image, which can lead to problems if not done systematically. The authors offer step-by-step guidance for working through the required process successfully.
Configuring a Windows XP Embedded thin client
by Sean Liming and John Malin
Introduction
Thin clients are becoming increasingly popular computing platforms among IT departments. The ability to run an operating system with all the major applications -- word processing, spreadsheets, and other company software -- on remote servers saves companies millions in computing service fees. Thin client architecture requires very little local storage, and acts like a window to the backend servers that host the major applications.
IT departments like thin clients because they save hundreds of dollars versus the cost of a fully configured PC, and they also reduce application software maintenance costs for deployment and upgrading. Of course, no two IT departments are alike -- each has its own approach to security or custom implementation to access the network. Therefore, easy configurability of thin clients is important.
There have been several requests on the Windows XP Embedded (XPe) newsgroups asking to modify either thin client hardware or make some change to the software. The customization requests are quite diverse in scope and complexity, but many would involve modifying the whole underline operating system image. Minor changes for TCP/IP address and domain names can be handled within the existing image, but changing the whole image takes some reverse engineering. This article provides the first steps to customizing Windows XP Embedded thin client platforms.
The hardware inside
An XPe image consists of a hardware layer (HAL, device drives) and a software layer (TCP/IP, notepad, Explorer). The XPe database groups the OS components into these two categories. Every image includes device drivers that interface to the hardware. A little understanding of the hardware is very helpful when make changes to the XPe OS image.
First, processor technology is an important aspect of the performance and the physical size of a thin client. Many thin client terminals are based on either VIA or Transmeta processors. These processors are ideal for thin client hardware platforms due to their low power, good performance, and the fact that they do not require a cooling fan.
The boot media is the next, if not the most important, piece of hardware that you need to understand. Many thin clients use solid state technology such as CompactFlash and mini-IDE flash drives as the boot and storage medium. The use of non-rotating media makes thin client systems a little more robust then their larger PC counterparts. The usable lifespan of flash memory devices is a bit of an issue, though.
Windows XP Pro and XP Embedded are constantly reading from and writing to a disk. This translates into many flash erase cycles, of which CompactFlash and mini-IDE flash memory devices have a limited number. Without sophisticated wear-leveling technology, CompactFlash and mini-IDE flash cards will wear out much faster than in normal consumer-electronic style use.
To protect the life of the flash, thin client manufacturers implement XP Embedded's Enhanced Write Filter (EWF) to prevent writes (erase cycles) to the flash drive. All writes are redirected to the RAM disk (a.k.a. overlay). If you need to make any changes to the OS -- such as domain connectivity or change TCP/IP static address -- the EWF can be disabled to allow updating of this data, and then re-enabled. Setting up EWF is a bit tricky, especially when it comes to CompactFlash cards. When you are recreating an XPe image for your thin client you will have to get familiar with EWF setup.
Another drawback of these flash memory devices is their boot time. CompactFlash and mini-IDE flash devices typically boot with Port I/O mode at a rate of 3 to 5 MB/s. At that rate, a system could take as long as 90 seconds to boot. In contrast, an SATA hard drive uses DMA to speed up access to 155 MB/s.
If your target has an internal header for USB 2.0 and has BIOS support to boot USB 2.0 devices, you could upgrade to an M-Systems uDiskOnChip (uDOC). The uDOC offers security, reliability, performance, and cost effective solutions for embedded systems. You don't have to worry about flash life since the uDOC features M-System’s TrueFFS wear-leveling technology. The boot times are just as fast as a hard drive, since the uDOC is operating over USB 2.0. The overall system performance will improve with the uDOC in your system.
Finally, you will need to be familiar with other devices on the platform such as the Ethernet, audio, and video controllers. You may need to create components for these devices, if the drivers are not in the database.
Running Target Analyzer (TAP.EXE)
Creating a custom XP Embedded image implies that we have to create a custom configuration in Target Designer. To get the baseline components for the target hardware configuration, we need to run Target Analyzer (TAP.EXE) on the thin client system to get a PMQ file that contains a list of the devices in the system.
It shouldn't be too difficult to run TAP, since XP Embedded is already running on the thin client. This is where understanding the hardware becomes important. In order to run TAP, you need to get TAP on the thin client. Here are some options: - Attach a USB floppy drive or USB flash key to the thin client and run TAP.EXE from that device.
- Copy TAP directly to the internal storage media. EWF can get in the way, so one way is to remove the CF or mini-IDE from the thin client, connect the media to your development PC using an adapter, copy TAP to the media, then place the media back into the thin client, boot the thin client, and finally run TAP. You will also need a method to copy the PMQ file that TAP generates to the development machine or save the PMQ file to the media, keeping in mind the EWF issues.
- Alternatively, if you can get to a network share, you could download TAP to the thin client and then run TAP so the output is placed back onto the network share.
Of course, if you are trying to upgrade the thin client from another OS, then you will need to perform some additional steps. The MS-DOS version of Target Analyzer (TA.EXE) could be used, but it is doesn't produce all the components needed to develop a bootable image. You may need to add a few extra components to get the image to boot. Here is a list of some of the components to add: - PCI standard host CPU bridge
- PCI standard ISA bridge
- Plug and Play Software Device Enumerator
- Primary IDE Channel
- Secondary IDE Channel
- Disk Drive
- Standard Dual Channel PCI IDE Controller
- Standard IDE/ESDI Hard Disk Controller
There may be more components to add. Ideally, you want to install XP Pro on the target system and then run TAP.EXE under XP Pro. The resulting PMQ file will have the complete list of system components. You may have limited local storage space so installing XP Pro might not be possible. One solution I have used is to build an image based on the MinLogon Sample Macro component to host the TAP session: - Open Target Designer
- Create a new configuration called TAPrun.
- Add the MinLogon Sample Macro component to the configuration.
- Run a Dependency Check with Auto-resolve enabled.
- Build the image
- Once the build has completed, copy TAP.EXE to the root of the image
The final XPe image uses the Standard PC HAL so the image should run on all PC platforms that can run XP. The image size is about 25MB. Download the image, with TAP.EXE in the root of the image, to the target device and let FBA run. Once FBA completes, you can run TAP.EXE to get the PMQ file.
The resulting PMQ file will not have a complete list of components, but it will have found the critical components to boot the OS. Follow the steps outlined in the next section to import and create a Platform Macro Component. The only problem with this technique is that the Standard PC component will be in the PMQ list instead of another possible Computer component like ACPI. Many systems today support the ACPI specification for power management and other BIOS features.
If you want to get the exact Computer components, run TA.EXE from DOS on the target, import the resulting PMQ file, and compare the Computer component results of the TA.EXE analysis under DOS to the TAP.EXE analysis under MinLogon. TA.EXE under DOS will reveal the Computer component that is best suited for the system. You may have to replace the Standard PC component with "Advanced Computer and Power Interface" or "ACPI Uniprocessor PC" components if your hardware has ACPI support, and you will want to add any other missed components that TA found.
Platform Macro Component and missing drivers
Capturing the PMQ file with TAP on the target system is the most challenging aspect of this process. The next step is to create a Platform Macro Component that contains the hardware components and basing line for the configuration. - Open Component Designer
- From the menu, select File->Import. This will bring up the open import file dialog.
- Locate and OPEN the devices.PMQ file.
- The Import File dialog appears. Enter a log file name:
\deviceMacro.log and click the Start button. When completed, the import dialog lists the number of components found out of the number of devices in the PMQ list. A new SLD file is created with a component titled devicesTAP.
- In the details pane of the devicesTAP component, change the name of the component to XPES_target.
- Next to Prototype in the details pane, click Browse.
- The Select Prototype Component dialog appears. Traverse the component tree Software->Test & Development->Selector Prototype Component. Highlight the component and click OK.
- Select Group Membership, and from either the menu or right click the mouse select Add Group Membership.
- The Add Component Group Membership dialog appears. The logical place to put the platform is under platforms. Expand the tree until you locate platforms: Categories->Hardware->Platforms, and then click OK.
- Save the SLD file to the hard drive.
- Open Component Database Manager and import the newly created SLD file into the database.
If there were any missing components, such as network, audio, or video devices, you will have to create custom components for them. The deviceMacro.log file will list the names of the missing device components and their PCI IDs. Sometimes the hardware vendor will supply the drivers on CD, but most of the time you will have to search and download these drivers from the chip manufacturer. Since VIA and Transmeta processors typically involve a two chip solution, finding the drivers should be straightforward.
Most of the time, the driver's INF file can be imported into Component Designer to create the SLD and component. Other components sometimes require a little more work with the help of Component Helper, DependencyWalker, and FilMon/RegMon tools.
Once you have created the components and imported them into the database, you should edit the Platform Macro Component and add the newly created hardware components as dependencies.
Configuring the software
Now that the hardware layer is ready, the next part is the software customization of the image from within Platform Builder. You can mold the image to your specification since the configuration is being created from scratch. Some of the possible changes are: - Custom Shell -- instead of a stock shell such as Explorer, you can create a custom shell with its own look and feel, or create multiple shells for specific user types such as administrator and user.
- Security Settings -- custom security settings can be added to lock users out of specific applications, directories, or drives.
- Third Party Software -- there are many companies that develop software for thin client solutions and most of these companies have XPe components that can be imported into the XPe database.
- Administration Support -- the thin client should have some basic administration support components for networking, display, etc.
| Component | Thin client usage | | Domain Participation | The Domain Participation component is a macro component that bundles components which make it possible for an embedded device to participate in Windows domain security. | | Netshell | Command line utility to set the TCP/IP settings for network adapters. Required to access the network settings in the network control panel. | | TCP/IP Utilities | Contains a number if TCP/IP utilities including ipconfig.exe | | System Control Panel | Provides the interface to change the Domain and computer name | | Display Control Panel | Change video resolution | | Date/Time Control Panel | Set the local time zone, date, and time | | Audio Control Panel | Support systems with sound and audio |
The most important feature to enable and the most challenging is EWF (Enhanced Write Filter). Unless you are using the uDOC, you will need to implement EWF to protect the flash drive. Mini-IDE flash drives shouldn't be a problem since they are IDE flash disks that are fixed devices. Many manufacturers set up EWF with a second partition as the EWF volume. You have your choice of EWF implementation and overlay type, since you're recreating the image from scratch. Since this is flash media, RAM or RAM-REG overlays are the two best choices.
CF cards are a different story. Most off-the-shelf CF cards are ID'd as removable, which creates most of the headaches to set up EWF on CF. XP/XPe will only view one partition on a removable medium, thus RAM-REG is the only overlay type choice that can be made. CF cards that are ID'd as fixed devices can be ordered special from the manufacturer. The choice of using the RAM overlay with the second partition is possible. You may find that the thin client manufacturer has already configured the flash drive as fixed so all you need to do is replace the image on the drive.
Not only will you have to enable EWF, but you will want to control EWF; so updates and modifications to the image can be made within a working image. The EWF API can be used to add custom controls to shells or EWF administrator applications. EWFMGR.EXE and the EWF API can only be accessed via Administrator accounts. Power Users, Users, Guest accounts cannot change the state of EWF.
If you need to duplicate the image, you will have to add the System Cloning Tool component to the configuration and add a special reseal library to address EWF.
Once the configuration is completed and the image is built, the image will need to run FBA on the target system. The image will have to be copied down to the target media, either through physically removing the device from the target system or using a software solution like Remote Recover.
Reading Further
The overview presented in this article provides basic tips for getting started with configuring a thin client with a custom image. The real work is in the details. There are many solutions for working with Windows XP Embedded that can be found in a number of books, articles, and websites: - msdn.microsoft.com/embedded
- Windows XP Embedded Advanced, Sean D. Liming, RTC Books, 2003, ISBN:0-929392-77-9
- Windows XP Embedded Supplemental Toolkit, Sean D. Liming, Cedar Hill Publishing, February 2005, ISBN: 1-932373-96-9.
- www.seanliming.com -- XPe Center @ seanliming.com -- contains various articles and links to different resources on Windows XP Embedded.
XP Embedded thin client solutions
Thin clients come in many form factors: terminal, notebook, and tablet. There are many companies that are building hardware and software solutions for XPe thin clients. The table below lists a few companies and websites that have a solution for XP Embedded thin clients. Also refer to the WindowsForDevices Windows-powered thin client quick reference guide.
We like to keep the table up to date. Please let us know if you find a company that makes an XPe thin client solution that is not in the table.
Bibliography - Windows XP Embedded Advanced, Sean D. Liming, RTC Books, 2003, ISBN:0-929392-77-9
- Windows XP Embedded Supplemental Toolkit, Sean D. Liming, Cedar Hill Publishing, February 2005, ISBN: 1-932373-96-9.
About the authors
 Sean Liming is a Microsoft eMVP and is the author of three books on Windows Embedded. Liming is currently the Managing Director of SJJ Embedded Micro Solutions, which offers books, toolkits, training courses, and consulting services covering all aspects of embedded design hardware, software, manufacturing, and life-cycle management.
 John Malin has a BS and MS in Solid State Physics from Case Western Reserve University. John was an early pioneer in using PC’s to develop embedded software for x86-based embedded devices in the mid 80's. Over the past 20 years John has worked with a number of real-time, multitasking, embedded operating systems starting with VRTX, Nucleus, PharLap, ThreadX, and Windows CE. John has also been active in XP Embedded development and co-authored the XPe MOC updates for XPe SP1 and SP2. John admits that when he started working with embedded systems, he had a lot more hair.
(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.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Windows is a trademark or registered trademark of Microsoft Corporation in the United States and/or other countries and is used by WindowsForDevices under license from owner. All other marks are the property of their respective owners. WindowsForDevices is an independent publication not affiliated with Microsoft Corporation.
news feed