29 Mar 2018
Key considerations for Windows Embedded End of Life
Graeme Wintle, Director, ByteSnap Design looks at the important question of managing Windows end-of-life scenarios
With end of life dates looming, many Windows Embedded developers are examining migration options for devices running on legacy Windows CE or Mobile OS.
Here we survey the “landscape” and examine options; while explaining how technically challenging migration projects can be.
For device manufacturers and software developers, there are several key dates in the platforms’ product lifecycles when ‘mainstream’ and ‘extended’ support ends.
Windows CE End of Life Support Phases
After an OS enters the extended support phase, no patches will be applied, unless security related. Critically, after the extended support phase no patches are applied, security or functional.
Many Microsoft customers can choose to migrate to the next version of Windows Embedded Compact or to another OS/platform as the dates approach. This decision can be influenced by the current hardware platform and the type and amount of supporting application software.
Some customers require ongoing security patches to support product sales, including devices in the banking and medical sectors; whilst others are looking for the next generation platform. Clearly, any development will need support during the design phase and throughout the product lifecycle, so selecting a platform with longevity is important.
CE5.0 and CE6.0 hardware resources are similar; CE7.0 offered larger images and higher RAM usage. Consequently, migrating to the next version of the OS may not be viable on the current hardware platform. The effort to port, test and re-validate the platform to extend product life for a few years can be a painful process.
Also amongst your upgrade considerations is the operating system. Windows CE has been superseded by Windows IOT which has limited platform compatibility; the other two main contenders are Linux and Android. Android better serves multipurpose devices, leaving Linux as the main choice for a single purpose embedded device.
OS Migration: Developing your legacy Windows CE environment for the future
For those from a Microsoft Embedded background, the move to using Linux can be a path that isn’t necessarily clear.
There are choices from the build system, kernel and many others through to the way applications are launched on start-up. Windows Embedded had a considerable number of features but pales in comparison to the configurability of Embedded Linux.
However, the main core pieces in the OS remain the same for both systems: bootloader, kernel and filesystem:
Windows CE wraps the kernel and filesystem together into an NK.BIN file, whereas Linux splits these into a kernel file and a root filing system (all the user level drivers, applications and features). From a conceptual level this is fairly similar.
Linux gives a much greater level of flexibility with uboot having native support to read and write FAT partitions; systems can leverage multiple kernels, configuration files and splash screens without allocating blocks of reserved flash for each purpose - commonplace in CE.
The first choice on the OS (after CPU selection) is the development tool. Typically, Yocto is used to build the OS components, drivers and system configuration. It gives a great level of control and the creation of smaller targeted Linux builds.
Like Windows CE, the Linux system can have a very simple bootloader or perform complex tasks prior to launching the kernel. uboot in Linux offers much more out of the box support than eboot normally included from WinCE. This includes partitioning to support storage of splash screens and kernel images, network support for debug and boot support through to security features such secure boot for hardware signing. uboot can be customised to support multiple kernel images for redundancy - a great addition if you have the available storage space.
Also akin to Windows CE, Linux has a file system with all configured applications included. These are in a separate file system compared with the NK.BIN. This allows changing of files which are core to the system.
How to partition Embedded Linux
We’d recommend a number of partitions to separate the root file system from user data; in this way, these partitions can be erased without changing system files.
Another approach is dual filesystems; this allows running from an ‘active’ bank whilst updating a second ‘inactive’ partition. On a successful update, the banks can be switched to allow booting from the new image. Any failure in the update process will not leave the system in a broken state. As the updates can be 10-100s MB in size, this is a very useful feature to implement.
Unlike Windows CE, which builds some sources and links to the binary libraries from Microsoft, the Linux system compiles everything - kernel, drivers and application - from source. Building and debugging in a smart way is vital to cut down wait times. Having the right build tools is also essential.
At ByteSnap, we employ build servers with shared iSCSI NAS racks, moving customer VMs between servers to even loads. Using a 24 core Xeon with a 48Gb RAM disk for building can build a typical Yocto release in 30-45 minutes. On a laptop, this could take 24hrs.
OS development should also focus on revision control to track changes. Due to the large number of source files in a BSP, the remote repositories used to build a Linux BSP can be unreliable. It’s crucial to have a cache of these so that a build can be reproduced for a customer. We deploy a warehouse system to cache remote downloads, so that any build released to customers can be reproduced with all packages even if some cloud servers are unavailable or a bunch of code is updated to a new version.
How to Migrate Windows CE to a new Embedded Linux or Android environment
The natural migration for Windows Handheld users is to an Android platform. Android has a strong set of development tools and with substantial built-in support for features. Applications can be built quickly and efficiently; it may be that the new application is simply a clean development including all the features of the new product.
If the application is particularly large, there are options to include code, Android although normally written in Java can be interfaced with C/C++ code (using the NDK – Native Development Kit). Microsoft also offers Xamarin in Visual Studio, allowing developers to compile C# for Android and targeting multiple platforms. Each of these approaches has positives and negatives, from features through to implementation times, retesting and validation etc.
Windows CE platforms are typically custom single purpose embedded devices, as opposed to off the shelf Windows Handheld devices. Migration is likely to embedded Linux; again, the OS will be targeted to the device - removing all unnecessary elements to make a clean, lean deployed OS.
Features such as security, firmware updates, and custom drivers will be implemented in the OS. Porting a Windows CE CPP application to this environment maybe a little daunting. Graphical frameworks such as QT offer some great support porting across platforms, but can be considerably heavy weight.
A Simple Graphical OpenGL Framework: SnapUI
At ByteSnap, we employed the approach of writing our own very light weight OpenGL framework, “SnapUI”. This uses familiar objects - such as text boxes, icons, scroll bars - described in an XML description file. Then implementing native CPP objects to render these graphical objects using the hardware accelerated OpenGL of the CPU. This allows quick and easy prototyping and movement to product quality applications, ensuring all graphics are hardware assisted and not software rendered.
Even when targeting Linux on your device, you can use Windows development machines and Visual-Studio if your team is most comfortable with these. VisualGDB is a tool which enables you to cross compile on a build machine. This may be a server in the back room, the tool chain on the PC or even the embedded device itself. Visual-Studio is used as an editor and build manager, pushing source files to the build device, building, deploying the executable, setting breakpoints, inspecting variables and all the other features you’d expect from an IDE.
Page 1 of 1
About the author
Graeme Wintle is a Founder Director at ByteSnap Design, an award-winning electronics design consultancy in the UK. After graduating in Software Engineering from Newcastle University, Graeme quickly distinguished himself at Nokia, GST Technology and Intrinsyc. He has twenty years of experience working in embedded software development across several verticals, including IoT, Energy, AV, Industrial and FinTech. Graeme is the brains behind SnapUI, a lightweight user interface development framework, used to accelerate and optimise product development.
ByteSnap has dedicated application engineers with experience porting and writing application from the ground up on Linux, Android and Windows. They can advise on the best approach to get the most from your embedded platform, see http://www.bytesnap.co.uk/software-development/ for more details or call ByteSnap Design on +44 121 222 5433.
Most popular articles in Processing & embedded
Share this page
Want more like this? Register for our newsletter