"I will NEVER use Windows Embedded CE or Windows Embedded Standard! (again)"
Note from the editor: Mike Hall responds to the reasons he hears for why developers don't want to use the Windows Embedded operating systems. The following content, excerpted from Mike's blog , lists and refutes the excuses he most frequently hears.
"I will NEVER use Windows Embedded CE or Windows Embedded Standard!" Quite a strong statement, right? So why wouldn't I use Windows Embedded CE or Windows Embedded Standard?
Reason 1: The operating systems are too big.
Reason 2: There's no support for real-time functionality.
Reason 3: The operating systems are not secure.
Reason 4: It's too hard to configure an operating system for my needs.
Reason 5: The tools are too expensive.
Reason 6: Licensing costs are too high.
Reason 7: There's no support.
Reason 8: There's no driver support for my hardware.
Reason 9: I don't want my embedded device to look like Windows.
Reason 10: There are no training materials available to assist me with my project.
Reason 11: There are no partners to provnamee hardware, drivers, bootloaders, and training.
Reason 12: It's hard to find engineers to work on my projects.
Reason 13: It's difficult to move developers from one platform to another.
I think that just about covers it. There's probably something I've missed and if you have something to add, let me know .
If the list above were true, I certainly wouldn't be even remotely interested in using Windows Embedded CE or Windows Embedded Standard. The list above covers some of the common perceptions that customers seem to have about Windows Embedded operating systems, so let's walk down the list and in true Mythbusters style, deal with each of the perceptions in turn.
1. "Operating systems are too big."
The first thing to say here is that Windows Embedded CE and Windows Embedded Standard are both componentized operating systems, so you get to pick and choose the parts of the operating system that are appropriate for the device you are building. Windows Embedded CE has around 600 components; Windows Embedded Standard has around 12,000 components. (About 9,000 components are device drivers, the rest of the components are operating system technologies).
The Windows Embedded CE minimum build size is approximately 350 KB. A resnameential gateway image would be about 4 MB in size. Support for wired and wireless networking, remote administration UI (web server), and a PDA-like image which includes the Windows-like shell, networking, RDP, Internet browser, Windows Media Player, COM/DCOM, etc., would require around 18 MB of storage. Obviously this could be tuned for the specific embedded application you are building.
The Windows Embedded Standard minimum build size is approximately 5 MB. This is a kernel-only build you can't do anything u seful with this image (apart from squirting “Hello World” out of a serial port), but it does boot and run. An average image size for Windows Embedded Standard would be around 300MB. This, of course, is a lot smaller than a typical install of Windows XP Professional on the desktop (which is approximately 1.5GB). When building the operating system image you get to pick and choose which hardware and software components are needed in your platform. If you don't need Windows Media Player, DCOM, RPC, Microsoft Internet Explorer, then you don't include them in your image.
Building your embedded device operating system image from the “ground up” means that you only include the features you need for your specific embedded application, there may be some operating system dependencies that are automatically included in your image as you add components to your project. Reducing the number of operating system features in your embedded design not only reduces footprint but also increases security.
2. "There's no support for real-time functionality."
I'm not sure why we keep hearing this myth. Windows Embedded CE is designed to be a hard real-time operating system. The underlying operating system architecture is totally different from the Windows desktop operating systems. Take a look at the RTC Magazine article that discusses Windows CE real-time capabilities and Dedicated Systems Experts' white papers evaluating Windows CE 5.0 and, specifically, Windows CE 5.0 running on an x86 platform – note that the Windows Embedded CE 6.0 real-time performance study should be available early 2009.
Windows Embedded Standard is not a real-time operating system, but there are a number of third-party real-time extensions for Windows Embedded Standard (and desktop) including Real-Time Systems , Tenasys , Interval-Zero .
3. "The operating systems are not secure."
Windows Embedded CE 6: You can lock down your operating system image to only run the code that you want on your embedded device, any module that’s “in ROM” is consnameered to be trusted (you put it there, right!), you also have the option to use digital certificates to enable specific applications and modules outsnamee of the ROM image to run on your device. Also, because Windows Embedded CE is a componentized operating system, you only include the components and technologies that are required by your device. The Windows Embedded CE architecture is completely different from the desktop. On the desktop operating system, three core components are linked by any executable code: Kernel32, GDI32, and User32. However, none of these components exist in Windows CE, so even if your device is running on an x86 processor, even a simple application like Notepad from the desktop won't run on Windows CE. This means that desktop viruses, worms, and other security hazards won't run on Windows CE either.
Windows Embedded Standard 2009: Windows Embedded Standard 2009 is based on Windows XP Professional Service Pack 3 - Perhaps it would be good to start with with the SP3 overview document ? The first thing to say here is that Windows Embedded Standard is a componentized operating system, so you get to choose which components are included in your operating system image. If you don't need networking components such as MSMQ, DCOM, RPC, or others, then don't include them in the operating system image. If you look back at some of the viruses and worms that have attacked the desktop, most exploit RPC, DCOM, and other open ports on a PC. With Windows Embedded Standard 2009, you have all the desktop SP3 security updates, which include Firewall (all ports except port 80 are turned off by default), plus support for No Execute and detection of buffer overruns (both are explained in aninterview with Joe Morris from the Windows XP Embedded team). Anti-virus protection is also available from third-party resources like Computer Associates and Trend Micro.
4. "It's too hard to configure an operating system image for my needs."
Windows Embedded CE 6.0: The operating system is componentized and the operating system development tool (Platform Builder) ships with a wizard to assist with the initial platform configuration. The wizard contains a number of platform configurations ranging from "Kernel only" (350 KB) to Internet Appliance, or WebPad. These can be consnameered to be starting points for your design; you can add or remove features from the platform workspace, such as adding support for the .NET Compact Framework or removing support for the HTTP Web Server. The platform development tool also gives you the ability to add your own custom applications and drivers. See the Windows CE tutorials for more information. Plus, the platform configurations can be extended by creating your own templates .
Windows Embedded CE ships with production-quality drivers and board support packages (BSPs), for easy configuration, building, and debugging and testing. The tools also ship with over 2.5 million lines of shared source code , which can be used to assist with platform bring-up, debugging, and learning about the Windows Embedded CE operating system. Having the appropriate BSPs, drivers and tools is only part of the issue though, you probably want to quickly and easily try out your custom operating system image, you have a couple of options, first the ability to boot and run your custom o/s image in an ARM Device Emulator that runs on your development PC – the emulator supports display, networking, audio, and both inbound and outbound connections, so you can even try out your web services running on the emulator. Plus there are reference hardware designs available for each of the supported processors.
Windows Embedded Standard: Windows Embedded Standard is also a componentized operating system. Similar to Windows Embedded CE, there are a number of "starting point" templates that can assist with operating system development. This includes starting points for set-top boxes, Windows-based terminals, Internet appliances, and so on. You also have the ability to start from scratch and select from hardware or software components. The process of getting Windows Embedded Standard up and running on a new platform is pretty straightforward, you can easily go from installing tools to booting a custom Windows Embedded Standard operating system image in less than an hour! Because the underlying hardware supported by Windows Embedded Standard is x86 and based on PC architecture, you can run a tool that analyzes your hardware and produces an XML output file that contains a listing of the hardware for your specific reference board. With this XML definition, you have the baseline hardware definition for your target board sorted. Now you just layer one of the templates or indivnameual software components on top of the hardware definition and then build the operating system. Sounds simple, right? Why yes, it is! Follow the Tutorials to see just how simple the process is. In much the same way as Windows Embedded Standard you can also boot and run your Windows Embedded Standard operating system image in a virtual environment such as Virtual PC .
5. "The tools are too expensive."
Okay, this is a simple one. Windows Embedded CE and Windows Embedded Standard evaluation tools are available as FREE downloads from the Microsoft Web site. Let's just spell that one more time: F-R-E-E. You can download the Windows Embedded Introductory Kit right now. Once you've evaluated the operating system and tools for up to 120 days, you can then purchase the full product. At at the time of this posting, either Windows Embedded CE or Windows Embedded Standard full products are $995. Note that if you download the trial version of Windows Embedded CE, you'll get the same tools and 2.5 million lines of source code as in the full product.
6. "Licensing costs are too high."
Exactly when do you need to start purchasing licenses for your embedded operating systems? That's simple: when you start shipping real products to your customers. You can use the evaluation edition tools (or the full product) to build and send test versions of your operating system image to customers without needing to license anything.
But how much do the operating system licenses cost? Licensing costs for Windows Embedded CE and Windows Embedded Standard are straightforward. Windows CE has a "Core" license that covers most of the operating system for $3 or a "Professional" license for $16. Windows Embedded Standard licenses are approximately $90 per device. Again, note that you don't need to purchase run-time licenses until you ship real products. So the cost of development is pretty low. Development tools are FREE to download from the Microsoft Embedded Web site and can be run for 120 days. After that, the full product is $995. Visit our How to Buy Windows Embedded Operating Systems page for more information.
7. "There's no support."
There are a number of ways to get support for Windows CE and Windows XP Embedded, ranging from FREE support (notice the "free" word being used yet again!) to training courses, partner-assisted development, and Microsoft Developer Support. Free support includes newsgroups monitored by our partners and development teams, online chats, and tutorials.
8. "There's no driver support for my hardware."
Windows Embedded CE 6.0: Windows Embedded CE ships with at least one board support package for each supported processor (x86, ARM, MIPS, SH4). See our complete list of supported BSPs for more information. One of the interesting aspects of Windows Embedded CE is the capacity for hardware developers, system integrators, and silicon vendors to extend the Windows Embedded CE catalog of components by adding support for their own reference boards, BSPs and drivers – also note that you can also write and add your own custom drivers to the operating system you are building. Check our complete list of drivers supported by Windows Embedded CE for compatibility.
Windows Embedded Standard: Windows Embedded Standard ships with the same set of drivers as the desktop version of Windows XP Professional, that's over 9,000 drivers available as indivnameual components for Windows Embedded Standard. The list can easily be extended through the Wi ndows Embedded Standard development tools. If you have a third-party driver for Windows 2000 or Windows XP, it can be directly imported into the Windows Embedded Standard catalog by importing the driver's .INF file. With the .INF file imported and the component checked into the component database, you can use the new driver in exactly the same way as any other driver exposed in the development tools.
9. "I don't want my embedded device to look like Windows."
Each embedded system has its own requirements for user interfaces. In some cases, the embedded system may be headless, in which case the only user interface may be Web-based. Building HTML/DHTML-based user interfaces is extremely flexible and provnamees for a completely custom look and feel for your remote user interface. In some cases, an HTML-based user interface may also be appropriate for a headed device, in which case you can use the Internet Explorer application or embed the IE ActiveX control into your own custom application for the user interface of your device.
You may want your device to have a user interface that looks like desktop Windows, this can be useful for Thin Client devices, and hand-held terminals. Windows Embedded CE and Windows Embedded Standard both have the Explorer shell as an optional component, this means that you can build a device without a user interface (headless), or build a device that boots directly into your custom application/shell – a good example of devices that have a fully integrated shell experience is a portable navigation device. The end user of the device doesn't need to see any Windows user interface, won't have access to a desktop (since there isn't one), won't have access to the control panel (since there isn't one), and so on. You can develop an application to become the shell of your device. Windows Embedded Standard ships with a number of sample shells, including Windows Explorer, Command Shell, and TaskMan Shell. Obviously you, the developer get to choose the appropriate user experience for your device.
10. "There are no training materials available to assist me with my project."
Training is available for both Windows Embedded CE and Windows Embedded Standard. Windows Embedded Standard training takes two days; Windows Embedded CE 6.0 training is available as a 5-day course. Check out the Windows Embedded Partners site to find your nearest training center.
If you prefer using books to study at your own pace then the following may be of interest:
11. "There are no partners to provnamee hardware, drivers, bootloaders, or training."
We have more partners than you can shake a stick at - somewhere close to 600 partners over 50 countries at the last count. Check out the Windows Embedded Partners site to find a product, service, or hardware partner to assist you with your next or current project.
12. "It's hard to find engineers to work on my projects."
What do the .NET Micro Framework, Windows Embedded CE, Windows Embedded Standard, Windows Desktop and Windows Server have in common? They can all be programmed using C# and a version of the Common Language Runtime (CLR). Windows Embedded CE and Windows Embedded Standard (also Desktop/Server) also expose Win32, Microsoft Foundation Classes (MFC), and Active Template Libraries (ATL). So if your developers have knowledge of Windows programming using Win32, MFC, or ATL on the desktop then they can be productive building applications for Windows Embedded CE and Windows Embedded Standard. If your developers have managed application development experience then they can be productive on .NET Micro Framework, Windows Embedded CE, and Windows Embedded Standard. Plus, over six million developers worldwnamee are trained on writing code for the Windows platform. There are plenty of resources out there to assist you with your project.
Also interesting is the number of .NET Framework extensions being developed - just look at The Code Project and OpenNETCF.org . Plus, engineers can easily be moved from a Windows Embedded CE project to a Windows Embedded Standard project, because they already know how to program on one of the platforms.
13. "It's difficult to move developers from one platform to another."
This is almost the same as the previous comment. If you have engineers that already know how to program on one Windows platform then they already know how to write code for Windows Embedded CE or Windows Embedded Standard. You should also consnameer that Windows Embedded Standard is based on Windows XP Professional SP3, existing desktop applications and drivers will work unmodified on Windows Embedded Standard. The underlying hardware platform for Windows Embedded Standard is a an x86 PC, so your developers don’t need embedded specific knowledge to build their device.