Petzold’s Programming Windows 6E is coming soon!
Greetings. We’re looking very very good for publishing Charles Petzold’s classic book, Programming Windows, in its sixth edition, in January 2013. You can order a preliminary ebook plus final ebook here, and you can preorder the print book on the same page.
Today we’d like to share the book’s Introduction, in which Charles describes the book’s intended audience, organization, coverage, and much more. Take it away, Charles!
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 “Download the tools and SDK” link on that 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 first 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 reflected 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 first 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 computers 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 fingers. The simple word "touch" is now sufficient. Part of the new programming interface for Windows 8 applications treats touch, mouse, and pen input in a unified 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 files 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 files 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.
Programmers who use the managed languages C# or Visual Basic .NET will find 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 convinced of the advantages of managed languages for development and debugging, and for me C# is the language that has the closest fit to the Windows Runtime. I hope C++ programmers find C# code easy enough to read to derive some benefit 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 RC 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 predefined 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 benefit by watching someone else do it. Your own fingers must get involved. The source code in these pages is downloadable via the “Companion Content” link here:
https://shop.oreilly.com/product/0790145369079.do [NOTE: The companion content currently available is for the Release Preview ebook. The final companion content will be available in mid-January.]
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 Built Tablets were originally distributed with the Windows 8 Developer Preview installed, I progressively replaced that the Consumer Preview (build 8250) in March 2012 and the Release Preview (build 8400) in June 2012, and eventually the official 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 first 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 his blog entry:
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 fine development environment, particularly compared with the setup I used to write the first 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 first 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 first book contract:
Perhaps the most amusing part of this contract occurs further down the first 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 fixed-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 simultaneous 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 flawed 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 finish until August and the book wasn’t published until early 1988. The final 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 first 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 first 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 fine 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 file 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 efficiency 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 efficiency, and Windows has even sparked some energetic controversy once again. Windows 8 is easily the most revolutionary updating to Windows since its very first 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 find 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.
More in the Future
I suspect that Windows 8 will dominate my programming life for a while, which means that I’m likely to be posting blog entries about various aspects of Windows 8 programming. You can access my blog and subscribe to the RSS feed at www.charlespetzold.com.
I always enjoy solving a thorny programming problem and posting a blog entry about it, so if you have a Windows 8 programming issue that you’d like me to take a look at and possibly figure out, write me at cp@charlespetzold.com.
Beginning with the January 2013 issue of MSDN Magazine, I will be writing a monthly column called “DirectX Factor,” focusing specifically on using DirectX from Windows 8 and Windows Phone 8 applications. MSDN Magazine is available for free perusal at https://msdn.microsoft.com/magazine.
Behind the Scenes
This book exists only because Ben Ryan and Devon Musgrave at Microsoft Press developed an interesting way to release early content to the developer community and get advance sales of the final book simultaneously.
Part of the job duties of Devon and my technical reviewer Marc Young is to protect me from embarrassment by identifying blunders in my prose and code, and I thank them both for finding quite a few.
Thanks also to Andrew Whitechapel for giving me feedback on the C++ sample code; Brent Rector for an email with a crucial solution for an issue involving touch, as well as some background into IBuffer; Robert Levy for reflections about touch; Jeff Prosise for always seeming to have a dead-on answer when I’m puzzled; Larry Smith for finding numerous flaws in my prose; and Admiral for prodding me to make the book as useful as possible to C++ programmers.
The errors that remain in these chapters are my own fault, of course. Later in this Introduction is an email address for reporting errors to the publisher, but I’ll also try to identify the most egregious issues on my website at www.charlespetzold.com/pw6.
Finally, I want to thank my wife Deirdre Sinnott for love and support and making the necessary adjustments to our lives that writing a book inevitably entails.
Charles Petzold
Roscoe, NY and New York City
December 10, 2012