Tag Archives: Embedded

Tech Friday — WES and Ruby

Microsoft has made available considerable information about Windows Embedded Standard, (WES) which is the latest version of Windows Embedded, based on Windows XP.

There are (roughly) three versions of embedded operating systems from Microsoft:

Windows Embedded Standard: Allows a stripped down version of Windows XP for powering set-top boxes, game boxes, and machines dedicated to a single application. This is what we’re using in one version of our telemedicine set-top box.

Windows Embedded POS: An enhanced version of WES for cash registers and checkout scanner applications.

Windows Embedded CE: This is the version of Windows used for mobile phones and other hand-held and portable devices. The code base and software development tools for CE are different than Windows Embedded, with many of these related to WES.

There are a total now of twenty-nine (29!) training videos related to Windows Embedded Standard.

The Windows Embedded Developer Center site is the gateway on Microsoft’s Developer Network to all things related to Windows Embedded.

The Windows for Devices web site has information related to all version of Window Embedded as well as hardware that runs under Windows Embedded.

Other Notes:

Smashing Magazine has a nice introduction to Ruby on Rails.

Logging in as Root in Ubuntu with Live CD

We just had a little contretemps as we attempted to replace system files on our Windows XP embedded machine with a new image. The easiest way we’ve found to copy the files is to run an Ubuntu Linux Live CD, which boots up a Linux desktop. Since the default user in the Linux desktop is guest, the user does not have privileges to replace the files a second time. To get around this, you have to log in using the root account. Steps:

1. in the original desktop, under the security tab for logins, be sure to check the box “allow local administrator to log in” under system->administration->login window.

2. Open a terminal session

3. type sudo passwd root

4. enter a password for the root user

5. re-enter a password for the root

6. shutdown – change user, and log in as root with your new password.

Background: There are three sort of funny things about this process for users who are not familiar with Ubuntu.

1. Ubuntu does not install a root user account by default. Or, maybe it installs the account, but it doesn’t allow its use. Thus, the act of assigning a password to the root user account is necessary to activate the account.

2. Even if you have a valid root account set up, by default Ubuntu does not allow you to log into a standard Gnome desktop. That’s why you have the change the setting in the security preferences.

2. In this example, since we are using the Live CD, you have do step 1 first. If you restart the computer from scratch all configuration settings are lost, because the Live CD does not allow you to permanently write anything to the disk.

Woof.

In any case, this solved our problem; we were able to blow away the system files on our target hard drive C:, so that we were able to copy a fresh version of our XPe image to the drive.

Photos of a Intel "Mini-ITX" type system

Wanted to show some photos of the little systems picked up from Logic Supply. Here’s a look at the exterior of the fanless one. The top and sides are perforated to let the heat out. Click on the photos to see a larger image.

Here’s a look with the covers off. You can see the massive heat-sink that sits over the processor, to the right…the smaller, shiny heat sink sits above the hard drive.

A look right down on the top…

And, a view with both heatsinks removed. You can see the mini hard drive to left. It is mounted into a carrier that has the hard drive heat sink already attached.

System specs:

Intel Celeron M440 (Yonah) 1.86Ghz
1 meg of Ram
2.5″ Samsung hard drive SATA 80 GB

Tiny Computers from Logic Supply

I’m testing a tiny computer from Logic Supply It has the following specs:

Intel Celeron M440 (Yonah) with a Front-side bus of 533Mhz
1 gig of memory
A 2.5″ Hitachi hard disk 5400 rpm
Panasonic DVD/CD reader
No OS
Build and test for additional $45.00

The case is about 7″ x 7″ and maybe 1.5 inches tall.

Total price is $661 before tax.

They gave me an awesome tour of the assembly plant. Dozens of these little guys being assembled, tested and burned in.

The one caveat that I would bear in mind is that the ones without fans can run hot…really hot, like hard to hold your hand on to them hot. This was the case at least when they were running the test program which exercises the processor.

I ordered mine with a fan; and the noise is acceptable, just a low swoosh (so far).

It came without an OS, so I’m installing Vista just for grins.

