Share via

VC++ product strategy: the next level of detail

  • Article

Thanks to everyone who provided feedback on my last post on VC++ product strategy.  While I totally appreciate and value the feedback, I have to admit that a few responses did leave me with more questions than answers.  I'd like to therefore first call some of these things out and then I'll share some of my other thoughts on your comments in the hope of getting your input on this next level of detail.

It's about strategy, not features
While the feedback I am seeking is about VC++ long term strategy,  many of you provided feedback about your preferences for devoting resources to this feature or that feature.  While throwing a big feature or two into your list is okay, I'm really more interested in your thinking on where Visual C++ should go as a product.  When done right, features should be a manifestation of the overall product's strategy -- features are implemented in order to accomplish some larger goal or enable some specific scenario.

While I would be inclined to try to reserve maybe 15% of the product unit's resources for "random" features and customer requests, 85% of the PU's effort should go into that feature work intended to fulfill a larger end goal.  It's that 85% I really want your feedback on.

The standards dilemma
Several of you called out improved standards compliance as an area of key strategic investment.  I'm all for this, as standards compliance is the enabler of multiplatform C/C++, and many VC++ customer use C++ in order to write platform or vendor agnostic code.  However, since blogs are about being frank and honest, I'll just come right out and say that I don't agree with the level of investment in standards that several of you recommended.  For example, one reader thought we should be investing 90% of our resources in improving standards compliance, and other recommendations on the higher side included 75%, 40%, and 30%.

Again, here the focus is on standards conformance as a feature, which I don't think is the most profitable way to view conformance.  Conformance should be a means to accomplish some end.  What is it that you're trying to accomplish that our currently level of conformance will not enable you to accomplish?

Given that Visual C++ 2005's level of standards conformance is among the best -- in the upper 90's percentage-wise -- it's difficult for me to see how a continuous and massive investment in this area could be justified.  This is particularly true when I look at some of the many potential investment areas where we can make a real and dramatic impact on the day-to-day productivity and happiness of VC++ developers.  I'm speaking about areas like build throughput, IDE code intelligence (e.g., Intellisense, refactoring, etc.), integration with MS online services (Connect, Windows Error Reporting, etc.), concurrency, native/managed interop, and the like.

C++/CLI designers
At least one of you asked for XAML support in C++/CLI.  This one is interesting to me, and I'd like to hear your feedback on it.  One school of thought is "language parity," that we must try to support everything in C++ that we support in the managed-specific languages.  Another school of thought is that we should let each language evolve in potentially separate directions if that enables developers to fully exploit the capabilities of each language.  Honestly, I'm finding myself increasingly in the latter camp.  For example (and this is totally off the top of my head), what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing? I can see arguments both ways, but I like the idea of not expending my team's effort on "keeping up" with C# in areas where interop should suffice and instead using my resources to innovate in other areas where C++ adds more unique value.  What do you think?

Surprise: Mobile
There were a couple of things in your comments that were surprising to me, such as the desire for better mobile devices support, particularly for C++/CLI.  Slight organizational digression: the VC++ team doesn't own the mobile agenda -- that's owned by the Visual Studio for Devices team.  However, we work closely with that team, as we provide a number of core technology pieces upon which they build devices support into VS.  Serious question: why is it important to many of you to support C++/CLI for .NET Compact Framework? It is because you prefer the C++ language to C# or are there more specific technical reasons why you seek C++ /CLI support for .NET CF?

No surprise: better optimizations
Many of you called out speed and efficiency as important areas of investment.  We agree.  In fact, we agree to such a degree that we have spun our code generation team off into a completely separate product unit.  This product unit is building a new, optimization and transformation-friendly, compiler back-end based on MSR's Phoenix framework.  While you won't see the fruits of this investment in Orcas, it is definitely an area of substantial investment that will begin bearing fruit for VC++ developers in the post-Orcas timeframe.

