Programming Microsoft Windows CE NET 3rd Edition

Douglas Boling download

https://ebookgate.com/product/programming-microsoft-windows-ce-
net-3rd-edition-douglas-boling/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Professional Microsoft Windows Embedded CE 6 0 Samuel

Phung

https://ebookgate.com/product/professional-microsoft-windows-
embedded-ce-6-0-samuel-phung/

Microsoft Jscript NET Programming Justin Rogers

https://ebookgate.com/product/microsoft-jscript-net-programming-
justin-rogers/

Programming Microsoft ADO NET 2 0 Core Reference David

Sceppa

https://ebookgate.com/product/programming-microsoft-ado-
net-2-0-core-reference-david-sceppa/

Programming the Microsoft Windows Driver Model 2nd

Edition Walter Oney

https://ebookgate.com/product/programming-the-microsoft-windows-
driver-model-2nd-edition-walter-oney/
MCTS Self Paced Training Kit Exam 70 502 Microsoft NET
Framework 3 5 Windows Presentation Foundation Matthew
A. Stoecker

https://ebookgate.com/product/mcts-self-paced-training-kit-
exam-70-502-microsoft-net-framework-3-5-windows-presentation-
foundation-matthew-a-stoecker/

Microsoft Windows XP Inside Out Ed Bott

https://ebookgate.com/product/microsoft-windows-xp-inside-out-ed-
bott/

Special edition using Microsoft Windows Vista Robert

Cowart

https://ebookgate.com/product/special-edition-using-microsoft-
windows-vista-robert-cowart/

Microsoft Access VBA programming for the absolute

beginner 3rd Edition Michael (Michael Vine) Vine

https://ebookgate.com/product/microsoft-access-vba-programming-
for-the-absolute-beginner-3rd-edition-michael-michael-vine-vine/

Programming Visual Basic 2008 Build NET 3 5

Applications with Microsoft s RAD Tool for Business 1st
Edition Tim Patrick

https://ebookgate.com/product/programming-visual-
basic-2008-build-net-3-5-applications-with-microsoft-s-rad-tool-
for-business-1st-edition-tim-patrick/
PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399

Copyright 2003 by Douglas Boling

All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or
by any means without the written permission of the publisher.

Library of Congress Cataloging-in-Publication Data

Boling, Douglas McConnaughey, 1960-
Programming Microsoft Windows CE .NET / Douglas Boling.--3rd ed.
p. cm.
Includes index.
ISBN 0-7356-1884-4
1. Microsoft Windows (Computer file) 2. Operating systems (Computers) 3. Microsoft
.NET. I. Title.

QA76.76.O63B625 2003
005.4'469--dc21 2003042205

Printed and bound in the United States of America.

123456789 QWT 876543

Distributed in Canada by H.B. Fenn and Company Ltd.

A CIP catalogue record for this book is available from the British Library.

Microsoft Press books are available through booksellers and distributors worldwide. For further information
about international editions, contact your local Microsoft Corporation office or contact Microsoft
Press International directly at fax (425) 936-7329. Visit our Web site at www.microsoft.com/mspress. Send
comments to mspinput@microsoft.com.

ActiveSync, ActiveX, Developer Studio, DirectX, Microsoft, Microsoft Press, MS-DOS, Visual Basic,
Visual C++, Visual C#, Visual Studio, Win32, Windows, Windows NT, and Windows Server are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.

The example companies, organizations, products, domain names, e-mail addresses, logos, people,
places, and events depicted herein are fictitious. No association with any real company, organization,
product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Acquisitions Editor: Anne Hamilton Interior Artist: Michael Kloepfer

Project Editor: Kathleen Atkins Proofreader: nSight, Inc.
Technical Editor: Jim Fuchs Indexer: Julie Hatley
Interior Graphic Designer: James D. Kramer Cover Designer: Methodologie, Inc.
Principal Compositor: Dan Latimer

Body Part No. X09-39008

To Nancy Jane
Acknowledgments
Books are produced by diverse teams of talented people. My name appears on the cover, but countless
others were involved in this book’s creation. The teams of people who worked on this edition all
pushed themselves to the max to complete this revision.

First, there’s the talented team at Microsoft Press. Kathleen Atkins, the project leader and editor of all
three editions of this book, took my gnarled syntax and confused text and made it readable. The
technical editor for this edition, as well as the first edition of the book, was Jim Fuchs. Jim provided a
great sanity check for me as well as providing a huge amount of help in getting the CD organized and
produced. Shawn Peck performed the copyediting duties, keeping the text within the rules of the
English language. Dan Latimer performed the desktop publishing duties, and Michael Kloepfer
produced the illustrations. Thanks to Julie Hatley for the index. Anne Hamilton, who was the
acquisitions editor for both the second and third editions of the book, deserves credit for getting these
revisions released. Thanks, Anne, for all your efforts in keeping this book up-to-date.

Thanks also to the various Microsoft development and marketing teams. Over the years, they have
tolerated my endless questions. Thanks to Mike Thomson, Michael Malueg, and Andrew Pearson for
answering questions and reviewing chapters. Ori Amiga on the Pocket PC team provided all manner of
priceless assistance: answering questions, getting new builds, and even providing hardware. Thanks
also to Dominique Fortier, who provided great assistance on the Pocket PC, Bluetooth, and OBEX
content in this edition. I had great support from the Compact Framework team from Craig Neable,
Mark Gilbert, and Kei Amos. A special thank-you goes to Jeana Jorgensen, who, across a variety of
jobs at Microsoft, has always tolerated my cries for help no matter the hour or relevance to her job.
Thanks to all of you. Your help made this book so much better than it would have been without you.

I also need to acknowledge Tatia Meghdadi, John Doub, and the team at Socket Communication, who
provided Bluetooth hardware and software for testing.

A special thanks goes to my agent, Claudette Moore, and the team at Moore Literary Agency.
Claudette handled all the business details, freeing me to deal with the fun stuff.

This edition of Programming Windows CE builds on the foundation of the two earlier editions, so what
you read is based on work from a much larger team. In addition to the people already mentioned, other
folks from Microsoft Press have helped immensely in the editing and production of the earlier editions
of the book. They include Brian Johnson, Julie Xiao, Rebecca McKay, Rob Nance, Cheryl Penner,
Elizabeth Hansford, and Michael Victor.

My personal support team is headed by my wife, Nancy. Thanks, Nancy, for the support, help, and
love. The personal support team also includes our boys, Andy, Sam, and Jake. They make sure I
always remember what is important in life. I also must acknowledge my parents, Ronald and Jane
Boling. They are my role models.
Introduction
I’ve been working with Microsoft Windows CE for almost as long as it’s been in existence. A
Windows programmer for many years, I’m amazed by the number of different, typically quite small,
systems to which I can apply my Windows programming experience. These Windows CE systems run
the gamut from PC-like mini-laptops to cellular phones to embedded devices buried deep in some large
piece of industrial equipment. The use of the Win32 API in Windows CE enables tens of thousands of
Windows programmers to write applications for an entirely new class of systems. The subtle
differences, however, make writing Windows CE code somewhat different from writing for the
desktop versions of Windows. It’s those differences that I’ll address in this book.
Just What Is Windows CE?

Windows CE is the smallest and arguably the most interesting of the Microsoft Windows operating
systems. Windows CE was designed from the ground up to be a small ROM-based operating system
with a Win32 subset API. Windows CE extends the Windows API into the markets and machines that
can’t support the larger footprints of the Windows XP kernel.

The now-defunct Windows 95/98/Me line was a great operating system for users who needed
backward compatibility with MS-DOS and Windows 2.x and 3.x programs. Although it had
shortcomings, Windows Me succeeded amazingly well at this difficult task. The Windows
NT/2000/XP line, on the other hand, is written for the enterprise. It sacrifices compatibility and size to
achieve its high level of reliability and robustness. Windows XP Home Edition is a version of
Windows XP built for the home user that does strive for compatibility, but this is secondary to its
primary goal of stability.

Windows CE isn’t backward compatible with MS-DOS or Windows. Nor is it an all-powerful

operating system designed for enterprise computing. Instead, Windows CE is a lightweight,
multithreaded operating system with an optional graphical user interface. Its strength lies in its small
size, its Win32 subset API, and its multiplatform support.

Windows CE also forms the foundation for the initial version of the .NET Compact Framework, a
version of the .NET runtime for mobile and embedded devices. The Compact Framework provides the
same powerful .NET runtime environment with a smaller class library so that it fits in small battery-
powered devices.
A Little Windows CE History

To understand the history of Windows CE, you need to understand the differences between the
operating system and the products that use it. The operating system is developed by a core group of
programmers inside Microsoft. Their product is the operating system itself. Other groups, who develop
devices such as the Pocket PC, use the newest version of the operating system that’s available at the
time their product is to be released. This dichotomy has created some confusion about how Windows
CE has evolved. Let’s examine the history of each, the devices and the operating system itself.

