The following content, excerpted from Microsoft’s Mike Hall’s blog, lists and refutes the excuses he most frequently hears for not using Windows Embedded Standard.
“I will NEVER use Windows Embedded Standard!” Quite a strong statement, right? So why would I not use Windows Embedded Standard?
* Reason 1: The operating systems are too big.
* Reason 2: There is no support for real-time functionality.
* Reason 3: The operating systems are not secure.
* Reason 4: It is too hard to configure an operating system for my needs.
* Reason 5: Licensing costs are too high.
* Reason 6: The tools are too expensive.
* Reason 7: There is no support.
* Reason 8: There is no driver support for my hardware.
* Reason 9: I do not want my embedded device to look like Windows.
* Reason 10: There are no partners to provide hardware, drivers, bootloaders and training.
* Reason 11: It is hard to find engineers to work on my projects.
* Reason 12: It is difficult to move developers from one platform to another.
I think that just about covers it. If the list above were true, I certainly would not be even remotely interested in using Windows Embedded Standard. The list above covers some of the common perceptions that customers seem to have about Windows Embedded operating systems, so let us 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 Standard are componentised 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 Standard has around 12 000 components. (About 9000 are device drivers, the rest are operating system technologies).
The Windows Embedded Standard minimum build size is approximately 5 MB. This is a kernel-only build; you cannot do anything useful 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 300 MB. This, of course, is a lot smaller than a typical install of Windows XP Professional on the desktop (which is approximately 1,5 GB).
When building the operating system image, you get to pick and choose which hardware and software components are needed in your platform. If you do not need Windows Media Player, DCOM, RPC, Microsoft Internet Explorer, then you do not 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 is no support for real-time functionality'
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 and Interval-Zero.
3. 'The operating systems are not secure'
Windows Embedded Standard 2009 is based on Windows XP Professional Service Pack 3 - perhaps it would be good to start with the SP3 overview document?
The first thing to say here is that Windows Embedded Standard is a componentised operating system, so you get to choose which components are included in your operating system image. If you do not need networking components such as MSMQ, DCOM, RPC or others, then do not 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 an interview 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 is too hard to configure an operating system image for my needs'
Windows Embedded Standard is a componentised operating system. 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 analyses 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 individual software components on top of the hardware definition and then build the operating system.
Sounds simple, right? Why yes, it is! Tutorials can be followed 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. 'Licensing costs are too high'
Exactly when do you need to start purchasing licences for your embedded operating systems? That is 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 licence anything.
But how much do the operating system licences cost? Licensing costs for Windows Embedded Standard are straightforward. At the time of going to print, Windows Embedded Standard licences start at approximately R865* per device.
Again, note that you do not need to purchase run-time licences until you ship real products. So the cost of development is pretty low. Development tools are FREE to download from the Microsoft Embedded website and can be run for 120 days. After that, at the time of going to print, the toolkit cost is approximately R9200* per developer.
6. 'The tools are too expensive'
Okay, this is a simple one. Windows Embedded Standard evaluation tools are available as FREE downloads from the Microsoft website. Let us just spell that one more time: F-R-E-E. Once you have evaluated the operating system and tools for up to 180 days, you can then purchase the full product. At the time of going to print, the Windows Embedded Standard toolkit cost is approximately R9200* per developer.
7. 'There is no support'
There are a number of ways to get support for 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 Microsoft partners and development teams, online chats and tutorials.
8. 'There is no driver support for my hardware'
Windows Embedded Standard ships with the same set of drivers as the desktop version of Windows XP Professional; that is over 9000 drivers available as individual components for Windows Embedded Standard. The list can easily be extended through the Windows 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 catalogue 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 do not 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 provides 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 handheld terminals. Windows Embedded Standard has 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 a device that has a fully integrated shell experience is a portable navigation device.
The end user of the device does not need to see any Windows user interface, will not have access to a desktop (since there is not one), will not have access to the control panel (since there is not 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.
11. 'There are no partners to provide hardware, drivers, bootloaders or training'
Microsoft has 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 is hard to find engineers to work on my projects'
What do the .NET Framework, 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 Standard (also Desktop/Server) also exposes 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 Standard.
If your developers have managed application development experience then they can be productive on .NET Framework and Windows Embedded Standard. Plus, over six million developers worldwide 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.
13. 'It is 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 Standard.
You should also consider 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 an x86 PC, so your developers do not need embedded specific knowledge to build their device.
*Indicated pricing is subject to Arrow Altech Distribution’s terms and conditions and are subject to change. Pricing is based on an exchange rate of R8,40 per $US and excludes VAT.
For more information contact Mark Böhmer, Arrow Altech Distribution, +27 (0)11 923 9600, [email protected], www.arrow.altech.co.za
| Tel: | +27 11 923 9600 |
| Fax: | +27 11 923 9884 |
| Email: | [email protected] |
| www: | www.altronarrow.com |
| Articles: | More information and articles about Altron Arrow |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version