Discussing Visual C++ product strategy

There is an interesting post on VC++ Orcas forum, which I thought I would link to from my blog. Initial question contains a summary of frequently asked questions about VC++ strategy in managed code. The author has expressed several concerns about VC++ approach and feature set. We who work on the product also think about these issues. Bill is VC business manager and he has spent several months by drilling down into details of VC++ business and its implications on technology focus for VC++. He has already replied to the thread with a brief outline of the current strategy for VC++. Take a look, feel free to jump into discussion and share your thoughts. Here is the direct link to the post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1032378&SiteID=1.

Also, I have re-arranged tags on my posts a little bit to better represent content I post here. In addition, I had to block comments to posts older than 90 days. I am receiving too much spam comments. Hopefully this is a temporary measure. I may enable it back if spam issue is resolved.


Comments (4)

  1. nico-pyright says:

    Hi Nikola,

    thanks for relaying this info.

    Should we understand that the fantastic work made on C++/CLI is only intended to use interop and make transition to C# ?

  2. Kris says:

    It is refreshing to see that VC++ is taking on a new direction. I think this is good for the VC++ community. For a while I thought VC++ has lost its focus and appeal.  I think  VC++ should aim at building great native applications. I like C++/CLI especially for interop but I think that is where it should stop. By providing every designer that is available for managed code, you are just wasting away your valuable resources who could be otherwise used for adding new native VC++ features and libraries. I bet there is a lot of inhouse C++ libraries MS built over the years as most of your products are built in VC++. Why not try and provide those – not as part of the language itself but add-ons – they would enable some of the hardcore C++ guys to build some neat apps. Why not provide a library for Vista capable features? Anything to keep the VC++ community alive and growing would be welcome and I bet there are places where C++ still out shines C#, else why would MS still use VC++ in majority of their products and companies like google build all their core tools in C++.

  3. Nikola Dudar says:


    When members of VC team talk to customers about a language of choice to develop purely managed code, most if not all of them already use C# or they are perfectly fine to use C#. C++ developers are usually quick to learn C# and successful in using it. Overall feeling that C# does everything one need when working only with managed code and there is not need for C++/CLI to provide same level of tool support. However, in area of interop, C++/CLI is extremely helpful and it is the primary language of choice. With this said, the team feels that we need to focus on area where we do best and bring unique value to our customers. This is why "moving forward we will increase our support for native development tools and will work to provide “friction-free” interop between native & managed code", as Bill says it.


    Thanks for your support! I and other folks on the team agree with you on the unique role of VC++ in developing native code. We try to introduce as much as possible of new features in native area with every release. In the upcoming release (Orcas), we are working on a refresh to MFC support for common controls, dialogs and overall UI drawing to enable developers to build first class apps on Windows Vista. We have added support for new controls available on Vista and new messages added to controls and dialogs since XP. Most if not all of it is going to be available in the upcoming February CTP. Also we are looking on alternative ways of releasing VC++ libraries separately from the mainline product. For example, we are working toward releasing ATL Server as a shared source library, so it can be evolved by its community and be independent of shipcycle for VC++ product.  I should be able to share more information about this project later this month or in February. As for the releases after Orcas, I would expect to see many more features in area  of native code development. It may be features in existing libraries, it may be new libraries and new tools.


  4. A belated Happy New Year to everyone. I’m finally back from vacation. Catching up: VCBlog: A couple of

Skip to main content