Welcome to MSDN Blogs Sign in | Join | Help

Windows Embedded Blog

A look at Embedded and other Cool Stuff.

News

  • This posting is provided "AS IS" with no warranties, and confers no rights.
And now... Windows XP vs Windows XP Embedded...

Just to round out the story, I should also compare Windows XP with Windows XP Embedded...

How does the story begin... oh, yes, that's right... </clears throat> A long time ago, in...

Windows XP Embedded can be traced back to the days of Windows NT 4.0, there were two flavors of NT 4.0, Server, and Client - a Microsoft development team based out of Israel took on the task of componentizing the operating systems and creating a set of tools around the operating systems that made it easy(ish) to create an embedded device based on the Windows NT 4.0 code base, the operating system was barely componentized, developers could choose from a small number of components - the operating systems were licensed in one of four buckets, depending on whether you were using a headless configuration of the operating system, or display based, and client, or server.

At the time that Windows NT 4.0 Embedded shipped the development work on Windows 2000 was already started, the time needed to componentize an existing operating system was looking to be about 18 months, so we decided to skip Windows 2000 (and licensed Windows 2000 with embedded restrictions to those that wanted to build embedded systems around the Windows 2000 codebase) and move directly to building an embedded version of Windows XP Professional.

From day one of the Windows XP desktop development effort the Windows XP Embedded team were hard at work taking component definitions and dependency information from the Windows Desktop team so that at the end of the development process for Windows XP Pro we were ready to deliver an embedded version of the operating system. The Windows XP Embedded product shipped within 90 days of the desktop version of Windows XP Professional.

The Windows XP Embedded operating system was originally released in 2001, since then there have been two updates, SP1, and SP2, each has added functionality from the desktop, and some additional embedded specific features, like the ability to boot and run from read-only media, boot (not install) from the network, hibernate once and resume many (very cool), and so on...

The operating system is broken down to approx 12,000 components, 9,000 drivers, and 3,000 operating system technologies.

Building and Deploying a Windows XP Embedded SP2 operating system image is fairly straight forward - take a look at the Windows XP Embedded tutorial here - this shows the typical steps needed to configure, build, deploy, and boot a Windows XP Embedded SP2 operating system image.

So, Windows XP Embedded SP2 is based on exactly the same binaries as Windows XP Professional SP2, this means that desktop applications and drivers will work with Windows XP Embedded without any source code modifications.

- Mike

Posted: Tuesday, March 15, 2005 11:31 AM by mikehall

Comments

Jeff Parker said:

Aha, so that answers that question from the previous story.
# March 15, 2005 12:32 PM

Hisham Ibrahim said:

I have a .dll file that was running in Windows XP Pro SP2. This .dll was created using VB 6.0. This .dll is being used by my application for printing. When I try to install this application into WindowsXP Embedded, I have a problem registering the .dll. Can you explain why..?What component that I need to run in order for me to register this .dll?
# March 22, 2005 8:19 PM

Mike said:

I have a couple of questions...

1. How are you registering the DLL on the desktop ? - and when you try to register the DLL on Windows XP Embedded, what happens ?

2. What dependencies does the DLL have ? - you can use Depends.exe (search for this on google or MSN Search) to determine the file dependencies - your DLL might not 'register' because it's missing some dependencies in the O/S.

- Mike
# March 22, 2005 8:23 PM

Hisham said:

My answer..

1. The installer will register it automatically. Haven't try to register it manually.

2. I've download the Depends.exe that you've suggested. After knowing all the dependecies, what should we do?

3. How could we know what component contain the dll mention in the Depends.exe. Please advice.. Thanks.
# March 23, 2005 3:04 AM

Mike said:

ok, so there are a number of debugging steps for you to follow.

1. You have the list of dependencies for the DLL, make sure those DLL's are in your O/S image

2. Make sure that Setupapi is an included component in the O/S image - this is required for MSI installers.

3. Use Filemon from System Internals to determine (at the point of failure) what is trying to be loaded from the O/S - the utility can be found here - http://www.sysinternals.com/

- Mike
# March 23, 2005 9:23 AM
New Comments to this post are disabled
Page view tracker