The first Windows Embedded Standard (WES) was actually a rebranding of XP Embedded incorporating Service Pack 3, its USP componentized into more than 10,000 discrete parts. WES 2009 enabled vastly cut-down versions of the retail XP Professional, the desktop/laptop flavor these days trading as Enterprise.

Back in the days when flash was restrictively expensive per megabyte, there was significant value in trimming superfluous OS functions to facilitate productionized products using the capacity below. Consequently, the potential unit cost savings were huge. However, the benefit of this approach wasn’t borne only from storage savings; compared to today, the relatively “creaky” embedded CPUs of old had limited processing capacity themselves and little RAM to play around with. Naturally, when processing capacity is limited, one did not want a large proportion of their CPU and memory bandwidth occupied by background services unused within their embedded application. At the time, Windows Embedded Standard was groundbreaking.

These benefits came at a price. The boggling number of components combined with the need to integrate applications designed purely for the standard XP Professional meant WES image developers spent most of their time investigating and resolving dependency issues. A single file that hadn’t been included in an image often was the difference between applications functioning perfectly or not at all. This left a sour taste in the mouths of many software developers who’d been sold the simplicity and tasked with the image creation.

The next WES version derived from Windows 7 Enterprise was WES 7. This addressed the needlessly excessive componentization, grouping common components and their dependencies into more easily digestible feature packs and adding a new design template Application Compatibility, which included all those painfully elusive typical application dependencies for you.

The strong embedded-enabling features – particularly write filters that are critical for embedded devices where ensuring proper shutdowns is laughable and the consequences of a corrupted OS through improper shutdowns or a malicious user – are unthinkable. After the launch of Windows 8, WES 8 quickly followed suit and adhered to the same mantra as WES 7, albeit causing frustration of its own by defaulting the new Metro interface, which many embedded systems with sub-XGA displays couldn’t actually support.

Today, I can’t help but sense that same sour taste from the WES 2009 days. Daily I hear about system developers shunning WES, afraid of application compatibility issues and feeling “safer” with Windows Enterprise. This happens despite the reality being that without the embedded-enabling features of WES, their OS deployment is far from safe and at any time could descend into system recovery mode, where it may or may not be able to fix itself. Part of this decision is that the old argument of reducing storage capacity needs no longer applies; the smallest available capacities of SSDs invariably exceed the storage requirements of even the Windows Enterprise version. CPU processing and RAM capacity is similarly magnitudes higher than the OS can possibly require, so it’s erroneously perceived that the previous need for WES has gone, too.

With the introduction of Windows 10, it seems the embedded variant has vanished completely. Yes, the CPU, RAM, and storage needs no longer require consideration, and yes, the embedded-enabling features are now being offered through the Enterprise version. However, it appears Microsoft forgot something: the Windows Embedded Standard licenses of previous versions offered around a 60 percent reduction in cost to recognize their embedded, single-use applications – no sign of that yet! Look out for my upcoming piece investigating the future viability of Window Enterprise-derived OSs in our industry.