Advertisement Jump to content
Sign in to follow this  

'win32 API' or '.net' Huge confusion

This topic is 4241 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

Alright I'd like to make games in OpenGL and I'm confused to as what is going on here. If I were to look at the Win32 API (which is what most people are using these days) then what about the future of this API? I've heard that Vista supports mainly the '.net' framework and its moving away from the win32 API (only using it for backwards compatibility with older versions of windows? I looked at a lot of game programming job description and most of them want you to have Win32 API knowledge. Is there going to be a change with the API to the .net framworks for games? or just mainly for office / business applications? I'm using primarily C++.

Share this post

Link to post
Share on other sites
.NET is many things; among them is System.Windows.Forms or "WinForms," a managed windowing API. This is built on top of the native Win32 API, and is only accessible from managed code (e.g., you must use C++/CLI or VS 2003's "Managed C++" extensions, not regular C++).

For C++ code, you'd want to interface directly with Win32 or use some other windowing wrapper built on top of Win32, depending on the extent to which you need to use the API.

Win32 is not going anywhere for a while. (Besides, you shouldn't be afraid of changes in technologies or APIs anyway.. you will need to learn and use multiple technologies in your career as a programmer, if you think you can pick the "best one" or the one with the most longevity up front and learn only that, you're going to relegate yourself to the ranks of mediocre programmers for your entire career. The technology industry changes.)

Share this post

Link to post
Share on other sites
"Win32 API"...

In modern terms is simply a term to indicate dealing with the Windows Message Pump. Microsoft's Win9X, and NT operating systems are based on a message pump. That is, any time a user performs an action such as moving the mouse, pressing a button, changing windows, etc...a "message" is sent to all windows which need to know this information.

It was common in the early 90's to work directly with the message pump. Every time a message was sent you'd switch it to determine if it was a message you were interested in, and then pass the arguments to your own function handler. This system was not object oriented, not written in C++, and in general, is no longer used today. Does this mean it's not important to know how the message pump works, to be able to override it when necessary, etc...? No. You still need an understanding of the pump, and you'll still occasionally need to be able to override the pump in order to capture events which are not easily accessible with modern GUI API's.

At any rate, after people got tired of doing things with the "Win32 API" Microsoft developed MFC - The Microsoft Foundation class library. This was essentially a weak wrapper around the Win32 API which used classes, inheritance, represent the major objects and events within windows. However, implementation was difficult, limited, and required the use of macro's, get it to work. The only benefit was that it was open source.

Around this time other GUI frameworks started becoming popular: ATL/WTL, Qt, etc...

However, Microsoft became aware of the limitation of MFC, and with the advent of .NET released a new framework called WinForms. This was a much more intuitive, easier to use, managed architecture. It still captures messages being sent by the windows message pump, but except in limited cases is no longer strictly a wrapper around the Win32 API calls. Although it is possible to make unmanaged Win32API calls using pInvoke, it's not the most frequent method of accomplishing things.

.NET and WinForms has proven very popular over the last 7 years, and up until Vista was the prefered way to do things for any Windows development (except in games of course, which are always 10 years behind modern trends).

Even more recently, however, Microsoft introduced WPF with the release of Vista. It's a brand new architecture based on the .NET 3.0 Framework which separates control functionality from presentation. This means you've got complete control over the appearance of your components, controls, and windows, even while making it possible to change implementation details. It also allows you to override the appearance of the windows Common Controls, while keeping all the built in functionality. I can make a button, border, radio button, etc...look however I want. If I want a radio button which just looks like button which is stuck in a depressed state, I can...with no code changes.

WPF is implemented via a combination of XAML and Code-behind, making it possible for designers, artists, and programmers to work in parallel.

Finally, WPF is the basis for microsoft's new venture, Silverlight, which is a cross-platform, cross-browser plugin which allows the execution of .NET 3 and WPF applications directly within a browser. This is their attempt at making computing even more web based, as complete applications can now be embedded directly within any browser, and distribued using ClickOnce installation.

Now, with all of the above said, it should be clear that the days of "Win32 API" programming are long gone for those seriously interested in Windows Development. However, keep in mind that much the above is just overheard for game developers. As well, most game companies are 10 years behind modern windowing capabilities. And save for "Tools Programming", you're not likely to find a game written using WinForms or WPF as the main windowing frame work.

More often than not, games fall back to the ol' Win32 API Message Pump, capture the main messages, and then send them off to handler functions. Keep in mind, though, most game programmers never seen this main message loop as it's nearly always covered by layer upon layer of in-house frameworks designed to hide the main program loop.

My advice, become familiar with the Win32 Message pump and "API", but then drop it and move on to .NET WinForms and WPF. You'll use it in more serious windows applications, and as you're likely to never have to deal directly with Win32 Messages in your games any more, it's not much of a concern.

Share this post

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

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!