The Devices

The first products designed for Windows CE were handheld “organizer” devices with 480-by-240 or
640-by-240 screens and chiclet keyboards. These devices, dubbed Handheld PCs, were first introduced
in late 1996. Fall Comdex 97 saw the release of a dramatically upgraded version of the operating
system, Windows CE 2.0, with newer hardware in a familiar form—this time the box came with a 640-
by-240 landscape screen, sometimes in color, and a somewhat larger keyboard.

In January 1998 at the Consumer Electronics Show, Microsoft announced two new platforms, the
Palm-size PC and the Auto PC. The Palm-size PC was aimed directly at the pen-based organizer
market dominated by Palm OS–based systems. The Palm-size PC featured a portrait mode and a 240-
by-320 screen, and it used stylus-based input. Unfortunately for Windows CE fans, the public
reception of the original Palm-size PC was less than enthusiastic.

Later that year, a new class of mini-laptop–style Windows CE machines with touch-typable keyboards
and VGA or Super VGA screens made their appearance. These machines, called H/PC Professionals,
provided 10 hours of battery life combined with improved versions of Microsoft’s Pocket Office
applications. Many of these machines had built-in modems, and some even diverged from the then-
standard touch screen, sporting track pads or IBM’s TrackPoint devices.

In April 2000, Microsoft introduced the Pocket PC, a greatly enhanced version of the old Palm-size
PC. The original Pocket PC used a prerelease of the more full-featured Windows CE 3.0 operating
system under the covers. The user interface of the Pocket PC was also different, with a cleaner, 2D,
look and a revised home page, the Today screen. The most important feature of the Pocket PC,
however, was the greatly improved performance of Windows CE. Much work had been done to tune
Windows CE for better performance. That improvement, coupled with faster CPUs, allowed the system
to run with the zip expected from a pocket organizer. With the Pocket PC, the inevitability of Moore’s
 Law enabled Windows CE devices to cross over the line: the hardware at this point was now capable
of providing the computing power that Windows CE required.

The Handheld PC was updated in 2000 to use Windows CE 3.0. Although these systems (now called
the Handheld PC 2000) haven’t been a consumer success, they have found a home in the industrial
market, where their relative low cost, large screens, and great battery life satisfy a unique niche market.

The Pocket PC was updated in late 2001 with a release named Pocket PC 2002. This release was based
on the final released version of Windows CE 3.0 and contained some user interface improvements. An
exciting development was the addition of the Pocket PC Phone Edition, which integrated cellular
phone support into a Pocket PC device. These devices combined the functionality of a Pocket PC with
the connectivity of a cellular phone, enabling a new generation of mobile but always connected
software.

Another group within Microsoft released the Smart Display, a Windows CE .NET 4.1–based system
that integrated a tablet form factor device with wireless networking and a base connected to a PC.
When the Smart Display is in its base, it’s a second monitor; when removed, it becomes a mobile
display for the PC.

In the spring of 2003, the Pocket PC team released an update of the Pocket PC called the Pocket PC
2003. This system, while not providing much of a change to the user interface, did provide a huge
increase in stability and performance because it was based on Windows CE .NET 4.2. The Pocket PC
2003 also added integrated Bluetooth support for those OEMs that chose to include it.

Microsoft has also been working with OEMs to produce cellular phones based on Windows CE. A
smattering of these phones, called Smartphones, were released in late 2002 and were initially based on
Windows CE 3.0. An upgrade in 2003 moved the Smartphone to Windows CE 4.2 and increased the
feature set of the device to include the .NET runtime.

New devices are being introduced all the time. An example are the Media to Go devices, which are
mobile video players using a hard disk for storage. The power of the Windows CE operating system
enables applications that are beyond the capability of systems with simpler operating systems to run on
these devices.

The Operating System

Although these consumer-oriented products made the news, more important development work was
going on in the operating system itself. The Windows CE operating system has evolved from the days
of 1.0, when it was a simple organizer operating system with high hopes. Starting with Windows CE
2.0 and continuing to this day, Microsoft has released embedded versions of Windows CE that
developers can use on their custom hardware. Although consumer platforms such as the Pocket PC get
most of the publicity, the improvements to the base operating system are what enable devices such as
the Pocket PC and the Smartphone.

Windows CE 2.0 was released with the introduction of the Handheld PC 2.0 at Fall Comdex 1997.
Windows CE 2.0 added networking support, including Windows standard network functions, a
Network Driver Interface Specification (NDIS) miniport driver model, and a generic NE2000 network
card driver. Added COM support allowed scripting, although the support was limited to in-proc
servers. A display driver model was also introduced that allowed for pixel depths other than the
original 2-bits-per-pixel displays of Windows CE 1.0. Windows CE 2.0 was also the first version of the
operating system to be released separately from a product such as the H/PC. Developers could
purchase the Windows CE Embedded Toolkit (ETK), which allowed them to customize Windows CE
to unique hardware platforms. Developers who used the ETK, however, soon found that the goal of the
product exceeded its functionality.

With the release of the original Palm-size PC in early 1998, Windows CE was improved yet again.
Although Windows CE 2.01 wasn’t released in an ETK form, it was notable for its effort to reduce the
size of the operating system and applications. In Windows CE 2.01, the C runtime library, which
includes functions such as strcpy to copy strings, was moved from a statically linked library attached to
each EXE and DLL into the operating system itself. This change dramatically reduced the size of both
the operating system and the applications themselves.

In August 1998, Microsoft introduced the H/PC Professional with a new version of the operating
system, 2.11. Windows CE 2.11 was a service pack update to Windows CE 2.1, which was never
formally released. Later in the year, Windows CE 2.11 was released to the embedded community as
Microsoft Windows CE Platform Builder version 2.11. This release included support for an improved
object store that allowed files in the object store to be larger than 4 MB. This release also added
support for a console and a Windows CE version of CMD.exe, the classic MS-DOS–style command
shell. Windows CE 2.11 also included Fast IR to support IrDA’s 4-MB infrared standard, as well as
some specialized functions for IP multicast. An initial hint of security was introduced in Windows CE
2.11: a device could now examine and reject the loading of unrecognized modules.

Windows CE 2.12 was also a service pack release to the 2.1, or Birch, release of Windows CE. The big
news in this release was a greatly enhanced set of Platform Builder tools that included a graphical front
end. The operating system was tweaked with a new notification interface that combined the disparate
notification functions. The notification user interface was exposed in the Platform Builder to allow
embedded developers to customize the notification dialog boxes. A version of Microsoft’s PC-based
Internet Explorer 4.0 was also ported to Windows CE as the Genie, or Generic IE control. This HTML
browser control complements the simpler but smaller Pocket Internet Explorer. Microsoft Message
Queue support was added as well. The “go/no go” security of Windows CE 2.11 was enhanced to
include a “go, but don’t trust” option. Untrusted modules can run—but not call—a set of critical
functions, nor can they modify parts of the registry.

The long-awaited Windows CE 3.0 was finally released in mid-2000. This release followed the April
release of the Pocket PC, which used a slightly earlier internal build of Windows CE 3.0. The big news
for Windows CE 3.0 was its kernel, which was optimized for better real-time support. The enhanced
kernel support includes 256 thread priorities (up from 8 in earlier versions of Windows CE), an
adjustable thread quantum, nested interrupt service routines, and reduced latencies within the kernel.

The improvements in Windows CE 3.0 didn’t stop at the kernel. A new COM component was added to
complement the in-proc COM support available since Windows CE 2.0. This new component included
full COM out-of-proc and DCOM support. The object store was also improved to support up to 256
MB of RAM. File size limits within the object store were increased to 32 MB per file. An Add-On
Pack for the Platform Builder 3.0 added even more features, including improved multimedia support
though a media player control; improved networking support (and XML support) with PPTP, ICS, and
remote desktop display support; and a formal introduction of the DirectX API.

The next release of Windows CE involved more than just new features; the name of the product was
also changed. Windows CE .NET 4.0, released in early 2001, changed the way virtual memory was
organized, effectively doubling the virtual memory space per application. Windows CE .NET 4.0 also
added a new driver loading model, services support, a new file-based registry option, Bluetooth,
802.11, and 1394 support. Ironically, while .NET was added to the name, Windows CE .NET 4.0
didn’t support the .NET Compact Framework.

Late in 2001, Windows CE 4.1 was a follow-on to Windows CE 4.0, adding IP v6, Winsock 2, a bunch
of new supporting applets, and an example Power Manager. Windows CE 4.1 also supports the .NET
Compact Framework. The final bits of the .NET runtime were released as a quick fix engineering
(QFE) package after the operating system shipped.

The second quarter of 2003 saw the release of Windows CE .NET 4.2. This update provided cool new
features for OEMs wanting to support Pocket PC applications on embedded systems. The Pocket
PC–specific APIs that support menu bars, the soft input panel (SIP), and other shell features were
moved to the base operating system. The Explorer shell was rewritten to support namespace
extensions. The performance of the kernel was improved by directly supporting hardware paging tables
on some CPUs.

