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

Answers to your MFC/ATL questions from the Visual C++ .NET Product Manager (轉)[@more@]

以下文章選自的訪談系列，被訪者是VC++專案經理。

主題是關於MFC/ATL與的相互關係。討論比較有條例，至少部分解答了我自己的某些疑惑，相信此文對很多VC員能提供不少有益的資訊。

因為時間關係，沒有翻譯，原文在此，大家先睹為快吧:)

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 Fran 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 world? Are MFC and ATL's days numbered?

 (MFC,ATL在.NET世界中的前景如何？他們真的時日無多了嗎？）

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. consrs 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 succesul. 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 at a pace you set.

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

（這些類庫在哪些地方適用於.NET框架？）

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 seamley 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 ship 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和ATL的新版本DLL叫什麼？）

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 , will there be any reason at all to write C++ or MFC apps?

（一旦.NET成為PC環境的主流，還有必要寫C++或MFC應用程式嗎？）

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?

（對開發者而言，何時用MFC，何時用Windows Form?）

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 6.0 in place of MFC. Each offer distinct advantages - the developer or architect must detene 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 and Windows Forms?

 （是否MS還在繼續使用MFC寫程式，亦或轉而使用C#和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?

（WTL的未來如何？它會成為一個商業框架嗎？）

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 ives 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 and XP.

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

（你能該我們一個VC新特性的概要介紹嗎？）

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 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, and CE 2002? Will MFC try to emulate some of the new components in .NET?

（我能指望MFC和ATL/WTL會針對W2K,XP和CE的新特性而進行新的擴充套件嗎？是否MFC會依照.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?

（有什麼工具可以幫助開發人員從MFC/ATL轉到.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 feeack about the importance of such a tool.

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

（在.NET上我還能使用MFC和舊的MFC元件嗎？）

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 and . Simply add a key 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 Services?

（是否MFC和ATL將被擴充套件以支援XML服務）

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 .NET?

（原來的嚮導機制有時候挺叫人頭疼，比如對派生類的處理。MS打算如何解決？）

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 VSprogram 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++

（是否MFC要被轉換成受管制程式碼使其用於受管制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?

（針對.NET是否會實現一個類似於MFC的應用框架？）

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?

（如果我不打算寫受管制程式碼，還有什麼不可抗拒的理由讓我升級到VS.NET上嗎？）

Every ect of the product has updates - the IDE, the deger, 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 lisense, 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?

（我能用VC++.NET開發傳統的MFC應用嗎？）

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 features.