So far the buying experience has been terrific. They are really helpful on the phone. They specialize in small machines using mini-ITX motherboards using either Intel, AMD or Via systems. This unit is a candidate platform for our embedded application, and a successor to our beloved Pundit pizza-box sized system.

Disk Partitions

I am reminding myself of how disk partitions work, and how they can be manipulated. The impetus for this is an attempt to load Windows XP Embedded (XPe) on my target machine, an ASUS Pundit. Using Acronis Disk Director Suite, ($49.00) I created a separate small partition for the XPe installation. The problem then was trying to figure out how to boot the extra partition.

Partitions can be marked several ways
a. Active Primary – this is the boot partition. There can only be one of these on a disk.
b. Primary – This can be either a bootable partition, or not.
c. Extended – A physical partition that can be further subdivided into other partitions.
d. Logical – A subdivision of an extended partition.

The upshot for the test machine is that I want to have two partitions; one for the original Windows and software installation, that includes all of the necessary application software and a second testing partition for the Windows XPe image which contains all the applications and drivers already burnt into the XPe image.

Also, I need to be able to designate one partion or the other as the boot partition. This is done by marking the partiion as “Active”, and insuring that the boot drive letter is designated drive C:. The first part, designating the partition as the boot partition, seems to work fine within the Acronis program. Changing the drive letter, on the other hand, does not seem to be so intuitive as it involves a registry edit.

The drive letter desgination is important, because many programs rely on the designated drive letter to find their own executables and data.

To boot the XPe partition, I changed it to the “active” partition, and then renamed the drive letter to C: A final change involved changing the Boot.ini file which is present in the root directory of the partition. This file looks like this:


[boot loader]
timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Microsoft Windows
XP Embedded" /fastdetect /noexecute=AlwaysOff

and it gets modified to change partition(1) to partition(2) in both instances, so that the boot designated boot partition is indeed the 2nd partition on the drive. I recall from my distant MCP days, that although disk drives are numbered beginning with 0, the partitions are numbered beginning with 1. The diagnostic for this is that if you have already designated the second partition as active, but still boot into the “wrong” partition, it means that the OS files that are loaded are the ones that are pointed to be the boot.ini. To make this even more confusing, there is the notion of the “system” partition and the “boot” partition. This is a distinction which I think is only talked about when dealing with Microsoft operating systems. Perversly, the names seem to be reversed….it is the “system” partition which contains NTLDR and boot.ini. and the “boot” partition which contains \Windows, and \Windows\System32, and all the operating system binary files.

In 99% of the cases, of course these files are are all on the same partition and in most cases there is a single partition on a drive anyway.

Quick Introduction to Windows XP Embedded

Introduction To Windows XP Embedded
A five minute video introduction to working with XP Embedded.

Target Analyzer
creates an XML file which describes all the hardware
Runs from XP
16 bit version runs from DOS

Component Designer

Import the results of the Target Analyzer. Example shows about 200 hardware devices in the snapshot
Create a custom component for an application

XPe ships with 9000 device drivers, 3000 operating system components
If not included, you can import an .inf file for a device driver. You can then use this just like any other component

Component Database Manager
This tool is used to manage the database of components and check in new components

Target Designer
Select a design template (like “information appliance”)
Checks all dependencies.
Builds the target image.

The difference between a built XPe image is that the operating system that is built is built in a bootable form (not “installable” form).

More webcasts here.

Building a Windows XPe Test Environment

Back in May I worked through a Microsoft Virtual Lab online that created a test target environment for a Windows XPe device.
Today, I’m attempting to build my own version of a target device using Microsoft Virtual PC, following instructions from MSDN, How to Demonstrate Windows XP Embedded.

Continuing with the “virtual” theme, I was pleased to see instruction for creating an image on a Microsoft Virtual PC.
If you have never used this, it is available now as a free download, and it is great for trying things out without trying to scrounge another PC someplace. An essential developer’s tool, Virtual PC can be used to try different operating systems, (including non-Microsoft O/S’s), program builds, simulated client environments, virtual networks with multiple workstations, you name it.

