Programming Windows - Charles Petzold

[Scott_Arm]

Is the book "Programming Windows" by Charles Petzold still relevant today? I've noticed it's not a really new book, and I was just wondering if the book applied to the WindowsAPI as it exists in WindowsXP. I know the WindowsAPI is out the window once Vista comes out, but I think it'll be a while before we see the end of XP. I'd like to learn about the API, and it seems like this was a highly recommended book. I'm just not sure if it was more of a WindowsNT/98 book than a WindowsXP book.

Anyone know if his books on .NET are any good? He seems to be a highly respected authour.

 

[Fdooch]

A must read.
.NET wraps WinAPI with OO but doesn't change the concepts of working with threads, GDI etc.
J.Richter books are also on the 'must read' list.

 

[_xxx_]

Had that book for ages but never bothered reading but from what I've seen it seems to be very good.

 

[Rolf N]

A waste of time and money IMO (and I bought it and read a fair amount of it).
It's horribly structured, it's cluttered with irrelevant and annoying off-topic distractions. It doesn't explain things and just throws them at you in random order.

It's really much more effective to plough through MSDN. Just grab a random "How to put my first window on screen" tutorial, run from there and look up unknown stuff on first encounter.

There is nothing in that book that isn't also on MSDN, on the contrary, and MSDN is much more detailed and has much better structure to boot.

 

[Scott_Arm]

Interesting ... two replies at completely opposite ends of the spectrum

 

[Rolf N]

Interesting ... two replies at completely opposite ends of the spectrum

Whether this book is useful to you or not will depend on what level of Win32 programming you've already learned. For a beginner, it will surely help getting the baby steps done, though for that purpose the book is too expensive IMO. There are just so many good programming resources available for free on the net. If you prefer having a physical book to read anywhere, then grab this.

The gripe I have about the book is that it will leave you wanting once you need to know things more specifically. The Win32 API has some quirky design choices and the book was written from the perspective of someone who never questions them and probably thinks they are logical, obvious and the only way there is. The quirks are never mentioned or explained in the book, and that's the huge problem with it.

1)On Win32 windows are owned by the threads that created them. There are many things you might want to do to a window that will fail if attempted from a different thread. DestroyWindow will fail. SendMessage will hang your process. I've had to learn these things the hard way. You will find it mentioned on MSDN, but you will not know anything about these pitfalls if all you have is this one book, no matter how often you read it.

2)As you probably know, Win32 requires "message pump" code to be executed for a window. What happens to messages passed to a fresh window after creation but before entering the message pump? Will the messages sent by CreateWindow bypass the message pump and immediately dispatch to the Window procedure, or are they all queued up until the message pump starts?
You will not find this question answered in the book.

And the list could go on and on.

If you're looking for a technical reference, look elsewhere. This book is prose.

 

[Scott_Arm]

Whether this book is useful to you or not will depend on what level of Win32 programming you've already learned. For a beginner, it will surely help getting the baby steps done, though for that purpose the book is too expensive IMO. There are just so many good programming resources available for free on the net. If you prefer having a physical book to read anywhere, then grab this.

The gripe I have about the book is that it will leave you wanting once you need to know things more specifically. The Win32 API has some quirky design choices and the book was written from the perspective of someone who never questions them and probably thinks they are logical, obvious and the only way there is. The quirks are never mentioned or explained in the book, and that's the huge problem with it.

1)On Win32 windows are owned by the threads that created them. There are many things you might want to do to a window that will fail if attempted from a different thread. DestroyWindow will fail. SendMessage will hang your process. I've had to learn these things the hard way. You will find it mentioned on MSDN, but you will not know anything about these pitfalls if all you have is this one book, no matter how often you read it.

2)As you probably know, Win32 requires "message pump" code to be executed for a window. What happens to messages passed to a fresh window after creation but before entering the message pump? Will the messages sent by CreateWindow bypass the message pump and immediately dispatch to the Window procedure, or are they all queued up until the message pump starts?
You will not find this question answered in the book.

And the list could go on and on.

If you're looking for a technical reference, look elsewhere. This book is prose.

I'm not an experienced Win32 programmer. Most of the programming I've done was in C or C++ for the command line on Linux or Qnx. I've used Java and .NET for making little applications. This book might be what I'm looking for. I'll try to track one down to take a look before I buy.

 

[ERP]

I'm not an experienced Win32 programmer. Most of the programming I've done was in C or C++ for the command line on Linux or Qnx. I've used Java and .NET for making little applications. This book might be what I'm looking for. I'll try to track one down to take a look before I buy.

I haven't read the book in a lot of years...
It's an introduction as pointed out above, there are a lot of gotchas in the windows API that you will have to learn the hard way. Some of the API is none obvious, like continually allocating and releasing resource handles (until you realise there are a finite number available). There are so many ways to screw yourself in the API.

The question is why do you want to learn the windows API, I did it back in the Win3.1 days, when I had no choice, but today for most of the windows apps I write I'd probably stick to C#.

I write the same 100 line wrapper over and over for D3D apps, but that's about the limit of my "windows" programming these days, and you just need one example to know how to do that, not a book.

 

[Scott_Arm]

I haven't read the book in a lot of years...
It's an introduction as pointed out above, there are a lot of gotchas in the windows API that you will have to learn the hard way. Some of the API is none obvious, like continually allocating and releasing resource handles (until you realise there are a finite number available). There are so many ways to screw yourself in the API.

The question is why do you want to learn the windows API, I did it back in the Win3.1 days, when I had no choice, but today for most of the windows apps I write I'd probably stick to C#.

I write the same 100 line wrapper over and over for D3D apps, but that's about the limit of my "windows" programming these days, and you just need one example to know how to do that, not a book.

My friend has been doing some game programming for the last year, and we haven't worked on any projects together since we got out of school almost a year ago. He wanted me to do a few projects with him. Previously he'd been using the Allegro library, because it was easy. He wants to switch over to Directx. Neither of us have used DirectX or the WindowsAPI directly. Our first game project is going to be pong

 

[Miksu]

My friend has been doing some game programming for the last year, and we haven't worked on any projects together since we got out of school almost a year ago. He wanted me to do a few projects with him. Previously he'd been using the Allegro library, because it was easy. He wants to switch over to Directx. Neither of us have used DirectX or the WindowsAPI directly. Our first game project is going to be pong

You could still use C# and .NET. Altought somewhat buggy, Managed DirectX is easy to use.

 

[Scott_Arm]

You could still use C# and .NET. Altought somewhat buggy, Managed DirectX is easy to use.

I suggested it, and he doesn't want to use it. I may learn it on the side, for myself.

 

[_xxx_]

Interesting ... two replies at completely opposite ends of the spectrum

No, MSDN really rocks hard

EDIT:
For usual Win programming I'd rather recommend Chapman's "Learn Visual Studio 6 in 21 days" or something from Jesse Liberty. Easy and fast and gives you a good start.