Kristian Kristensen’s Blog

Reading Karel Donk’s post about The Future of MFC, got me thinking. In this post Karel tells what Somasegar – a Visual Studio 2005 lead – answered to his question about the The Future of MFC:

MFC continues to be the most popular C++ library in use to day (by far). It is unique in its feature breadth as well. There remains many features in MFC that arent found in other frameworks (including .NET). With Visual Studio 2005, we have made it possible for the C++ developer to leverage existing C++ code, the strengths of MFC, and the strengths of .NET all within a single application.

Going forward, we expect to continue to enhance the integration between .NET and MFC. As Longhorn releases to the market, it is our intention to continue to support Longhorns advancements in MFC. Developers can look forward to seeing MFC updated to leverage the latest native and managed APIs and frameworks.

As an MFC developer, you have more access to more frameworks than any other type of developer on the platform. You can leverage the best from all worlds as it makes sense to do so from a business perspective. We fully expect to support this capability into the foreseeable future.

This is interesting because it’s the first time I’ve heard anything about Microsoft’s strategy with MFC. Couple this with Mary Jo Foley’s article The “Dirty Little Secret” About Longhorn, in which she talks about the “lack” of .NET in Longhorn (my emphasis):

Longhorn won’t be based on the .Net Framework.

We’re still expecting that the .Net Framework will ship with Longhorn on the CD and/or “in the box” in some way. But the .Net Framework won’t be at Longhorn’s core, we hear.

It appears as though Microsoft has slowed down a bit, and maybe the Raymond Chen camp is fighting back, taking territory on the MSDN guys (if one is to quote Joel Spolsky‘s article: How Microsoft Lost the API War)

In conclusion: It may not be such a bad idea to bet your skills on MFC and C++. I suppose a lot of future applications for Windows will be written using this combination. And probably using the model that Office is using, in which one hosts the .NET runtime (CLR) for user extendable features (macros, custom code, etc.), but the base application is built using MFC and C++.

If you like my writing you should subscribe to my RSS feed.