Advertisement Jump to content
Sign in to follow this  
formalproof

Win32 API and Petzold - still relevant?

This topic is 1802 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I recently managed to get a cheap copy of Charles Petzold's Progamming Windows, 5th Edition (1998). I haven't really kept up with times all that well. So my question is: is this book, and the Win32 API in general, still relevant and useful?

 

I'm pretty sure that programs using the Win32 API described in the book are still compatible with modern versions of Windows. But has the API changed much since 1998? Will I get suboptimal performance or miss some important operating system features if I use the API calls described in the book?

 

The reason for my interest in Win32 API is that I'd like to be able to program with the minimal amount of abstraction layers (such MFC, .NET or the standard C/C++ IO libraries). That way, I get to know what my program really is doing under the hood. I am also involved in some research projects where speed and efficiency are critical, and I suspect I may have to write a very high-performance Windows program in the future. For this purpose, I suppose C and Win32 are still the way to go?

Share this post


Link to post
Share on other sites
Advertisement

If you use a lot of Win32 UI, then no, I doubt that is very efficient at all.

Performance critical calculations will likely have very little if anything to do with that API, and if you want to display graphics quickly for example then there are much better ways. Win32 can be pretty good for like file access and such if you like the programming model, but for performance it won't really matter what API you choose (as long as you do some research to find reasonable alternatives).

Nothing wrong with C if you like programming in it.

Edited by Erik Rufelt

Share this post


Link to post
Share on other sites

To clarify, I don't think there's anything wrong with Win32, and I write almost everything I do on Windows with it (just because it's the one I learned once and haven't needed anything else). I just think that choosing it for needing to write "high-performance Windows programs" would be a bad reason.

Share this post


Link to post
Share on other sites

yes it is still relevant and usefull, this base winapi not changed at all - and imo winapi is a good option to learn - though i am not sure if you will not find easier source than this book - Petzold book is slow in read, though  i got it on disk and sometimes look into it

 

The bigger change form those times is the change form 32 bit to 64 bit - this could be some difference and a pocket of details not covered in the book, but i was not doing 64 bit winapi yet so idont know what was changed - and if this is a second api mimicking the first or those are just the same functions jast called from 64bit cpu (?) I cannt see it

 

could maybe somewhere answer to that? what changed here?

Share this post


Link to post
Share on other sites

Charles Petzold's Progamming Windows, 5th Edition (1998). ... Is this book, and the Win32 API in general, still relevant and useful?
 
The reason for my interest in Win32 API is that I'd like to be able to program with the minimal amount of abstraction layers (such MFC, .NET or the standard C/C++ IO libraries). That way, I get to know what my program really is doing under the hood.

 
It might work for the purposes you described, with some caveats.
 
 
 
Beware that in a few ways it will be like an archaeological dig. 
 
Know before starting out that you are dealing with outdated practices and non-standard code from the VC5 era. That is way before the C++ language was standardized. The compilers have advanced and that edition relies heavily on pre-standard C++. 
 
You will have two sets of problems.
 
First, the language. You are going to encounter a lot of things that are relics. Much of the code will not even compile on a modern compiler. The language has gone through FOUR editions of standards, FIVE if you include how many of the changes in the C language got incorporated as extensions. Many of the practices in that age of book have been superseded. It is a very bad reference if your intent is to learn the language.
 
Second, the API. The Windows API has grown quite a lot since then, and you will certainly find a few things that are slightly broken as the API has grown to support larger environments. Most of the Windows API will work in approximately the same way the book documents, but it is still fifteen years out of date.
 

I am also involved in some research projects where speed and efficiency are critical, and I suspect I may have to write a very high-performance Windows program in the future. For this purpose, I suppose C and Win32 are still the way to go?

Probably not. It depends on your research project and the type of computing you will be doing.

The largest improvement to computing over the 15 years has been the migration to parallel processing. Back then most computers were single core, and parallel instructions (SIMD) were fairly new. A book from 1998 is going to make reference to the then-new MMX-enabled Pentium 2 processors that few people had yet purchased. Today you can spread your processing across four, eight, twelve, or possibly more processors; each processor is capable of working on 16 or even more variables at once through SIMD operations.

Taking it further, if you are working entirely in floating point math there are many benefits from moving processing from the CPU to the GPU. You can jump from around 100 GFLOPS on the CPU to around 5 TFLOPS by doing the work on the GPU. If your high performance systems can be moved to the graphics card you can see a 50x improvement.

Edited by frob
Wow. That was the VC5 era. And Pentium 2 was freshly released. Scarily I remember when that was new and exciting, and the run on the PPro chips as Adobe and other big corporations bought them all. Why does that make me feel really old?

Share this post


Link to post
Share on other sites

If you're going to write "windows applications", i.e. not web, command line or full screen games, then knowledge of the Win32 API is very useful. Despite all the improvements with winforms, wpf, etc, Win32 is still important under the hood.

 

That said, I wouldn't want to actually use the Win32 api to write anything non-trivial. There are simply more efficient (and to be clear, I'm talking programmer efficiency not cpu efficiency) ways of writing a Windows UI.

 

Right now, it's future is unclear. MS don't seem to really know what they want Windows to be anymore, and that confusion is born out by their UX apis. Windows 8 has largely failed in the consumer space and there has been huge resistance to it in enterprise. The merits or lack thereof of win 8 are irrelevant, the fact is the market doesn't like it.

 

Given their new CEO comes from an enterprise background, we may start to see Windows as a desktop OS return to a productivity focus. If that happens, we may see a renewed focus on Win32.

Share this post


Link to post
Share on other sites

It's quite useful for teaching you how to write dialog box style apps and handle control messages manually which you have to do quite a lot for 3DS Max plugins.

 

EDIT: And if you have to dig around under the hood in MFC, although if you have to do that you are probably better off looking for another job ;)

Edited by Paradigm Shifter

Share this post


Link to post
Share on other sites

It is important but not a priority. It takes time to note that a Win32 loop is very very similar to an Engine. The variables sometimes confuses. Like INT_PTR CALLBACK, MSG, etc. The first time I've looked to this I said: what the hell? But it's like a game. It has a space inside the code to handle and dispatch messages/actions/input a update function to refresh data variables and a paint command to render stuff (just a eg.). 

Share this post


Link to post
Share on other sites

could maybe somewhere answer to that? what changed here?

 

Not much has changed in the 64 bit API. A lot of code written for 32-bit windows should just be a matter of re-compiling.

 

The big thing to watch out for are pointer values that are common to store as integers in certain cases. SetWindowLong/GetWindowLong comes to mind. They have now been replaced with SetWindowLongPtr/GetWindowLongPtr. They use the data type UINT_PTR instead of UINT. If you use them, they will work on both 32 and 64 bit.

 

As for the original question, yes, the book is still pretty much relevant. New functions are added to the API  every now and then, and that's about as far as the changes in the API go. The stuff that the book talks about should work. Microsoft is really good at backwards compatibility.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!