RTM’d today: Programming Windows, Sixth Edition

Article
01/14/2013

Hello, programmers! We’re happy to announce that Charles Petzold’s newest update to his classic book, Programming Windows, has shipped to the printer! The book contains 1136 pages—we were simply silly to originally estimate the book’s length at 800 pages—and its ISBN is 9780735671768.

You can also download a PDF with two complete chapters and the full Table of Contents here. [NOTE: OK, the sample-chapters PDF has been fixed; please download it again.]

Programming Windows, Sixth Edition focuses on creating Windows 8 apps accessing the Windows Runtime with XAML and C#. (The book also provides C++ code samples.) The Sixth Edition includes 19 chapters in two parts:

PART I ELEMENTALS
CHAPTER 1 Markup and Code   3
CHAPTER 2 XAML Syntax   31
CHAPTER 3 Basic Event Handling   69
CHAPTER 4 Presentation with Panels   97
CHAPTER 5 Control Interaction   139
CHAPTER 6 WinRT and MVVM   193
CHAPTER 7 Asynchronicity   221
CHAPTER 8 App Bars and Popups   261
CHAPTER 9 Animation   329
CHAPTER 10 Transforms   377
CHAPTER 11 The Three Templates   449
CHAPTER 12 Pages and Navigation   539

PART II SPECIALTIES
CHAPTER 13 Touch, Etc.   615
CHAPTER 14 Bitmaps   683
CHAPTER 15 Going Native   779
CHAPTER 16 Rich Text   845
CHAPTER 17 Share and Print   893
CHAPTER 18 Sensors and GPS   953
CHAPTER 19 Pen (Also Known as Stylus)   1013

It’s a pleasure to share this excerpt from Charles’s Introduction:

Introduction

This book—the 6th edition of Programming Windows—is a guide to writing
applications that run under Microsoft Windows 8.

To use this book, you’ll need a computer running Windows 8, on which you can
install the Windows 8 development tools and software development kit (SDK), most
conveniently in the form of the free download of Microsoft Visual Studio Express 2012
for Windows 8. That download is accessible from the Windows 8 developer portal:

https://msdn.microsoft.com/windows/apps

To install Visual Studio, follow the "Downloads for developers" link on that page and
then the “Download the tools and SDK” link on the following page. This page also
provides information on obtaining a Windows 8 developer account that lets you upload
new applications to the Windows Store.

The Versions of Windows 8

For the most part, Windows 8 is intended to run on the same class of personal
computers as Windows 7, which are machines built around the 32-bit or 64-bit Intel
x86 microprocessor family. Windows 8 is available in a regular edition called simply
Windows 8 and also a Windows 8 Pro edition with additional features that appeal to
tech enthusiasts and professionals.

Both Windows 8 and Windows 8 Pro run two types of programs:

Desktop applications
New Windows 8 applications, often called Windows Store applications

Desktop applications are traditional Windows programs that currently run under
Windows 7 and that interact with the operating system through the Windows
application programming interface, known familiarly as the Win32 API. To run these
desktop applications, Windows 8 includes a familiar Windows desktop screen.

The new Windows Store applications represent a radical break with traditional
Windows. The programs generally run in a full-screen mode—although two programs
can share the screen in a “snap” mode—and many of these programs will probably be
optimized for touch and tablet use. These applications are purchasable and installable
only from the application store run by Microsoft. (As a developer, you can deploy and
test applications directly from Visual Studio.)

In addition to the versions of Windows 8 that run on x86 processors, there is also a
version of Windows 8 that runs on ARM processors, most commonly found in low-cost
tablets and other mobile devices. This version of Windows 8 is called Windows RT,
and it only comes preinstalled on these machines. One of the ﬁrst computers running
Windows RT is the initial release of the Microsoft Surface.

Aside from some preinstalled desktop applications, Windows RT runs new Windows
Store applications only. You cannot run existing Windows 7 applications under
Windows RT. You cannot run Visual Studio under Windows RT, and you cannot develop
Windows 8 applications under Windows RT.

The Windows 8 user interface incorporates a new design paradigm that is likely to
be reﬂected in Windows Store applications. Somewhat inspired by signage in urban
environments, this design paradigm emphasizes content over program “chrome” and is
characterized by the use of unadorned fonts, clean open styling, a tile-based interface,
and transitional animations.

Many developers were ﬁrst introduced to the Windows 8 design paradigm with
Windows Phone 7, so it’s interesting to see how Microsoft’s thinking concerning large
and small computers has evolved. In years gone by, Microsoft attempted to adapt the
design of the traditional Windows desktop to smaller devices such as hand-held com-
puters and phones. Now a user-interface design for the phone is being moved up to
tablets and the desktop.

