Click here to Skip to main content
15,860,972 members
Articles / Desktop Programming / ATL
Article

Answers to your MFC/ATL questions from the Visual C++ .NET Product Manager.

Rate me:
Please Sign up or sign in to vote.
4.94/5 (9 votes)
13 Feb 2002CPOL10 min read 346.4K   29   77
The definitive set of 'What's the deal with MFC' answers from Microsoft's Nick Hodapp.

Introduction

Nick Hodapp is the Visual C++ Product Manager. He's also damn nice guy whom I unfairly and continually give a hard time. I caught up with Nick at VSLive! 2002 in San Francisco and passed on a bunch of questions that I see continually being asked by MFC and ATL developers so that we could get the set of definitive 'What's the deal with MFC' answers.


1. What are the future plans for MFC, ATL in the .NET world? Are MFC and ATL's days numbered?

This is a very popular question. I’m sure you’re aware that there are literally millions of Visual C++ developers who use, extend, and incorporate both MFC and ATL into their applications. In fact, as many as 75% of all Visual C++ developers use MFC. Microsoft considers these libraries to be extremely robust and mature - they’ve been around for a long time, have been used as the infrastructure for hundreds of thousands of applications, and have grown over the years with countless updates and extensions. They have been very successful. Our focus is starting to shift to .NET, but MFC and ATL will each be continually updated in order to maintain sync with operating system features, and will be maintained into the foreseeable future. Backwards compatibility is always an issue with libraries like these, and as computing environments and requirements change it becomes more and more difficult to extend an older technology and still retain robustness. The time has come for us to introduce a newer technology with a renewed lifespan, and the C++ team is committed to making the transition as easy and comfortable as possible for MFC developers. With Visual C++ .NET you can continue to use MFC and ATL where it makes sense, and begin the transition to the .NET Framework at a pace you set.

2. Where do these libraries fit into the .NET vision?

Today MFC and ATL fill roles that aren’t yet fully realized in .NET. .NET, with all of its thousands of classes in the framework library, doesn’t provide application framework functionality similar to that provided by MFC. Developers need to be aware of their options - both managed and unmanaged, and choose carefully the technology most suited for the task. Visual C++ developers are typically very advanced, and have for years been accustomed to choosing appropriate technologies for their applications -- so this should be nothing new. With .NET, VC++ developers have the distinct advantage of being able to seamlessly integrate existing unmanaged code with newer managed code and data without the headaches of losing backwards compatibility or learning a new language. Managed extensions for C++ make sense for progressing applications forward, and they’re easy to use.

3. How long will these libraries be supported?

We have no plans to stop supporting any library shipping with Visual C++. All of the VC++ libraries have extremely high usage in real-world code, and Microsoft isn’t about to ignore this fact. We’ll continue to refine existing libraries, and have plans to introduce new libraries as technology evolves.

4. What are the new version numbers and DLL names for MFC and ATL?

MFC version 7.0 - MFC70.DLL
ATL version 7.0 - ATL70.DLL

Note the changes from the DLL names in 6.0 - we broke binary compatibility in order to make some key refinements to the libraries themselves. But your code will recompile against the new versions just fine.

5. Once .NET becomes established on every PC running Windows, will there be any reason at all to write C++ or MFC apps?

Assuming feature parity between .NET and MFC, a developer might choose MFC if there were a compelling need to write purely unmanaged code. Developers may choose to use C++ to target .NET because of the powerful C++ language features not found elsewhere, like templates, and the quality of code generated by the compiler. Visual C++ .NET is the only .NET compiler that generates highly optimized MSIL, and it is the only compiler that can generate an assembly image containing both managed and unmanaged code. Developers should choose C++ when they need unbounded flexibility and control.

6. Why would a developer wish to use MFC instead of Windows Forms, and why Windows Forms instead of MFC?

Windows Forms are a technology that do not yet provide the command-routing and document-view infrastructure found in MFC. Today, choosing Windows Forms is similar to choosing Visual Basic 6.0 in place of MFC. Each offer distinct advantages - the developer or architect must determine what priorities are relevant. The really sweet thing about C++ is that you can choose MFC and at the same time incorporate .NET technology where it makes sense. One reason we did this was so it would be dead-simple to extend existing applications without requiring them to be rewritten. A second reason is to enable the C++ developer to self-pace their adoption of .NET technology. We knew the C++ developer wouldn’t be interested in a technology that forced abandonment of their existing skills or code.

7. Will MS be writing any of their apps in MFC or will they start moving to C# and Windows Forms?

A majority of Microsoft applications are already incorporating .NET technology, using not only C#, but also C++ and Visual Basic .NET. There may well be less MFC development done at Microsoft going forward, but because MFC is integral to so many existing applications - our own and 3rd party -- it will continue to be a viable and supported framework for some time to come.

8. What is the future of WTL? Will it be made an official framework?

