Win32 API vs MFC : What to choose

Question

4.29/5 (3 votes)

See more:

I have recently studied the Win32 API. (Bought Charles Petzold's Book and almost completely read it). I really like the Win32 API but it feels like I'm wasting time. So I am thinking about learning MFC. I believe I will be able to learn fast since I know Win32.

There're a few questions.
Is it worth learning MFC ?
How hard/easy is it to port MFC applications to other platforms ?
What do you personally prefer; MFC or Win32 (or neither) ?

Edit:
I am only writing native apps with C++.

Posted 17-Oct-13 1:21am

Codexzy

Updated 3-Oct-21 22:19pm

v2

Add a Solution

8 solutions

Solution 5

There is always low level stuff and very high level stuff and a gradual transition between the two. On windows if we speak of GUI the lowest level is the WinAPI that is a procedural C interface (located mostly in the user and gdi libraries) and the interface of a really good high level gui framework implementation is usually object oriented and it has usually nothing to do with the pure C WinAPI gui interface of windows.

A high level framework (like Qt, java swing, Delphi, .Net gui frameworks) may seem to be hard to use at first if you are used to using winapi or MFC but after learning them (and the MVC pattern they make use of) these higher level frameworks are much better and its much easier to write nicer/reusable code with them. Not to mention that most good high level libs give you tools to visually edit the windows (in a much better way then the winapi dialog resource editor used in winapi and mfc). The high level APIs usually hide the low level API completely from you (and simply/normal gui code doesnt contain ugly stuff like hooking into winapi HWNDS/dialog controls with MFC objects).

If you focus on nice code design then learn how a high level object oriented gui library works. If you are interested about whats going on under the hood then learn some low level winapi too, it definitely makes you a better programmer and you understand even higher level gui libraries especially if you learn how to implement a simple object oriented gui framework on top of winapi. In my opinion struggling through the book of Charlest Petzold isn't a waste of time.

MFC: forget about it and learn it only if it is necessary. BTW MFC is a very big library that isn't only about gui: http://msdn.microsoft.com/en-us/library/ws8s10w4.aspx[^]
MFC contains some useful high level classes (for example to do networking, ...) but using these makes your program very hard to port to other platforms. If we speak of the GUI part of MFC: it is much more near to the raw winapi then to a high level object oriented nice framework. In fact, MFC is quite outdated and MS maintains if because of the tremendous heritage code but it has not much to do with a modern gui framework and most of its class methods has the same name as the winapi functions and usually they do the same. Most of the MFC mechanisms build on the raw winapi mechanisms and MFC doesnt try to hide this (that is sometimes terrible in my opinion). MFC is only half (or maybe one-third) object oriented and the rest is basically straight winapi. If you still want to learn MFC (or if you have to learn MFC because you have to maintain some projects in MFC) then learning the book of Charles Petzold is a must, you have to know winapi in order to work with MFC because MFC gui is basically a set of classes that have the same methods as the gui part of the winapi. period. If you are OK with mediocre MFC knowledge then you can do it without learning winapi just by copy pasting examples from the net but in case of some tricky problems you will often need the help of others.

If you want to taste some nice gui frameworks then search for some gui example code written in the above mentioned gui frameworks and compare them with mfc examples. Check out the level of "object orientedness" and the connection with winapi or any other low level apis of these frameworks and MFC. You will see the difference especially if you have winapi experience.

The opensource and crossplatform sibling of MFC is wxWidgets, to me wxWidget solutions/mechanisms feel quite similar to those of MFC.

EDIT: Forgot to mention some important things:
Qt is quite good, the only thing I don't like in it is the superflous signal-slot mechanism and its code generator before compilation. But the lib itself is quite OK. Qt also has a lot of non-gui helper classes (like networking, xml, ...)

Another very nice alternative is C++ Builder. Its gui editor is like that of Delphi's or .Nets gui builder that is the best in my opinion. C++ Builder has the disadvantage that you have to stuck to its C++ compiler but if that is OK then this gui builder is probably the best RAD tool for C++ gui editing. If you are curious about how does it feel to develop gui-intensive app with the best gui development tools then definitely try either .Net, Delphi (pascal) or C++ Builder (that has exactly the same IDE as Delphi).

Posted 17-Oct-13 12:10pm

pasztorpisti

Updated 17-Oct-13 12:22pm

v2

Solution 1

MFC is your choice if you want C++ and Windows. On other platforms it wont run.

If you want portability you better learn Java.

I am programming for over 10 years MFC but feel it is disappearing. I use the MFC for "GUI-Stuff" and do the hard work with C++.

My tip is not "to learn" MFC but use the "learning by doing" approach for the needed MFC-Stuff. In codeproject are tons of MFC-code so you can learn it here. ;-)

Posted 17-Oct-13 1:39am

KarstenK

Comments

Albert Holguin 17-Oct-13 10:40am

Well.. there is Wine as a portability layer for MFC.

KarstenK 17-Oct-13 10:43am

A great argument for using MFC...

really....

Solution 4

Yes, there's a lot of differing opinions on this out there...

Quote:
Is it worth learning MFC ?
How hard/easy is it to port MFC applications to other platforms ?
What do you personally prefer; MFC or Win32 (or neither) ?

Worth learning: Sure, if you already are familiar with the WinAPI, it really isn't a big deal. You'll just find that everything is wrapped around C++ classes and a lot easier to accomplish your work. You can't say there's a lot of jobs that require MFC out there but knowing the WinAPI and MFC will mean you know a lot more about Windows than most of the other programmers out there (some of these abstraction layers sure make programmers that don't know squat about what's going on behind the scenes). Plus, like I mentioned in one of the other solutions, MFC has been around for a LONG time.

Porting: Well, you can use the Wine interoperability layer for running MFC apps in Linux but you definitely have to test, test, test. As hard as they try, Wine isn't perfect, so there's a lot of things that work well in Windows and don't work well with Wine in Linux. Best option here is to make sure you separate the GUI and core code so you have the option to simply add a native Linux compatible GUI and recompile.

MFC v. Win32: MFC is way better than the raw Win32 API. With that said though, it is nice to know what it is that MFC is wrapping up behind the scenes because then you can easily manipulate MFC (or any other framework) to work exactly how you want it to.

Posted 17-Oct-13 4:50am

Albert Holguin

Solution 6

I really like the Win32 API but it feels like I'm wasting time.

Well, That's wrong I think. Classes supported by MFC is the capsulated API functions and classes.

However, it depends on your work in the future. According to my experience, WIN32 API is very important and knowledge of WIN32 API is very useful using MFC.

When making programs with MFC, there are lots of problems not be solved via MFC. At that moment, we implement WIN32 API method to solve.

In my own opinion, studying WIN32 API is not wasting time.

Thank you.

Posted 17-Oct-13 16:11pm

WuRunZhe

Solution 2

Is it worth learning MFC ?

If you using C++ (native, not .net) then MFC is still one of the best platforms. It is preferable over the pure Windows API anyway, because it encapsulates much of the resource allocations nicely. But before starting a new project with MFC I would take a look at the alternatives, like Qt or using C# and .net instead of native C++.

How hard/easy is it to port MFC applications to other platforms ?
There is not much portability. With MFC you are virtually stuck to Windows. That's why I would take a look at Qt.

What do you personally prefer; MFC or Win32 (or neither) ?
If it is either/or, then MFC without question. You can do all things that can be done with Win32 API (actually you can still call Win32 API functions in an MFC application). But MFC makes several things like message routing, resource allocation, and application structuring a lot easier.

Posted 17-Oct-13 1:43am

nv3

Comments

Codexzy 17-Oct-13 8:06am

Yes I am using native C++.

Albert Holguin 17-Oct-13 10:35am

Posted a comment to this solution.

Albert Holguin 17-Oct-13 10:34am

You're forgetting about Wine for porting applications to Linux. Works decently well as long as you always test your code in both Windows and Linux (don't assume it's going to work in Linux because it works in Windows). Also, everyone I know that's used Qt has complained about it... so I don't know I'd call it a "better alternative" to MFC, just an "alternative".

nv3 17-Oct-13 10:43am

Thanks, Albert, for pointing that out. I haven't worked with Wine yet. It's interesting to hear that there is in fact some portability for MFC applications. I have heard good an bad things about Qt. I surely contains some very nice features.

Albert Holguin 17-Oct-13 10:52am

Wine works, but it's a pain in the butt... and Qt works, but it's a pain in the butt too. I guess there's options for everything. We have an engineer that has sworn never to work with Qt again after a major project that converted old C++ code onto Qt for multi-platform use.

KarstenK 17-Oct-13 10:45am

What are your "profesionell experiences" with Wine?

I wont "ride dead horses" like MFC :-(

Albert Holguin 17-Oct-13 10:55am

Wine works ok but you have to make sure to test everything. There's trivial things that work well in MFC but not all that well in Wine. They also don't support every single thing available in MFC, for example, threading priorities... but their rationale is that thread priorities can open you up for DoS attacks (which is true). I wouldn't call MFC a dead horse quite yet, not as long as MS continues to support it and put out new versions.

Solution 7

MFC v. Win32
Well, there are those who have the pleasure of working from scratch; and you maybe one of them (I am one of them). On the other hand, you may be looking for a quicker and more immediate way of reaching to the solution. This two possibilities will clearly define what your choice will be.
My personal opninion is that: working with pure WinAPI will seem to be "waste of time" in the begining, but once you get the thing clearer, you will "fly like a fish in the water". For the majority of the things (function, structs...) you can have already created your own classes/libraries. Use MFC to have the things rapidly done (That is one the main design principle of the MFC), but a solid knowledge of WinAPI will be a good weapon on this path.

Posted 18-Jul-16 2:57am

VNyavotso

Comments

Richard MacCutchan 18-Jul-16 9:23am

This question was opened and answered nearly 3 years ago. Your comments are too late and add nothing new.

Solution 9

It is better to stick to windows API. You can use VC++ or DEVC++ or codeblocks.
If you use MFC you will have to stick to microsoft vc++.
Microsoft claims that using MFC simplifies programmimg and reduces the code. On the contrary it increases coding. Just imagine use clumsy SDI and MDI are. I have not yet understood how to use them.
On the contrary using API is simple. you have only one c++ file containing windows structure and a procedure. You don't have to break your head to understand it. In a complex application you can have more window structures and more procedures. But that is a rare situation. On the other hand MFC creates one header file and a source file for each class you use. you will have dozen files for even a simple application.

( Microsoft has both winAPI and MFC. It is not to belittle Microsoft.)

Posted 28-Sep-24 15:32pm

Member 16383089

Comments

CHill60 30-Sep-24 9:30am

Your opinion bucks the trend of solutions posted in the 11 years since this question was asked - possibly because, as you admit yourself, you don't actually understand how to use MFC. Beyond that, you have added nothing new to the thread.

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Maximilien · Accepted Answer · 2013-10-17T03:28:00

It depends on what kind of work you expect to do in the near future; and what kind of technology those domains are using (look at the job listings).

One important thing is that when developing application is to split the GUI compoenents (MFC, QT, ... ) from the core features (C++) so that if you need to port the application, you will have to only port/rewrite the GUI part and not the core features.

I've been using C++/MFC full time for the last 12 years, and I know that if I change job, I will probably need to do something else (there ain't no job locally with C++/MFC),

Win32 API vs MFC : What to choose

8 solutions

Solution 5

Solution 3

Solution 1

Solution 4

Solution 6

Solution 2

Solution 7

Solution 9

Add your solution here

Preview 0

Win32 API vs MFC : What to choose

8 solutions

Solution 5

Solution 3

Solution 1

Solution 4

Solution 6

Solution 2

Solution 7

Solution 9

Add your solution here

Preview 0

Existing Members

...or Join us