C++ Libraries


I recently got a chance to meet with a number of developers and some MVPs in my trip to the Far East.  One of the questions that people asked me was related to Visual C++ and support for libraries in the .NET world.  One of the key goals of Visual C++ 2005 has been a commitment to enable you to protect your existing assets as you move forward.  We wanted to make sure that you can easily access existing and new Windows technologies from your C++ code.  Visual C++ code built using MFC, ATL, etc. will seamlessly take advantage of new windows applications.


 


Libraries


Visual C++ 6.0 – CRT, SCL, MFC, ATL


Visual C++ 2002 and 2003 – CRT, SCL, MFC, ATL, ATL Server


Visual C++ 2005 — CRT, SCL, MFC, ATL, ATL Server, Support Library, OpenMP


 


Technologies


Visual C++ 6.0 – Win32, COM, OLE,


Visual C++ 2002 and 2003 – Win32, COM, OLE, .Net, Web Services, WinForms


Visual C++ 2005 — Win32, COM, OLE, .Net, Web Services, WinForms


 


Namaste!


Comments (7)

  1. Rup says:

    What’s SCL? No obvious hits for it in MSDN.

  2. Stephane Rodriguez says:

    Soma, I disagree with all you said above :

    – MFC is still alive, but it’s not the same MFC. An MFC 6.0 codebase does not run with MFC 7.x because the binaries are different and the API different (notably the use of STL in MFC). Perhaps this does not make a mountain of difference for a 20,000 line product. But think of a multi-million line product.

    – newer MFC has had regressions. And because there was no VC++ 7.x service pack, nobody was given an "automatic" way to benefit from the QFE (I am pretty sure this was fixed long ago already) The infamous MFC DDE regression bug in 7.x is one, but there are some more.

    – last but not least, the C++ compiler has new __default__ compiler options, and some existing options have been dropped. There is a paper that deals with this exactly, but clearly those who can’t afford those have to stick with version 6.0

    – also, another thing you fail to mention is that since beginning of this year the Platform SDK is not compatible anymore with VC++6.0. Which means anybody relying on the Platform SDK is forced to upgrade.

    So give good, valid, transparent reasons to upgrade. And given the above, this is pretty a big deal.

  3. Earlier this week, DevDiv VP S.Somasegar answered a question about the Visual C++ libraries in his blog….

  4. John Bandela says:

    I think SCL stands for Standard C Library

  5. Martyn Lovell (martynl@microsoft.com) says:

    I wanted to follow up to Stephane’s comments. I’m the development lead of the Visual C++ Libraries team.

    As a general point, let me say that we have put a lot of effort in making it easy to move from VC6->VC7->VC8. Though these products include lots of new features, we’ve worked hard to add them in ways that have low impact on existing code. I’ve been involved in efforts to port very large source bases between these different versions, and while I’ve seen specific pain points, they have not been severe. We definitely want to understand the pain you are feeling on upgrade and help you through it and learn from it.

    Let me respond to your specific points:

    – MFC is still alive, but it’s not the same MFC. An …

    Though MFC did make some significant architectural changes between VC6 and VC7, most of the APIs remain the same, and most codebases require only small changes to move from VC6 to VC7. We have experience of porting very large internal codebases from VC6 to VC7.

    The move from VC7 to VC8 is even easier for MFC.

    ATL includes larger changes between VC6 and VC7, but still most codebases move without too much work.

    MFC does not use STL, in either VC6, 7 or 8. What makes you think that STL is in use in MFC?

    If you let us know what problems you are seeing, perhaps we can work with you to help you understand and move through them. There’s also some good MFC migration information on MSDN, but feel free to contact me directly.

    – newer MFC has had regressions. And because there was no VC++ 7.x service pack, nobody was given an "automatic" way to benefit from the QFE

    We are definitely disappointed we haven’t managed to do a service pack for VC7.1 yet. It’s been hectic around here working on Whidbey. However, we have tried to be very responsive to QFE requests. You The should be able to request a QFE at no cost for a real bug you are blocked by.

    – last but not least, the C++ compiler has new __default__ compiler options, and some existing options have been dropped….

    I don’t know which options you are referring to. Though there have been option changes, I’ve not heard about any that had a large impact on MFC apps. Feel free to follow up if you have more information – even the changed defaults should not have a significant impact on porting your application to VC7.

    – also, another thing you fail to mention is that since beginning of this year the Platform SDK is not compatible anymore with VC++6.0….

    The Platform SDK remains compatible with VC6, 7 and 8. However, because VC6 is out of mainstream support now (and about to be out of support completely in just over a month), the PSDK team didn’t spend effort testing compatibility with such an old toolset. But in practice, you should not find the platform SDK a reason to force an upgrade to a newer VC.

    > So give good, valid, transparent reasons to upgrade….

    I can think of lots of great reasons to upgrade from VC6 to VC8 (IDE improvements, compiler improvements, .NET Runtime). However, since we’re talking about libraries here, let me focus on that and give you my top ten libraries reasons to upgrade from VC6 to VC8

    – security

    Huge security improvements in existing code, plus many new more secure functions, plus annotations to allow static analysis to find security bugs in your code.

    – Debugging

    Great debugging functionality in STL. Much improved validation in ATL and the CRT.

    – Quality

    Large number of bugs fixed, many reported by customers. Focus on making many core scenarios work as expected.

    – Standards Conformance

    Major improvements to many standards conformance issues such as STL and the CRT.

    – ATL/MFC unification

    ATL and MFC easy to use together, and sharing common code for simple types.

    – .NET platform integration

    Easy ability to mix managed and native code as needed, and to work with Microsoft’s new managed platform.

    – Winforms

    Specific MFC support for working with WinForms in an MFC-based application.

    – 64 bit support

    Complete support for the two 64 bit platforms that have appeared since VC6. Plus, of course, support for time values greater than 2038.

    – Major ATL mprovements

    ATL added lots of functionality (including COM, and app-server) in V7.

    – deployment

    Much improved and safer deployment story using manifests.

    Let me finish by saying that if you are having trouble moving to a newer version of VC, you should definitely feel free to get in touch with me and I’ll try to help you understand the issues you are facing.

    Martyn Lovell

    Development Lead

    Visual C++ Libraries

  6. diegov says:

    Please, include MFC and ATL with Visual C++ Express. The URL point to a post in which I explain my point of view.