Embedded Operating Systems : Componentized or Vertical Focused ?

We've seen just how easy it is to build a Point of Service device using the WEPOS (Windows Embedded for Point of Service) SDK, I wrote the code needed to support a Barcode Scanner in about two minutes using around 10 lines of code, adding additional peripherals would have been just as simple.

WEPOS isn't like Windows CE or Windows XP Embedded (and at the same time it's very much like Windows CE and Windows XP Embedded) - the main difference is that WEPOS isn't a componentized operating system, you don't have components to choose, you "install" the WEPOS operating system onto your target machine (you do have a number of setup options, which includes the ability to choose applications such as Media Player or Internet Explorer to be part of your image) - at the core WEPOS is a cut down install of Windows XP Professional SP2 (around 300MB), the install process takes around 30 minutes to complete and, at that point you have a ready to run WEPOS operating system - of course you still need to write the POS application - we've already seen how easy that is.

Here's the question... Would you prefer to have componentized operating systems where you take time to pick and choose the individual operating system features, and therefore tweak the operating system footprint, and therefore the supported operating system API's and technologies - or would you prefer to have more vertical focused operating system images like WEPOS that speed your time to market through fast installs, managed libraries to support your hardware and support for all the latest desktop security and management features (including Windows Update, SMS etc...) ?

How do you make the trade-off between footprint and time to market ?

- Mike

Comments (9)

  1. tzagotta says:

    Hi Mike, One concern I have about the configurability of Windows CE is the amont of time required to test your selected configuration. One of Microsoft’s premiere partners told me that we should plan to spend at least 4 weeks just to create and test the OS configuration. Is this realistic?

  2. M says:

    > at least 4 weeks just to create and test the OS configuration

    Impossible to give a good estimate without more information.

    Are you using custom hardware or some well-defined hardware with an existing BSP? What is your experience of Windows CE? What do you mean by "create and test"? Does it include applications, or just to boot the OS?

    I could probably find a configuration that I would have up and running within a day or so, but with custom hardware, OAL, and a bunch of drivers that could easily extend to several weeks.

  3. Sean Gahan says:


    I think the answer depends on who is evaluating the question. The developer will want the control of the OS and the foot print; whereas I think management would opt for the vertical solution because of the reduced requirements to complete the project. I also believe the size of the company developing the unit will have to come into play; for example, a smaller company would be more likely to opt for the vertical solution based on their developer resources, whereas a larger company can dedicate more resources to the project and cut down time to market. By the way in Jerry Krasner’s article “Total Cost of Development” he states that the average time to market for windows devices is about 8 months with about 8 developers, do you feel this number is still accurate and how do you think your vertical solution will impact the current development model.

    Best regards,

    Sean Gahan

  4. mikehall says:

    tzagotta, testing is obviously very important for any project whether this be an enterprise desktop application, XBOX 360 game, consumer electronics device, industrial control system, or other embedded device – and of course testing can occur at a number of levels, Windows CE ships with the "CETK" (Windows CE Test Kit) that can be used to automate testing of various device drivers on your system, and (since the CETK test DLL’s run in user mode) can be customized to run additional tests of your embedded device.

    There are two parts to your question.

    1. Customization

    2. Testing

    Customization can be as simple as selecting one of the Windows CE Platform Wizards and building the operating system – this assumes that you have a BSP to target and test (Windows CE does ship with an x86 emulator, so you can test many aspects of your design while you’re working on your "real" hardware and BSP)

    Customization can also involve selecting individual operating system components, the Windows CE development tools (and XPE) contain dependency information for components, so selecting something like the .NET Compact Framework (for example) would pull in the dependent components needed for a compact framework application to run.

    Overall, testing is extremely important, and becomes more time consuming if you are building custom hardware and a custom BSP – you now have a number of moving parts, you need to debug and test the hardware, and debug and test your BSP/Drivers and overall operating system configuration.

    – Mike

  5. mikehall says:


    In this industry I don’t think there’s a "one size fits all" embedded operating system, which is why there’s a family of Windows Embedded operating systems to choose from – you can make a decision to use Windows CE, Windows XP Embedded, or Windows Embedded for Point of Service – each operating system has been designed to fit with a specific category of embedded device.

    When thinking about the TCO study from Jerry Krasner this talks about 8 months for custom hardware and customized operating system image, this doesn’t talk about using off the shelf hardware and o/s.

    If we look at WEPOS (Windows Embedded for Point of Service) the hardware is x86 processor and PC Architecture (relatively low cost, readily available), tons of peripheral support since the core of WEPOS is Windows XP Professional SP2 – so in this case you only need to write the application that sits on top of the operating system.

    Windows XP Embedded is a componentized operating system, so you do choose the components that make up your final operating system image – same as WEPOS the underlying hardware is x86 and PC Architecture with tons of peripheral support – typical time to market with XPE devices is 12-14 weeks (typically customization of the hardware is limited to plugging PCI cards or external peripherals (serial, USB, 1394 or whatever).

    Windows CE is typically longer time to market than WEPOS or XPE since you are probably going to be building custom hardware that meets the needs of your specific device, this includes the choice of processor (x86, MIPS, ARM, SH4) and supported peripherals – in many cases you will need to write/modify bootloader, and BSP/driver code to get your specific device running – the advantage is that you can reduce BOM for your device (no PCI bus, lower cost processor, less memory etc…) and get native real-time support.

    One other thing to bear in mind, is that the device you’re building, in many cases, isn’t a stand alone device, think of the POS terminal, ATM, Rock-Ola music player, and other devices – in many cases there’s also the back end server infrastructure you need to work with, whether this means using XML Web Services, SQLCE with data replication, raw HTTP posts, sockets or other technologies part of your overall test plan needs to include the integration with whatever back end services you’re using.

    – Mike

  6. Mike,

    Verticaly focussed or componentized is an interesting question from a "technology" point of view. But i think there is another factor that we developers have to bear in mind and would be the enduser and specifically how they make use of the devices (in our case POS terminals) we build. When we started back in 1998 we built PC based Windows POS software and the majority of problems we encountered were due to users just switching off the "cash register" as they see it. We all know what this does to Win95/98/ME i guess. All drivers for POS peripherals where OPOS based, so i guess that would be pretty much the same as WEPOS now. But with XP and the all connected world we live in came problems like virusses, waiters playing online games etc. So our choice for WinCE on X86/VIA based hardware for our POS terminals was not driven by time to market or development time but by the dramatic decrease of service calls we expect from an OS that does not know virusses (yet), can be sitched off without penalty, boots relatively quick and most of all looks like a cashregister to the enduser and not like a PC !!!

    Just another point of view from Holland.



  7. mikehall says:

    Franks, thanks for the comment – Interestingly, Windows XP Embedded SP2 doesn’t need to boot into the Windows Shell, you can boot directly into your application (your application becomes the shell) – with the SP2 release of Windows XP Embedded there’s a new technology called HOTM (Hibernate Once, Resume Many), this allows a user to rip the power out from a device, plug back in and ‘resume’ the operating system from a known good image – HORM makes use of EWF (the Enhanced Write Filter), which can be used to mark a R/W hard-drive as R/O, and also protect flash based boot systems – in effect, any write commands are filtered into an in-memory cache instead of being written to the underlying boot media – thus the media cannot be corrupted when the power is removed/replaced.

    – Mike

  8. Thanks for your comment Mike. I got the evaluation versions of XP embedded and WEPOS 2 weeks ago. Didn’t have time to install and try it yet. But we do have a considerable amount of users still using standard XP running our POS app. So i will put some effort in your suggestion of evaluating WEPOS and/or XP embedded on our flash based X86 hardware.

Skip to main content