Whilst originally producing Windows Embedded Operating System images for their customers to evaluate the capabilities of, it soon became apparent that the desire to heavily customise the Operating System was not there for every customer – the result being that customers favoured utilising what was initially designed to be an evaluation platform as their production image!
As Windows Embedded Standard (WES), consisting of XP Embedded and WES 2009, are easily retrospectively customisable, customers were looking to DSL to provide an essentially one-size-fits-all image that saves them the costs associated with development tools, learning curves for training employees and the administration of deploying images and purchasing licenses as part of the production process.
As embedded computers are designed to be just that, once a system is deployed and in use by an end user, it is barely recognisable as a PC. Whilst everyone knows that PCs should be shutdown rather than just turned off to avoid disk corruption, either due to an inaccessible shutdown option, or the end user not even realising the risk still exists – embedded systems often experience power being cut without prior warning.
A huge advantage for industrial rugged systems is WES’ ability to use flash memory. Whilst flash memory is enormously beneficial due to its non-mechanical nature in a system exposed to shock and vibration, its downside is the comparatively limited number of read/write cycles in its lifetime compared to a mechanical Hard Drive.
Thankfully WES considers both potential pitfalls of the hardware platforms it is designed to run on. The solution? Write filters that divert storage device writes to volatile RAM, whilst fully emulating normal processes such that no software modification is required.
Advantages:
– Hugely increases the lifetime of flash memory, necessitating storage medium writes only during initial booting phase
– Permits sudden power outage, original files (critically also registry files, those most prone to cause BSOD errors when corrupted) left intact, all writes occur in RAM. Allows system to be truly embedded and not need to be treated as a PC at all.
– Protects against malicious end users making configuration changes – any changes made to the registry (or any part of the disk) are all stored in volatile RAM, so once reset the system defaults back to its original state.
– Protects against viruses – any malicious software inadvertently installed will not survive a reboot.
– Permits booting from read only media – allows hardware protected ‘read only’ devices, including CD or DVD media to be used to store an OS, the latter offering multi-layer read only protection.
– Permits booting from previously non-OS friendly media – even USB drives can be used to reliable run a WES operating system long term.
Disadvantages
– Does not persist changes through a reboot – Interestingly which in some cases can be a major advantage, this becomes a disadvantage in the following situations
– An administrator or field engineer wishes to make configuration changes locally to an embedded system, or their own Client software.
– Client software wishes to log activity within log files.
– Clients wish to update their software either locally or remotely
Thankfully these common situations were also considered well in advance, WES’ write filters circumvent these potential pitfalls via a number of means to provide a ‘best of both worlds’ environment.
Multiple types of write filters
Both types of write filter offer distinct advantages, the earlier EWF (Enhanced Write Filter) now have been superseded by the highly configurable FBWF (File Based Write Filter). The fundamental difference being EWF is concerned with protecting entire drives & volumes, FBWF is concerned with folders and files.
EWF
Offers all of the advantages listed above, though what it cannot do is allow some paths to be protected against writes and others not (to allow log files, etc). For read only media (such as a CD-ROM) EWF is the most suitable.
FBWF
Controlling at file/folder level allows every single file or directory on the device to be either read only, or not – permitting log file directories, software configuration changes, etc).
Both types of write filter can be temporarily disabled during development to persist changes, but as this requires a complete reboot it is not recommended that this method is used to service field production units, as the system is left exposed.
For details of how to configure the FBWF that DSL pre-installs, please see our Frequently Asked Questions
The main purpose of write filters is to protect the vulnerable registry, note by default the registry is not protected. Execute “FBWFMGR /removeexclusion C: \regfdata” to protect the registry – whilst it is disabled of course!
DUA
Device Update Agent allows remote updating of client software and configuration that operates securely but within the restraints of the write filter setup. This circumvents the issue that any updated software would not persist through a reboot, yet doesn’t require the directory it is stored in to be exposed as allowing writes.
HORM
Hibernate Once, Resume Many function allows an embedded system to boot significantly quicker (as a desktop PC would resume from hibernation) and offers an almost ‘instant’ on experience. This also means the end user does not see the booting process thus is able to recognise it as a PC based device at all. Note EWF is required, FBWF is not supported.
