Fog Creek Software
Discussion Board

MFC Future?

Just a slight digression from this topic:

For someone who have invested 4 to 5 years working with MFC to get to the nuances of the infrastructure, it is disappointing (to say the least) to find out that Microsoft will be obsoleting this.  I am sure there are many many companies who have invested their products on MFC and ActiveX.  What do people working in these areas think and what are your plans for the future?  Move your applications to .NET?  That is a major investment with a ZERO return business case.

Hoang Do
Sunday, March 23, 2003

I see this as one of the issues with using a proprietary platform such as MFC, .Net, WTL etc.

I expect in 5 years time I’ll see similar posts bemoaning the demise of .Net due to its replacement by some new essential technology from MS.

Tony E
Sunday, March 23, 2003

Is the source code to MFC not provided as part of Visual Studio/SDK?

Duncan Smart
Sunday, March 23, 2003

The source IS provided.

Sunday, March 23, 2003

Tony E.,

So true, so true.

There are some MSFT "technologies" (ie, programming API's / techniques) that will have a longer life than 5 years:

1. The Win32 (kernel) API.
2. DirectX (specifically: DDraw, DSound).

Outside of those, well, its pretty amusing...  Party on.

Sunday, March 23, 2003

Where did the story that MFC was being obsoleted come from?  Looking at the MS web site, MFC is alive and well in VS.Net 2003:

"Visual C++ .NET 2003 continues to deliver a range of libraries, including:

A fully ISO-compliant STL implementation (providing generic container classes and algorithms).
ATL and MFC (now updated for Windows XP and Windows Server 2003).
ATL Server (enabling unmanaged dynamic Web content and XML Web services). "

(from )

Is there something I'm missing?

Sunday, March 23, 2003

Well, I think what worries the original poster is that the center-of-gravity of Microsoft platform application programming seems to be moving from Win32/MFC to .Net/CLR.

It's not that MFC's going to stop working, it's more that it's become mature, and probably won't get many new features from now on.

The "ha ha, serves you right for trusting MS rather than going open source" argument doesn't really apply here, since you do get the source for MFC.

It's just how things go -- you could port MFC to C#, and make it work with the CLR, but then it wouldn't really be MFC any more.

I'm not sure why the original poster is worried, though. They can pretty much reuse all their MFC experince with C#/CLR. It's not like they have to start over from the beginning.

Anonymous developer
Sunday, March 23, 2003

I disagree with Nat.

.NET represents a significant platform shift. The goal is to get away from unmanaged code, which includes directly accessing Win32 and DirectX. Those technologies are both exposed from within .NET (as of DirectX 9, which includes a managed wrapper). You can argue that the abstraction isn't good enough yet, but it will be. This IS Microsoft's future.

MFC isn't going to just stop working one day, but I think we're all agreed that MFC had its last major update many years ago with VC++ 4.2. Since then, MFC has been on coast, because it's a matured technology. Unless and until Microsoft one day says "we aren't going to support Win32 any more", MFC is still a viable (if annoying) way to write Windows apps.

Now as to the original poster, I think your personal growth as a software developer means you need to make a choice what to do. Some day soon (let's guess a year or two), all new development jobs on Windows are going to be in .NET, and that MFC knowledge isn't going to count for as much as it does today. So you probably need to start learning .NET if you're going to stay with the Windows platform for the long term future.

Brad (
Sunday, March 23, 2003

Oh, and by my guess, Microsoft has only had a shift like this twice in its history before: moving from real mode DOS programming to 16-bit Windows programming, and again moving from 16-bit to 32-bit Windows programming. Nothing else has really been as significant as the shift to .NET is.

Brad (
Sunday, March 23, 2003

Tony E - you forgot to mention Java. (Still owned by Sun, IIRC)

I guess if you want to truly be "vendor independent" then you're stuck with C++, PHP, HTML, Perl (can Larry call Perl home? [g] )...


Sunday, March 23, 2003

From a career point of view, one should always invest time in learning things that will have a long term value.

For example, when people ask me what to learn, I always say learn SQL. I learned it more than 10 years ago in the dos based FoxPro. I use it for every application I work on today. Be it ms-SQL, ms-access/JET, and now MySql. Lean SQL, and I will take bets that you also will be using it in 10 years from now. I have no doubt this skill will last me more than 20+ years.

So, one should pick and choose good long term technologies that don’t change. That means generally the platform should be based on as many proven standards as possible. I remember writing software in Pascal, and have not done that for more then 10+ years now. However, if I had learned C back then, it would certainly have been a skill that I still use today. So, C was also a major standard (it is obvious that system software was being starting to be written in C, and not Pascal at the time). The choice of language should have been obvious to me, but it was not. Don’t we all love hind sight!).

The other key is to pick technologies that add value to the business community (so, standards + key technologies = good!).

Many tools and platforms and environments we learn generally only have a shelf live of 5 years, or even less.

If you don’t like the idea of learning a new development tool every 2 or 3 years, then you will quickly find out it is time to leave this industry.

Remember, good developers will concentrate on those skills that make them good developers, and that is NOT knowing how to print hello in 20 different computer languages. A good sprinkling of software development books is really recommend here.

Oh, gee, what is the new software flavor of the week? It should not matter.

Don’t start learning Java because it is cool. Lean Java because it is key technology that IBM is using to deliver corporate solutions.

Further, the value of what you learned is ONLY of use if those tools let you create solutions to people who WILL PAY for those solutions.

Smalltalk was revolution in software development, but did not deliver solutions to the BUSINESS community. This is critical, since you want to learn tools that let you DELIVER solutions.

Hence, Microsoft is not stopping me from writing software in FoxPro 2.6. In fact, I have often mentioned how incredible the MS track record is in this regards. Recall how apple in the early 90’s had everyone THROW OUT all software for the next platform. This was done again recently at apple.

With MS, you should be able to use the MFC library for years to come anyway.

Hey, how about learning a new word processor every year?

Remember ZyWrite, then SuperScript, and then Wordstar, and then WordPerfect and then ami-pro, and then ms-word? Way back then, people learned a new word processor every year.

In addition, people also were learning new systems all the time. Turbo-Pascal, then VB, then Delphi.  Heck, the same goes for database software. Lets see, Advanced Revelation, then dbaseII, then Reflex, then FoxPro, then ms-access. This is the short list!

Software cycles for development tools are actually increasing in time, not decreasing.

I cringe to think of just the word automation code that I would have to throw out today if clients throw out ms-word.

The only real problem I can say here is that developers can only absorb so much, and the HUMAN COST of learning a new system is rising DRAMATICALLY to day.

The result of this increased hum cost now means that picking the right tools and platforms is VERY IMPORTANT. Before, it was easy, you just picked whatever you wanted, or seem to need at the time.

Now, we have to use our brains, and pick real solid tools.

So, while you might have to do some new platform learning..that should be viewed a welcome new challenge.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, March 23, 2003

MFC isn't going to be supported?  At what point in time?

complex matter
Sunday, March 23, 2003

Albert - I wish most programmers shared your mature view of technology. Kudos to your thumbnail overview of the tradeoffs of embracing new technology.

I haven't yet heard anyone debate the "human cost" of pushing all-new platforms and tools. It's simply enormous, and the learning curve just gets injected into the scene along with the rest of the activities needed to grind out software. But most programmers are distracted by the shiny baubles of every new tool/toy.

Bored Bystander
Monday, March 24, 2003

I can't honestly remember a job where I wasn't learning something new when I came on. I just think it's an accepted part of this job that you won't know everything you need to know when you get there.

A well grounded view of the essentials, as Albert suggests, is absolutely priceless.

Brad (
Monday, March 24, 2003

As someone who moved from mainframe systems programming (assembler) to PCs quite late on I managed to avoid having to write any C++ using MFC and whilst I did learn C++ I had a look at MFC and decided it was just too much of an investment to learn enough to do even the most rudimentary things.

As an experienced programmer of some 16 years when I first looked at C++/MFC I found it very hard going and almost impossible to figure out.. MFC seems to require a ton of calls all interspersed throughout the code. Visual C++ would then annotate it with loads of unintelligible (to the untrained eye) comments. Or at least that's how I remember it!

With .NET you can achieve the simple activities with the minimum of fuss but you still have GDI if you want to get stuck into the heart of the presentation layer. Seems perfect to me.

MFC dead? Brilliant. Did it ever need to be that complicated? Clearly not. .NET abstracts away the complication. MFC was just one of those stepping stones which cause a lot of effort and sweating on the way to somewhere decent.

Monday, March 24, 2003

.NET is a new concept and I really agree that we have to go for it; there is no doubt that it saves development time. The point here is, how about the small companies that have all their code developed in MFC and do not have money to throw everything away? It is very important that Microsoft provides a way to migrade code as easy as possible. A .NET MFC would not be a bad idea (hehehe).

Jose L. Teodoro
Saturday, March 13, 2004

I'd say MFC will still be kicking a** until and unless not every operating system has the .NET runtime already running on it. If I wrote a nifty shareware client application on .NET now. Any if web users would like to try out my application then would probably get a message saying "Requires .NET framewirk so install this 20 meg footprint" and then the users is gonna say "oh!! forget it".
                  But couple of years down the line when windows 95 and 98 become Win 3.11 then yes Win32 would be only used for writing low level device drivers which is mostly now a days done by device manufacturers themselves.


Wednesday, June 9, 2004

Well I'm a little bummed out about the whole thing.

MFC doesn't even support ADO very well. .. and what about ADO.NET ??? nothing from what I've been reading.

I just started doing my home work on the subject and have been a user of MFC and Clarion for WINDOWS: Topspeed.

Call me ignorant (or a  guy just starting to do his homework), but I was hopping to hear that ther might be something like 'MFC .net'.???  It seems to me that all MICROSOFT would have to do is add some support for ADO.NET and we would all be business. Why trash the MFC framework??

Some I get the feeling that MFC .NET will eventually happen? ... from my limited reading it seems to be MFC only hope as a longterm FRAMEWORK?

MFC is nothing more than a wrapper for the WIN API, true but I was hoping for something where a person knowledable in MFC/ODBC/MULTI-VIEWS/PRINTING could generate an app in 1 month if having to go to C# .NET

Does anybody know if jumping on to VC++ .NET or C# .net with the above background will be enough to genearte and deploy a DATABASE app. in One month.

I'm thinking of learning VBASIC .NET, but affter getting a couple of books on the subject I think it would take me 4-6 months to put a proffesional invoicing product together.

Anyhow , how much of MFC transfers over to the .NET FRAMEWORK?

And what do you guys think of something along the lines of MFC .NET

Wednesday, June 16, 2004

While I do not have a lot of MFC experience, I write all my software using WTL, which I understand is very similar - especially at the level of sophistication and technical prowess required to get things done.

As I see it, you do not need to worry about MFC or WTL being gone anytime too soon, purely because of the fact that current client computers do not have .NET framework installed. In fact, WTL is developing rapidly as open-source code and has some excellent websites dedicated to it. So until the time comes that some killer .NET app gets everyone to download the framework, things appear to me to stay as they are. And since I have not seen any compelling .NET software, and nor do I need to upgrade any of my existing words processors, spreadsheets etc., I don't even see myself as having too much need to get .NET onto my computer at this point in time.

My recommendation... stick with what you know, but just keep an out out for 'the next thing'.

Simon Hayden
Get software updates to your clients the Quick and Easy way!

Monday, August 23, 2004

*  Recent Topics

*  Fog Creek Home