One important characteristic of this new environment is an emphasis on multitouch,
which has dramatically changed the relationship between human and computer. In
fact, the term “multitouch” is now outmoded because virtually all new touch devices
respond to multiple ﬁngers. The simple word “touch” is now sufﬁcient. Part of the
new programming interface for Windows 8 applications treats touch, mouse, and
pen input in a uniﬁed manner so that applications are automatically usable with all
three input devices.

The Focus of This Book

This book focuses exclusively on writing Windows Store applications. Plenty of other
books already exist for writing Win32 desktop applications, including the 5th edition
of Programming Windows. I’ll occasionally make reference to Win32 API and desktop
applications, but this book is really all about writing new Windows 8 applications.

For writing these applications, a new object-oriented API has been introduced called
the Windows Runtime or WinRT (not to be confused with the version of Windows 8 that
runs on ARM processors, called Windows RT). Internally, the Windows Runtime is based
on COM (Component Object Model) with interfaces exposed through metadata ﬁles
with the extension .winmd located in the /Windows/System32/WinMetadata directory.
Externally, it is very object-oriented.

From the application programmer’s perspective, the Windows Runtime resembles
Silverlight, although internally it is not a managed API. For Silverlight programmers,
perhaps the most immediate difference involves namespace names: the Silverlight
namespaces beginning with System.Windows have been replaced with namespaces
beginning with Windows.UI.Xaml.

Most Windows 8 applications will be built not only from code but also markup,
either the industry-standard HyperText Markup Language (HTML) or Microsoft’s
eXtensible Application Markup Language (XAML). One advantage of splitting an
application between code and markup is potentially splitting the development of the
application between programmers and designers.

Currently there are three main options for writing Windows 8 applications, each of
which involves a programming language and a markup language:

C++ with XAML
C# or Visual Basic with XAML
JavaScript with HTML5

The Windows Runtime is common to all these options, but the Windows Runtime is
also supplemented by another programming interface appropriate for the particular
language. Although you can’t mix languages within a single application, you can create
libraries (called Windows Runtime Components) with their own .winmd ﬁles that can be
accessed from any other Windows 8 language.

The C++ programmer uses a dialect of C++ called C++ with Component
Extensions, or C++/CX, that allows the language to make better use of WinRT. The C++
programmer also has direct access to a subset of the Win32 and COM APIs, as well as
DirectX. C++ programs are compiled to native machine code.

Programmers who use the managed languages C# or Visual Basic .NET will ﬁnd
WinRT to be very familiar territory. Windows 8 applications written in these languages
can’t access Win32, COM, or DirectX APIs with as much ease as the C++ programmer,
but it is possible to do so, and some sample programs in Chapter 15, “Going Native,”
show how. A stripped-down version of .NET is also available for performing low-level
tasks.

For JavaScript, the Windows Runtime is supplemented by a Windows Library for
JavaScript, or WinJS, which provides a number of system-level features for Windows 8
apps.

After much consideration (and some anguish), I decided that this book would focus
almost exclusively on the C# and XAML option. For at least a decade I have been con-
vinced of the advantages of managed languages for development and debugging, and
for me C# is the language that has the closest ﬁ t to the Windows Runtime. I hope C++
programmers ﬁnd C# code easy enough to read to derive some beneﬁt from this book.

I also believe that a book focusing on one language option is more valuable than
one that tries for equal coverage among several languages. There will undoubtedly be
plenty of other Windows 8 books that show how to write Windows 8 applications using
the other options.

With that said, I have greatly enjoyed the renewed debate about the advantages of
C++ and native code in crafting high-performance applications. No single tool is best
for every problem, and I will be exploring C++ and DirectX development for Windows 8
more in the future, both in my blog and the pages of MSDN Magazine. As a modest
start, the companion content for this book includes all the program samples converted
to C++.

The Approach

In writing this book, I’ve made a couple assumptions about you, the reader. I assume
that you are comfortable with C#. If not, you might want to supplement this book with
a C# tutorial. If you are coming to C# from a C or C++ background, my free online book
.NET Book Zero: What the C or C++ Programmer Needs to Know About C# and the .NET
Framework might be adequate. This book is available in PDF or XPS format at
www.charlespetzold.com/dotnet.

I also assume that you know the rudimentary syntax of XML (eXtensible Markup
Language) because XAML is based on XML. But I assume no familiarity with XAML or
any XAML-based programming interface.

This is an API book rather than a tools book. The only programming tool I use in this
book is Microsoft Visual Studio Express 2012 for Windows 8 (which I’ll generally simply
refer to as Visual Studio).

