Czech Technical Univerzity Prague

Faculty of Nuclear Sciences and Physical Engineering

Department of Physical Electronics

Programme: Instruments and Informatics

Use of Embedded PC with Windows XP Embeddedfor Experiment Control on DPE

Bakalá°ská práce

Author: Pavel Pokorný

Project leader: Ing. Pavel Jirou²ek, CSc.

Consultant: Ing. Josef Blaºej, PhD.

Year: 2011

P°ed svázáním místo téhle stránky vloºíte zadání práce s podpisem d¥kana (bude to jediný

oboustranný list ve Va²í práci) !!!!

Declaration

I hereby declare that this thesis is my own work and that, to the best of my knowledge and

belief, it contains only material where due acknowledgment has been made in the text.

In Prague ............................................................

Pavel Pokorný

Acknowledgments

I would like to thank Department of Physical Electronics, especially Prof. Ing. Ivan Procházka,

DrSc., and Ing. Pavel Jirou²ek, CSc. for providing all needed hardware and software, that allowed

succesfull realization of this project.

Pavel Pokorný

Contents

1 Introduction 7

2 Description of Windows XP Embedded 9

2.1 Relation of Windows XP Embedded to Windows XP Professional . . . . . . . . . . 9

2.2 Embedded Enabling Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Architecture of Windows XP Embedded . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 Component Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.3 Con�gurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.4 Run-time image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Tools for development of Windows XP Embedded . . . . . . . . . . . . . . . . . . 12

2.4.1 Component Database Manager . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Component Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3 Target Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Advantages of Windows XP Embedded for industrial applications . . . . . . . . . . 15

3 Comparison of Windows XP Embedded with other operating systems 16

