C++ GUI without Frameworks

Question

So as far as I understand it, there is no way to have a C++ GUI designer and ship your application as one, standalone executable. All the 3rd party frameworks add their dependencies in form of .dll-s etc., be it MFC, Qt, WTL, wxWidgets, GTK. That leaves me with only one solution - design the GUI for my current application myself using Win32 API. Are my assumptions correct or am I missing something? I've always wondered how uTorrent and some others have managed to do it. Thanks.

Answer 1

Depending on your application's minimal OS requirements, you can link dynamically to an MFC or ATL (in case of a WTL application) version that's included in the minimal targetted version of Windows.

And there's an added advantage of such solution - whenever a security update of the used library comes out, you don't have to update your application in order to benefit from it.

But still it's not that horrible to code for pure Windows API anyway so I'd suggest you go with it.

One problem is that apps compiled with newer versions of Visual Studio require latest CRT runtime library that you have to ship in the installer or make the user install it by himself. There are ways to overcome that. I think that blog entry is the one I stumbled upon some time ago. Of course you have to be careful with that as if you link dynamically against an old CRT library, it'd be best to code against its headers as well. Maybe there's a way to get rid of the CRT dependency completely.

Edit

I decided to elaborate after a heated discussion with Cody Gray below to maybe restate my points and put out some warnings.

Rant incoming

Even desktop software is a service you have to maintain for the user once you ship it. Operating systems versions change, their APIs and shipped libraries change as well. Apple doesn't have a problem with "breaking" apps with newer OS X and iOS versions and developers understand they have to keep their products up-to-date or they'll lose clients or be too busy with support calls. Microsoft among others in "big business world" created a class of programmers that think of software as buildings. You design it, build it, someone approves it and you're done, after maybe supporting it for two more years. And that's not what it should be.

Even when one writes as much future-proof application as possible, i.e. depending on completely defined, general and documented behavior of the target operating system and any that could come after it, and even they link statically against all libraries it uses, they make it self-contained, correct and oldnewthing-approved, they still have to actively maintain it for years to come. The libraries it's dependent on do change. They are upgraded, improved, bugs are removed, vulnerabilities are fixed, OS-dependent behavior is updated, removed fixed or generalized.

Even if the app is dependent on the absolutely minimal set of system libraries, everything above applies as well.

So regardless of your app being supposed to be used for a limited time or not, you have to assume and plan you're going to have to maintain it, if anything changes that's related to your app. Even if it's a pure Win32 API application, you'll have to check how it behaves in the newer version of Windows, whether it provides UI elements or services that users of that new OS expect from their apps.

And having said that, if you don't go the pure Win32 API route, be mindful of the trade-offs you make when and if using any of the hacks I originally mentioned.

Even if your project results in a throwaway app. Even if just for future-proofing yourself.

Answer 2

No, you can statically link most of the popular GUI frameworks, including MFC, Qt, ATL/WTL, and wxWidgets. I don't know about GTK, but I assume that you probably can statically link it, too.

Statically linking means that instead of dynamically linking to the library code living in a DLL, you link that code directly into your executable, resulting in a single, standalone EXE file you can ship without any external dependencies.

But of course, those dependencies will still be there and they will still bloat the size of your executable, which may be a problem, depending on your deployment mechanism. Also, there's something to be said for programming close to the metal, so using the Win32 API directly is definitely an option. That's going to produce the absolutely smallest, lightest application possible, and probably the fastest, too. In fact, I believe this is precisely what μTorrent does (or at least, it's what they used to do several versions ago).

Answer 3

Some frameworks allow you to build a self-sufficient "standalone monolyte" EXE, without any extra dependencies (apart from obvious API provided by the OS). For instance in MFC you have an option to either "static" or "dynamic" MFC usage. The 1st option means all the needed stuff will be linked within your EXE.