Learning Win32 to develop GUI Applications

Question

if you're a c++ programmer, would you go for the Win32 API or .NET to develop GUI applications?

Answer 1

I would go with Qt. It's a cross-flatform C++ GUI framework.

Answer 2

Try this free book - I found it very good. It's a guide to C# and .net for C++ programmers and skips right by the usual kiddy stuff.

http://www.charlespetzold.com/dotnet/

Answer 3

I'd say do both. I learned a little Win32 stuff before .NET came out. I played around with both the Win32 API itself and MFC. It was very educational. I learned a lot about how Windows treats your application and things it expects you to do. If I go back and learned .NET now, I'm fairly certain I'd appreciate it more than I would without any prior experience.

Answer 4

Win32 is an API (Application Programming Interface). So is .NET. So is POSIX. The first two have GUI toolkits integrated into the main API, but you can use other toolkits such as Qt (as suggested by Skildrick) or wxWindows instead if you choose. For *nix, the main API is POSIX and almost all of them use X11 as the low-level graphics layer, then you need some GUI toolkit on top (none is integrated into POSIX). Depending on the type of displays you want, OpenGL is another very good highly portable GUI toolkit, though it focuses on high-speed vector graphics rather than UI widgets.

One good reason for using the Win32 API's integrated GUI toolkit is that many of the other parts of the Win32 API use it, e.g. WSAAsyncSelect and MsgWaitForMultipleObjectsEx are non-GUI functions which are integrated into GUI message processing. A good wrapper toolkit will give you enough control to continue using these, but few do since this approach is very different with non-Windows OSes and most alternative toolkits value portability above capability.

Even .NET, which is designed from the ground up to run optimally on Windows, can't use asynchronous procedure calls or waitable timers from a UI thread, since none of the message processing in .NET uses MsgWaitForMultipleObjects. So you end up forced to use multiple threads and a ton of yucky synchronization code.

But stay away from MFC. It is basically an academic exercise in implementing exceptions without compiler support, not the kind of framework you want for serious applications. Most of the other "features" got added after modern C++ design was much better understood but continue to use the dangerous messy style started by the early hacks on exceptions and virtual inheritance in the name of keeping things consistent. There are much better choices available today.