3.1 Windows CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 .NET Micro Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 FreeBSD (TinyBSD, NanoBSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 GNU/Linux distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Development of Windows XP Embedded image 18

4.1 Identi�cation of Target Device Hardware . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Authoring Components and Customizing Shells . . . . . . . . . . . . . . . . . . . . 21

4.3 Design of Run-Time Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4 Security Features of a Run-Time Image . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 Deployment of a Run-Time Image . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6 Management and Servicing a Run-Time Image . . . . . . . . . . . . . . . . . . . . 23

5 Description of Debian Live 25

5.1 Relation of Debian Live, Debian and GNU/Linux . . . . . . . . . . . . . . . . . . . 25

5.2 Persistence of user data and/or changes to �lesystem . . . . . . . . . . . . . . . . . 26

5.2.1 Full persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2 Home automounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.3 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Tools for development of Debian Live image . . . . . . . . . . . . . . . . . . . . . . 27

5.3.1 The live-build package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.2 The live-boot package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.3 The live-con�g package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Development of Debian-based image 28

6.1 Create base Live system con�guration . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Customize con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3 Build the resulting �le-system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.4 Deploy the resulting �le-system and bootloader to the target medium . . . . . . . 30

7 Comparison of Windows XP Embedded and Debian Live 31

7.1 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2 Build process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.3 Build tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.4 Deployment of a Run-time Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.5 Embedded Enabling Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8 Evaluation of properties of built device 33

9 Conclusion 34

Bibliography 35

Chapter 1

Introduction

Nowadays, computers are used for more than just calculations. They are used as embedded control

system for many various devices from dishwashers and refrigerators, ATMs, to lathes. The range

of controlled devices is vast and developers must choose suitable means for building given device

considering resource restrictions, requested user interface etc. Many devices require to be pro-

grammed speci�cally for their task using only assembler or some low-level language like C. On the

other hand, some devices require some services (like networking, �le sharing, remote management,

graphical output) that are di�cult and expensive to develop. In this case, we can use operating

system that will provide these services and integrate our application(s) into this system.

Some examples of operating systems for embedded devices are: Embedded Linux, QNX, Win-

dows XP Embedded, Windows CE. [20] This is only small excerpt of available embedded operating

systems.

This thesis is focused on development of Microsoft Windows XP Embedded image for computer

that will provide services for experiment control on Department of Physical Electronics. The

indended purpose of this computer is to provide network access for printer (currently shared via an

outdated computer), allow monitoring of the lab using installed webcam and to provide platform

for running long term data collection. To decrease the chance of failure and to reduce maintenance

requirements, the image is being developed using Windows XP Embedded.

The goals of the project are following:

1. Describe Windows XP Embedded, their properties, development tools and advantages for

use for control application.

2. Compare Windows XP Embedded with other operating systems.

3. Create components for applications required for experiment control conducted on Department

of Physical Engineering.

4. Evaluate properties of built device with respect to functionality, stability and security.

The thesis outline is following:

Chapter two describes Windows XP Embedded in general and their advantages for industrial

control.

Chapter three compares Windows XP Embedded with other available embedded platforms.

Chapter four is dedicated to description of development process of run-time image for Depart-

ment of Physical Electronics Embedded PC including detailed description of included applications.

Chapter �ve describes the possible Windows XP Embedded alternative, �Debian Live�.

7

Chapter six summarizes development process of Debian image using Debian Live toolchain.

Chapter seven compares properties of Windows XP Embedded and Debian Live.

Chapter eight evaluates properties of built device with respect to functionality, stability and

security.

8

Chapter 2

Description of Windows XP

Embedded

Windows XP Embedded is an operating system and development platform in componentized form,

designed to build more advanced smart, connected, and service-oriented embedded devices. [11]

Windows XP Embedded provides the same Win32 API as Windows XP Professional. However,

developers can choose which parts of operating system, and thus which API, will be present on

target device. This selection allows reduction of size of run-time image to meet restricted device

resources. Also removal of unneeded components leads to increased system stability and security.

Windows XP Embedded provides some features speci�cally designed to support embedded devices.

2.1 Relation of Windows XP Embedded to Windows XP Pro-

fessional

Windows XP Embedded are basically componentized form of Windows XP Professional. That

means that all parts (kernel, drivers, system services) are divided into small blocks that are formed

of �les, registry data and meta-data needed for build process.

Greatest di�erence is in the intended target costumer. Windows XP Professional are targeted

at o�ce customers that will use various programs for work and entertainment. Windows XP

Embedded are targeted to applications, where device running Windows XP Embedded will provide

only single function. This division is not only formal, but also enforced by Microsoft license

agreement for Windows XP Embedded, that states that:

Embedded systems may use a ROM-based operating system or they may use a disk-based

system, like a PC. But an embedded system cannot be used as a commercially viable substitute

for multipurpose computers or devices.

This limits the use of o�ce automation/personal computing functions (e-mail, word processing,

spreadsheets, database, network browsing, scheduling, and personal �nance) permitted with the

particular embedded licensed product.

Windows XP Embedded is licensed for devices that perform O�ce Automation and Personal

Computing Functions only to the extent that the O�ce Automation and Personal Computing

Functions: (i) directly support the operation of, and are an integral part of, the Embedded Appli-

cation (de�ned below); and (ii) operate only when used with the Embedded Application (that is,

the O�ce Automation and Personal Computing Functions shall only permit creation, play, display,

9

or communication of content that is directly related to the commercial or industrial processes or

tasks that the device is speci�cally designed to address).

An �Embedded Application� means industry- or task-speci�c software programs and/or func-

tionality that provide the primary functionality of the device and which o�er signi�cant function-

ality in addition to Windows XP Embedded.[12]

2.2 Embedded Enabling Features

Because embedded devices are often designed to run for long time without intervention from

system administrator, it is necessary to provide stable and secure experience. This is allowed by

protecting device from unwanted changes. Protection can be made on storage media level with

Enhanced Write Filter or �le-system level with File-based Write Filter. Both of these �lters store

changes made to protected area to RAM or dedicated partition of hard-drive. When the device is

rebooted, all changes are reverted, unless administrator gives the command to commit changes to

underlying media.

Enhanced Write Filter also allows to run the system from non-writable media, like CD-ROM

or DVD-ROM, while simulating writability by redirecting writes to RAM. Enhanced write �lter

also provides simple way how to reduce the wear on Compact Flash device.

Other embedded enabling features include option to boot target device from USB Device or

over network, and automated message box interceptions to prevent applications from being blocked

while waiting for user response.

Support for network boot allows customer to manage all images for devices using central server.

Also the devices can have simpler hardware, because they do not need any kind of non-volatile

storage media, except for �ash memory for BIOS.

USB Boot feature can be used in similar way as network boot. All USB Thumb Drives can be

managed in one place and distributed as required, thus administrators does not have to visit every

device locally to maintain run-time image.

2.3 Architecture of Windows XP Embedded

The following �gure shows relation of di�erent parts and tools of Windows XP Embedded, that

will be described later in following sections.

10

Files

Registry

Metadata

Component

Component

Files

Registry

Metadata

ComponentDB

ComponentDesigner

FileRepository

Component DatabaseManager

TargetDesigner

Configuration

Configuration

Run-time image

Run-time image

Figure 2.1: Structure of Windows XP Embedded

2.3.1 Components

As mentioned before, basic building blocks of Windows XP Embedded are components.

Components are the self-contained units of functionality that, when combined, describe all of the

features of a run-time image. Components can include core and extended properties, resources such

as �les and registry keys, scripts, group memberships, component help, and a list of dependencies

upon other components. Every component designates a repository or repositories, from which its

�les can be copied at build time, and a prototype component from which it inherits properties and

resources. Components are saved in .sld �les and imported into the component database.

Components are intended to be as small as possible. Depending on the requirements of your

embedded scenario, a simple component might set one registry key, and a complex component

might describe an entire feature such as Internet Explorer. Typically, components are used to

de�ne applications, services, and device drivers.[8]

2.3.2 Component Database

All components, along with groups, repositories and other information are stored using Microsoft

SQL Database Server. This allows simple sharing of single database among many developers, who

can focus on their work and do not have to care about synchronization of data between them.

Storing data in database also allows versioning of components and in result repeatable build.

Repeatability of build is very important for costumer support because it allows support personnel

to recreate environment exactly matching customers device.

2.3.3 Con�gurations

When designing image for target device, components required for given task are put together into

con�guration. A con�guration is the set of components and resources that fully describes a speci�c

run-time image. Each con�guration is authored against the Windows XP Embedded Client (x86) -

US English platform, which de�nes the type of run-time image that the con�guration can generate.

A con�guration is composed of the following items of information [9]:

� A set of con�guration properties.

11

� A list of component instances that de�ne individual components that have been included in

the con�guration. This includes the base component that de�nes the minimum functionality

required by the platform.

� A list of con�guration-level �les that will be copied to the run-time image when the con�g-

uration is built.

� A list of con�guration-level registry keys that will be created in the run-time image registry

when the con�guration is built.

� A list of custom resources that will be added to the run-time image.

� A block of script obtained from the platform de�nition.

2.3.4 Run-time image

Run-time image is compilation of �les and registry data, that is created based on con�guration.

This image is deployed to target device, where installation is �nalized with First Boot Agent

(FBA). FBA con�gures hardware drivers and performs tasks that are not possible during image

build on developer computer.

2.4 Tools for development of Windows XP Embedded

2.4.1 Component Database Manager

Microsoft®Windows XP Embedded Component Database Manager is used to select and manage

the component database and repositories. The component database contains the components that

make up the Windows XP Embedded operating system (OS) as well as any custom components

that have been added. Repositories are collections of �les that are available for copying to a

run-time image during the build process.[4]

12

Figure 2.2: Screenshot of Component Database Manager

2.4.2 Component Designer

Microsoft® Windows XP Embedded Component Designer is used to create and modify custom

components and any associated repositories, packages, dependency groups, and repository sets.

These objects are saved in component de�nition (.sld) �les, imported into the component database,

and used in con�gurations.[5]

13

Figure 2.3: Screenshot of Component Designer

2.4.3 Target Designer

Windows XP Embedded Target Designer is used to create and modify a con�guration and build

it into a run-time image. With Windows XP Embedded Target Designer you can add components

and resources to a con�guration, modify various properties of the components and resources that

you add, modify properties of the con�guration itself, check component dependencies to ensure that

necessary components are included in the con�guration and estimate the footprint of a run-time

image before building it.[6]

14

Figure 2.4: Screenshot of Target Designer

2.5 Advantages of Windows XP Embedded for industrial ap-

plications

There are several advantages of using Windows XP Embedded over other non-embedded versions

of Windows operating system.

First advantage is that the run-time image can contain only components needed for given ap-

plication(s). Exclusion of unnecessary components reduces possible collisions and removes possible

points of failure.

Second advantage is reduced footprint that is achieved using components. Reduced footprint

allows to use smaller storage media, e.g. Compact Flash cards or Solid State Disks. The reduced

number of included components also reduces memory and processor requirements, because of lower

computational overhead caused by unnecessary services otherwise included in Windows.

Third advantage are embedded enabling features that allows the device to be restored to the

given state set up by vendor. This enables stable user experience and helps the vendor to reproduce

problems, because of the known state of device.

15

Chapter 3

Comparison of Windows XP

Embedded with other operating

systems

There is a large number of embedded operating systems available in the world. Many of these

systems are designed for particular class of devices, e.g. cell phones, or are provided by vendors

with their hardware and are not available for general use. The comparison focuses on few generally

available embedded operating systems. The comparison is mostly based on available documentation

and other online resources.

3.1 Windows CE1

Windows Embedded CE is a componentized, real-time operating system to deliver compelling

experiences on a wide range of small footprint consumer and enterprise devices.[14]

The use of Windows CE was found by the author unfeasible, mainly because the computer

manufacturer does not provide the required drivers compatible with Windows CE. The requirement

of the drivers stands from the fact, that although the OS is called Windows (CE), it is not related

to any of the versions of Windows found in common computers. The drivers and applications must

be compiled speci�cally for Windows CE.

3.2 .NET Micro Framework2

The .NETMicro Framework is .NET for small and resource constrained devices. It o�ers a complete

and innovative development and execution environment that brings the productivity of modern

computing tools to this class of devices.[13]

The .NET Micro Framework is not in fact suited for this kind of device. The primary targeting

are simple, much smaller (much more embedded) devices. Because of completely di�erent system

architecture, development of .NET Micro Framework device that would satisfy the speci�ed re-

quirements is would require to create all the applications from scratch. Because of time constrain

the author has decided to abandon use of .NET Micro Framework.

1http://msdn.microsoft.com/en-us/windowsembedded/ce/default.aspx2http://www.microsoft.com/netmf/default.mspx

16

3.3 FreeBSD (TinyBSD3, NanoBSD4)

TinyBSD is a set of tools made up of shell scripts designed to allow easy development of Embedded

Systems based on FreeBSD.[3] The author has analyzed the build process used by NanoBSD script

and determined that the process is very similar to the build process of Linux distribution based

image. The use of NanoBSD (or any other embedded variant of BSD system) is most likely feasible.

The possible problem with BDS-based image is missing driver for the web camera.

3.4 GNU/Linux distribution

The implementation of a GNU/Linux distribution for this device can be easily achieved if it is

possible to create a Live CD for such distribution, optionally with persistence. The Live CD

generally requires that the system is loaded from a read-only media and (if the persistence is not

implemented) it has no swap area and no other writable storage except from the computer RAM.

The implementation of the persistence mechanism must be analyzed in terms of frequency and

volume of writes to the underlying media. For example, the Casper persistence, implemented in

Ubuntu, uses a dedicated partition or �le for storing data, but this area is constantly under pressure

from writes. Therefor it is not suitable for the long-term use with Compact Flash card.

As an example of GNU/Linux distribution that can be used for this particular task is Debian

distribution and Debian Live Project. More about Debian Live is discussed in Chapter 5.

3http://www.tinybsd.org/4http://www.freebsd.org/doc/en/articles/nanobsd/index.html

17

Chapter 4

Development of Windows XP

Embedded image

The following list shows the development process to use to create a run-time image [10]:

1. Identify Target Device Hardware

The �rst step in the development process is to identify the target device hardware you plan

on deploying to.

You can use Target Analyzer to automatically detect the hardware on your system, or you

can individually select each device driver component when you are creating your run-time

image in Target Designer.

2. Author Components and Customize Shells

During the componentization phase you create components for your applications, shells,

and device drivers. Using Component Designer, you can de�ne the �les that make up the

component, assign dependencies on other components, and set registry information.

Also, during this phase you can customize your shell by eliminating pop-up balloons and

intercepting message boxes.

3. Design a Run-Time Image

During the design phase, choose the components required for your run-time image.

This includes components that support system hardware, and base Windows components that

are required to run your applications (such as networking support or multiple languages).

Additionally, this phase includes creating custom components for your own applications and

device drivers.

Embedded-speci�c components, such as EWF and Minlogon, can be added to your run-time

image during this phase.

4. Add Security Features to a Run-Time Image

During the design phase, you must consider how you will keep your device up to date with

patches and updates. Adding a servicing mechanism, such as DUA, is required to be able to

update your run-time image.

Additionally, it is imperative that you add security components to your run-time image to

help prevent malicious attacks.

18

5. Deploy a Run-Time Image

After you have designed your run-time image, you are ready to build your run-time image

and deploy it to your device.

You build your run-time image in Target Designer. Target Designer creates a Windows XP

embedded �le system.

The standard method of deployment is to copy the XP embedded �le system to your device.

However, there are additional embedded-speci�c components that you can add to your run-

time image to support di�erent types of deployment. For example, the cloning component

supports deploying to mass devices.

6. Manage and Service a Run-Time Image

After your run-time image is deployed, you can service your device with updates using one of

the supported servicing mechanisms. You must add one of the update mechanisms to your

run-time image during the design phase of the development process.

4.1 Identi�cation of Target Device Hardware

Identi�cation of target device hardware is necessary to include proper drivers for hardware and to

reduce image size by excluding drivers not needed in given scenario. Identi�cation can be done

using tool �Target Analyzer�. This tool lists all connected hardware, its Plug-and-Play IDs and

other data. Because source data are read from Windows Registry, it is necessary to clean-up utility

output to remove unwanted records. Typical sources of unwanted drivers are software-emulated

hardware (virtual network cards or CD-ROM drives) and hardware connected via USB. Records

about hardware connected to computer remains in registry inde�nitely, even when the device is

removed, and these records will appear in output of Target Analyzer and as the result number of

drivers that would be included in run-time image. Easiest way to avoid these problems is to run

Target Analyzer from Windows PE.

The target device for this thesis is DataLab PC 1200 from Moravian Instruments Inc. with

following hardware con�guration[19]:

Component TypeCPU VIA EDEN 1.2 GHzMemory 512 MB DDR2, 533 MHz, SDRAMChipset VIA CN700Video UniChrome ProPower supply 230 V/50 Hz AC or 18-28 V DCStorage media Compact Flash Type INetwork Gigabit EthernetI/O Ports RS-232C, USB 2.0

Table 4.1: Con�guration of DataLab PC 1200

The main advantage of this computer model is absence of any moving parts (no cooling fans,

no spinning hard-drive). Drivers were provided from vendor in form suitable for conversion to

components using Component Designer and were componentized without any complications.

19

Figure 4.1: DataLab PC 1200

There are several peripherals connected to computer: webcam Microsoft LifeCam VX-6000 for

simple surveillance of the lab, where the device will be placed, printer Minolta Magicolor 2300 that

is currently shared via an outdated computer and the touchscreen that will provide user interface

for device.

Driver for printer was downloaded from vendor website and componentized via Component

Designer, however installation on target device was not successful due to following problems. The

cause of �rst problem was that the information �le (.inf) referenced uncompressed driver �les but

downloaded package contained only compressed �les. Solution for this problem was simply to

decompress all driver �les and include them in component. Second problem was that the USB

printers require another component �USB Printing Support�, that was not initially included.

For complete installation, the author had not only to include the componentized driver, but

also had to run the driver installation utility. Only then was the driver completely installed and

fully functional.

Figure 4.2: Minolta Magicolor 2300

Componentizing driver for webcam proved to be very di�cult since driver is provided in form of

installer which downloads most up-to-date driver package from web. The exact URL of downloaded

package was determined using network monitoring tool Wireshark 1. After downloading package

manually and decompressing, the .inf �le was imported to component using Component Designer.

1http://www.wireshark.org/

20

Figure 4.3: Microsoft LifeCam VX-6000

Driver for the touchscreen is already provided by the vendor as a component for Windows XP

Embedded and it was usable out of the box.

4.2 Authoring Components and Customizing Shells

Creating components for application can be di�cult in case of lack information about what �les

and registry data are used. Sometimes �les are located in system folders instead of installation

directory and registry data have names that are not related to application. In such case it is useful

to analyze the application using tools, which can help reveal location of missing �le or registry

data.

Some tools that are capable in assisting with application analysis are:

1. Process Monitor - an advanced monitoring tool for Windows that shows real-time �le system,

Registry and process/thread activity. 2

2. Dependency Walker - tool for analyzing dependencies of application on dynamic-link libraries.3

Drivers can be componentized by importing .inf �le using Component Designer. However, some

.inf �les are imported incorrectly and it is necessary to add or �x some data. Common problem

is that some vendors does not provide drivers for their hardware as simple archive, but in form

of installer. In these cases it can be hard to obtain proper �les by decompressing the installer or

using some other methods.

To minimize footprint and still provide graphical interface, alternate Windows shell Blackbox

for Windows 4 , application based on *NIX shell Blackbox, was used and customized by removing

links and menu items for non-existent functions. It is graphical, highly customizable, yet very

lightweight shell with minimal dependencies. Blackbox shell component contains several �les and

single registry value, that is used to set path to shell executable.

Access to webcam, either locally or remotely is provided by application Dorgem 5 that consists

of single executable �le. Dorgem uses to access webcam Video for Windows which is included in

DirectX package. Application itself has small footprint, however DirectX package consist of several

larger components that have more dependencies by itself. Dorgem has build-in HTTP server that

allows access to webcam image from remote station using any web browser.

2http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx3http://www.dependencywalker.com/4http://www.bb4win.org/5http://dorgem.sourceforge.net/

21

Because of possibility that this device will also serve as backup server, FileZilla Server 6, simple,

yet powerful, FTP server, was installed using standard installer and later componentized. FileZilla

Server supports FTP and FTPS (FTP over SSL) and includes features like bandwidth limits,

transfer compression and virtual �le system. For alternative method of backup (especially from

*NIX clients), the rsync7 service has been implemented using software DeltaCopy 8. rsync is an

open source utility that provides fast incremental �le transfer. The DeltaCopy software provides

rsync client for Windows, most *NIX can install rsync client from their package repositories.

4.3 Design of Run-Time Image

Selection of components included in run-time image is usually based on target hardware, to include

all required drivers, and applications intended to be run on target device. Because components

are depended on other, all necessary components are added when these dependencies are solved

by Target Designer. If you are designing your own component, it is necessary to pay attention to

dependencies, so that they include all �les (mostly dynamic libraries) required by your application.

While creating run-time image in Target Designer, it is possible to con�gure some options for

several components. Examples of con�gurable components are Windows Firewall (con�guration

of exceptions), display adapter drivers (con�guration of resolution, color depth and screen refresh

rate) and Hardware Abstraction Layers components (computer name and workgroup membership).

Run-time image contains hardware drivers for DataLab PC 1200, Microsoft LiveCam VX-6000

and Minolta Magicolor 2300, components for Blackbox shell, applications Dorgem, FileZilla Server

and DeltaCopy. Common dynamic libraries (e.g. Visual C++ Runtimes) are also included to ease

later deployment of other applications.

Printer sharing is provided via Line Printer Remote protocol, that is provided by Print Services

for UNIX component of Windows Embedded. This protocol allows access to printer from both

Windows and *NIX clients without any need for setting up security. Sharing via Microsoft File and

Printer Sharing was also made available, however it is currently unsecured against unauthorized

access.

4.4 Security Features of a Run-Time Image

Windows Embedded Standard supports the same con�gurable security options as Microsoft Win-

dows XP Professional. One important security component is Windows Firewall that provides a

barrier between your system and potentially harmful content on a network, such as viruses and

worms. Windows Firewall can prevent unauthorized network access to the run-time image. An-

other security feature is patch management and related components.

The run-time image is secured using Enhanced Write Filter that protects device from permanent

unauthorized changes. In case that device con�guration is changed, rebooting the device will

restore previous state. Windows Firewall is included to prevent unauthorized access over network.

Currently, there is no automated solution for Windows security patch management. If any patch

will be needed, it will be installed manually.

6http://�lezilla-project.org/7http://www.samba.org/rsync/8http://www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp

22

4.5 Deployment of a Run-Time Image

Run-time image can be deployed either on-line on target device or o�ine by connecting storage

device to another computer.

On-line deployment is usually performed using Microsoft Windows Preinstallation Environ-

ment, which provides a small but powerful boot environment that can be used for many Windows

XP Embedded development tasks. Windows PE provides the following features [7]:

� A hardware-independent Windows environment with a small footprint both on the bootable

media and in memory.

� A subset of the Win32 application programming interfaces (APIs), a command-line interface

(Cmd.exe) capable of running batch �les, and support for Windows Script Host (WSH),

HTML Applications (HTA), and ActiveX Data Objects (ADO) used to create custom tools

or scripts.

� Network access and support for standard in-box network drivers that may be required for

copying images and test suites from a network that uses TCP/IP.

� Support for all mass-storage devices that use Windows 2000 or Windows XP drivers.

� Native support to create, delete, format, and manage NTFS �le system partitions.

� Hardware diagnostics to load and test speci�c hardware drivers.

In case that the hardware of the target device (especially network controllers or mass storage

devices) is not natively supported by Windows PE, relevant drivers can be added to the image or

loaded at runtime.

O�ine deployment requires connecting storage media from target device to developer computer.

This method is complicated in case the storage media is hard-drive, however in case of Compact

Flash cards, it is easy to connect CF card using proper card reader.

Since many scenarios require to build many pieces of the same device, Windows XP Embedded

includes component for cloning support. Using the cloning support, the FBA can be executed

and manual modi�cations can be performed on single device. After that, the image is prepared

for cloning using fbaclone.exe command. Clonable image can be then replicated to other storage

media. CLoend image will perform only very short �nal step after �rst start.

The author has deployed the run-time image on-line using Windows Preinstallation Environ-

ment with added driver for network controller of DataLab PC 1200. Windows PE were booted

from USB Flash Disk, however it was necessary to con�gure BIOS for every boot to prefer USB

Hard Drive before internal hard disk or Compact Flash card. To minimize Compact Flash card

wearing, all tests were performed using 2.5� hard drive. After �nishing the testing phase, the

author has migrated the run-time image to the Compact Flash Card.

4.6 Management and Servicing a Run-Time Image

Securing device with latest updates and patches is complicated, especially when Enhanced Write

Filter or File Based Write Filter are used. There are several possibilities, how to keep the device

up-to-date.

First possibility is manual installation of updates and patches. This process is time-consuming

and error-prone, but in some scenarios only viable way of updating device. Patches for Windows

23

Embedded are distributed only trough OEM channel, and as the result customers cannot update

device without vendor support.

Second option is to use Device Update Agent provided by Microsoft. DUA is a service that

runs on the client and polls for a command script to perform �le, directory, systems and registry

operations. DUA can perform the following tasks: update application or application data, deploy

new �les and registry changes, execute process.[2] Using DUA is fairly easy, however the scripting

language is very limited and lacks any conditional structures like if or switch.

Last option is to develop custom software solution, that can handle all possible scenarios with

EWF and/or FBWF.

There is currently no automated solution for patch management and servicing. Since the

device is going to be protected with Enhanced Write Filter and automating patch management is

complicated under these circumstances, device has to be managed manually until there is a need for

automated solution. The author developed proof-of-concept software based on Nullsoft Scriptable

Install System9 that uses API for Enhanced Write Filter to control disk protection for possible use

in automated solution in the future.

For manual management and servicing, the Enhanced Write Filter Manager is included. EWF

Manager is an utility, that wraps EWF API for use from command line. This allows administrator

to commit changes or enable/disable the �lter using simple commands.

9http://nsis.sourceforge.net/

24

Chapter 5

Description of Debian Live

5.1 Relation of Debian Live, Debian and GNU/Linux

Debian is a GNU/Linux operating system distribution based on Linux kernel and set of GNU and

other free software. The Debian Project provides access to more than 35000[1] packages, including

libraries, kernel components, graphical front-ends and user applications. Other sources for Debian

packages are available, either as repositories or as separate package �le downloads.

A Debian Live system is a Debian operating system that does not require a classical installer

to use it. It comes on various media, including CD-ROM, USB sticks, or via netboot.[17] Although

the Debian Live does not aim at providing environment for embedded computers, the properties

of the live systems are suitable for developing such devices. The live system is designed to run

from read-only media and to store user changes only when requested (if storage space is available).

With Debian Live, it's a Debian GNU/Linux operating system, built for one of the supported

architectures (currently amd64, i386, powerpc and sparc).

It is made from the following parts:[16]

Linux kernel image usually named vmlinuz*

Initial RAM disk image (initrd) a RAM disk set up for the Linux boot, containing modules

possibly needed to mount the System image and some scripts to do it.

System image The operating system's �lesystem image. Usually, a SquashFS compressed �lesys-

tem is used to minimize the Debian Live image size. Note that it is read-only. So, during

boot the Debian Live system will use a RAM disk and �union� mechanism to enable writing

�les within the running system. However, all modi�cations will be lost upon shutdown unless

optional persistence is used (see Section 5.2).

Bootloader A small piece of code crafted to boot from the chosen media, possibly presenting a

prompt or menu to allow selection of options/con�guration. It loads the Linux kernel and its

initrd to run with an associated system �lesystem. Di�erent solutions can be used, depending

on the target media and format of the �lesystem containing the previously mentioned com-

ponents: isolinux to boot from a CD or DVD in ISO9660 format, syslinux for HDD or USB

drive booting from a VFAT partition, extlinux for ext2/3/4 and btrfs partitions, pxelinux for

PXE netboot, GRUB for ext2/3/4 partitions, etc.

25

5.2 Persistence of user data and/or changes to �lesystem

A live CD paradigm is a pre-installed system which runs from read-only media, like a CD-ROM,

where writes and modi�cations do not survive reboots of the host hardware which runs it.

A Debian Live system is a generalization of this paradigm and thus supports other media in

addition to CDs; but still, in its default behavior, it should be considered read-only and all the

run-time evolutions of the system are lost at shutdown.

Persistence is a common name for di�erent kinds of solutions for saving across reboots some, or

all, of this run-time evolution of the system. To understand how it could work it could be handy

to know that even if the system is booted and run from read-only media, modi�cation to the �les

and directories are written on writable media, typically a ram disk (tmpfs) and ram disks' data do

not survive reboots.

The data stored on this ramdisk should be saved on a writable persistent medium like a Hard

Disk, a USB key, a network share or even a session of a multisession (re)writable CD/DVD. All

these media are supported in Debian Live in di�erent ways, and all but the last one require a

special boot parameter to be speci�ed at boot time: persistent. [15]

5.2.1 Full persistence

By �full persistence� it is meant that instead of using a tmpfs for storing modi�cations to the

read-only media (with the copy-on-write, COW, system) a writable partition is used. In order to

use this feature a partition with a clean writable supported �lesystem on it labeled live-rw must

be attached on the system at boot time and the system must be started with the boot parameter

persistent. This partition could be an ext2 partition on the hard disk or on a USB key created

with, e.g.:

# mkfs . ext2 −L l i v e−rw /dev/sdb1

If you already have a partition on your device, you could just change the label with one of the

following:

# tune2 f s −L l i v e−rw /dev/sdb1 # f o r ext2 , 3 , 4 f i l e s y s t em s

But since live system users cannot always use a hard drive partition, and considering that most

USB keys have poor write speeds, full persistence could be also used with just image �les, so you

could create a �le representing a partition and put this image �le even on a NTFS partition of a

foreign OS, with something like:

$ dd i f =/dev/ nu l l o f=l i v e−rw bs=1G seek=1 # f o r a 1GB s i z ed image f i l e

$ / sb in /mkfs . ext2 −F l i v e−rw

Then copy the live-rw �le to a writable partition and reboot with the boot parameter persis-

tent.

5.2.2 Home automounting

If during the boot a partition (�lesystem) image �le or a partition labeled home-rw is discovered,

this �lesystem will be directly mounted as /home, thus permitting persistence of �les that belong

to e.g. the default user. It can be combined with full persistence.

26

5.2.3 Snapshots

Snapshots are collections of �les and directories which are not mounted while running but which

are copied from a persistent device to the system (tmpfs) at boot and which are resynced at

reboot/shutdown of the system. The content of a snapshot could reside on a partition or an image

�le (like the above mentioned types) labeled live-sn, but it defaults to a simple cpio archive named

live-sn.cpio.gz. As above, at boot time, the block devices connected to the system are traversed

to see if a partition or a �le named like that could be found. A power interruption during run

time could lead to data loss, hence a tool invoked live-snapshot �refresh could be called to sync

important changes. This type of persistence, since it does not write continuously to the persistent

media, is the most �ash-based device friendly and the fastest of all the persistence systems.

A /home version of snapshot exists too and its label is home-sn.*; it works the same as the

main snapshot but it is only applied to /home.

Snapshots cannot currently handle �le deletion but full persistence and home automounting

can.

5.3 Tools for development of Debian Live image

5.3.1 The live-build package

live-build is a collection of scripts to build Debian Live systems. These scripts are also referred

to as "commands". The idea behind live-build is to be a framework that uses a con�guration

directory to completely automate and customize all aspects of building a Live image.[18]

The most important commands are:

� lb config: Responsible for initializing a Live system con�guration directory and for au-

tomating subsequent modi�cations.

� lb build: Responsible for starting a Live system build.

� lb clean: Responsible for removing parts of a Live system build.

5.3.2 The live-boot package

live-boot is a collection of scripts providing hooks for the initramfs-tools, used to generate an

initramfs capable of booting live systems, such as those created by live-build. This includes the

Debian Live ISOs, netboot tarballs, and USB stick images. At boot time it will look for read-only

media containing a "/live" directory where a root �lesystem (often a compressed �lesystem image

like squashfs) is stored. If found, it will create a writable environment, using aufs, for Debian like

systems to boot from.[18]

5.3.3 The live-con�g package

live-con�g consists of the scripts that run at boot time after live-boot to con�gure the live system

automatically. It handles such tasks as setting the hostname, locales and timezone, creating the

live user, inhibiting cron jobs and performing autologin of the live user.[18]

27

Chapter 6

Development of Debian-based image

The cornerstone of image development is set of scripts from the Debian Live Project1. These scripts

provide easy-to-use tool to start the development. The following list shows the development process

to use to create a run-time image.

1. Create base Live system con�guration

The Debian Live provides single command to create the the skeleton con�guration folders

that can be later modi�ed: lb config

2. Customize con�guration

The con�guration �les created in previous step can be modi�ed to include software packages

in the �nal image, to change certain system settings (like host name, user locale, . . . ) It

is also possible to add custom �les that will be included in resulting image (e.g. /etc/skel

directory that will be used as a template for users home directory)

3. Build the resulting �le-system

The building of resulting system is handled by another command: lb build

4. Deploy the resulting �le-system and bootloader to the target medium

6.1 Create base Live system con�guration

Creating the skeleton con�guration is handled by the lb config command. The con�guration

structure can be created manually, however due to the amount of needed �les and directories the

manual process is quite error-prone. The skeleton con�guration can be customized with parameters

passed to lb config command, but everything can be modi�ed later via con�guration �les.

1http://live.debian.net/

28

|−− auto/| `−− f un c t i on s /`−− c on f i g /

|−− binary|−− binary_debian− i n s t a l l e r /|−− binary_debian−i n s t a l l e r −i n c l ud e s /|−− binary_grub/|−− binary_loca l−debs/|−− binary_loca l−hooks/|−− binary_loca l−i n c l ud e s /|−− binary_loca l−pa c k a g e s l i s t s /|−− binary_loca l−udebs/|−− binary_root f s /|−− binary_sys l inux /|−− boots t rap|−− chroot|−− chroot_apt/|−− chroot_loca l−hooks/|−− chroot_loca l−i n c l ud e s /|−− chroot_loca l−packages /|−− chroot_loca l−pa c k a g e s l i s t s /|−− chroot_loca l−patches /|−− chroot_loca l−preseed /|−− chroot_sources /|−− common|−− i n c l ud e s /|−− source`−− templates /

23 d i r e c t o r i e s , 5 f i l e s

Figure 6.1: Debian Live Con�guration Tree

6.2 Customize con�guration

The applications distributed via Debian package repositories can be added to the con�guration

by creating list of wanted packages or by using prede�ned templates. In case of packages (.deb

�les) not available via Debian repositories, the addition means simply copying the .deb �le to

given directory. The customization of other �les is also accomplished by copying required �les to

prede�ned folders in the con�guration folders structures.

The lb config command provides simple interface for adding packages. The switch ��packages�

allows user to add speci�ed packages. For larger set and/or better �exibility the package list can

be provided. The Debian Live provides several prede�ned lists for common use (e.g. prede�ned

lists for di�erent graphical interfaces like KDE, GNOME or Xfce). User can create own package

lists and supply them during con�guration. The package lists are con�gured via ��packages-lists�

switch of lb con�g command.

It is also possible to rede�ne available repositories to add packages other than those available

in Debian o�cial repositories. e.g. for inclusion of latest (or development) versions of packages

provided in separate repositories.

29

6.3 Build the resulting �le-system

The build is initiated via lb build command. The resulting �le-system can be build either as

bootable ISO image for burning to CD-ROM or as separate �les for copying to USB Flash or in

this case to the CompactFlash card. In both cases the �le-system is stored as SquashFS compressed

�lesystem to minimize the Debian Live image size. The �le with SquashFS is read-only, so, during

boot the Debian Live system will use a RAM disk and �union� mechanism to enable writing �les

within the running system. However, all modi�cations will be lost upon shutdown unless optional

persistence is used.[16]

The build process sets up the Debian core using debootstrap and then chroots to the newly

setup �lesystem. Then the new system is con�gured for network and the installation of all required

packages is started. The package installation is handled via Advanced Packgate Tool (APT) that

6.4 Deploy the resulting �le-system and bootloader to the

target medium

In case of the CompactFlash the deployment means copying all the �les from the resultant �le-

system and con�guring the bootloader (setting up Master Boot Record). This can be accomplished

either o�ine by connecting the CompactFlash Card to the development computer or online with

help of Live Linux distribution (or Windows PE) depending on the �lesystem that will be used on

the CompactFlash Card.

Compact Flash Card− f i l e s y s t em

− f i l e s y s t em . squash − Squashed Debian Live f i l e s y s t em( conta in s Linux d i r e c t o r y s t r u c tu r e = bin , etc , sbin , usr e t c . )

− vmlinuz − The Linux ke rne l− s y s l i nux

− l d l i nux . sys − The boot loader− s y s l i nux . c f g − The boot loader c on f i gu r a t i on

− l i v e−sn . cp io . gz − The p e r s i s t e n c e snapshot

Figure 6.2: File structure of CompactFlash Card with Debian Live

30

Chapter 7

Comparison of Windows XP

Embedded and Debian Live

7.1 Licensing

The Windows XP Embedded are covered by proprietary license that limits the scope of usage

of the run-time image to a single purpose installation. On the contrary, the Debian (being open

source software) has no such limitation and the run-time image can be freely redistributed.

7.2 Build process

The main idea behind build process of both Windows XP Embedded and Debian live is that the

resulting system is composed from various packages that can depend on others and that these

dependencies are resolved during build automatically.

In case of Windows XP Embedded the componentization can be somewhat di�cult, especially in

cases of third-party applications, that are not natively designed to support Windows XP Embedded.

On the other hand, the Debian package management is core component of Debian system and thus

the majority of applications is provided via Debian packages, therefore there is no need to create

packages for third-party applications.

In both cases the dependencies of components (packages) can bring to the resulting image

unneeded components (and thus increase the resulting size). The necessity for certain dependen-

cies is questionable in case of embedded device, where the provided (and required) services and

components are strictly limited by device design.

An example of bloated component in Windows XP Embedded is Microsoft .NET Framework.

Because the framework can be installed only as a single component, the number of dependencies is

huge (the .NET Framework directly depends on 86 components). The reason for these requirements

is that the framework can possibly interact with all of the required components. However in case

of single function application, interaction with certain components is not required by design, e.g.

the camera control software does not require printing capability or Active Directory access. In

these cases the dependencies can be modi�ed (or left unresolved) to save space.

The Windows XP Embedded require �nal step to be performed directly on the target device,

to setup hardware drivers and con�gure �le system. The Debian Live image is ready to use after

the build and require no further con�guration.

31

7.3 Build tools

The tools for Microsoft Windows XP Embedded are described in Section 2.4. The tools are mainly

GUI based, although some automation is available using script xpecmd.wsf. The tools for Debian

Live are console-based scripts that can be easily automated.

Windows XP Embedded tools store all components data in the �le repository and SQL database

installed on the development computer (or accessed over the LAN). The Debian Live tools access

the package data in the repositories over the Internet. Therefore the Internet connection is re-

quired for building the Debian image because the packages that will be included in the image are

downloaded from the repositories.

7.4 Deployment of a Run-time Image

Both Windows XP Embedded and Debian Live can be deployed either online on the target machine

or o�ine using another computer to copy required �les to the storage media. Both operating

systems can be deployed online using their �live� versions (in case of Microsoft Windows XP

Embedded it is the Windows PE described inSection 4.5; in case of Debian the already discussed

Debian Live can be used to create the live version for deployment).

7.5 Embedded Enabling Features

Both operating systems provide su�cient tool for deploying the run-time image from read-only

media (or from media where writing is undesirable, such as Compact Flash Cards) or over the

network with optional persistence of changes. Both systems provides similar system, where changes

to the �le system are stored in the memory and overlayed over the �le system stored on the storage

media. When it is neccessary to persist the changes, the device user invokes a single command

to store the changes to the storage media (in case of Windows XP Embedded) or to the snapshot

archive (in case of Debian Live). The full persistence method is also available on both systems.

32

Chapter 8

Evaluation of properties of built

device

To be done

33

Chapter 9

Conclusion

Windows XP Embedded provides features and properties that makes them excellent candidates for

embedded devices that do not have strict resources limits but cannot support full blown installation

of Windows XP. The componentization allows the manufacturer to include only features required

for given device to reduce resource requirements and decrease chance of software collisions. Another

important point are Embedded Enabling Features speci�cally designed for increasing stability of the

installation by preventing changes to the installation. Because Windows XP Embedded provides

the same programming interface as Windows XP, it is fairly easy to port existing applications

without many changes.

The comparison with other operating systems is summarized in Chapter 3. The author fo-

cused in detail on comparsion with GNU/Linux distribution Debian and the Debian Live project.

The author was able to create run-time image based on Debian using Debian Live with similar

functionality as the Windows XP Embedded image, however this image was tested only in virtual

computer using VirtualBox OSE. Although the Debian Live does not aim to be the used in the

embedded devices, its properties makes it a valuable candidate for devices with slightly limited

resources (similar requiremets as in case of Windows XP Embedded). The packaging philosophy

is very similar to that used in Windows XP Embedded, however the number of already packaged

application is much higher than in case of Windows XP Embedded. In case of unpackaged applica-

tions, it is easier to add them to the image, compared to Windows XP Embedded, because most of

*nix application are deployed by copying �le. The description of the system and the development

process is in Chapter 5 and Chapter 6.

The author successfully created required components for hardware drivers and applications that

will currently run on device and provide remote access to webcamera and printer. Details about

creation of these components are mentioned in Chapter 4. Deploying run-time image on target

device was done on-line using customized Windows Preinstallation Environment booted from USB

Flash Disk.

The device now full�lls all required functions (web camera access, printer sharing server). Using

the Enhanced Write Filter, the device is protected against any changes. Because of the usage of

the EWF, the author decided that other security measures are currently not neccessary. In case of

device malfunction or unintented change, the system is restored by single restart of the computer.

34

Bibliography

[1] D. L. Debian Project. All debian packages in "squeeze", 4 2011. Available from: http:

//packages.debian.org/stable/allpackages?format=txt.gz.

[2] Sean D. Liming. Windows XP Embedded Advanced. RTC Books, 2003.

[3] Jean Milanez Melo. About tinybsd, 2007. Available from: http://www.tinybsd.org/.

[4] Microsoft. Component database manager guide, 2009. [Online; accessed 19-July-2009].

Available from: http://msdn.microsoft.com/en-us/library/aa940321(WinEmbedded.5)

.aspx.

[5] Microsoft. Component designer guide, 2009. [Online; accessed 19-July-2009]. Available from:

http://msdn.microsoft.com/en-us/library/aa940181(WinEmbedded.5).aspx.

[6] Microsoft. Target designer guide, 2009. [Online; accessed 19-July-2009]. Available from:

http://msdn.microsoft.com/en-us/library/aa940538(WinEmbedded.5).aspx.

[7] Microsoft. Windows preinstallation environment, 2009. [Online; accessed 21-June-2009].

Available from: http://msdn.microsoft.com/en-us/library/ms940812(WinEmbedded.5)

.aspx.

[8] Microsoft. Windows xp embedded components, 2009. [Online; accessed 19-June-2009].

Available from: http://msdn.microsoft.com/en-us/library/aa460527(WinEmbedded.5)

.aspx.

[9] Microsoft. Windows xp embedded con�gurations, 2009. [Online; accessed 19-June-2009].

Available from: http://msdn.microsoft.com/en-us/library/aa460528(WinEmbedded.5)

.aspx.

[10] Microsoft. Windows xp embedded development process, 2009. [Online; accessed 19-June-2009].

Available from: http://msdn.microsoft.com/en-us/library/aa460544(WinEmbedded.5)

.aspx.

[11] Microsoft. Windows xp embedded faq, 2009. [Online; accessed 18-June-2009]. Available from:

http://www.microsoft.com/windowsembedded/en-us/products/wexpe/faq.mspx.

[12] Microsoft. Windows xp embedded licensing requirements and guidelines, 2009. [On-

line; accessed 19-July-2009]. Available from: http://msdn.microsoft.com/en-us/library/

bb499133(WinEmbedded.5).aspx.

[13] Microsoft. .net micro framework, 2010. Available from: http://www.microsoft.com/netmf/

default.mspx.

35

[14] Microsoft. Windows embedded ce overview, 2010. Available from: http://www.microsoft.

com/windowsembedded/en-us/products/windowsce/default.mspx?WT.mc_ID=FY10_CE.

[15] Debian Live Project. Customizing run time behaviours. Available from: http://live.

debian.net/manual/en/html/customizing-run-time-behaviours.html.

[16] Debian Live Project. Debian live manual, 2010. Available from: http://live.debian.net/

manual/en/html/the-basics.html.

[17] Debian Live Project. About debian live project, 04 2011. Note about deblive. Available from:

http://live.debian.net/project/about/.

[18] Debian Live Project. Overview of tools, 04 2011. Available from: http://live.debian.net/

manual/en/html/overview-of-tools.html.

[19] Moravské p°ístroje a.s. Moravské p°ístroje a.s. :: Datalab pc 1200, 2009. [Online; accessed

15-August-2009]. Available from: http://www.mii.cz/art?id=369&cat=57&lang=405.

[20] Wikipedia. List of operating systems � wikipedia, the free encyclopedia, 2009. [Online;

accessed 18-June-2009]. Available from: http://en.wikipedia.org/w/index.php?title=

List_of_operating_systems&oldid=297114243.

36