Because Windows CE is a work in progress, the next version of Windows CE is being developed. I’ll
be updating my Web site, www.bolingconsulting.com, with information about this release as it
becomes available.
Why You Should Read This Book

Programming Microsoft Windows CE is written for anyone who will be writing applications for
Windows CE or the .NET Compact Framework. Embedded systems programmers using Windows CE
for a specific application, Windows programmers interested in writing or porting an existing Windows
application, and even developers of managed code can use the information in this book to make their
tasks easier.

The embedded systems programmer, who might not be as familiar with the Win32 API as the
Windows programmer, can read the first section of the book to become familiar with Windows
programming. Although this section isn’t the comprehensive tutorial that can be found in books such
as Programming Windows, by Charles Petzold, it does provide a base that will carry the reader through
the other chapters in the book. It can also help the embedded systems programmer develop fairly
complex and quite useful Windows CE programs.

The experienced Windows programmer can use the book to learn about the differences among the
Win32 APIs used by Windows CE and Windows XP. The differences between Windows CE and
Windows XP are significant. The small footprint of Windows CE means that many of the overlapping
APIs in the Win32 model aren’t supported. Some sections of the Win32 API aren’t supported at all. On
the other hand, because of its unique setting, Windows CE extends the Win32 API in a number of areas
that are covered in this text.

This book is also useful for the developer using the .NET Compact Framework. The Compact
Framework currently has gaps in its functionality: it requires managed applications to make calls to the
operating system to perform certain tasks. The book is a great guide to what’s available in the
operating system. A chapter in this book discusses the unique nature of developing managed code on
Windows CE–based devices.

The method used by Programming Windows CE is to teach by example. I wrote numerous Windows
CE example programs specifically for this book. The source for each of these examples is printed in
the text. Both the source and the final compiled programs for a number of the processors supported by
Windows CE are also provided on the accompanying CD.

The examples in this book are all written directly to the API, the so-called “Petzold” method of
programming. Since the goal of this book is to teach you how to write programs for Windows CE, the
examples avoid using a class library such as MFC, which obfuscates the unique nature of writing
applications for Windows CE. Some people would say that the availability of MFC on Windows CE
eliminates the need for direct knowledge of the Windows CE API. I believe the opposite is true.
Knowledge of the Windows CE API enables more efficient use of MFC. I also believe that truly
knowing the operating system also dramatically simplifies the debugging of applications.
What’s New in the Third Edition

The third edition of this book is a major revision that adds significant new text about a variety of
subjects from the Smartphone to Bluetooth. The book has been updated to cover the new features of
Windows CE .NET 4.2. New chapters have also been added to cover the Smartphone and the .NET
Compact Framework. A number of chapters have been significantly expanded to cover topics such as
OBEX, Bluetooth, and services. Other chapters have been reorganized to better present the topics.

A chapter has been added covering the Smartphone and the communication features of the Pocket PC
Phone Edition. This chapter covers how to write applications for the Smartphone 2003 device. Also
covered is how to write applications that work with the connection manager and send and receive
messages through the Short Message Service (SMS) system on both the Smartphone and the Pocket PC
Phone Edition.

There is a new chapter on the .NET Compact Framework. This chapter covers how to write managed
applications on Windows CE. After an introduction to managed applications, the chapter concentrates
on Windows Forms applications, the unique classes of the .NET Compact Framework. A significant
portion of the chapter covers how to call from managed code to unmanaged or native code since there
are times when the managed class library doesn’t provide the functionality necessary for the
application.

The device-to-device communication chapter contains coverage on Bluetooth and OBEX. Bluetooth is
a wireless communication standard that frankly isn’t well explained in many texts. This chapter
explains Bluetooth and provides a simple, straightforward example of its use. It also contains a section
on OBEX, the Object Exchange standard that’s used by both Bluetooth and Infrared Data Association
(IrDA). Another example in the chapter uses OBEX to send files to other devices over either Bluetooth
or IrDA.

The Pocket PC chapters have been updated to cover the new features of the Pocket PC 2003 devices.
The menu bar example from the Pocket PC chapter in the second edition of this book has been moved
to the common controls chapter, reflecting the move of the Pocket PC API to the general operating
system features in the latest version of Windows CE.

The drivers and services chapter has been updated to cover Windows CE services. Windows CE
services were introduced in Windows CE .NET 4.0. Services provide a way to have code running in
the background without the overhead of a separate process for the service. The operating system also
provides a super service that can monitor IP ports and notify a service when a client connects to that
port. A simple Windows CE service example is provided in the chapter, demonstrating how to write a
service and use the features of the super service.
For those owners of the first edition of this book, this edition contains all the new features of the
second edition as well. Those updates included extensive coverage of the Pocket PC and Windows CE
device drivers. Also, the new memory management and threading features that have been implemented
since the first edition was published make this edition a significant update.
.NET Compact Framework

A developer would have had to be on a desert island somewhere not to have heard of Microsoft’s .NET
initiative. This initiative consists of a run-time environment that isolates code from the hardware while
at the same time providing a type-safe runtime for increased security. A smaller version of this runtime
has been written for embedded and battery powered devices. The initial version of the .NET Compact
Framework runs on top of Windows CE on the Pocket PC and on embedded systems based on
Windows CE .NET 4.1 and later.

The unique requirements of embedded devices will make it a challenge to write applications using only
managed code. Embedded applications and some mobile applications require the application to be
tightly integrated with the device. Because one of the features of the runtime is to isolate the hardware
from the application, an embedded managed application sometimes needs to break the bounds of the
runtime and directly access some operating system functions.

As previously mentioned, the Compact Framework chapter spends a significant amount of time
discussing how managed applications can access the operating system. This discussion includes the
techniques for marshaling parameters across the managed/native code boundary—a task that’s
somewhat more difficult in the Compact Framework than on the desktop.
What About MFC?

I used to have a stock answer for people who asked me whether they should use MFC to build
Windows CE applications: Don’t do it! The old Windows CE systems with their slow CPUs were hard-
pressed to run complex, full-featured MFC applications. These days, I’m a little less dogmatic. The
newest Windows CE platforms are now fast enough to allow MFC-based applications to run with
reasonable performance. The MFC runtime library is included in ROM on these devices, so the
footprint of the application is simply the code, not the code plus the MFC runtime.

But just as speed and the runtime have been added to the platforms, the sun is setting on MFC.
Microsoft no longer pushes development of MFC applications. Instead, the .NET environment is the
development target of choice. So should you develop in MFC? I say no, not for new projects. For old
ones, there still is a place for MFC simply so that the projects don’t have to be ported to other tools.
Windows CE Development Tools

This book is written with the assumption that the reader knows C and is at least familiar with Microsoft
Windows. All native code development was done with Microsoft eMbedded Visual C++ under
Windows XP. To compile the example programs in this book, you need Microsoft eMbedded Visual
C++ 4.0, which is conveniently supplied on the companion CD. You also need the appropriate
platform SDKs for the Windows CE device you’re targeting.

Each example already has a predefined project set up, but you can also choose to create the projects
from scratch. For almost all the examples, simply create a generic WCE Application project. For the
examples that require access to functions unique to the Pocket PC, special code links to those
functions, even though the project settings don’t specifically define a Pocket PC application.

For developers who want to build applications that run on the Pocket PC 2000 and 2002, you need to
use Embedded Visual C++ 3.0. Unfortunately, there isn’t enough room on the companion CD for both
eVC 3 and eVC 4, but eVC 3 is available as a download from the Microsoft Web site. You’ll also need
the appropriate SDKs for those older Pocket PC systems. Many of the examples in the book can be
compiled for the older Pocket PC devices. Some examples, however, such as the Bluetooth, OBEX,
and services examples, use features that aren’t available on the older systems.

.NET Compact Framework applications are developed with Visual Studio .NET 2003. This tool isn’t
provided on the CD because it’s huge and, unfortunately for us programmers, not free. Still, this tool is
an incredibly productive development environment. For those interested in developing managed code,
the pain of the cost of upgrading is mitigated by the increase in developer productivity. You’ll need
Visual Studio .NET 2003 to compile the examples in the Compact Framework chapter. This tool
provides the necessary runtimes for all Pocket PC devices as well as embedded versions of Windows
CE based on version 4.1 or later.
Target Systems

You don’t need to have a Windows CE target device to experience the sample programs provided by
this book. The various platform SDKs come with a Windows CE emulator that lets you perform basic
testing of a Windows CE program under Windows XP. This emulator comes in handy when you don’t
have an actual device handy. The emulator runs a version of Windows CE inside a PC emulator which
results in an actual Windows CE operating system runtime executing on the PC.

