Fog Creek Software
Discussion Board

Best Windows Programming Books?

I'm looking to get myself well-acquainted with Windows programming. I know C++, but I don't know:

1) What class library like ATL or MFC would be easiest and/or most flexible


2) What book or books might be best in teaching me how to use and create windows, dialogs, controls, etc. so that I can start applying my knowledge quickly.

My background is some C++, a bunch of Perl, and have wrote some simple MFC "dialog" apps using the AppWizard, which I would like to wean myself away from.

Thanks for the responses.

Friday, February 13, 2004

Advanced Windows (I think its on its 3rd edition) by Jeffrey Richter. 

Really good for things like threads, semaphores, events, processes, virtual memory,...  Not aimed at UI stuff but lots of valuable insights.


Friday, February 13, 2004

"Programming Windows" by Charles Petzold (make sure you get the latest edition, which includes the latest stuff)

The Delphi VCL (Visual Component Library) is the best framework for developing Windows applications, and comes with one of the best IDEs available today: Borland Delphi.

Friday, February 13, 2004

"Programming Windows, 5th Ed." by Charles Petzold or "Win32 Programming" by Rector & Newcomer are usually the two recommended Windows API books. I'd pick one or the other, but opinion on them seems to be somewhat split as to which is better.

As far as ATL vs. MFC goes, I would say that ATL (without any add-on libraries) has better COM support but MFC is better for GUI programming. There are libraries for ATL like WTL ( & Atilla ( that provide better support for GUI programming.

Hope this helps.

Semi-Anonymous Coward
Friday, February 13, 2004

Probably this one -

Friday, February 13, 2004

wxWindows has a nice gentle learning curve, very similar to MFC but open rather than proprietary.

Only learn ATL if you intend to start writing COM objects.

Tony Edgecombe
Friday, February 13, 2004

Beside Petzold and Advanced Windows, "Windows Graphics
Programming" ( is one of the
greatest Windows programming books.

Even if you don't care much about bitmaps, metafiles and
alpha channel, this book has lots of other topics you'll need
sooner rather than later.

After that, buy any Win32 book because they are becoming
scarce commodity these days.

Friday, February 13, 2004

Petzold.  Oh, and then there's Petzold.  Oh yeah, I hear there's a new version of Petzold.

Make sure you learn Windows programming before you so muchs as *look* at any of the bolt-on C++ re-abstractions like MFC, etc.

Friday, February 13, 2004

At the risk of postin' me too like a brain-dead AOLer:

Don't even THINK about writing Windows code without a copy of Petzold.

This may be changing ever-so-slowly as C#/Forms become more popular, but an understanding of the old Win32 C API is absolutely vital to make good use of MFC, etc. Petzold covers the Win32 API in all its glorious cruft :)

Dan Maas
Friday, February 13, 2004

Actually, Petzold covers most of the Win32 user interface API. He barely scratches the surface of the rest of Win32 programming. That's why you need two books: Petzold for the UI stuff, and Richter for the system level stuff (I/O, threading, etc.).

Chris Tavares
Friday, February 13, 2004

Today, the .NET framework works over Win32 - it works by calling Win32 functions.

Microsoft is planning to change this in Longhorn - large parts of the future .NET framework which will exist in Longhorn will NOT run over Win32.

.NET will be the native API of Longhorn and future Windows OSes.

Friday, February 13, 2004

I think this is a difficult turning point for those just getting into Windows programming using C or C++, especially if they're doing it to improve their employability.  On one hand there are still many applications written in Win32 and MFC, so there is still maintenance to be done.  And their are issues revolving around the deployment of .Net apps (as Joel and others have written), so Win32/MFC is still viable in that sense.

But on the other hand, it takes a long time to master Win32 and MFC.  Neither is that difficult on the surface, but there is a lot to remember, arcane syntax to deal with, and a lot of little things you learn with time.  So, by the time someone starting out now masters it, will it be a viable skill in the marketplace?

So if the OP is determined to learn this, I would say buy "Programming Windows with MFC" by Jeff Prosise and learn that.  You can get a awful lot done in MFC before having to go under the hood and deal with Win32 directly.  In the meantime, still buy Petzold for background reading, so if you ever do need to go under the hood you're prepared.

Friday, February 13, 2004

Petzold? It was good advice until Windows Petzold is pretty much useless, better to pick up some of the one author per chapter Wrox Press books.

I think that today a copy of MSDN (even if it is not the latest), Visual C++ and the desire to learn by writing small programs and moving up is the best way to learn.

Code Monkey
Friday, February 13, 2004

When It comes to Windows programming, here is the fastest way to learn (in my opinion):

1. Get Borland C++Builder or Borland Delphi (Borland products are worth every cent)

2. Write Windows apps using VCL

3. After some experience with VCL, you can start learning MFC.

These are the reasons :

1. VCL is so superior, its the only way to write Windows apps.

2. MFC is a steep mountain to climb - its basically WinAPI, with a few improvements, but its still Windows API.

3. Once you master VCL (this will happen quickly - believe me), you can try MFC - you'll be better prepared for the problems will encounter and you will understand why Borland created VCL.

The difference between VCL and MFC is like the difference between C and assembler code. That is why .NET seams so "good" for MSVC-only programers.

Saturday, February 14, 2004

Don't rely on Microsoft-provided documentation to learn the Win32 API. The MSDN docs are good as a reference but they won't teach you the "big picture." (I remember doing the old Scribble tutorial and ending it more confused about Windows than when I started)

Sounds like I should try VCL...

Dan Maas
Sunday, February 15, 2004

MFC is not the Windows API.  It's a very different abstraction built in a subset of C++ on top of the Windows API.  But MFC is a very leaky abstraction (to use Joel's metaphor) and quite insufficient and awkward.  You'll often poke through into Windows to accomplish simple things.  Programming in the underlying Windows API first will give you a solid conceptual grounding upon which to base your weeks or months of frustration as you learn MFC's own intricacies, oddities, and design blunders.

I agree that the Richter book will be a very important asset as you progress from pure UI programming to more advanced topics.  But the Petzold book teaches fundamental UI programming with Windows better than any source available.  I encourage Code Monkey to offer specific suggestions about what topics his WROX suggestion holds that Petzold misses.  In a quick look at the current WROX catalog I found only VB, ASP and C# titles.

Wednesday, February 18, 2004

I will be interested to see whether .NET becomes the "native" API in Longhorn.  I'd welcome that, but we heard similar predictions about COM nearly a decade ago.  Certainly, the CLR will be where most of the action will be.  But only in the switch to NT around 1993 can I remember Microsoft *ever* removing a major lower layer, and even then they rebuilt that layer as an emulation environment shipped on every box.  "Native" or not, once Longhorn is mainstream, C# and the CLR will likely be the serious Windows programming environment of choice, but that's quite a few years off.  It took 7+ years to complete a deep mainstream transition to NT, and Longhorn is far from being a shipping product.

Wednesday, February 18, 2004

Most 'real' programmers will tell you that ATL is better, faster, and start ranting on about threads and other such issues in order to flaunt their knowledge. But in all honesty, if you can find a decent programmer who remains open minded towards Microsoft, and doesn't fall into the "hate Bill Gates because your'e supposed to as a programmer" stereotype, you may get them to admit that MFC is actually a fantastic library providing the programmer with full class functionality over the Win32 API. If you can get them to ignore the distribution issue(I mean, big deal, so you have to distribute your application with a few extra dll's) If you dont mind the distribution issue - well then MFC is awesome. ATL is no doubt faster, and you can read all about the geeky advantages ATL provides - if you can find documentation ! The only way to really find out what method or function you need, is to search through the atl header files and hope to find something that sounds like what you need. MFC is extremely wel documented, and that in and of itself makes for quick development. For instance, in ATL - in order to populate a listbox (CListView object), you have to add the columns and the rows before you try to populate - it just shouldnt be that way. And by the time you figure this out (remember, there's no docs to tell you this), you could have finished the entire app using mfc. I will say this - it is really cool that everything you need for gui development is wrapped up in those few atl header files, and it is awesome to be able to distribute an application stand alone, no additional files, or ocx's to register. That is very cool. But ATL is very close to the raw Win32API, and quite frankly Ive faced just as many challenges programming in VB while using raw Win32API calls. A library like atl should wrap the Win32API up real nice, and friendly - and I dont think that ATL does this. Perhaps if there was more documentation...I dont know. But Im a decent programmer and i happen to love MFC. Take it for what its worth. If you use ATL, chances are your boss will love you for it, but I dont know about ATL when Im writing my own applications which have nothing to do with work - then, I choose MFC.

Tom Shavel
Wednesday, June 16, 2004

*  Recent Topics

*  Fog Creek Home