Creating a Windows XP Application [Archive]

JVene

April 29th, 2009, 06:06 PM

There are many schools of thought, so I'll use mine :)

I personally assert that the proper reaction a C++ developer should have to a C level API is to encapsulate. In the case of Win32, that would suggest a GUI application framework, but of course my directive to encapsulate doesn't really mean you have to write it.

For a long time Windows applications have been developed using MFC, microsoft's C++ framework. It has an older style feel to it, and is well known, well covered in dozens of books, and does work. It's not exemplary modern C++, but you can bet that anything Windows native API was intended to do, you can manage with MFC. I don't personally recommend it or use it, though I have used it.

One issue that has rung true for me through the years is the subject of portability. Classic portability means you write an application such that it can compile on various platforms, usually meaning *nix, Mac and Windows. In the past that has meant a 'least common denominator' approach to UI appearance and operation, but that has gotten much better in recent years. QT is expensive for commercial use, but is also a well known, well documented, well supported framework with a more modern C++ design than MFC, but some take exception to it's design while others prefer it.

wxWidgets is a free counterpart. Both QT and wxWidgets will allow developers to create applications that compile and work on Mac (this is the least supported and most recent of the group), Linux and Windows. Mac is 'late' in both QT and wxWidgets because of Apple, and of the design choices made in both frameworks. QT is ahead in this regard. For Mac targets there was a choice to be made. The underlying C API for Mac is Carbon (their name for it). wxWidgets for MAC was originally based on carbon, as was QT, because it was closer to their design for their backend on other platforms. However, Apple announced that carbon was now limited to 32 bit OSX builds, and would never port to 64 bits. That meant that the only way to make 64 bit application targets for MAC would be to use Cocoa instead of Carbon. This is problematic for several reasons, not the least of which is that Cocoa uses a language most non-Apple (non-Next) developers never heard of, Objective-C.

QT moved forward with Objective-C/Cocoa backend development. wxWidgets had some alpha work as far back as 2001 as I can tell, but I don't see that there's any movement on that front at this point. I haven't checked in some time.

There's also WTL (Windows Template Library), another Microsoft specific framework, and a host of historical frameworks that I've not tracked which at one time had significant popularity and various degrees of portability.

Portability has a second theme that is more important than platform independence. The ability to code one application that can target multiple platforms can widen the customer base, but portability applies within a platform, too.

Think about the migrations of Windows from 1.0, 2.0, 3.0, the disaster of migrating to Windows 3.1, which I doubt anyone under 30 would remember well, the migration from 16 bit Windows to 32 bit Windows (a major shift where the existing frameworks didn't help at the time), portability between NT and Windows 95/98/Me, and, now, portability from 32 to 64 bit Windows, Vista, and Windows 7.

MFC can take you there, but it has not always been a smooth ride (we were recently threated that MFC would reach an endpoint). You're all but guaranteed that MFC will be among the first C++ frameworks to support new versions of Windows (until MS decides otherwise, again), but I don't believe that is nearly as important as it used to be (though Windows 7 may surprise us).

You mentioned .Net. That's not specifically a C++ framework, but a different take on the concept of OS API. From *Nix, DOS and Windows, the primary interface to the OS was C, or a C wrapper for assembler interfaces in the case of DOS (nearly the same thing). Objective-C, on the MAC (well, first on Next), and Cocoa (the framework) were the first departure in a commercial OS I know of. In that case, the underlying language has object oriented constructs, and the OS interface is a set of classes, not a series of families of functions.

.NET is yet another branch on that same theoretical shift. The .NET means of building an application is not something a C++ student would want to implement in C++, but you'd be better off in C#, or even J#, because that's what .NET is really aimed toward. C++ has the means, but it is yet another layer of language extensions, and therefore is ANOTHER thing to have to learn for a C++ developer. I have yet to be convinced .NET is superior in any regard, primarily because my own concerns about portability override the option, but an entire generation of developers have emerged that prefer C#, and therefore .NET, for the kind of applications they make.

I think that last point is key. Certain frameworks take you in directions better suited for a type of application target. C# isn't going to become Adobe's language of choice for their large portfolio of applications, for example. They don't use MFC either. They make most of the products to run on MAC and Windows, and a significant volume of their framework was developed in house. They have a counterpart to XAML, for instance, that may even be better. It is not public, to my knowledge - or at least not all of it.

Contrast that to AutoDesk products. 3D Studio Max, Revit and AutoCAD, 3 industrial grade standard products of architecture, drafting and 3D modelling/rendering, are all based on MFC.

As a result, you won't find any of these products on a MAC, whereas if you use Photoshop on a MAC, and then on Windows - while it looks entirely different, it works about the same.

Think of where the industry would be today if all major vendors made their software in the fashion Adobe chose, and especially if they threw Linux into their mix of targets!

That should give you some idea of how to investigate which potential frameworks are best for you to choose.

However, not everyone is an entrepreneur. Many will look for a job in a firm. Some will end up in corporate application development (where Java and C#/.NET now reign), others in shrinkwrap (working for Adobe perhaps), others will make games (for which there is no interest in MFC, wxWidgets - they need frameworks of a different kind: game engines).

I hope you're not unsatisfied for not getting a "oh, use xyz framework, it's the best" - or "just use MFC" answer out of me, ....well, sorry. There is not valid, short, quick answer to that.

You may well study a few of these so you understand the merits of each (you can download QT and wxWidgets for free, QT will limit you to GPL and study, but you'll be able to use it). You'll need to learn flexibility anyway, because as sure as we're going to have 8 and 16 core CPU's, any framework you choose will reach some endstop beyond which you can only proceed if you're ready to jump ship to yet another one.

Even MFC did that to us in Visual C 1.5 for 16 bit builds.

Then there's the story of OWL.....look that up if you want to know how to make Windows/OS2 portable applications for some reason. Lots of developers were sad to see that dropped, but it was time.