Embedded Systems: Windows Special Purpose


O mighty habraman and the most beautiful habravimen! An insignificant remarked that the surah of the brilliant Windows Embedded has not yet been recorded in the book of wisdom of Habr. Let me, the unworthy one, tell you one instructive story about how the specially bulletproof Windows ® ™ was built and implemented at the facilities of a Russian railway corporation.

How did we get to such a life

So, one morning, a messenger from programmers arrived in our humble abode of System Software with terrible and sad news. Truly, I tell you, programmers on a business trip could not update the software at the workplace, because it encircled the shaitan and populated it with viruses, trojans, porno-banners and counter-strike (the innocent users were sauirno nothing to do with it).

The software is an automated workstation of signaling systems, written in VC ++ 6 + MFC + WINAPI.

Our wise caliph, learning of such indecency, called a sofa. And so the court wise men and stargazers said:

Anti-virus was not installed due to the lack of Internet stations (stations are scattered across the entire surface of Russia and traveling with an offline base for updating is somehow not an option). Some stations have access to the intranet, where there is a corporate antivirus, but firstly: not at all, and secondly: the antivirus there is chthonic Symantec, old and good.

After a certain number of utilities, it was decided to replace desktop Windows with something more durable and reliable, but win32-compatible. Out of the whole mass of suitable platforms, Windows XP Embedded was chosen, as on it already there were achievements and indeed, such a cool system.

Windows XP Embedded is an embedded component operating system based on Windows XP Professional Edition and is intended for use in various embedded systems: industrial automation systems, ATMs, medical devices, cash registers, slot machines, VoIP components, etc. Windows XP Embedded includes additional embedding functions, including a write protection filter (EWF and FBWF), boot from flash memory, CD-ROM, network, using its own shell system, etc.

Currently known as Windows Embedded Standard.

Windows on steroids

We figured out what can be done with the integrated tools of the Windows Embedded IDE:
  1. disable write to disk
  2. restrict user account rights
  3. to deprive the user of the ability to run anything other than AWP
  4. close unused ports
  5. disable mounting external USB drives
  6. exclude application and system software from the system that is not required for the direct work of the workstation (Media Player, Outlook Express, Paint, Explorer, etc.)

But it's all boring and simple. The bosses were inspired by the idea of ​​modular software ™, which consists in dividing the application, system software and configuration into “modules” - FS images that combine software by functional features. The advantages of this approach:

  1. software structure becomes more streamlined
  2. more convenient software versioning system (I apologize for this miracle term, there was no better idea)
  3. increased deployment / software update speed - a large file is written faster than many small ones
  4. increasing system flexibility, for example - system software (OS) can be mounted in read-only without affecting application programs

There are no obvious minuses, it would seem - introduce and rejoice. But the fact that for QNX (originally a modular system was developed for our industrial computers) was simple and natural in Windows became a hell of a migraine and looked like an attempt to cross a sea urchin with a crane. As a result, it turned out to be implemented, but first things first.

Windows trimming

How the tasks were solved on points:
  • to block writing to disk we use EWF with data mapping in RAM

Advanced write filter - a driver that intercepts write accesses to the hard disk and buffers them depending on the settings:
  • on a specially selected hidden section
  • in RAM

In this case, real writing to the protected partition does not occur, it is performed only at the request of the user (the so-called commit), for which the kind Microsoft provides the API and the ready-made utility ewfmgr. When using a special section for buffering, the data will be saved between reboots, in the case of buffering in RAM - not.

  • create an account from the predefined Windows template - “regular user” and put it in the autologon
  • create a component of the Shell type (system shell) running the workstation as a system shell; We exclude explorer.exe from the system. A particularly ingenious user still has the ability to view the directory structure through the file save dialog in one of the workstation windows, but:
    • this is a problem for programmers (hehe)
    • do not forget about filtering records and limited account

  • because I'm not a big fan of the WHS dialect of VB, then I used the batch file pulling netsh.exe firewall
  • I did just that with extra components - I created an XP Embedded project containing only vital components (i.e., components automatically added according to the hardware dependencies + required infrastructure for workstation work)
  • disconnecting external USB-drives was performed in a barbaric way , namely, the driver for USB-drives and the installation wizard for new equipment were excluded from the system image, and the display of the new equipment wizard was disabled through the registry key when an unknown PnP device was connected (well, what if)

    The problem of disabling PnP devices can be solved in several ways (and there is also devcon ), but this one attracted me with its global nature, i.e. at the same time, any other unauthorized peripheral devices will be disabled with USB drives, but it will still be possible to replace the USB mouse / keyboard (since the driver is in the system and it contains a digital signature - such drivers are installed automatically)

Mount images

Finding software to mount images on Windows was long and painful. Only RAM-drive implementations came across, which is certainly cool, but not that. I remembered that a utility for mounting vhd files was included in the Windows Virtual Server bundle, but I could not open how to add it to my WinXP and whether it was legal at all. The project of the century was almost covered with a copper basin, I was wondering how to get off less blood and avoid developing my own driver, when suddenly a link to the excellent filedisk surfaced in Google. It works in all respects - it can mount images as logical disks (it does not know how to emulate the media, but it was not required), it is made as a driver, which makes it easy to add XP Embedded to the project, it contains a console utility for managing disks out of the box - what necessary for use in startup scripts. In general - one hundred percent hit.

The driver is installed, but where can I get the images themselves? We take dd for windows and create images of the required size from its virtual / dev / null. We connect them using filedisk, see logical disks without FS, create NTFS on them, fill them with content.

On one of the images, I placed the startup scripts that run after the logon and make some settings (setting the IP address, screen resolution, etc. from the config file). It is clear that by the time of the logon, the images should already be mounted. And then I tried a bunch of options - Schtasks , which allows you to perform a task with logon (but it didn’t always work somehow), drove the script to mount disks into services using sc - at the same time, the contents of the images were not accessible to user accounts on behalf of which it was launched application software (as an option, it would be possible to transfer tasks from scripts to a service, but scripting is somehow prettier to me than this soulless C ++). As a result, the collective farm - AutoExNtmounts before the logon, and the system configuration tasks are performed using encrypted cpau tasks on behalf of the administrator (because auto-login is performed under the normal user account). This was the first of the stably working options, and debugging by that time got me so bad that I spat on the ugliness of the method and left it as it is.

Additionally, he developed a small simple startup utility, because Explorer Shell was excluded from the project and nobody processed the author’s keys in the registry, and someone had to run the programs at the start.

On this my torment with the Windows system software basically ended, it is time to think about how all this crap will be installed on the target machine.


Windows XP Embedded does not contain tools for partitioning and formatting a drive, unlike regular Windows XP. Those. XPe installation consists of copying the project directory structure to the root of the partition formatted in FAT32 / NTFS and marked as active (the boot flag is set). The XPe package includes a WinPE disk, which contains the necessary tools for partitioning, but the scenarios for using this disk are rather vague (for example, it cannot be used as a recovery disk). Praising to myself such a concern for users, I decided not to mess with Microsoft products at all to deploy XPe (although there seems to be a free Windows AIK, but from previous experience trying to figure out the licensing restrictions of Microsoft products, it was decided to look for something on the side).

I decided to try my luck with GNU / Linux, because The ntfs-3g driver has been stable for quite some time and worked for itself (and, by the way, in rather strange places - according to Realtek, in the SDK for their multimedia platforms it is used as the default file system for external drives). I took the Ubuntu LTS Live-CD, cleaned it of the logos and mention of Ubuntu (for Canonical puts forward such requirements for a deep modification of the system) and began to customize. The choice of distribution was determined by personal preferences.

The first version of the deployment environment was a bash script that communicated with the user using zenity. Simple and tasteful. Was rejected as not sufficiently divine in terms of UI.

The second version was written in Mono (C # - the corporate standard) and contained almost all the graphic elements of GTK. The High Commission noted that the UI is still not divine enough, but still viable.

The installation procedure itself consisted of calling external utilities - parted for markup, mkfs.ntfs from the ntfsprogs package (ntfstools) to create the FS, and rsync to copy data from the installation media.

Next, reboot and go directly to the deployment of Windows Embedded.


Now Windows XP Embedded (Windows Embedded Standard 2009) is rapidly losing relevance (although support will continue until 2015) - it was replaced by Windows Embedded 7, which is much, much, much more convenient than XPe, but my colleague is developing it using it, I He described (as he could, hehe) his own experience. I hope someone finds something useful in this collection of bad tips.

In conclusion, I’ll list some useful resources for Windows Embedded:

  • First of all, this is of course a thematic section on MSDN
  • Russian-language forum of the company "Quart" - the official supplier of Windows Embedded in Russia. Probably the only major Russian-language resource on Windows Embedded.
  • There was also an excellent repository of user scripts and components xpefiles.com, but something bad happened to it.

Also popular now: