A Visit to Redmond - Part 4

Introduction

 Last week I popped on over to Redmond to have a chat with the guys at Microsoft on the future of Visual C++, MFC, and the new .NET world. Instead of presenting a point list of what we can expect in the future, I wanted to give you guys a taste of what a visit to Redmond is like, and I'm dead keen on having feedback from you on your own personal experiences.

A quick Thanks goes to Dundas Software and Microsoft for making this trip possible.

Part 4 - Visual C++

As I mentioned in part 3, and most important thing I got out of the meeting was that Visual C++ and MFC is alive and well. PDC 2000 was a launch of the new technologies surrounding .NET, and unfortunately the message that was delivered was a little murky on the future of C++/MFC.

There were a number of reasons this happened. PDC 2000 was not the 'header file' conference of past years, where loads of Microsoft guys would walk through the new libraries on offer, the new header files you needed to use these libraries, and the new API's available for whatever version of Windows was flavour of the month. PDC 2000 was more about the explaining, and demonstrating, the future directions of Microsoft's vision rather than trying to show every single change that had been made in the move to .NET.

Another reason C++ and MFC lacked exposure is that it was hopelessly overshadowed by the new kid on the block: C#. Internet applications are the big thing in .NET, and C++ programmers will most likely feel more comfortable writing their ASP+ apps in C# rather than in VB. Then there was the "Is C# Cool" (depends how you look at it), and "Is C# Microsoft's answer to Java" (you decide ) controversies.

But most of all, C++, and MFC in particular, no longer has an evangelist like Mike Blasczak. When you think of MFC who do you think of? George Shepherd, Jeff Prosise and others certainly spring to mind as prominant book authors, and Paul DiLascia writes great code, but who is there to stand up, be opinionated, possibly obnoxious, insightful, and hugely entertaining in their quest to enlighten the peasants about the magic that is MFC?

So, sadly, MFC was a was a bit of a wallflower at the PDC bash, but the guys at Microsoft would very much like to make up for that.

So what's the deal with Visual C++ and MFC in .NET?

Visual C++ is still the development language of choice for many applications. Managed extensions for Visual C++ allow you to create applications that interact with the .NET framework in a way that makes programming simple, quick, and intuitive. Visual Studio is mostly written in C++, as is Microsoft Office (managed wrappers will be provided for .NET). There is simply too much legacy code out there to even think of abandoning or downgrading the language.

 Visual C++ has also been improved in a number of different ways. The debugger in Visual Studio.NET is from Visual C++. There is a new crash recovery feature that allows an application to be restored to its state immediately prior to crashing, allowing post mortems to be carried out. 'Edit and Continue' has been improved, and there is now public access to the debug info file (all the guys at NuMega will be cheering on this one).

C++ conformance has also been improved. My notes are a little smudged on whether the VC++ compiler is the most conformant compiler, or merely the second most conformant (there is a mysterious, unidentifiable, beer-coloured stain on that page of my notes). The Microsoft guys claim that the compiler is so conformant that other compiler manufacturers no longer bother to publish conformance tests.

(brief pause as the din dies down)

No - I never said Visual C++ was 100% conformant, and this seems to be a serious source of aggravation among developers. There were even a number of wry looks among the product managers when discussing VC++'s conformance, but Ronald Laerman, Lead Program Manager for MFC/ATL was very candid on this point. He freely admits that the compiler is not 100% conformant, but what would developers rather have - a new compiler that is 100% conformant and will most likely break legacy code (or fill it with untraceable bugs), or a compiler that is so, so close, but which works seamlessly with all your current and previous code bases. Another point Ronald bought up is that while many developers point to other compilers as being more conformant, what is actually meant by these developers is that the particular compiler they use supports their pet feature. Microsoft would rather keep most of the people happy most of the time than a few of the people happy all of the time. And that "most" is a really big "most". They really are doing their best to make life as easy as possible for us developers.

C++ will always be the language that gives you the most power and flexibility. Microsoft has made a significant investment into the future of the language, and it has been enhanced to work seamlessly in the new .NET environment. While VB and C# may become the GUI application programming language of choice, C++ will the language of choice for writing drivers and components.

I'll talk more about MFC 7, ATL, WTL and STL in a later instalment. The news is all good.

The Microsoft guys felt that they were making Visual C++ more complicated, but for programmers who wish to continue writing non-managed native mode apps in VC++ there is no change. Managed extensions are just that - they are extensions. All your old code will work, and you can continue creating apps the same way until the cows come home (do you have that expression over here?). If you want to dip your toes into .NET then you can. If you want to dive-bomb in and do a big belly-landing then managed extensions allow you to do whatever you want, and the new classes in MFC and ATL will make this even easier.

Next Instalment...

The Compilers.