Markup languages are generally much more toolable than programming code.
Indeed, some programmers even believe that markup such as XAML should be entirely
machine-generated. Visual Studio has a built-in interactive XAML designer that
involves dragging controls to a page, and many programmers have come to know and
love Microsoft Expression Blend for generating complex XAML for their applications.
(Expression Blend is included among the free download of the development tools and
SDK I mentioned earlier.)

While such design tools are great for experienced programmers, I think that the
programmer new to the environment is better served by learning how to write XAML
by hand. That’s how I’ll approach XAML in this book. The XAML Cruncher tool featured
in Chapter 8, “App Bars and Popups,” is very much in keeping with this philosophy: it
lets you type in XAML and interactively see the objects that are generated, but it does
not try to write XAML for you.

On the other hand, some programmers become so skilled at working with XAML
that they forget how to create and initialize certain objects in code! I think both skills
are important, and consequently I often show how to do similar tasks in both code
and markup.

As I began working on this book, I contemplated different approaches to how a
tutorial about the Windows Runtime can be structured. One approach is to start with
rather low-level graphics and user input, demonstrate how controls can be built, and
then describe the controls that have already been built for you.

I have instead chosen to focus initially on those skills I think are most important for
most mainstream programmers: assembling the predeﬁned controls in an application
and linking them with code and data. This is the focus of the 12 chapters of the book’s
Part I, “Elementals.” One of my goals in Part I is to make comprehensible all the code
and markup that Visual Studio generates in the various project templates it supports.
Part II, “Specialities,” covers more low-level and esoteric tasks, such as touch, bitmap
graphics, rich text, printing, and working with the orientation and GPS sensors.

Source Code

Learning a new API is similar to learning how to play basketball or the oboe: You don’t
get the full beneﬁt by watching someone else do it. Your own ﬁngers must get involved.
The source code in these pages is downloadable via the “Companion Content” link here:

https://shop.oreilly.com/product/0790145369079.do

But you’ll learn better by actually typing in the code yourself.

My Setup

For writing this book, I used the special version of the Samsung 700T tablet that was
distributed to attendees of the Microsoft Build Conference in September 2011. (For
that reason, it’s sometimes called the Build Tablet.) This machine has an Intel Core i5
processor running at 1.6 GHz with 4 GB of RAM and a 64-GB hard drive. The screen
(from which most of the screenshots in the book were taken) has 8 touch points and a
resolution of 1366 × 768 pixels, which is the lowest resolution for which snap views are
supported.

Although the Build Tablets were originally distributed with the Windows 8 Developer
Preview installed, I progressively replaced that with the Consumer Preview (build 8250)
in March 2012 and the Release Preview (build 8400) in June 2012, and eventually the
ofﬁcial release of Windows 8 Pro. Except when testing orientation sensors, I generally
used the tablet in the docking port with an external 1920×1080 HDMI monitor, and an
external keyboard and mouse.

When the Microsoft Surface ﬁrst became available, I purchased one for testing my
applications. For deploying and debugging applications on the Surface, I used the
technique discussed by Tim Heuer in this blog entry.

This technique is more formally described in the documentation topic "Running
Windows Store apps on a remote machine":

https://msdn.microsoft.com/en-us/library/hh441469.aspx

The Surface became particularly vital for testing programs that access the orientation
sensors.

For the most part, however, I’m still using the Build Tablet in the docking station. The
external keyboard, mouse, and monitor lets me run Visual Studio and Microsoft Word
as I’m accustomed to, while my Windows 8 programs run on the tablet’s touch screen.
This is a ﬁne development environment, particularly compared with the setup I used to
write the ﬁrst edition of Programming Windows.

But that was 25 years ago.

The Programming Windows Heritage

This is the 6th edition of Programming Windows, a book that was ﬁrst conceived by
Microsoft Press in the fall of 1986. The project came to involve me because at the time
I was writing articles about Windows programming for Microsoft Systems Journal (the
predecessor to MSDN Magazine).

I still get a thrill when I look at my very ﬁrst book contract:

Perhaps the most amusing part of this contract occurs further down the ﬁrst page:

The reference to “typescript” means that the pages must as least resemble something
that came out of a typewriter. A double-spaced manuscript page with a ﬁxed-pitch font
has about 250 words, as the description indicates. A book page is more in the region of
400 words, so Microsoft Press obviously wasn’t expecting a very long book.

For writing the book I used an IBM PC/AT with an 80286 microprocessor running
at 8 MHz with 512 KB of memory and two 30 MB hard drives. The display was an IBM
Enhanced Graphics Adapter, with a maximum resolution of 640×350 with 16 simultane-
ous colors. I wrote some of the early chapters using Windows 1 (introduced over a year
earlier in November 1985), but beta versions of Windows 2 soon became available.

