Last updated:
1. September 2008

User Interface Programming

(Start main menu) Home ­ Articles ­ Book ­ Resources (End main menu)

Programming Industrial Strength Windows

(Start sub-menu)

Table of Contents


Sample Chapter




My blog »

(End sub-menu)

If you’re de­vel­op­ing Win­dows soft­ware for a com­mer­cial or shrink­wrap type mar­ket, this book should be required read­ing.

Joel Spolsky

The author has paid a lot of at­ten­tion to details […] that make the ap­pli­ca­tion easier to use and more in­tui­tive.


A highly recom­mend­ed, user friendly, and much appre­cia­ted add­ition to the Win­dows pro­gram­mer’s ref­e­rence shelf.

Midwest Book Review

Petter is one of my favorite tech­ies. When he sol­ves a pro­b­lem, it stays sol­ved. This book’s great strength is that it details how to do error handling and exception handling in the UI and how to ar­chi­tect that in­to the de­s­ign. Er­ror han­d­ling is so im­p­or­t­ant and is often done so poor­ly or not at all.

Laura Arlov (GUI Design for Dummies)

Programming Industrial Strength Windows

by Petter Hesselberg

R&D Books, January 2000
528 pages, includes CD-ROM
ISBN: 087930605X

“Error handling has been omitted for clarity.”

Too many times have I read that sentence in a pro­gram­ming book or article. Not that there’s anything inherently wrong with this; simplification is a legitimate tea­ch­ing device. The problem is that the literature is terribly one-sided—it’s a rare gem that says, “error hand­ling has been included to show how it’s done.” Many pro­gram­mers never learn how to han­dle er­rors and anoma­lies. Even more chil­ling, some never rea­lize that the is­sue exists. The re­s­ults are all around us: robust­ness and relia­bility are rarely con­side­red def­in­ing character­istics of soft­ware.

This book gives you an understanding of what it takes to build industrial strength software—software that works reliably and robustly, software that doesn’t get bet­ween the user and his task. It will not bestow soft­ware nirvana upon you; indeed, no book ever could. That un­at­tain­able state of grace can only be app­roached through ex­perience; the most a book can do is to help you get the right rather than the wrong kind of ex­perience. My highest hope is that the book will inspire you to care—about your users, about your pro­fes­sion and about getting the details right.

The adjective “fragmented” describes much of the computer literature. Many books use minimalist examples to illustrate various APIs and sub­systems, and rarely draw things together into a coherent whole. Again, this is not nec­es­sa­rily a Bad Thing; many excellent books use this app­roach.

Un­for­tu­nately, it is not enough. When you assemble those fragments to create a full-blown app­li­ca­t­ion, their in­ter­ac­tion gives rise to an ex­po­nent­ial in­crease in com­plex­ity, and a myriad of details must be con­sid­e­red. This aspect of soft­ware construction is rarely covered, and the lit­terature is left with a hole large enough to drive a truck-full of bugs through. Sadly, bugs and inconsistencies often are considered de­f­i­n­ing characteristics of computer software.

This book takes a more holistic approach; it is built around the develop­ment of a single 20,000-line application.

In ad­di­tion to error handling and app­li­ca­t­ion architecture, the book focuses on usa­bility. Efficient flow of information should receive much consideration during soft­ware design, but the current state of the World Wide Web is proof that it rarely re­cei­ves any consideration at all. Does the user really need that ani­mated deodo­rant on his desk, or would your develop­ment effort be better spent ensuring that the user can get his work done efficiently and effectively, and that his data are never lost? While I like cool stuff as well as the next programmer, I think it should be built on solid ground rather than shifting sands.


Page xvii: The name Leif Arne Roues should be Leif Arne Rones.

Page 46: “…A subclassing function that applies yellow backgrounds, for example, could conceivably be used for both edit con­t­rols and list boxes. Then you’d have to store two pointers to two old win­dow functions…”

This does not make any sense. Change to:

“…A single win­dow could certainly have more than one subclassing function associated with it—one to provide a yellow background, another to filter out illegal characters. Then you’d have to store two pointers to two old win­dow functions…”

(Start bottom menu)

TopHomeArticles • Book • Resources
Win­dows De­vel­oper Maga­zineR&D BooksCMP Books Petter Hesselberg

(End bottom menu)

Programming Industrial Strength Windows (cover)

R&D Books

View larger image

TextEdit on CodePlex
PISW on CodePlex

Download source code (archive)

CMP Books Logo

Programming Windows is very tough
Provided your method is wrong;
Your programs get labeled “unusable stuff,”
You won’t have employment for long.

Programming Windows is breezy and cool
Provided your method is right;
You finish on time and can lie by the pool,
You don’t have to work through the night.

 More Windows poetry