|
|
|
 |
Best Windows Programming Books? I'm looking to get myself well-acquainted with Windows programming. I know C++, but I don't know:
Alai
Advanced Windows (I think its on its 3rd edition) by Jeffrey Richter.
MikeG
"Programming Windows" by Charles Petzold (make sure you get the latest edition, which includes the latest stuff)
MX
"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.
Semi-Anonymous Coward
Probably this one - http://www.ibiblio.org/Dave/Dr-Fun/df200002/df20000210.jpg
AJS
wxWindows has a nice gentle learning curve, very similar to MFC but open rather than proprietary.
Tony Edgecombe
Beside Petzold and Advanced Windows, "Windows Graphics
VPC
Petzold. Oh, and then there's Petzold. Oh yeah, I hear there's a new version of Petzold.
veal
At the risk of postin' me too like a brain-dead AOLer:
Dan Maas
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
Today, the .NET framework works over Win32 - it works by calling Win32 functions.
Mike
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.
Nick
Petzold? It was good advice until Windows 95...now Petzold is pretty much useless, better to pick up some of the one author per chapter Wrox Press books.
Code Monkey
When It comes to Windows programming, here is the fastest way to learn (in my opinion):
C++_will_live_on
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)
Dan Maas
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.
veal
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.
veal
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
|
