Embedded PC with Windows XP Embedded -...
Transcript of Embedded PC with Windows XP Embedded -...
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