Jump to content

  • Log In with Google      Sign In   
  • Create Account

Win32 API and Petzold - still relevant?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 formalproof   Members   -  Reputation: 165

Like
0Likes
Like

Posted 11 February 2014 - 12:26 PM

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?



Sponsor:

#2 Erik Rufelt   Crossbones+   -  Reputation: 3479

Like
0Likes
Like

Posted 11 February 2014 - 12:47 PM

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, 11 February 2014 - 12:50 PM.


#3 Buckeye   Crossbones+   -  Reputation: 4923

Like
5Likes
Like

Posted 11 February 2014 - 02:01 PM

In high contrast to Erik's response, I use Petzold's 5th edition (perhaps revised, mine is 1999) a lot. It appears to be entirely compatible with Windows 7 in spite of its age. The example projects on the CD, with only minor changes necessary to the project properties, compile and run without error (which amazes me, actually.) Most of the C code can be upgraded to C++ without much effort. Petzold uses an older programming style (15 years ago, not surprising), which needs some tweaking to use in C++ - functions with assumed return types, etc.

 

Relevant? Depends on what you intend. If you're into grass-roots programming, it's an excellent resource. Truth be told, though, I haven't a clue if the Windows API for the things Petzold discusses have been expanded or extended.

 

Optimal? Haven't a clue. [EDIT - got interrupted] A lot (most?) of the stuff discussed in the book isn't the sort of thing that need to be optimized: dialog boxes, buttons, etc.


Edited by Buckeye, 11 February 2014 - 02:17 PM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#4 Erik Rufelt   Crossbones+   -  Reputation: 3479

Like
3Likes
Like

Posted 11 February 2014 - 02:32 PM

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.



#5 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 11 February 2014 - 02:49 PM

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?



#6 frob   Moderators   -  Reputation: 21318

Like
4Likes
Like

Posted 11 February 2014 - 02:50 PM

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, 11 February 2014 - 03:14 PM.
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?

Check out my personal indie blog at bryanwagstaff.com.

#7 ChaosEngine   Crossbones+   -  Reputation: 2357

Like
1Likes
Like

Posted 11 February 2014 - 02:56 PM

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.


if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#8 Paradigm Shifter   Crossbones+   -  Reputation: 5373

Like
1Likes
Like

Posted 11 February 2014 - 02:59 PM

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, 11 February 2014 - 03:00 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#9 Irlan   Members   -  Reputation: 1506

Like
1Likes
Like

Posted 11 February 2014 - 03:08 PM

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.). 



#10 wack   Members   -  Reputation: 1306

Like
1Likes
Like

Posted 11 February 2014 - 03:08 PM

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.



#11 Buckeye   Crossbones+   -  Reputation: 4923

Like
0Likes
Like

Posted 11 February 2014 - 03:42 PM


... That is way before the C++ language was standardized. The compilers have advanced and that edition relies heavily on pre-standard C++.

...

Much of the code will not even compile on a modern compiler.

 

smile.png  Pre-standard C++ ...  true, back when it was called C.

 

Everything I've tried from the CD compiles fine on VS2013, BTW.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#12 Aardvajk   Crossbones+   -  Reputation: 5982

Like
2Likes
Like

Posted 11 February 2014 - 03:52 PM

Win32 isn't that bad, but it is C, so you are constantly struggling against a lack of type-safety when decoding message structures. Its okay.

 

Re the high performance thing though, libraries that wrap Win32 (Qt, WxWidgets) and take a great deal of pain out of the process don't really preclude any of the performance. You have to bear in mind which bits need to be high performance - they are hardly likely to be related to the GUI. I doubt you need to shave any cycles off what happens when a button is pressed, or when a scroll bar is rendered.

 

It is more likely your high performance will be required in either calculation or rendering. In the first case, the GUI library you use is entirely irrelevant. In the latter case, GDI, which is the graphical part of Win32, is not an appropriate choice for high performance rendering in the modern world - you want to look at an API (OpenGL, Direct3D, Direct2D or whatever it is called, etc) that will take full advantage of graphics hardware, so again the library wrapper around the GUI is not important.

 

