• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
formalproof

Win32 API and Petzold - still relevant?

16 posts in this topic

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?

0

Share this post


Link to post
Share on other sites

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
0

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?

0

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.

1

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
1

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

1

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.

1

Share this post


Link to post
Share on other sites


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

0

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0