You should consider a number of factors when deciding which Windows CE hardware to use for
testing. First, if the application is to be a commercial product, you should buy at least one system for
each type of target CPU. You need to test against all the target CPUs because, although the source
code will probably be identical, the resulting executable will be different in size and so will the
memory allocation footprint for each target CPU.
What’s on the CD

The companion CD contains the source code for all the examples in the book. I’ve also provided
project files for Microsoft eMbedded Visual C++ so that you can open preconfigured projects. All the
examples have been designed to compile for systems based on Windows CE 4.2, Pocket PC 2003, and
Smartphone 2003.

In addition to the examples, the CD also includes a free copy of Microsoft eMbedded Visual C++ 4.0.
This is the same full-featured eMbedded Visual C++ product that you can download from Microsoft’s
Web site or pay to have sent to you on CD. Consider these tools the prize in the Cracker Jack box. Also
included is the platform SDK for the Pocket PC 2003.

The companion CD contains a StartCD program that provides you with a graphical interface from
which you can access the contents of the CD. This program will autorun when the CD is inserted into
your CD-ROM drive if you have that feature enabled in Windows. If you don’t have autorun enabled,
just navigate to the root directory of the CD and run StartCD.exe from Windows Explorer. The file
Readme.txt, available from the StartCD program or in the root directory of the CD, will give you
additional information about the contents of the CD, system requirements for the included tools and
SDK, and information about support options for the included products.

The following are the system requirements for installing and running Microsoft eMbedded Visual C++.
Please note that to run the eMbedded Visual C++, you’ll need to be using Windows 2000, Windows
XP, or Windows Server 2003.

PC with Pentium processor; Pentium 150 MHz or higher processor recommended

Microsoft Windows XP, Windows 2000 Service Pack 2 (or later) or Windows Server 2003

32 MB of RAM (48 MB recommended)

Hard disk space required: minimum installation: about 360 MB; complete installation: about 720
MB

CD-ROM drive compatible with multimedia PC specification

VGA or higher-resolution monitor required; Super VGA recommended

Microsoft Mouse or compatible pointing device

Other Sources

Although I have attempted to make Programming Microsoft Windows CE a one-stop shop for
Windows CE programming, no one book can cover everything. To learn more about Windows
programming in general, I suggest the classic text Programming Windows (Microsoft Press, 1998) by
Charles Petzold. This is, by far, the best book for learning Windows programming. Charles presents
examples that show how to tackle difficult but common Windows problems. To learn more about the
Win32 kernel API, I suggest Jeff Richter’s Programming Applications for Microsoft Windows
(Microsoft Press, 1999). Jeff covers the techniques of process, thread, and memory management down
to the most minute detail. For learning more about MFC programming, there’s no better text than Jeff
Prosise’s Programming Windows with MFC (Microsoft Press, 1999). This book is the “Petzold” of
MFC programming and simply a required read for MFC programmers.

To learn more about .NET programming, I recommend Programming Windows with C# (Microsoft
Press, 2002), by Charles Petzold. Charles has applied his amazing skills to the Windows Forms part of
the .NET Framework. This is a great book to come up to speed on the client side of .NET
programming.
Support

Every effort has been made to ensure the accuracy of this book and the contents of the sample files on
the CD-ROM. Microsoft Press provides corrections and additional content for its books through the
World Wide Web at this location:

http://www.microsoft.com/mspress/support/

If you have problems, comments, or ideas regarding this book or the CD-ROM, please send them to
Microsoft Press.

Send e-mail to

mspinput@microsoft.com

Or send postal mail to

Microsoft Press

Attn: Programming Microsoft Windows CE, Third Edition, Editor

One Microsoft Way

Redmond, WA 98052-6399

Please note that product support is not offered through these mail addresses. For further information
regarding Microsoft software support options, please go to http://support.microsoft.com/directory/ or
call Microsoft Support Network Sales at (800) 936-3500.

Visit the Microsoft Press Web Site

You are also invited to visit the Microsoft Press World Wide Web site at the following location:

http://www.microsoft.com/mspress/

You’ll find descriptions for the complete line of Microsoft Press books, information about ordering
titles, notice of special features and events, additional content for Microsoft Press books, and much
more.
You can also find out the latest in Microsoft Windows CE .NET software developments and news from
Microsoft Corporation by visiting the following Web site:

http://www.microsoft.com/windows/embedded/ce.net/
Updates and Feedback

No book about Windows CE can be completely current for any length of time. I maintain a Web page,
http://www.bolingconsulting.com/cebook.htm, where I’ll keep a list of errata, along with updates
describing any features found in subsequent versions of Windows CE. Check out this page to see
information on new versions of Windows CE as they’re released.

Although I have striven to make the information in this book as accurate as possible, you’ll
undoubtedly find errors. If you find a problem with the text or just have ideas about how to make the
next version of the book better, please drop me a note at CEBook@bolingconsulting.com. I can’t
promise you that I’ll answer all your notes, but I will read every one.

Doug Boling

Tahoe City, California

April 2003
Part I
Windows Programming Basics
Chapter 1
Hello Windows CE
Since the classic The C Programming Language, programming books traditionally start with a “hello,
world” program. It’s a logical place to begin. Every program has a basic underlying structure that,
when not obscured by some complex task it was designed to perform, can be analyzed to reveal the
foundation shared by all programs running on its operating system.

In this programming book, the “hello, world” chapter covers the details of setting up and using the
programming environment. The environment for developing Microsoft Windows CE applications is
somewhat different from that for developing standard Microsoft Windows applications because
Windows CE programs are written on PCs running Microsoft Windows XP and debugged mainly on
separate Windows CE–based target devices.

While experienced Windows programmers might be tempted to skip this chapter and move on to
meatier subjects, I suggest that they—you—at least skim the chapter to note the differences between a
standard Windows program and a Windows CE program. A number of subtle and significant
differences in both the development process and the basic program skeleton for Windows CE
applications are covered in this first chapter.
What Is Different About Windows CE

Windows CE has a number of unique characteristics that make it different from other Windows
platforms. First of all, the systems running Windows CE are most likely not using an Intel
x86–compatible microprocessor. Instead, Windows CE runs on 4 different CPU families, SHx, MIPS,
ARM, and x86. Fortunately, the development environment isolates the programmer from almost all of
the differences among the various CPUs.

Nor can a Windows CE program be assured of a screen or a keyboard. Pocket PC devices have a 240-
by-320-pixel portrait-style screen, while other systems might have screens with more traditional
landscape orientations in 480-by-240, 640-by-240, or 640-by-480-pixel resolution. An embedded
device might not have a display at all. The target devices might not support color. And, instead of a
mouse, most Windows CE devices have a touch screen. On a touch-screen device, left mouse button
clicks are achieved by means of a tap on the screen, but no obvious method exists for delivering right
mouse button clicks. To give you some method of delivering a right click, the Windows CE convention
is to hold down the Alt key while tapping. It’s up to the Windows CE application to interpret this
sequence as a right mouse click.

Fewer Resources in Windows CE Devices

The resources of the target devices vary radically across systems that run Windows CE. When writing
a standard Windows program, the programmer can make a number of assumptions about the target
device, almost always an IBM-compatible PC. The target device will have a hard disk for mass storage
and a virtual memory system that uses the hard disk as a swap device to emulate an almost unlimited
amount of (virtual) RAM. The programmer knows that the user has a keyboard, a two-button mouse,
and a monitor that these days almost assuredly supports 256 colors and a screen resolution of at least
800 by 600 pixels.

Windows CE programs run on devices that almost never have hard disks for mass storage. The absence
of a hard disk means more than just not having a place to store large files. Without a hard disk, virtual
RAM can’t be created by swapping data to the disk. So Windows CE programs are almost always run
in a low-memory environment. Memory allocations can, and often do, fail because of the lack of
resources. Windows CE might terminate a program automatically when free memory reaches a
critically low level. This RAM limitation has a surprisingly large impact on Windows CE programs
and is one of the main challenges involved in porting existing Windows applications to Windows CE.
Unicode

One characteristic that a programmer can count on when writing Windows CE applications is Unicode.
Unicode is a standard for representing a character as a 16-bit value as opposed to the ASCII standard
of encoding a character into a single 8-bit value. Unicode allows for fairly simple porting of programs
to different international markets because all the world’s known characters can be represented in one of
the 65,536 available Unicode values. Dealing with Unicode is relatively painless as long as you avoid
the dual assumptions made by most programmers that strings are represented in ASCII and that
characters are stored in single bytes.

A consequence of a program using Unicode is that with each character taking up two bytes instead of
one, strings are now twice as long. A programmer must be careful making assumptions about buffer
length and string length. No longer should you assume that a 260-byte buffer can hold 259 characters
and a terminating zero. Instead of the standard char data type, you should use the TCHAR data type.
TCHAR is defined to be char for Microsoft Windows 95 and Microsoft Windows 98 development and
unsigned short for Unicode-enabled applications for Microsoft Windows 2000, Windows XP, and
Windows CE development. These types of definitions allow source-level compatibility across ASCII-
and Unicode-based operating systems.

New Controls

Windows CE includes a number of new Windows controls designed for specific environments. New
controls include the command bar and menu bar controls that provide menu- and toolbar-like functions
all on one space-saving line, critical on the smaller screens of Windows CE devices. Other controls
have been enhanced for Windows CE. A version of the edit control in Windows CE can be set to
automatically capitalize the first letter of a word, great for the keyboardless design of a PDA. Windows
CE also supports most of the controls available on desktop versions of Windows. Some of these
controls are even more at home on Windows CE devices than on the desktop. For example, the date
and time picker control and calendar control assist calendar and organizer applications suitable for
handheld devices, such as the Handheld PC (H/PC) and the Pocket PC. Other standard Windows
controls have reduced function, reflecting the compact nature of Windows CE hardware-specific OS
configurations.

Componentization

Another aspect of Windows CE programming to be aware of is that Windows CE can be broken up and
reconfigured by Microsoft or by OEMs so that it can be better adapted to a target market or device.
Windows programmers usually just check the version of Windows to see whether it is from the
 Microsoft Windows 95, 98, or Me line or Windows 2000, XP line; by knowing the version they can
determine what API functions are available to them. Windows CE, however, can be configured in
countless ways.

By far, the most popular configuration of Windows CE today is the Pocket PC. Microsoft defines the
specific set of Windows CE components that are present in all Pocket PC–branded devices. However,
some OEMs produce PDA devices that use Windows CE but are not branded as Pocket PCs. These
devices have a subtly different API from that of the Pocket PC devices. If you are unaware of this, you
can easily write a program that works on one platform but not on another. In embedded platforms, the
OEM decides the components to include and can create a Software Development Kit (an SDK)
specialized for its specific platform. If the OEM is interested in third-party development, it can make
available a customized SDK for its device. New platforms are continually being released, with much in
common but also with many differences among them. Programmers need to understand the target
platform and to have their programs check what functions are available on that particular platform
before trying to use a set of functions that might not be supported on that device.

Win32 Subset

Finally, because Windows CE is so much smaller than Windows XP, it simply can’t support all the
function calls that its larger cousins do. While you’d expect an operating system that didn’t support
printing, such as Windows CE on the original models, not to have any calls to printing functions,
Windows CE also removes some redundant functions supported by its larger cousins. If Windows CE
doesn’t support your favorite function, a different function or set of functions will probably work just
as well. Sometimes Windows CE programming seems to consist mainly of figuring out ways to
implement a feature using the sparse API of Windows CE. If thousands of functions can be called
sparse.
It’s Still Windows Programming

While differences between Windows CE and the other versions of Windows do exist, they shouldn’t be
overstated. Programming a Windows CE application is programming a Windows application. It has the
same message loop, the same windows, and for the most part, the same resources and the same
controls. The differences don’t hide the similarities. One of the key similarities is the tradition of
Hungarian notation.

Hungarian Notation

A tradition, and a good one, of almost all Windows programs since Charles Petzold wrote
Programming Microsoft Windows is Hungarian notation. This programming style, developed years ago
by Charles Simonyi at Microsoft, prefixes all variables in the program usually with one or two letters
indicating the variable type. For example, a string array named Name would instead be named szName,
with the sz prefix indicating that the variable type is a zero-terminated string. The value of Hungarian
notation is the dramatic improvement in readability of the source code. Another programmer, or you
after not looking at a piece of code for a while, won’t have to look repeatedly at a variable’s
declaration to determine its type. Table 1-1 shows typical Hungarian prefixes for variables.

Table 1-1. Hungarian Prefixes for Variables

Variable Type Hungarian Prefix

Integer i or n

Word (16-bit) w or s

Double word (32-bit unsigned) Dw

Long (32-bit signed) L
Char C

String Sz
Pointer P
Long pointer lp
 Variable Type Hungarian Prefix

Handle h

Window handle hwnd

Struct size cb

You can see a few vestiges of the early days of Windows. The lp, or long pointer, designation refers to
the days when, in the Intel 16-bit programming model, pointers were either short (a 16-bit offset) or
long (a segment plus an offset). Other prefixes are formed from the abbreviation of the type. For
example, a handle to a brush is typically specified as hbr. Prefixes can be combined, as in lpsz, which
designates a long pointer to a zero-terminated string. Most of the structures defined in the Windows
API use Hungarian notation in their field names. I use this notation as well throughout this book, and I
encourage you to use this notation in your programs.
Your First Windows CE Application

Enough talk; let’s look at your first Windows CE program. Listing 1-1 shows Hello1, a simple Hello
World application written for Windows CE.

Listing 1-1. Hello1, A simple Windows application

Hello1.cpp
//======================================================================
// Hello1 - A simple application for Windows CE
//
// Written for the book Programming Windows CE
// Copyright (C) 2003 Douglas Boling
//======================================================================
#include "windows.h"

//
// Program entry point
//
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow) {

printf ("Hello World\n");

return 0;
}

As you can see, aside from the entry point of the program, the code looks fairly similar to the classic
Kernighan and Ritchie version. Starting from just below the comments, we have the line

#include "windows.h"

which is the root of a vast array of include files that define the Windows CE API, as well as the
structures and constants they use.

The entry point of the program is the biggest difference between this program and a standard C
program. Instead of the C standard

int main (char **argv, int argc)

the Windows CE build environment expects the standard Windows entry point, While it is technically
possible to change the entry point prototype to match the C standard entry point, it typically isn’t worth
the trouble. as in

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPWSTR lpCmdLine, int nCmdShow);

Windows CE differs in some ways from the desktop versions of Windows. The first of the four
parameters passed, hInstance, identifies the specific instance of the program to other applications and
to Windows API functions that need to identify the EXE. The hPrevInstance parameter is left over
from the old Win16 API (Windows 3.1 and earlier). In all Win32 operating systems, including
Windows CE, hPrevInstance is always 0 and can be ignored.

The lpCmdLine parameter points to a Unicode string that contains the text of the command line.
Applications launched from Microsoft Windows Explorer usually have no command-line parameters.
But in some instances, such as when the system automatically launches a program, the system includes
a command-line parameter to indicate why the program was started. The lpCmdLine parameter
provides us with one of the first instances in which Windows CE differs from Windows XP. Under
Windows CE, the command-line string is a Unicode string. In all other versions of Windows, the string
is always ASCII.

The final parameter, nCmdShow, specifies the initial state of the program’s main window. It is passed
by the parent application, usually Explorer, and is a recommendation of how the application should
configure its main window. This parameter might specify that the window be initially displayed as an
icon (SW_SHOWMINIMIZE), maximized (SW_SHOWMAXIMIZED) to cover the entire desktop, or
normal (SW_RESTORE), indicating that the window is placed on the screen in the standard resizeable
state. Other values specify that the initial state of the window should be invisible to the user or that the
window should be visible but incapable of becoming the active window. Under Windows CE, the
values for this parameter are limited to only three allowable states: normal (SW_SHOW), hidden
(SW_HIDE), and show without activate (SW_SHOWNOACTIVATE). Unless an application needs to
force its window to a predefined state, this parameter is simply passed without modification to the
ShowWindow function after the program’s main window has been created.

The next line is the only functioning line of the application.

printf ("Hello World\n");

Windows CE supports most of the standard C library, including printf, getchar, and so forth. An
interesting aspect of this line is that unlike almost everywhere else in Windows CE, the string is not
Unicode but ANSI. There is a logical reason for this. For the C standard library to be compliant with
the ANSI standard, printf and the other string library functions such as strcpy use ANSI strings. Of
course, Windows CE supports the Unicode versions of the standard functions such as wprintf,
getwchar, and wcscpy.
 Finally the program ends with

return 0;

The value passed in the return line is available to other processes that use the Win32 API
GetExitCodeProcess.

Building Your First Application

To create Hello1 from scratch on your system, start Microsoft eMbedded Visual C++ and create a new
project by selecting the New command on the File menu. The first change from standard Win32
programming becomes evident when you see the new project dialog box. You’ll have the opportunity
to select from a number of platforms, as shown in Figure 1-1. For non-MFC or ATL projects, the chief
decision is to choose between WCE Pocket PC Application (to build code for a Pocket PC) and WCE
Application (for all other Windows CE systems). You’ll also pick the allowable target CPUs. For
example, selecting Win32 (WCE MIPII) enables compiling to a Windows CE platform with a MIPS
CPU. No matter what target device you have, be sure to check the WCE emulator target. This allows
you to run the sample program in the emulator under Windows XP.

Figure 1-1. The Platforms list box allows eMbedded Visual C++ to target different Windows CE
 platforms

eMbedded Visual C++ will next ask you whether you want to create an empty project, a simple
program, or a Hello World application. For all the examples in this book, pick Empty Project. This
choice prevents the code wizards from adding any extra code to the examples. Create new files for
Hello1.cpp from the File menu by clicking New.

