Game over for Windows CE6 support
Why should you care about April 10, 2018? Is it really the end of Windows CE6 support?
If you are an OEM which has been developing embedded devices over the past 15 years, you might have considered using Windows CE / Windows Embedded Compact a few years ago.
Even though Windows Embedded Compact is now a declining technology, since Microsoft stopped investing in the technology a few years ago (no new release since 2013), Windows CE used to have a prominent market share some years before, thanks to a very aggressive pricing policy. The “$3 CORE License”, marked the “Golden age” of Windows CE.
Now why does it make the date of April 10, 2018 so important (of course beside the discovery of four new exoplanets)?
On that date, the “Extended support period” of Windows Embedded CE 6.0 ended, which basically means that the OS is no longer supported or maintained.
Windows Embedded CE 6.0 was released to market in November 2006 and is the most recent version of Windows CE for which the “CORE license” was available. With the release of Windows Embedded Compact 7 in March 2011, Microsoft stopped making this ''low cost license'' available. Therefore, most of the embedded devices developed with Windows CE 6.0 (or earlier) did not migrate to WEC7 (or WEC2013), and even new product designs continued being developed with Windows Embedded CE 6.0 till the end of the “Standard support” period in April 2013, even though the new versions Windows Embedded Compact 7 or 2013 were available.
There is a lot of contradictory information circulating online regarding the End of Support, End of Extended Support, and End of License dates; the information below is intended to bring some clarity to this situation. The majority of this information is sourced directly from Microsoft, with End of License dates sourced from Advantech.
So what’s the difference between Mainstream Support, Extended Support and End of License? Mainstream support includes: requests to change product design and features, security updates, non-security updates. Extended support includes security updates and limited non-security updates. End of License is the date from which runtime licenses can no longer be shipped.
|Products||Life Cycle Start Date||Mainstream Support End Date||Extended Support End Date||End of License Date|
|Windows Embedded CE 6.0||30/11/2006||09/04/2013||10/04/2018||28/02/2022|
|Windows Embedded Compact 7||15/03/2011||12/04/2016||13/04/2021||28/02/2026|
|Windows Embedded Compact 2013||11/08/2013||09/10/2018||10/10/2023||31/05/2028|
Today, there are still thousands of devices on the market based on Windows CE 6.0, still using a “CORE License”, and an urgent need for the Device makers to find a migration path, with a very strong business impact.
No more Wince 6 support, what’s next?
So what are the possible options?
It depends on the market availability planned for these devices. The easiest (and likely most effective path) would be to stay with Windows Embedded technologies and migrate to Windows Embedded Compact 7 or 2013. This solution allows most of the application stack to be kept “as is”, as .NET or Win32 applications developed on Windows CE 6.0 are mostly compatible with the more recent releases. It has some restrictions, however:
Windows Embedded Compact 7 will reach its end of “Extended support period” in April 2021. Therefore, any plan to keep devices on the market beyond 2021 would make the choice of Windows Embedded Compact 7 a case of “pushing forward the problem”
Similarly, Windows Embedded Compact 2013 will reach end of “Standard support period” in a few months (October 2018) and the “Extended support period” will end 5 years later, in October 2023.
- One might think the best option is to go straight to WEC2013, to gain as much time as possible before the next blow… but we must keep in mind that with WEC2013, Microsoft removed the support for any ARM architecture before ARMv7. Thus, it is very likely that the hardware architecture of the device would not be compatible with WEC2013 which would imply a significant hardware redesign
Alternatively, one might consider the migration to completely different Operating Systems. This approach represents a better long-term decision as it allows moving out of the soon to come obsolescence of WEC technologies. With this solution, the main stake relates to the migration of the application layers, which might require significant rewriting. However, there are solutions on the market which can help with “minimizing the pain”.
From an OS standpoint, the following solutions can be considered
Windows 10 IOT Core:
Even though it might seem to be the natural path to proceed, migrating to Windows 10 IoT Core could be more challenging than it seems.
First, the upward compatibility of the application framework is very limited. More specifically, Windows 10 IoT Core application support is limited to UWP, which supports only a subset of the .NET Framework. Therefore, application migration from Windows CE / Windows Embedded Compact to Windows 10 IoT Core might be as challenging as to any non-Microsoft OS
In addition, Windows 10 IoT Core is much less flexible than Windows CE for adaptation to custom hardware, and the number of pre-existing hardware platform supported is very limited, which implies OS porting will be complex, or even a need for Hardware redesign
Finally, Microsoft long-term plan about Windows 10 IoT Core is unclear, and even though Microsoft announced a 10-year support commitment, there is always the same risk as with Windows Embedded Compact beyond this committed timeline
Linux or Android
These are probably the best choice considering the current market adoption and the level of support available from the embedded community. There is an extensive number of hardware platforms and architectures supported and full flexibility for OS porting and customization, which allows smooth and efficient OS migration, with probably no risk of HW incompatibility. The current level of market adoption along with the current organization of the open source community allows for a high level of confidence regarding the longevity of the technology. The most challenging part relates to the application migration, but for which there are possible solutions as detailed later on in this article.
If the Realtime capabilities of Windows CE are used in the context of the existing devices, RTOS solutions like QNX or Greenhills Integrity might be considered. However, in these cases, there is a very high probability of complete redevelopment of the application due to limited compatibilities between the application framework. An alternate solution in such cases is to consider using Linux RealTime extensions such as Xenomai or RTLinux.
Beside the OS selection and migration, the main stake in such a migration scenario relates to the Application Framework. Fortunately, there are existing solutions on the market to avoid the need for full redevelopment. We will mention two of them here:
- This framework allows executing .NET applications on non-Microsoft environments. Mono is the open source version targeting primarily Linux based environments while Xamarin is a commercial solution focused on Android (or even iOS). This framework allows cross-platform compatibility and is a good way to minimize the migration effort as most of the pre-existing .NET applications running on Windows CE would execute in a Linux or Android environment. However, it might not be a good fit when there are performances challenges, since it obviously introduces an additional intermediate layer that will impact the overall system performance
This application framework has significant market traction for embedded applications and is probably one of the best solutions on the market for cross-platform interoperability. Using Qt would likely imply some significant redevelopment of an existing .NET application. However, its compatibility with multiple OS architectures such as Linux, Android, QNX, Windows and Windows CE allows having an iterative approach with some potential parallelization of the efforts:
As a first step the existing .Net application can be migrated to Qt to execute on the existing Windows CE based device, which allows validating the solution and removing all risk before moving forward with the complete OS migration.
Then, the device can be migrated itself to Linux, Android, QNX or any Operating System with support for Qt. Thanks to its cross-platform interoperability, the same Qt application running on the Windows CE-based device would run with the new OS. This solution is also a good possibility when considering migrating first the device to Windows Embedded Compact 7, and later on to another OS, as the Qt-based application will be compatible with all the different OS technologies.
As a matter of conclusion, An Embedded Software migration project is never a simple and straightforward activity and requires having a holistic approach from the hardware up to the upper application layers, to ensure the architecture and choices of technologies are made with a complete system view and even a good understanding of the market and technology trends. Such migration might represent significant investments in the redesign, and therefore should be well thought through to avoid facing the same issues again a few years later.