Also no surprise: improve the native experience
Both the native and managed platforms are important to Microsoft.  We continue to innovate in both areas, with Windows Vista providing both a host of new native APIs as well as the impressive managed code innovations in .Net 3.0.  Visual C++, being the one Microsoft programming language that enables developers to target the native platform, is obviously a key piece of the overall native code strategy for the company.  So, it's not surprising that many of you would ask for improvements to the native code developer experience.  This message has been heard, loud and clear.  We do intend to invest heavily in the native code experience going forward.  I'll discuss this topic in greater detail as the specifics of our strategy solidify in the coming weeks and months.

Your questions
Finally, I'd like to answer some of the specific questions some of you asked of me in the comments...

Would Connect not be a better forum to generate feedback?

I'll answer that one with a polite-but-firm, "no." :) Connect is about providing a platform for Microsoft and customers exchange information about specific bug reports and feature requests.  Connect is not the best place to have a conversation about the various elements of product strategy.  Remember, I'd like to raise the level of this conversation above the specifics of this bug or that feature, and Blogs are better venues for conversations in general.

Is the VC++ team in charge of the MFC or is it the Platform SDK team?

Yep, we do.  The VC++ team owns the native C/C++ libraries, including MFC, ATL, SCL, and CRT.  The SDK team owns the headers and libraries for the Windows platform.

Will Vista still be the target OS for the post-Orcas release, or will it be Vienna?

It's still too early to say.  Right now we know that Orcas will target Vista, but it's too early in both the Vienna and Orcas+1 cycles to know whether Orcas+1 should sync up to Vista or Vienna.

Is Win32/Win64 here to stay?

Indeed they are.  And VC++ will be the tool used to target the native platform.

Will native and managed development co-exist or is native evil and responsible for all security problems of Windows?

Well, two things *can* be equally true.  :)  Yes, I believe that native and managed development will co-exist for the foreseeable future.  And, yes, it is easier to shoot yourself in the foot from a security standpoint with native code.

Look, native doesn't have to be evil for managed to be valuable.  And, likewise, managed doesn't have to be evil for native to be valuable.  They're both important and strategic platforms for Microsoft.  There are great APIs and libraries in both the native and managed world.  I believe an ongoing challenge for the VC++ team is to make managed/native interoperability so efficient and seamless that developers feel free to choose a library or API based on its suitability for their needs, not based on whether it's a native or managed library or API.

We've also done a lot of work in both the libraries and the compiler space in making the native world more secure, with the understanding that developers focused on native code also need better security technology.

Thanks again for all of your comments and a look forward to a productive round 2.  :)