After you have created the proper source files for Hello1 or copied them from the CD, select the target
Win32 (WCE x86em) Debug and then build the program. This step compiles the source and, assuming
you have no compilation errors, automatically launches the emulator and inserts the EXE into the
emulator file system; you can then launch Hello1. If you’re running Windows 98 or Windows Me, the
system displays an error message because the emulator runs only under Windows 2000 or Windows
XP.

If you have a Windows CE system available, such as a Pocket PC (PPC), attach the PPC to the PC the
same way you would to sync the contents of the PPC with the PC. Open Microsoft ActiveSync, and
establish a connection between the PPC and the PC. While it’s not strictly necessary to have the
ActiveSync connection to your Windows CE device running (eMbedded Visual C++ is supposed to
make this connection automatically), I’ve found that having it running makes for a more stable
connection between the development environment and the Windows CE system.

Once the link between the PC and the Windows CE device is up and running, switch back to
eMbedded Visual C++, select the compile target appropriate for the target device (for example, Win32
[WCE ARM] Debug for an iPaq Pocket PC), and rebuild. As in the case of building for the emulator, if
there are no errors, eMbedded Visual C++ automatically downloads the compiled program to the
remote device. The program is placed either in the root directory of the object store or, in the case of
the Pocket PC, in the \windows\start menu directory.

Running the Program

To run Hello1 on an embedded Windows CE deviceH/PC, simply click on the My ComputerHandheld

PC icon to bring up the files in the root directory. At that point, a double-tap on the application’s icon
launches the program.

To run the program on a Pocket PC, simply select the program from the Start menu on the device. The
program appears there because eMbedded Visual C++ downloads the application to be the
\windows\start menu directory. This way, a downloaded application is automatically visible on the
Start menu.

What’s Wrong?
If you start Hello1 by clicking on the icon or by selecting the program on the start menu of a Pocket
PC, nothing seems to happen. On a Handheld PC, the program appears to make the screen flash. This is
because the program starts, writes to the console, and terminates. Unless you start the program from an
already created console, Windows CE creates the console window when Hello1 executes the printf
statement and closes the console automatically when Hello1 terminates.

On a Pocket PC, the application runs, but the Pocket PC doesn’t come with support to display the
console functions such as the output from printf. It’s possible to add console support to a Pocket PC by
adding a driver, console.dll, to the Windows directory of the Pocket PC. That driver must be written to
take input from the driver interface, create a window on the screen, and print out the strings. The
console driver available on Handheld PCs and in embedded versions of Windows CE does this.
Hello2

Now that we have the basics down, it’s time to upgrade Hello1 to something you can at least see.
Because many Windows CE systems don’t have the console driver, Hello2 creates a message box with
the “Hello CE” text instead of using printf. Hello2 is shown in Listing 1-2.

Listing 1-2. Hello2, a simple Windows application using the MessageBox function

Hello2.cpp
//======================================================================
// Hello2 - A simple application for Windows CE
//
// Written for the book Programming Windows CE
// Copyright (C) 2003 Douglas Boling
//======================================================================
#include "windows.h"

//
// Program entry point
//
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow) {

MessageBox (NULL, TEXT ("Hello World"), TEXT ("Hello2"), MB_OK);

return 0;
}

When you compile and run Hello2, you should see a small window like the one shown in Figure 1-2.
Figure 1-2. Hello2 running on a Windows CE desktop

The MessageBox function that replaces printf provides two features for Hello2. First and most obvious,
it creates a window and places the “Hello World” text in the window. The second feature is that the
MessageBox function doesn’t return until the user closes the message box window. This feature allows
Hello2 to keep running until the user dismisses the window.

The MessageBox function is prototyped as

int MessageBox (HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);

The first parameter of MessageBox is the handle to the top-level window that will be the parent of the
message box when it is displayed. For now, we can leave this parameter NULL because Hello2 doesn’t
have any other windows. The second parameter is the text that appears in the window. Notice that the
string passed is couched in the TEXT macro, ensuring that it will be compiled as Unicode. The third
parameter, lpCaption, is the text that will appear in the title bar of the window. The last parameter,
uType, is a series of flags that specify how the message box appears on the screen. The flags specify
the number and type of buttons on the message box; the icon, if any, on the message box; and the
settings of style flags for the message box window.

The flags listed in Table 1-2 are valid under Windows CE.

Table 1-2. Default Flags

Flags Button or Icon

For Buttons:
MB_OK OK
MB_OKCANCEL OK and Cancel

MB_RETRYCANCEL Retry and Cancel

 Flags Button or Icon

MB_YESNO Yes and No

MB_YESNOCANCEL Yes, No, and Cancel

MB_ABORTRETRYIGNORE Abort, Retry, and Ignore

For Icons:

MB_ICONEXCLAMATION, MB_ICONWARNING Exclamation point

MB_ICONINFORMATION, MB_ICONASTERISK Lower case i within a circle
MB_ICONQUESTION Question mark

MB_YESNO Yes and No

MB_ICONSTOP, MB_ICONERROR, Stop sign

MB_ICONHAND

MB_DEFBUTTON1 First button

MB_DEFBUTTON2 Second button

MB_DEFBUTTON3 Third button

For Window Styles:

MB_SETFOREGROUND Bring the message box to the foreground.

MB_TOPMOST Make the message box the topmost
window.

The return value from MessageBox indicates the button pressed by the user. The return values are as
follows:

IDOK OK button pressed

IDYES Yes button pressed
IDNO No button pressed

IDCANCEL Cancel button pressed or Esc key pressed

IDABORT Abort button pressed
 IDOK OK button pressed

IDRETRY Retry button pressed

IDIGNORE Ignore button pressed

MessageBox is a handy function to have an application display a simple but informative dialog box.

One gotcha to look out for here: If you’re debugging and recompiling the program, it can’t be
downloaded again if an earlier version of the program is still running on the target system. That is,
make sure Hello2 isn’t running on the remote system when you start a new build in eMbedded Visual
C++, or the autodownload part of the compile process will fail. If this happens, close the application
and choose the Update Remote File menu command in eMbedded Visual C++ to download the newly
compiled file.

Hello2 displays a simple window, but that window is only as configurable as the MessageBox function
allows. How about showing a window that is completely configurable by the application? Before we
can do that, a quick review of how a Windows application really works is in order.
Anatomy of a Windows-Based Application

Windows-based programming is far different from MS-DOS–based or Unix-based programming. An

MS-DOS or Unix program uses getc- and putc-style functions to read characters from the keyboard
and write them to the screen whenever the program needs to do so. This is the classic “pull” style used
by MS-DOS and Unix programs, which are procedural. A Windows program, on the other hand, uses a
“push” model, in which the program must be written to react to notifications from the operating system
that a key has been pressed or a command has been received to repaint the screen.

Windows applications don’t ask for input from the operating system; the operating system notifies the
application that input has occurred. The operating system achieves these notifications by sending
messages to an application window. All windows are specific instances of a window class. Before we
go any further, let’s be sure we understand these terms.

The Window Class

A window is a region on the screen, rectangular in all but the most contrived of cases, that has a few
basic parameters, such as position—x, y, and z (a window is over or under other windows on the
screen)—visibility, and hierarchy—the window fits into a parent/child window relationship on the
system desktop, which also happens to be a window.

Every window created is a specific instance of a window class. A window class is a template that
defines a number of attributes common to all the windows of that class. In other words, windows of the
same class have the same attributes. The most important of the shared attributes is the window
procedure.

The Window Procedure

The behavior of all windows belonging to a class is defined by the code in its window procedure for
that class. The window procedure handles all notifications and requests sent to the window. These
notifications are sent either by the operating system, indicating that an event has occurred to which the
window must respond, or by other windows querying the window for information.

These notifications are sent in the form of messages. A message is nothing more than a call being made
to a window procedure, with a parameter indicating the nature of the notification or request. Messages
 are sent for events such as a window being moved or resized or to indicate a key press. The values used
to indicate messages are defined by Windows. Applications use predefined constants, such as
WM_CREATE and WM_MOVE, when referring to messages. Since hundreds of messages can be sent,
Windows conveniently provides a default processing function to which a message can be passed when
no special processing is necessary by the window class for that message.

The Life of a Message

Stepping back for a moment, let’s look at how Windows coordinates all of the messages going to all of
the windows in a system. Windows monitors all the sources of input to the system, such as the
keyboard, mouse, touch screen, and any other hardware that could produce an event that might interest
a window. As an event occurs, a message is composed and directed to a specific window. Instead of
Windows directly calling the window procedure, the system imposes an intermediate step. The
message is placed in a message queue for the application that owns the window. When the application
is prepared to receive the message, it pulls it out of the queue and tells Windows to dispatch that
message to the proper window in the application.

If it seems to you that a number of indirections are involved in that process, you’re right. Let’s break it
down.

1. An event occurs, so a message is composed by Windows and placed in a message queue for the
application that owns the destination window. In Windows CE, as in Windows XP, each application
has its own unique message queue. Technically, each thread in a Windows CE application can have
a message queue. I’ll talk about threads later in the book. (This is a break from Windows 3.1 and
earlier versions of Windows, where there was only one, systemwide, message queue.) Events can
occur, and therefore messages can be composed, faster than an application can process them. The
queue allows an application to process messages at its own rate, although the application had better
be responsive or the user will see a jerkiness in the application. The message queue also allows
Windows to set a notification in motion and continue with other tasks without having to be limited
by the responsiveness of the application to which the message is being sent.

2. The application removes the message from its message queue and calls Windows back to dispatch
the message. While it may seem strange that the application gets a message from the queue and then
simply calls Windows back to process the message, there’s a method to this madness. Having the
application pull the message from the queue allows it to preprocess the message before it asks
Windows to dispatch the message to the appropriate window. In a number of cases, the application
might call different functions in Windows to process specific kinds of messages.

3. Windows dispatches the message; that is, it calls the appropriate window procedure. Instead of
3.
having the application directly call the window procedure, another level of indirection occurs,
allowing Windows to coordinate the call to the window procedure with other events in the system.
The message doesn’t stand in another queue at this point, but Windows might need to make some
preparations before calling the window procedure. In any case, the scheme relieves the application
of the obligation to determine the proper destination window—Windows does this instead.

4. The window procedure processes the message. All window procedures have the same calling
parameters: the handle of the specific window instance being called, the message, and two generic
parameters that contain data specific to each message type. The window handle differentiates each
instance of a window for the window procedure. The message parameter, of course, indicates the
event that the window must react to. The two generic parameters contain data specific to the
message being sent. For example, in a WM_MOVE message indicating that the window is about to
be moved, one of the generic parameters points to a structure containing the new coordinates of the
window.
Hello3

Enough review. It’s time to jump into a full-fledged Windows application, Hello3. While the entire
program files for this and all examples in the book are available in the companion CD-ROM, I suggest
that, as in the earlier example, you avoid simply loading the project file from the CD and instead type
in the entire example by hand. By performing this somewhat tedious task, you’ll see the differences in
the development process as well as the subtle program differences between standard Win32 programs
and Windows CE programs. Listing 1-3 contains the complete source code for Hello3.

Listing 1-3. The Hello3 program

Hello3.cpp
//======================================================================
// Hello3 - A simple application for Windows CE
//
// Written for the book Programming Windows CE
// Copyright (C) 2003 Douglas Boling
//======================================================================
#include <windows.h> // For all that Windows stuff

LRESULT CALLBACK MainWndProc (HWND, UINT, WPARAM, LPARAM);

//======================================================================
// Program entry point
//
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow) {
WNDCLASS wc;
HWND hWnd;
MSG msg;

// Register application main window class.

wc.style = 0; // Window style
wc.lpfnWndProc = MainWndProc; // Callback function
wc.cbClsExtra = 0; // Extra class data
wc.cbWndExtra = 0; // Extra window data
wc.hInstance = hInstance; // Owner handle
wc.hIcon = NULL, // Application icon
wc.hCursor = LoadCursor (NULL, IDC_ARROW);// Default cursor
wc.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH);
Other documents randomly have
different content
 “FIGITUR IN JUSSO NOSTRA SAGITTA LOCO.”—Ovid.

The Broad Arrow and Naval & Military Gazette

has by far the largest circulation of all the Military Papers. This
results from the reputation it has acquired for early and exclusive
intelligence, from the high character of its articles, the independent
course of its staff of writers, and from its earnest support of all
measures for the good of the Services. Articles on specially
interesting subjects appear from week to week written for the most
part by officers of rank and experience, or by men of note in
literature who have made the Naval and Military affairs of the
country their special study.

The Broad Arrow and

The ordinary weekly issue of
Naval & Military Gazette contains fully one-fourth more
matter than the other Service Journals, even with their frequent
supplements.

The Broad Arrow and Naval & Military

Gazette circulates largely throughout India and the Colonies. It is
supplied direct to the Army and Marine bureaux of the French,
Russian, and other Governments, and it is read extensively by
Officers of Foreign Services, especially of the German, French, and
American Armies, who desire to acquire a true impression of facts
and public opinion in England regarding Military affairs.

Offices:—No. 6 LANCASTER PLACE,

STRAND, W.C.
 Crown 8vo. cloth, with Illustrations, 5s.

WORKSHOP RECEIPTS,
FIRST SERIES.
BY ERNEST SPON.
SYNOPSIS OF CONTENTS.
Bookbinding—Bronzes and Bronzing—Candles—Cement—Cleaning
—Colour-washing—Concretes—Dipping Acids—Drawing Office Details
—Drying Oils—Dynamite—Electro-Metallurgy—Enamels—Engraving
on Wood, Copper, Gold, Silver, Steel, and Stone—Etching and Aqua
Tint—Firework Making—Fluxes—Foundry Mixtures—Freezing—
Fulminates—Furniture Creams, Oils, Polishes, Lacquers, and Pastes—
Gilding—Glass Cutting, Cleansing, Frosting, Drilling, Darkening,
Bending, Staining, and Painting—Glass Making—Glues—Gold—
Graining—Gums—Gun Cotton—Gunpowder—Horn Working—
Indiarubber—Japans, Japanning, and kindred processes—Lacquers—
Lathing—Lubricants—Marble Working—Matches—Mortars—Nitro-
Glycerine—Oils—Paper—Paper Hanging—Painting in Oils, in Water
Colours, as well as Fresco, House, Transparency, Sign, and Carriage
Painting—Photography—Plastering—Polishes—Scouring—Silvering—
Soap— Solders—Tanning—Taxidermy—Tempering Metals—Treating
Horn, Mother-o’-Pearl, and like substances—Varnishes, Manufacture
and Use of—Veneering—Washing—Waterproofing—Welding.
Besides Receipts relating to the lesser Technological matters and
processes, such as the manufacture and use of Stencil Plates,
Blacking, Crayons, Paste, Putty, Wax, Size, Alloys, Catgut, Tunbridge
Ware, Picture Frame and Architectural Mouldings, Compos, Cameos,
and others too numerous to mention.
 In Demy 8vo. cloth, 600 pages, and 1420 Illustrations, 6s.

S P O N S’
MECHANICS’ OWN BOOK;
A MANUAL FOR HANDICRAFTSMEN AND
AMATEURS.
PRINCIPAL CONTENTS.
Mechanical Drawing—Casting and Founding—Forging and
Finishing Iron—Sheetmetal Working—Soldering, Brazing, and
Burning—Carpentry and Joinery—Details of Construction of
Workshop appliances, Rough Furniture, Garden and Yard Erections,
and House Building—Cabinet-Making and Veneering—Carving and
Fretcutting—Upholstery—Painting, Graining, and Marbling—Staining
Furniture, Woods, Floors, and Fittings—Gilding—Polishing Marble,
Metals, and Wood—Varnishing—Mechanical Movements—Turning in
Wood and Metals—Masonry—Roofing—Glazing—Plastering—
Whitewashing—Paperhanging—Gas-fitting—Bell-hanging, Ordinary,
and Electric Systems, &c. &c.
London: E. & F. N. SPON, 125, Strand.
Mr. WOLFFRAM, The Manor House,
Lee, London, S.E.
WITH A TEACHING STAFF OF TWENTY-THREE INSTRUCTORS,
PREPARES CANDIDATES FOR ALL ARMY
EXAMINATIONS.
SANDHURST, WOOLWICH, AND DIRECT
COMMISSIONS.
402 Candidates have passed the competitive Examinations direct
from Mr. Wolffram Establishment into the Royal Military
College, Sandhurst, and the Royal Military Academy,
Woolwich, and for Direct Commissions. This sum total has
never been equalled by any tutor in or out of London.
MILITIA MILITARY COMPETITIVE EXAMINATIONS.
257 Militia Officers have passed from Mr. Wolffram Establishment,
and during the last three years the first place has been taken three
times:—

1888{ 1st 1760

Lieut. A. Martyn
place marks.
1889{ 1st 1929
Lieut. C. H. Turner
place marks.
1890{ 1st Lieut. S. Fitzgerald 2034
place Cox marks.

The Militia Military Competitive Classes are under the direction of

Lieut.-Colonel J. L. Needham, R.M.A., P.S.C., late Professor of
Fortification and Instructor of Tactics and Military Topography at the
R.N. College, Greenwich, and formerly Garrison Instructor.
 PRELIMINARY ARMY EXAMINATION.
In addition to the above numbers, 364 Candidates have passed
the Preliminary Army Examinations in all subjects.
BIENNIAL TOTALS from 1872 to 1889 of SUCCESSFUL ARMY
CANDIDATES,
Who have passed from Mr. Wolffram for Woolwich, Sandhurst, Direct
Commissions, and Commissions through the Militia:—

1872 and
Eight 8
1873
1874 and
Thirty-eight 38
1875
1876 and
Fifty-six 56
1877
1878 and
Sixty-seven 67
1879
1880 and
Sixty-two 62
1881
1882 and
Eighty-one 81
1883
1884 and One hundred and
107
1885 seven
1886 and One hundred and
121
1887 twenty-one
1888 and One hundred and 122
1889 twenty-two
Six hundred and sixty-
Total 662
two

N.B.—The above Lists include only pupils who were reading in Mr.
Wolffram Establishment up to the date of the Examination in
question.
 NOTICE.
In compliance with the wishes of several clients, Mr. Wolffram will
open in London in January, 1891, for Non-Resident Students only, a
Branch Establishment of Classes for the Militia Military Competitive
Examinations.
All applications to be addressed to H. WOLFFRAM, The Manor
House, Lee, London, S.E.
 SOLE OBJECT OF THE SOCIETY—
TO SPREAD THE SAVING KNOWLEDGE OF CHRIST AMONG
OUR SOLDIERS.
The Committee make an EARNEST APPEAL FOR FUNDS to all who
have the religious and moral elevation of our Army at heart, and
who would wish to see the hands of the Military Chaplains
strengthened by the assistance of a body of men of the Soldiers’
own station in life, who, without the restraint unavoidable in the
intercourse of different classes of Society, may commend to them
the love of Christ, read to them the Word of Life, and strive to lead
them from the deceitful pleasures of sin to that peace which the
world can neither give nor take away.
There are now 90 Scripture Readers on the lists of the Society at
home and abroad.
Contributions in aid of the Society will be thankfully received by
the Treasurer, G. M. Holt, Esq., 17, Whitehall Place; and at the
National Provincial Bank of England, Piccadilly, W.; and by the
Secretary, Rev. William A. Blake, at the Offices, 4, Trafalgar Square,
Charing Cross, W.C.
 CARRIAGES.

HOOPER & CO..

107, VICTORIA STREET, LONDON, S.W.
ESTABLISHED 1807.

By Appointment to
HER MAJESTY THE QUEEN.
His Imperial Majesty the German Emperor.
Her Majesty the Queen Regent of the Netherlands.
His Royal Highness the Prince of Wales, K.G.

COACHBUILDERS TO
His Royal Highness the Duke of Clarence and
Avondale.
His Royal Highness the Duke of Edinburgh, K.G.
His Royal Highness the Duke of Connaught, K.G.
Her Royal Highness the Princess Louise.
Her Royal Highness the Duchess of Fife.
Her Royal Highness the Duchess of Albany.
His Royal Highness the Duke of Cambridge, K.G.

Also to the Embassies of GERMANY, RUSSIA, ITALY, and SPAIN.

CARRIAGES OF BEST QUALITY ONLY. HIGHEST WORKMANSHIP.
FINEST MATERIALS. EXCLUSIVE DESIGNS.
LANDAUS with own patent self acting balanced heads, light,
strong, compact, and durable. For one horse or for a pair of
horses.
BROUGHAMS on elliptic springs, for one horse. Rubber tyres,
and all latest improvements.
VICTORIAS on elliptic springs, light, for one horse. On C and
under springs with perch, large, high, and stylish, for a pair of
horses.
MAIL PHAETONS on perch and mail springs, mail axles. On
elliptic springs, for smaller horses. The most stylish carriage for
gentlemen’s own driving.
CHAR-A-BANCS for a pair or a team, our speciality, in various
sizes, a unique carriage for the country.
SOCIABLES as built by Hooper & Co., for Royalty and the
Nobility.
OMNIBUSES for private use, compact and comfortable.
REPAIRS at moderate prices; estimates free.
CARRIAGES of all kinds, new, and slightly used, to let on hire
with option of purchase.
 OPENED TO KEEP PACE WITH THE CIVIL SERVICE STORES.

The Cash Sales at these Stores now exceed a Quarter of a Million Sterling per
annum.
ALL GOODS 25 PER CENT. UNDER USUAL LONDON PRICES.
CHAS. BAKER & CO.’S ILLUSTRATED PRICE LIST, WITH EASY
SELF-MEASUREMENT FORMS, POST-FREE.
All Goods Carriage Paid to any part of the United Kingdom.
GENTLEMEN’S SUPERIOR CLOTHING,
TO ORDER OR READY FOR IMMEDIATE WEAR.
UNIFORMS. LIVERIES.
BOYS’ & YOUTHS’ CLOTHING,
OVERCOATS, WATERPROOFS,
HOSIERY, SHIRTS, HATS, BOOTS, etc.,
AND COMPLETE
SCHOOL OUTFITS.
 ETON JACKETS AND VESTS.
In super Black and Diagonal Cloths, ready for immediate wear,
thoroughly well cut and made. For Boys from 9 years of age.
Quality 1 .. .. 17/9 to 25/9
Quality 2 .. .. 22/6 to 31/6
Quality 3 .. .. 27/6 to 41/6
Trousers, 8/11, 10/9, 12/11, 14/11
 BOYS’ NORFOLK SUITS.
A Two-garment Suit for School and general wear;
for Boys from 7 to 11 years of age.
In durable Tweeds and Cheviots. 8/11, 12/11
In Scotch Cheviots, &c. 14/11, 19/11

GIRLS’ TAILOR-MADE REEFERS.

In Serges— 8/11, 12/9, 14/12
In Nap— 8/12, 11/9, 14/11, 19/11
 Sailor Costumes.
8/11, 11/9, 13/9, 14/11

BOYS’ ROYAL NAVY SUITS.

This favourite Suit, consisting of Blue Serge Blouse
(with Badge on arm) and Knickerbockers,
Singlet, Lanyard and Whistle complete.
4/11, 6/11, 8/11, 11/9, 13/9, 16/11, 19/11.
In Tweeds, 4/11, 5/11, 6/11, 9/11, 11/9, 18/9.
In Fine Worsted Cloths, 19/11
 YOUTHS’ CAMBRIDGE SUITS.
This style of Suit is kept in a very large variety of materials;
thoroughly well made and cut.
In Tweeds, 10/9, 12/11, 14/11, 18/11, 19/11, 22/6.
In Real West of England Cloths, Scotch Cheviots, &c.
27/6, 33/9, 37/6, 41/6, 45/6.
In Black Diagonals, 18/11 to 41/6.
BESPOKE TAILORING DEPARTMENTS are open at
each of
CHAS. BAKER & CO.’S DEPOTS. Purchasers are asked to
inspect the extensive stocks of REAL WEST OF ENGLAND
CLOTHS, OVERCOATINGS, SERGES, VICUNA CLOTHS,
TROUSERINGS, etc, showing in these Departments.
PATTERNS POST-FREE.
Cheques, Postal Orders, etc., to be crossed “Barclay, Bevan, Tritton &
Co.”
HIGH-CLASS CUTTERS BEING EMPLOYED, A GOOD STYLE AND FIT
CAN BE GUARANTEED.

CHAS. BAKER & CO.’S STORES,

Limited,
HEAD DEPOT & LETTER ORDER DEPT.: 271 & 272, HIGH
HOLBORN
(City side of the Inns of Court Hotel.)
City Branch: 82, FLEET ST. (Close to Ludgate Circus)
West End Branch: 192 194, OXFORD ST. (A few doors from Peter
Robinson.)
TOTTENHAM CT. RD.: 137, 138, 139 & 140, TOTTENHAM
COURT ROAD
(The extensive premises at the corner of Euston Road.)

EXPORT DEPT. CHAS. BAKER & CO., Limited, forward

consignments of their goods to any part of the World on receipt of
order and remittance. Price Lists, Patterns, and Easy Self-Measure
Forms, Post-free to any part of the Globe.

Transcriber’s Note

A small number of obvious typographical errors have been

corrected.
The spelling and punctuation of the source book have not
been changed even though some of the punctuation would not
be accepted today; for example, the plural of NCO (non-
commissioned officer) is printed as N. C. O.’s.
There are 23 footnotes in the source book marked by
characters such as * and †. The footnote markers have been
changed to numbers and each footnote has been moved to the
end of the main text.
The book contains 48 grayscale figures in the text and 19
double-page colour plates.
Each of the colour plates appears as two images in this ebook.
The following captions appear on each of the double-page
colour plates:
Printed by G. Löwensohn, Fuerth Bavaria
Published by William Clowes & Sons, Ld, London.
They have not been added to the colour-plate images.
 *** END OF THE PROJECT GUTENBERG EBOOK THE ARMIES OF
EUROPE ***

Updated editions will replace the previous one—the old editions will
be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free

distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be

used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:
 This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived

from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted

with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this

electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the Project
Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing

access to or distributing Project Gutenberg™ electronic works
provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com