We don’t have specific plans for WTL. However, we are rather stunned by its growing popularity and are keeping a close watch. It is not a topic we’re ignoring internally.

9. MFC and ATL had some changes under the hood, but no major facelift and only a handful of new classes. What were the reasons for this?

As I’ve said, these are mature libraries that accomplish their objectives well. Our intention is to enhance them to keep pace with operating system features, to refine them where it makes sense, and maintain backwards compatibility. The updates we made for Visual C++ .NET reflect this positioning, and comprise a slew of refinements that make these libraries easier and safer to use, while adding support for Windows 2000 and XP.

10. Can you give us a brief rundown of the new features in Visual C++?

The list is actually quite long - a full enumeration of new features exists in the product documentation under “What’s New in Visual C++ .NET”. I have several favorites that I’ve been using in my own code. For the first time, it is now easy to use both MFC and ATL in a single application - the compiler will no longer complain about conflicting header definitions. Both libraries now share CString, and have in common several of the other non CObject derived classes. This feature alone factors out a lot of potential for duplicated effort in code, and can lead to a much more elegant implementation. It’s about time we did this, and it just makes sense. The STL library has been entirely overhauled - with more readable source code, a faster and standards-compliant implementation, fixes to all known major issues like threading and cross-DLL usage, and, at long last, all new documentation. And of course, the compiler itself has loads of new options and features, including whole-program optimization, code security features including support for runtime buffer-overrun checking, and managed-code generation.

11. Can we expect MFC and ATL/WTL to be extended in the near future to cover new features and controls in W2K, XP and CE 2002? Will MFC try to emulate some of the new components in .NET?

Yes, MFC and ATL will continue to enable developers to target the newest features of Windows. If you want to include new .NET features in your MFC application you can do this directly - there’s no need for MFC emulation of the feature.

12. Are there any tools to help developers move from MFC/ATL to .NET?

Beyond the /CLR switch of the C++ compiler, no. Should there be? What would you like them to do? How should they work? We’re very interested in this and are keen to have feedback about the importance of such a tool.

13. Can I still use MFC and my old MFC components in .NET?

Yes. It is easy to wrap or extend existing C++ components so they are callable from .NET - by any language. This is much simpler than it used to be with COM and ActiveX. Simply add a keyword to mark an object as a .NET reference-type, and compile with /CLR. No IDL, no reference counting, no registration code. Code it and use it - very simple.

14. Will MFC and ATL be extended to cover XML Web Services?

MFC and ATL already have the capability to consume and expose XML Web Services in Visual C++ .NET, both with managed and unmanaged code.

15. The various wizards had some annoyances, such as not handling derived classes very well, or being too restrictive. How have Microsoft addressed this in Visual Studio .NET?

One way we’ve addressed this in Visual Studio .NET is by exposing, for the first time, an extremely extensive automation interface enabling developers and third-parties to create their own add-in applications. If a wizard or feature doesn’t do what you want it to, you can write your own. With VS.NET automation, you can plug into the IDE at the same level of integration as any of Microsoft’s features. If you’re a member of the VSIP program you can even integrate new languages and compilers with the IDE.

16. Will MFC be ported to managed code to allow it to be used in Managed C++

We won’t likely port MFC to be a fully managed library. But it is entirely feasible to extend your own MFC applications with managed code - without leaving C++.

17. Will there be a MFC-like framework for .NET?

The .NET framework will continue to evolve and will likely add capabilities that are found in MFC. The C++ team is driving for this internally - we want .NET to be a compelling and comfortable place for C++ developers. We’ll achieve this is in a couple of ways. First, we’ll continue to make it easy to use the .NET Framework in C++ code. Secondly, we’ll ensure that there are compelling reasons to continue using C++ - by enabling C++ to achieve a level of flexibility and control on .NET not found in other languages.

18. What compelling reasons are there to upgrade to Visual Studio .NET if I have no intention of writing managed code?

Every aspect of the product has updates - the IDE, the debugger, the compiler, the libraries. As I mentioned before, the compiler alone offers the several new optimization and code-security features that increase the robustness of your applications. Across the board we’ve overhauled features like Intellisense, debugging scenarios, even the warning and error messages you get building code.

Bottom line: building existing code with Visual Studio .NET will result in faster, more robust software with lots of new potential to expand the capabilities of your application with emerging technology.

19. Can I use Visual C++ .NET to develop traditional MFC apps?

Of course! No one is forcing VC++ developers to swallow .NET whole - in fact, managed-extensions aside, the majority of features we’ve added this iteration are geared at unmanaged code development. MFC development is better than ever with refined IDE integration, compile-time type-checking for message maps, ATL support, and new classes to access new OS features.

20. What’s your favorite Website?

CodeProject.com. You guys rock.

License

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