In those years, editing and compiling a Windows program occurred outside of
Windows in MS-DOS. For editing source code, I used WordStar 3.3, the same word
processor I used for writing the chapters. From the MS-DOS command line, you would
run the Microsoft C compiler and then launch Windows with your program to test it
out. It was necessary to exit Windows and return to MS-DOS for the next edit-compile-
run cycle.

As I got deeper into writing the book over the course of 1987, much of the rest of
my life faded away. I stayed up later and later into the night. I didn’t have a television
at the time, but the local public radio station, WNYC-FM, was on almost constantly with
classical music and programming from National Public Radio. For a while, I managed
to shift my day to such a degree that I went to bed after Morning Edition but awoke in
time for All Things Considered.

As the contract stipulated, I sent chapters to Microsoft Press on diskette and
paper. (We all had email, of course, but email didn’t support attachments at the
time.) The edited chapters came back to me by mail decorated with proofreading
marks and numerous sticky notes. I remember a page on which someone had drawn
a thermometer indicating the increasing number of pages I was turning in with the
caption “Temperature’s Rising!”

Along the way, the focus of the book changed. Writing a book for “Programmers
and Other Advanced Users” proved to be a ﬂawed concept. I don’t know who came up
with the title Programming Windows.

The contract had a completion date of April, but I didn’t ﬁnish until August and the
book wasn’t published until early 1988. The ﬁnal page total was about 850. If these
were normal book pages (that is, without program listings or diagrams) the word count
would be about 400,000 rather than the 100,000 indicated in the contract.

The cover of the ﬁrst edition of Programming Windows described it as “The
Microsoft Guide to Programming for the MS-DOS Presentation Manager: Windows
2.0 and Windows/386.” The reference to Presentation Manager reminds us of the days
when Windows and the OS/2 Presentation Manager were supposed to peacefully
coexist as similar environments for two different operating systems.

The ﬁrst edition of Programming Windows went pretty much unnoticed by the
programming community. When MS-DOS programmers gradually realized they needed
to learn about the brave new environment of Windows, it was mostly the 2nd edition
(published in 1990 and focusing on Windows 3) and the 3rd edition (1992, Windows 3.1)
that helped out.

When the Windows API graduated from 16-bit to 32-bit, Programming Windows
responded with the 4th edition (1996, Windows 95) and 5th edition (1998, Windows
98). Although the 5th edition is still in print, the email I receive from current readers
indicates that the book is most popular in India and China.

From the 1st edition to the 5th, I used the C programming language. Sometime
between the 3rd and 4th editions, my good friend Jeff Prosise said that he wanted to
write Programming Windows with MFC, and that was ﬁne by me. I didn’t much care for
the Microsoft Foundation Classes, which seemed to me a fairly light wrapper on the
Windows API, and I wasn’t that thrilled with C++ either.

As the years went by, Programming Windows acquired the reputation of being the
book for programmers who needed to get close to the metal without any extraneous
obstacles between their program code and the operating system.

But to me, the early editions of Programming Windows were nothing of the sort. In
those days, getting close to the metal involved coding in assembly language, writing
character output directly into video display memory, and resorting to MS-DOS only
for ﬁle I/O. In contrast, programming for Windows involved a high-level language,
completely unaccelerated graphics, and accessing hardware only through a heavy layer
of APIs and device drivers.

This switch from MS-DOS to Windows represented a deliberate forfeit of speed
and efﬁciency in return for other advantages. But what advantages? Many veteran
programmers just couldn’t see the point. Graphics? Pictures? Color? Fancy fonts? A
mouse? That’s not what computers are all about! The skeptics called it the WIMP
( window-icon-menu-pointer) interface, which was not exactly a subtle implication
about the people who chose to use such an environment or code for it.

If you wait long enough, a high-level language becomes a low-level language,
and multiple layers of interface seemingly shrink down (at least in lingo) to a native
API. Some C and C++ programmers of today reject a managed language like C# on
grounds of efﬁciency, and Windows has even sparked some energetic controversy
once again. Windows 8 is easily the most revolutionary updating to Windows since its
very ﬁrst release in 1985, but many old-time Windows users are wondering about the
wisdom of bringing a touch-based interface tailored for smartphones and tablets to the
mainstream desktop, and they grumble when they can’t ﬁnd familiar features.

I suppose that Programming Windows could only be persuaded to emerge from
semi-retirement with an exciting and controversial new user interface on Windows, and
an API and programming language suited to its modern aspirations.

RTM’d today: Programming Windows, Sixth Edition

Additional resources