But back to Windows XPe. I’m a newbie, so there were several non-obvious issues that I noted in the MSDN instructions.

The procedure describes using the Windows Preinstallation Environment. This is the equivalent of a DOS boot disk with a bunch of command-line utilities that you can use to prepare disk drives, copy drivers, and so forth. Windows PE has been around awhile, it appears to have been initially designed for use by “white box” computer system builders who wanted to configure hardware before installing Windows. So, essentially what you are doing to prepare the virtual PC is the following:

1. Create a new virtual PC and virtual hard drive for the embedded XP application.
Be sure the networking setting is set for “shared networking”.

2. Boot this new virtual PC using the first CD from the Windows XPe Evaluation Kit. This CD 1 contains the boot image for Windows PE. It will boot up the virtual PC and come to a command line with X: as the drive letter. The X:, in this case refers to the CD drive NOT the disk drive that you created for the virtual PC. This is because…you have to partition and format the virtual drive, per the instructions above in the MSDN article.

3. The article then describes the process of running TAP, the “Target Analyzer Tool” which captures the configuraton of the hardware that you are running on. This creates a file called devices.pmq

4. You need to get the devices.pmq to your host machine, either by running TAP with the output switch or copying the file to a share. This is a little confusing in the instructions; here is how I interpreted it.

a. Create a folder on the host machine called C:\Windows Embedded Images”

MD "C:\Windows Embedded Images"

b. Share this folder with a name XPe

NET SHARE XPe="C:\Windows Embedded Images"

c. On the virtual machine, Map the Z: drive to the shared folder using the IP address of the host machine as the server name.

NET USE Z: \\192.168.0.102\XPe

You may have to supply a name and password for this, (actually, this is a good thing..); I had to use my admin name and password to get in.

d. On the virtual machine drive C:, copy the devices.pmq to the shared folder

COPY  C:\ devices.pmq Z:

After completing this portion of the instructions, I continued on with the discussion of the compnent designer. This is one of the tools included in the Microsoft Windows Embedded Studio

1. Go to File Import, and choose the devices.pmq


The import function takes a few minutes to run. (10 or more). Once it is completed and you close the import dialog, you’ll get a first look at the component tree with the imported devices shown on the right.

Photo: c:\componentdesigner.png

2. Ok, moving right along the next step is to “finalize” the component.


This screen shot matches the one in the MSDN article.

3. Saving this file (from File|Save) creates an sld file.

4. Now the sld file needs to be imported into the Windows XPe component database using the Component Database Manager. This step is described in the MSDN document.

Finally, you get to build the Windows XP image using the Target Designer. This is where the components are chosen for the Windows image. Of course, the componet that you’ve just created needs to be added, as it contains all of the information about the target hardware.

The instructions say you should update the User Interface Core Component, but as this wasn’t added yet, I first added this manually. My guess is this would get added if you updated the dependencies before this step. By changing these, you have the opportunity to manipulate the user environment, similarly to the way you can set options using group policies.

Then, when you do the Dependency check, hundreds of components will be added. This step takes several minutes. When it completed, it showed that there were 10430 components included.


When all dependencies are resolved, you then build the run-time image. This took about 3 minutes, resulting with an image of 129.0 mb compressed, and an estimated uncompressed size of 179 megs. Not something that will fit on a floppy disk!

Doesn’t this look familiar?

As part of the process of installing this on to the virtual machine, the instructions call for using the Microsoft Resource Kit utility RoboCopy. This is XCOPY on steroids. Not only does it copy files and directories, but it preserves any attributes and settings on the files and directories. I did the copy. Occasionally it would stop because it claimed the network connection was down. I don’t think think so….as it copied from the the same physical machine. But in the end it looked OK.

This shows the result of the copy operation, and the root directory of the target machine. Recall that this is a command window within the Windows PE Environment (the graphic backround image), appearing in a virtual PC (the title bar and toolbar). Let’s see if the XPe image will boot!

The first boot agent starts. This writes the registry, installs system security, registers components, registers class installers, installs hardware devices, in short, completes the process of installation. Once configured, it forces a reboot again, and Voila! We’re into a session of XP embedded.