Comments

  • Anonymous
    October 03, 2006
    I can understand your desire to extend support for C++/CLI to XAML etc. However, is this really benefiting your customers? All of the managed code that I write is done in C#. All of the unmanaged code is done in C++. The same is generally true with my colleagues. I am asked to either maintain an unmanaged project, or to rewrite it in C#. They do not want a mixture of unmanaged and managed. C++ exists in my world for native code only. "what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing?" It is neither good or bad. However, I seriously doubt that I would ever have a chance to use it as I do all managed development in C#, not C++. Fully implement the 1998 standard. It's now 2006. When is export coming? It may not be popular with many, but that is beside the point: it is part of the standard and I expect to be able to use it. The 1998 standard should be fully implemented before starting on TR1. At the IDE level, I would love for Intellisense to just work. It dies far too often and too fast. I get tired of exiting VS, deleting the Intellisense DB, and restarting. So I often work without it. This makes the IDE little more than a glorified text editor. I'm not too excited about refactoring yet. The little bit that it can do, I can basically do manually almost as fast. I would like to see automatic externalization of strings to aid in globalization. "integration with MS online services (Connect, Windows Error Reporting, etc.): no thanks. "concurrency": If there is a new standard concurrency library, fine. But no thanks on proprietary stuff. "native/managed interop": I will not use it. C++/CLI Mobile support: no thanks; C# suits my needs just fine. Optimizations: absolutely. Performance-critical code is one of the main reasons that I use (native) C++.

  • Anonymous
    October 04, 2006
    I like the concept of integration with MS online services.  Once a product is out of the door, knowing that problems exist (crashes) and identifying them is a major issue. I'd love a built in capability in the development environment to say 'build and release', and have the relevant PDB files etc uploaded to a secure portal (note private portal too - MS run but not MS owned - code etc is customer proprietary) and for any product crash reports to automatically be visible there, showing stack traces etc. Basically automate what I do today which is take a mini-dump file and throw it into windows debugger to view what was going on. That would be a big time saver. I also think adding more static analysis tools to help identify problems and validate code quality would help. I would like the concept of 'formatting templates' to be added, so you can standardize on a style of code and then apply it to a project/file etc. Performance optimizations - definitely a favorite - making best use of processor capabilities automatically is best done by you guys working with Intel/AMD. VC++ is a very neat tool already though.   Keep up the good work!

  • Anonymous
    October 04, 2006
    You ask, "what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing?"  It might be a good thing from MS's standpoint but a bad thing for VC++ 6.0 (and C++ under UNIX) programmers who are debating whether to start using .NET once Vista comes out.  These folks aren't full-time programmers but instead are office workers who have to write programs to get their work done.  The less new material they have to learn to get started on .NET the better, and they don't want to have to learn C# first.  Granted, that really isn't hard, but why should they not be able just to migrate from VC 6.0 to VC 8.0 (learn what handles and delegates do) and then still be able to build user interfaces, now using WinForms and (with Orcas) XAML, just as they have been able to do with MFC all these years?  If C++/CLI is relegated to a tiny .NET/native interopability niche, it seems hardly worth MS's time and resources to maintain it.  It would make more sense simply to make the C#/native interoperability seemless and then eliminate the C++/CLI middleman entirely.  If, however, MS wants to keep using "language neutrality" as a selling point for .NET, they should make VC 8 be a genuine first-class language instead of a second-class one that is useful only as communications tool to a first-class language (C# or VB). If MS decides it would be the best use of resources to make VC++ the best possible tool for native coding and drop the .NET aspects entirely, that domain-specific approach would make sense too.  What doesn't make sense is the half-hearted approach of making C++/CLI a poor stepsister to C#.

  • Anonymous
    October 04, 2006
    VC++ is used to develop applications that target the Windows platform, so you have to follow the Windows division, VC++ can't evolve differently. That was also the reason for my exaggerated question regarding Win32/Win64. If Vienna exposes new stuff as C APIs or COM objects, then I would like to have C++/MFC wrappers for it. If the native APIs get a feature freeze and new APIs are only available through managed code, then it doesn't make sense to urge for new MFC classes. If we look at the Windows API, I personally love the base services, but everything regarding the common controls and user interface is at best ancient. So let's split an application into its parts, view (presentation), controller and model. So when Hawaii (Orcas+1) is released to manufacture we should have WPF v2 or v3 and the HWND based controls should rest in peace. With the arrival of Vienna it would then also be ok to drop support for Win9x/NT/2000, maybe even XP. WPF is currently not an option because of missing controls/MDI and it would lock out too many users. So around 2010 user interfaces should really be created from markup and with a designer and controls that expose properties to the designer and not ancient window messages. Layout/resizing/DPI aware user interfaces and localization should then be a must have like an undo feature today. So how does the VC++ developer creates the user interface with Hawaii? I would prefer C++/CLI support for XAML, because otherwise the controller and model would have to expose everything as managed code. And then I expect an application framework that brings the different parts of the application together. Design decisions that were made for the MFC have been made when we had what computers, 386? As for the language I don't see native C++ on the way out. C and C++ will remain import in many aspects, and not only for legacy code. VC++ is the application where this C code meets WPF. So VC++ really has a unique position. I hope that we will see changes to C++/CLI, const correctness, unions etc. (See codeguru slow chat) as well as C++0X. And C++/CLI support for mobile devices is important, otherwise I don't see how C++ code meets .NET

  • Anonymous
    October 04, 2006
    (Repost with corrected formatting) VC++ is used to develop applications that target the Windows platform, so you have to follow the Windows division, VC++ can't evolve differently. That was also the reason for my exaggerated question regarding Win32/Win64. If Vienna exposes new stuff as C APIs or COM objects, then I would like to have C++/MFC wrappers for it. If the native APIs get a feature freeze and new APIs are only available through managed code, then it doesn't make sense to urge for new MFC classes. If we look at the Windows API, I personally love the base services, but everything regarding the common controls and user interface is at best ancient. So let's split an application into its parts, view (presentation), controller and model. So when Hawaii (Orcas+1) is released to manufacture we should have WPF v2 or v3 and the HWND based controls should rest in peace. With the arrival of Vienna it would then also be ok to drop support for Win9x/NT/2000, maybe even XP. WPF is currently not an option because of missing controls/MDI and it would lock out too many users. So around 2010 user interfaces should really be created from markup and with a designer and controls that expose properties to the designer and not ancient window messages. Layout/resizing/DPI aware user interfaces and localization should then be a must have like an undo feature today. So how does the VC++ developer creates the user interface with Hawaii? I would prefer C++/CLI support for XAML, because otherwise the controller and model would have to expose everything as managed code. And then I expect an application framework that brings the different parts of the application together. Design decisions that were made for the MFC have been made when we had what computers, 386? As for the language I don't see native C++ on the way out. C and C++ will remain import in many aspects, and not only for legacy code. VC++ is the application where this C code meets WPF. So VC++ really has a unique position. I hope that we will see changes to C++/CLI, const correctness, unions etc. (See codeguru slow chat) as well as C++0X. And C++/CLI support for mobile devices is important, otherwise I don't see how C++ code meets .NET

  • Anonymous
    October 04, 2006
    The comment has been removed

  • Anonymous
    October 05, 2006
    The comment has been removed

  • Anonymous
    October 06, 2006
    We have tons of tested and debugged C++ code. Only the project I'm working for has >50MB of source code and we have a large URD to implement. And other products in our company have rather interesting C++ libraries we would like to reuse. Moreover, we reuse some source code which is being developed for very limited OSes. We don't want to rewrite it to C# each time it's updated. The problem is that one-way interop is not enough for us. We need all that magic of /clr switch in Windows CE! Windows CE 6.0 won't have that terrible 32MB virtual memory limitation. It will be fully functional OS - with no C++/CLI support. It's silly. Another thing is that there are ~50 C++ devs for mobile devices in our company of which only several people know C#. From my personal point of view C++ is superior to C#. My dream is to be able to use Boost libraries and /CLR switch in VS for Devices.

  • Anonymous
    October 16, 2006
    Steve Teixeira (Current Group Program Manager for VC++) has a nice series of posts ( here , here , and

  • Anonymous
    November 01, 2006
    I am very surprised that the Compact Framework does not support CLI/C++. We use it heavily for a number of reasons and not having it for devices seems a serious limitation. Is there any plan to add this immensely useful feature to VS05/Compact Framework?

  • Anonymous
    November 07, 2006
    As a C++/CLI developer working with a legacy MFC application and doing all new work in C++/CLI (using WinForms instead of MFC windows), I would be keen to see full XAML support in the C++/CLI designer, but failing that, why can't we have mixed projects, some classes C# and some C++/CLI? That way we can choose the right language for the right job.

  • Anonymous
    December 01, 2006
    First, I am all for componentization. No C++/CLI. If I want to do .Net I will use C#, and if I want to go native then it will be C++. I do not forsee myself using C++/CLI neither in the short or medium term. I think time should be spent on the native platform. But what I would like the most is REFACTORING! On a daily basis, doing heavy OOP refactoring is a nightmare for me. Be it a simple rename of a variable or a bit more complex polymporphic rename or moving code to superclass, refactoring is a real nightmare in Visual Studio simply because it has NO refactoring at all. Second, I would like more and better wizards to automate code generations such as Class/Methods/Members, etc... The Ultimate C++ IDE for me would be very similar to the Eclipse platform for java. It is the best IDE I have ever used. Be it the refactoring abilties, the browsing abilities, quick class overview, etc... this IDE is the platform to beat. Now I know that Java is a total different beast than C++, but for inspiration it might be worthwhile to take a look at Eclipse. Who knows, since it is opensource, maybe you guys can use Eclipse for Hawai? ;) Anyways here are my dollar spendings: Productivity Enhancements: 50$ Compiler Throughoutput:     30$ Concurrent Programming:    20$ REFACTORING: .....................Priceless

  • Anonymous
    December 12, 2006
    The comment has been removed