Written By
Founder CodeProject
Canada Canada
Chris Maunder is the co-founder of CodeProject and ContentLab.com, and has been a prominent figure in the software development community for nearly 30 years. Hailing from Australia, Chris has a background in Mathematics, Astrophysics, Environmental Engineering and Defence Research. His programming endeavours span everything from FORTRAN on Super Computers, C++/MFC on Windows, through to to high-load .NET web applications and Python AI applications on everything from macOS to a Raspberry Pi. Chris is a full-stack developer who is as comfortable with SQL as he is with CSS.

In the late 1990s, he and his business partner David Cunningham recognized the need for a platform that would facilitate knowledge-sharing among developers, leading to the establishment of CodeProject.com in 1999. Chris's expertise in programming and his passion for fostering a collaborative environment have played a pivotal role in the success of CodeProject.com. Over the years, the website has grown into a vibrant community where programmers worldwide can connect, exchange ideas, and find solutions to coding challenges. Chris is a prolific contributor to the developer community through his articles and tutorials, and his latest passion project, CodeProject.AI.

In addition to his work with CodeProject.com, Chris co-founded ContentLab and DeveloperMedia, two projects focussed on helping companies make their Software Projects a success. Chris's roles included Product Development, Content Creation, Client Satisfaction and Systems Automation.

Comments and Discussions

 
GeneralMy vote of 5 Pin
Pranit Kothari13-Mar-12 2:55
Pranit Kothari13-Mar-12 2:55 
QuestionCreating VC# ActiveX Control for other Visual Studio languages (or for VC++) Pin
Andy Rama18-Sep-08 0:41
Andy Rama18-Sep-08 0:41 
GeneralMigration from C# to VC++ 6.0 Pin
Antonymaharaj13-Oct-06 1:16
Antonymaharaj13-Oct-06 1:16 
GeneralMigrating VC++ 6.0 to VC++.NET Pin
diegoaso5-Mar-04 5:22
diegoaso5-Mar-04 5:22 
GeneralRe: Migrating VC++ 6.0 to VC++.NET Pin
Rajesh Pawa30-Aug-04 11:59
Rajesh Pawa30-Aug-04 11:59 
Generalalways on top Pin
Member 86656914-Dec-03 7:45
Member 86656914-Dec-03 7:45 
General.NET Pin
Anonymous1-Dec-02 8:01
Anonymous1-Dec-02 8:01 
GeneralRe: .NET Pin
Anthony_Yio22-Jan-03 17:15
Anthony_Yio22-Jan-03 17:15 
GeneralEvent Handling Pin
AGUVEN24-Nov-02 22:40
AGUVEN24-Nov-02 22:40 
GeneralRe: Event Handling Pin
canamguy11-Nov-04 8:07
canamguy11-Nov-04 8:07 
GeneralEvent Handling Pin
Anonymous24-Nov-02 22:34
Anonymous24-Nov-02 22:34 
GeneralMigrating VC++ 6.0 MFC project to VC++.NET Pin
Anonymous26-Sep-02 3:29
Anonymous26-Sep-02 3:29 
GeneralRe: Migrating VC++ 6.0 MFC project to VC++.NET Pin
Anonymous27-Sep-02 5:44
Anonymous27-Sep-02 5:44 
GeneralMore Confused Pin
8-Mar-02 1:08
suss8-Mar-02 1:08 
GeneralRe: More Confused Pin
8-Mar-02 3:13
suss8-Mar-02 3:13 
GeneralRe: More Confused Pin
Anthony_Yio22-Jan-03 17:18
Anthony_Yio22-Jan-03 17:18 
GeneralMFC and managed code Pin
mloibl3-Mar-02 10:57
mloibl3-Mar-02 10:57 
Generali frist see in china! Pin
error.cao1-Mar-02 22:13
error.cao1-Mar-02 22:13 
GeneralRe: i frist see in china! Pin
Nish Nishant1-Mar-02 23:04
sitebuilderNish Nishant1-Mar-02 23:04 
GeneralRe: i frist see in china! Pin
Amit Dey24-Nov-02 23:01
Amit Dey24-Nov-02 23:01 
GeneralMigrating VC++ 6.0 Application to VC++.NET Pin
Narayana Rao Surapaneni22-Feb-02 17:25
Narayana Rao Surapaneni22-Feb-02 17:25 
GeneralRe: Migrating VC++ 6.0 Application to VC++.NET Pin
8-Mar-02 2:17
suss8-Mar-02 2:17 
GeneralRe: Migrating VC++ 6.0 Application to VC++.NET Pin
tinasofty23-Jan-07 14:22
tinasofty23-Jan-07 14:22 
GeneralReverse engineered .NET code Pin
21-Feb-02 9:13
suss21-Feb-02 9:13 
GeneralRe: Solution for the Reverse engineered .NET code ? Pin
Gopalakrishna Palem22-Nov-05 14:14
Gopalakrishna Palem22-Nov-05 14:14 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.