That all said, Win32 can be quite satisfying in a perverse sort of way and I still prefer it to underpin full-screen game applications since the Win32 needed is quite minimal. Since getting proficient with Qt at work though, I'd never write a raw GUI application again, but I've already had my years of fun with Win32 and you haven't so the best of luck to you.


Edited by Aardvajk, 11 February 2014 - 03:54 PM.


#13 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 11 February 2014 - 04:34 PM

Win32 isn't that bad, but it is C, so you are constantly struggling against a lack of type-safety when decoding message structures. Its okay.

 

Re the high performance thing though, libraries that wrap Win32 (Qt, WxWidgets) and take a great deal of pain out of the process don't really preclude any of the performance. You have to bear in mind which bits need to be high performance - they are hardly likely to be related to the GUI. I doubt you need to shave any cycles off what happens when a button is pressed, or when a scroll bar is rendered.

 

It is more likely your high performance will be required in either calculation or rendering. In the first case, the GUI library you use is entirely irrelevant. In the latter case, GDI, which is the graphical part of Win32, is not an appropriate choice for high performance rendering in the modern world - you want to look at an API (OpenGL, Direct3D, Direct2D or whatever it is called, etc) that will take full advantage of graphics hardware, so again the library wrapper around the GUI is not important.

 

That all said, Win32 can be quite satisfying in a perverse sort of way and I still prefer it to underpin full-screen game applications since the Win32 needed is quite minimal. Since getting proficient with Qt at work though, I'd never write a raw GUI application again, but I've already had my years of fun with Win32 and you haven't so the best of luck to you.

 

I see people here treats winapi as as GUI library - but winapi is not gui

(it has some gui in it but the most important thing is a 'base program 

skeleton' window interaction with system by messages, input (keyboard /mouse) and some system things  - "winapi gui" is only side thing in winapi imo  [im using winapi abou 4 years, its program skeleton know 

like some ancient inscryption (almost by heart) but never did yet any gui in this )

 

nice thing in win32 coding is that you can produce very smal exe with no redistribuable, for example recently i was tinkering with some basic raytracer code and its exe had 14k bytes and it worked (now i got it grow to 28k)


Edited by fir, 11 February 2014 - 04:37 PM.


#14 Paradigm Shifter   Crossbones+   -  Reputation: 5373

Like
0Likes
Like

Posted 11 February 2014 - 04:41 PM

Win32 is a message passing/event driven API which includes some GUI.


Edited by Paradigm Shifter, 11 February 2014 - 04:41 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#15 Aardvajk   Crossbones+   -  Reputation: 5982

Like
1Likes
Like

Posted 11 February 2014 - 04:44 PM

Agreed, GUI is the wrong term. I call Qt a GUI library but it is also far more so the term is not sufficient.

 

What we call it makes little difference to the points made in the thread though. Everything that applies to "drawing controls on the screen" also applies to "using the file system", or "using OS synchronization features" etc etc. A lot of pain in a C API for no real advantage other than interest and, as fir points out, the small corner case of requiring a small distributable - hardly a frequent concern these days but a valid point.



#16 Paradigm Shifter   Crossbones+   -  Reputation: 5373

Like
1Likes
Like

Posted 11 February 2014 - 04:54 PM

Yup, there is a lot of pain ;)

 

It's not worth it for the effort involved even if there is some performance gain. Use the right tools for the job. Win32 API is fine for small dialog apps it gets unwieldy very fast.

 

EDIT: Although I thought it was a good book, it's how I learnt to program Windows (actually OS/2, but noone does than anymore)


Edited by Paradigm Shifter, 11 February 2014 - 04:55 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#17 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 11 February 2014 - 05:03 PM

Win32 is many purposes system api which specyficaly includes api calls and some massage event system intended for creation and management of the window (or windows) and controls (also its contents and overall system resources)

 

personaly i wouldlike if winapi will still be going on yet for some years,

i was learned it, its my primary environment, it costed me some experience, proved that it works and give some fun finally so i would like it not to be spoiled or removed to fast.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS