Is MFC obsolete?

[Sunil B.K.]

I have checked using PVIEW that most of the Microsoft products (msdev, IE, etc) donot use the mfc dll. They seem to run properly even if I delete the dll. Infact, Netscape Navigator cannot run without the dll. Why is it that MS itself doesnt use mfc?

[Martin Speiser]

Are you sure that MS don't use MFC? You can statically link it, so you don't need MFCxx.DLL.


Martin

[Sunil B.K.]

Thanks for the response.
But why would they use static linking? If the problem was to ensure that all users do have MFCxx.DLL, they could ship it with the so many DLLs that come with their products.

Sunil

[Martin Speiser]

Hi Sunil,

I checked several MS apps with depends.exe, and was surprised. Okay, not by IE, because what you see a iexplore.exe is basically only a COM client which hosts the WebBrowser and MSHTML control. But for Office 97 it looks like MS has it's own DLL. And then finally I found an app which uses MFC.DLL, DevStudio itself.

Well, maybe there will be a redesign of the MFC in near future. Everyone working with the library knows about the bugs and pitfalls, and a redesign is urgent. Just my 0.02 Euro worth.


Martin

[valiant]

according to B. ekiM (MFC Project Manager and author of Professional MFC with Visual C++ 5.0) MFC is alive and well and will be around for several more years at least. As to why MFC is not used in most MS projects is that Office ecetera have too much Non-MFC Legacy code to easily port and there does not seem to be much commercial sense to justify it. This statement (paraphrased from memory) was posted on the MFC Mailing list within the last month.

Valiant

[scytale]

Well, I won't be surprised if MFC are redesigned. I realized some time ago that MFC... Doesn't do anything! They are a poor wrap to the API calls. I'm sure there are a way to make a set of classes wich help more to the developers. Perhaps Microsoft have it but is not interested on deploying it.

[Martin Speiser]

Hi Scytale,

MFC was always developed as a poor wrapper over the Windows API. There are more abstract classes on the market, for instance StarView or ICLUI (the class library which comes with IBM VisualAge C++). It's just a personal thing what to use. I belong to the group which prefers the thin wrapper ;-)

Martin

[David Covello]

I have spoken to several teams in microsoft, and know first hand that they do not use MFC.
All their major products, like word, excel, ie, windows, etc. are written in pure C.
PowerPoint is written in C++, using a class library that the powerpoint team developed on their own.
The IDE for VC++ is written in MFC though, but relative to other apps it is relatively simple...
What else...
I know they have some products written in Java, only the actual GUI is done using native calls to the OS.
Would be pretty wierd if they suddenly stopped supporting MFC, since so many people depend on it.
But you never know...

[Ionel Munoz]

Hi:

You decide what to use depending on your field, and/or the kind of software you develop. A thin wrapper could be harder to use (and to learn) than a set of components like Borland's VCL for some kind of organizations. For RAD there is no doubt that MFC helps almost nothing.

On the other hand, for a relatively low level programming in Windows, it could be better using MFC instead. MFC has also the advantage of a big inertia, a lot of code spread over there, and a lot of money behind it(M$). So MFC won't die for sure.

Anyway, I think MFC is a bit old, really. MFC has an inheritance approach that promotes a high coupling among clases in the hierarchy. That's really bad. New programming philosophies point to easier componentware approaches, with lower coupling levels, and higher cohesion ones. COM/ActiveX is not so bad, mostly because its interface orientation, but Microsoft makes a big effort to complicate things whenever it deploys a new COM-based technology (maybe Microsoft Press has a good answer for this ;-)).

Finally, I belong to the group that tries to use the right tool for solving problems the most straightforward we can (whenever posible, of course); although I tend to use C++ (Microsoft or Borland) because it is my mother tongue :-D

Cheers
Ionel

[MRideout]

This isn't entirely true. Almost all of the components that make up MS Office are built using C++, just not with MFC. Object models are a core piece to component development.

[Tomaz Stih]

In my opition MFC has an identity chrisis. You can deploy it where it suits best but where does MFC suits best? What is really this library's place under the sun?

My opinion is: user interface programming. Paradoxically it is not a RAD tool. Paradoxically it also makes user interface programming harder because it tends to be a doc/view framework (paradoxically a very homogenous one and not consistent with latest OO achievements), and introduces a lot of concepts (such as serialization) which have ambition to be propagated throughout tiers but make user interfaces programming more complex. But still with this library you really have control over your widgets. And there is also a lot of stuff freely available ( thanks also to this site! :-) )

With complex apps you usually divide logic to tiers and use MFC just for presentation tier. So far one could use some MFC techniques (for example serialization and template collections) throughout the software.

But now with STL for containers, ATL for COM support and lousy and limiting persistence mechanisms what is there left to MFC except user interfaces (and OLE)?

As a framework it is lousy. Most of the time you use your document as a controller which only task is to hold a pointer to your top domain level object(s) and propagates notifications down the chain.

Serialization is not general enough and can't easily be extended to support stuff such as CDbArchive or CRegistryArchive...

Sincerely,
Tomaz

[binion]

Ok, this is second hand information, but I consider it to be at least somewhat reliable.

About 6 months ago I went on a job interview in Seattle (Redmond actualy) and one of the people I interviewed with was an ex-Microsoft guy, who kept contact with some of his old co-workers. According to him the team that works on MFC development was disbanded .. quite some time ago I believe he said. And that the reusable application framework for the future will be extended from (or based upon) the ATL.

Take it as you find it. However I would not be suprised to see MFC depricated and eventualy left behind. It is old, awkward, bloated, and simply a poor excuse for an OO-based application framework.