Why MSDN publishes more Managed Code than Native Code Information

From time to time, I get queries like “Why is Microsoft forcing managed code on us?” or “Why is Microsoft abandoning native code?” and so on. As MSDN is a key Microsoft public interface to developers, I thought I’d answer that from my own perspective.


Being a Program Manager at MSDN offers me a unique position within Microsoft as my specific job (Content Strategist) is to publish content that balances the needs of marketing and the technical product teams with our own knowledge of the target audience and the technologies involved while aligning with Microsoft’s overall business goals. Needless to say, the job can be quite challenging and at times more political than I’d prefer as I’ve been a programmer since the early 80’s and sometimes long for the days of being lost in low-level code as opposed to endless meetings. However, at the same time, I do enjoy my job very much as it enables me to see the business from many different vantage points and to have a basic understanding of why we do some of the things we do. One of those issues is the whole “managed code vs. native code” issue regarding why we promote the former much more than the latter.


To start with, I submit to you that there is no black and white here. We’re talking about the amount of information on managed code and managed code tools relative to native code information. In terms of native code, there are over 7,000 new APIs in the Windows SDK and every two weeks, we publish a new chapter to the Windows Vista Developer Story – a 600+ page collection of information on native SDK development. In addition, as we get closer to releasing the Windows Vista and the new Windows SDK, you’ll begin to see even more native code articles. However, most of the native code information is centralized on the Windows Vista and Visual C++ Developer Centers with the majority of information being published by MSDN being focused on managed code. Hopefully, this post will explain why – at least from my point of view.


Marketing –At Microsoft we have hundreds of products, but it’s no surprise that the reason we remain the most profitable software company in the world is by virtue of selling two main products - Windows and Office. In addition, it’s critical for the long-term stability of Microsoft that we also have a major impact on the Web.


Everything else (especially development tools) is simply a means of accomplishing those goals. An example is the Windows SDK. It’s completely free to anyone that wants to download it as it serves the greater purpose of getting developers to write Windows applications, which in turn sells more copies of Windows. In addition, you frequently see us hold training seminars that, at best, break even and might even lose money. Once again, the goal isn’t making money from these products or functions. The goal is to get information into the hands of developers so that they write Windows applications – or Web applications using Microsoft technologies.


There are many more examples – such as the free Visual Studio Express products, free training, free technical articles on MSDN and so on, but you get the point. The focus is always things like, “What can we do to the O/S to enable developers to create the apps they want for their customers?”, “How can we make the development tools easier to use to lower the cost of delivering that software in a timely fashion?”, etc.


Having said that, the latest technologies that accomplish the goals of selling Windows, pushing the Web and making it easier for developers to write Windows applications, are things like Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow, etc.  


Therefore, most conversations between marketing and MSDN deal with focusing on these newer technologies – in the form of publishing technical articles and whitepapers written by evangelists, promoting training and seminars, providing demos and hands-on labs and so on.


Product Teams – This is an easy one as most likely if you’re reading my blog, you’re also a developer and realize that most developers want to work on the latest, coolest thing. Our dev teams are no different. Therefore, internally when our product team developers write for MSDN they’re generally writing about the latest technologies. In addition, the various levels of management for these product teams also focus on requesting that we more heavily promote the latest innovations and features of their products.


Target Audience – If you ever want the definitive answer for why we at Microsoft do something, follow the metrics. The Visual Studio and .NET Developer Centers are – by far - the two most popular Dev Centers (in terms of traffic and users). They are followed up by Windows Vista (which is gaining rapidly despite still being in beta) and VB.NET. The meaning is clear. Developers come to MSDN looking for information about managed code and Windows Vista.


Therefore, one way of answering the question of why we post so much managed code content (relative to native code) is via the old adage, "We don't make the news; we only report it."  Like any other company we stay in business by meeting the needs of our customers. If customers weren't asking for and responding favorably to this, we’d be going in a different direction. Therefore, it’s simply inaccurate to say that we’re forcing anything on anyone. We’re the ones reacting to what the masses have requested and right now that’s managed code and tools for developing advanced UIs in the fasted time possible.

Comments (50)

  1. Rich Solomon (Troposphere) says:

    Wow. I had no idea the things you mentioned about native code regarding Vista and the Windows SDK.  I guess I didn’t dig deep enough on the website to see that stuff.  This certainly does educate my perspective on the issue.

    You have me seeing it 99% differently now.  The remaining 1% is still angry that Avalon is available ONLY to managed code.

    Best Regards,


  2. Tom Archer says:

    Rich: I’m glad I could answer your questions/concerns.

    One of the main reasons that Content Strategists blog is to "raise the window shades" (no pun intended) and let customers know that there’s real people and real reasons behind the decisions we make and that customers are ultimatelly our key stakeholders with our success being measured by our ability to respond to your needs and goals

  3. Kristoffer says:

    What I would like is a quick and easy way to search either managed or non managed APIs (or both as it does now). I generally know in advance what sort of information I want.

    Oh, and the Search button appears to be broken in Firefox. Manually pushing enter in the search box works though.

  4. David Totzke says:

    Great post.  Thanks for the insight.

  5. bob16972 says:

    You refer to web traffic concerning new technologies but you should always expect people who are on the ball to at least take more than a quick peek at any new technology to see if it has anything useful to offer. This does not mean every hit means another convert.

    http://www.tiobe.com has a similar flawed thinking when they rate the popularity of a language based on search engine hits. MSDN has most of what people need without the need to "google" for it 80% of the time so this would bias the Tiobe rating against your products (languages). Languages that get more hits may just mean the help system is flawed and users need to reach outside the manufacturers resources to get assistance.

    I have bought books on .NET, C#, and Java. Took tons of classes on Java but I still use Visual C++ Native code for everything I produce privately and at work. I came here today to check out what all the hype was about concerning WinFX but now I’m affraid to even investigate it as you folks will incorrectly assume I’m here because I’m subscribing to a new technology.

    Win32 remains so well documented and seasoned professionals will rarely need to stray outside their local copy of MSDN for standard production needs. My web traffic or book purchasing patterns do not even remotely represent what technologies are making it to market in my world. My web usage is merely me trying to make sure I don’t miss something that solves a problem I DON’T already have a solution for. Your data is skewed if you think all the traffic is anything but simple curiousity because of your massive marketing efforts. I would guess most people who have a foothold in a technology already, will likely only compare and contrast the new vs. old. Your likely to get the newbies to jump on board because they don’t already have investments in current technologies.

    I’ve only found GDI+ to provide some enhancements that I think I’d prefer not to live without. Anyway, I appreciate the fact that your in your position hopefully looking out for the rest of us and I appreciate the fact that you took the time for the post. My reply is only intended to suggest a more cautious response to the statistics and numbers being thrown around up there.

  6. stic says:


    prowokujący tytuł, nieprawdaż? 🙂

    czy ktoś z Was dziś jeszcze pamięta sztuczki i kruczki z C/C++?…

  7. Henric Joanson says:

    I think one of the keys to understanding this issue is in the the question itself. When native code developers ask themselfs "Why does Microsoft force managed code on their developers?" I think what they really want to ask themselfs is "Why can’t Microsoft be more like us and push native code on their developers?".

    The reasons for promoting the managed code base are rather obvious in my oppinion, not only from a marketing / economical perspective but also from looking at where Microsoft is going with the whole .NET platform.

    To sum it up, I think most of us understand why ms does promote managed code, but not why ms doesnt give enough attention to native code.

    hmm maybe I’m being a tad bit too philisophical about the whole matter, anyhow thanks for a good post.

  8. Chen says:

    I want to know how to develop Operating system using VC++, Any ideas to me?


  9. Wil says:

    I suspect the reason many developers ask about "Why so much managed code?" is that they are flummoxed by the Vista "relaunch" and the decision to use Windows 2003 Server as the code base.  With Avalon and Indigo now being "add-ons" rather than "pillars" of Vista, people are confused about whether to write to the .NET API or stick with MSFC / Win32.  Seeing so much managed code on MSDN, yet being told that the code base will remain unmanaged for at least the next 10 years, leaves developers in a state of uncertainty about how best to proceed.  IMHO, of course…

  10. Dmitriy says:

    I am developer WEB of applications and I use technology ASP.NET 2.0. After first acquaintance with WPF, I have understood, that I should be reoriented on new technology WPF, besides many official sources Microsoft write that Avalon and XAML functionalities which in hundreds times surpass DHTML give! In connection with that, that XAML applications can be integrated very easily with WEB, I believe, that would be more correct to build applications for WEB on XAML. But here there is one problem:

    Existing technologies, such as HTML, DHTML, JavaScript – are WEB standards which are supported by all browsers and are indexed by search engines: Yandex, Google, Rambler, etc. In this connection there is a question on availability of mine XAML a site in a global web.


    Whether undertakes what that measures Microsoft, on standardization XAML, how WEB the standard like HTML?


  11. Ranju. V says:

    I think .NET is quite simply a much better way of developing professional commercial software in that it makes shooting oneself in the foot a lot harder as opposed to developing software in native code (I am talking VC++ of course and not VB).  It is simpler, more organized and things get done a whole lot faster.  And that’s the reason it is popular and that’s the reason Microsoft is generating as much content as it is on it.

    Having said that however, it *is* somewhat sad that native code development is out of the "lime light" so to speak.  I myself am a great fan of plain SDK and C++ based programming and would definitely like to see Microsoft produce content on it.  I suspect that going forward VC++ gearheads will end up being a small elite group (capable of doing fancy tricks that the managed folks couldn’t ever do) – out of mainstream development and relegated to stuff like device drivers, games and things!

  12. Espen Harlinn says:

    There are about a zillion developers producing apps in VB that most of us will never hear about, and those unfortunate souls that end up using those apps will truly hate them. Over the years MS (and others) has tried to invent the silver bullet time and again, and we’re not there yet. When things don’t work as expected nothing beats debugging native code – where you can see what actually happens – and in a couple of years when .Net is a thing of the past – native code will still be with us. Just rewind the clock a couple of years an Java was cool – even you people at MS said so. I would just love to see – just once – somebody who actually can code – and carries some weight at MS: Tell the marketing division to stuff it. .Net is nice – but it is not the future. We’ve heard about c/c++ going away for quite some time now – it hasn’t happened yet.

    BTW: If you still has to show us managed code: DON’T USE VB – please use C# – it’s easier to read, even for VB programmers 🙂

  13. Anon says:

    My company currently has no intention of using managed code…

  14. Dave says:

    To me it is like a child opening the fridge to find the cheeze wizz, and  absolutely not having any idea of what it contains or how it got there in the first place.  AHHH yes but someone really knows!  Knows what?  It dosn’t matter, the kid is over there and still smiling!

    Thanks for the topic

  15. Alexei Kvasov says:

    Hi Tom,

    I am working on medical instrumentation software that acquires and displays data from medical hardware. Sampling rate is 4 packets per ms.

    What managed code? Not everybody is working on WEB apps (that will work only under IE 7?). There are different applications out there that require appropriate solutions and tools. There are different software developers out-there too. You should remember Tom, you have been there with us.

    On the topic:

    Thanks for attempt to articulate position of MS that you (as a MS employee) are not allowed to articulate.

    I think developers who’ve been around will agree that position of MS is not only to help developers to create applications for Windows, but for Windows only. It started with VB many years ago and still continues with C#. It was always war against Apple, Unix, Linux, IBM OS/2, Oracle, Java, PHP, Open Source, Free Software, you name it. Now it is AJAX war with Eclipse platform and others.

    I am not blaming MS, but this is how it always was.

    BTW: If you remove all references to native API from your website, will you still consider people who are looking for it browsing through countless managed code articles as MANAGED DEVELOPERS? (or should we say MANAGED BY MS DEVELOPERS?:-)

    Thanks for the topic,

    Best Regards,


  16. Ken says:

    I work on real time trading apps at a large company.  We have to handle thousands of price updates per second.  Many of these updates require some significant computations be updated as well.  If we fail to keep up we can loose thousands of dollars within seconds.  Furthermore, there’s still a lot of Unix dinosaurs around here and they’re not going away so whatever we do has to communicate with them.  This doesn’t even touch on what would most likely be a truly huge porting effort if we were ever to dive into .NET in a big way.

    I think we’ll be on native code for the forseeable future. In fact, if MS ever failed to adequately support native code there would be a strong push to move to a non-Windows OSes.

    We use .NET where we can around here but that isn’t many places.  Typically small apps for updating the database which could have been written with VB or C++/MFC if .NET weren’t available.  However, the heavy hitting mission critical apps (at least those that run on Windows) are in good old C++/Win32 and this will continue.

    .NET certainly has it’s place. I personally write .NET/C# code whenever I can and I love the C# language.  I have probably accounted for many of those hits you were seeing.  However, around here it can’t be used everywhere or even in most places.  My company could operate quite well without .NET if we had to.  Without native code we’d either have to shut down or switch to a non-Windows OS.

    As a previous person pointed out, not everyone writes web apps.  People who want to learn about .NET are doing it for many reasons and many (most?) are not using it as their primary development platform.  You need to remember that.

  17. Tom Archer says:

    Ken: Thanks much for the input. I agree with you that we do need to remember *all* of our customers. Hopefully, the fact that the SDK team has created 7,000+ new APIs clearly indicates to everyone that we are not in any way abandoning Win32/native programmers. Quite the contrary. We’re continuing to strengthen our offering to them with every release.

  18. Vamsum_Kris says:

    I think the way we program applications has changed a lot. Now a days programming is more of designing and configuring things rather than typing actual code, .net marvels at this, but unfortunately there is a huge performace bottleneck for using these things, also the way the memory is being handled is a mess; in our organization we ‘wrote’ thousands of lines for a web app and the final result- a too hopelessly slow product that fiinds it difficult to manage even dozens of users, i donno what will be the future but I believe the word will definately take a U turn and the demand for native code will return.

  19. Mark R. says:

    In many ways, I think this post just misses the mark entirely, especially with regard to the statement "We don’t make the news, we just report it."

    MS absolutely made the news with regards to managed code; once they decided that it represents a "better way" to do things, native code became an afterthought.  Every one of the MS marketing machines (of which MSDN Magazine is a part, though in many ways a *good* part) became almost entirely focused on managed code. They have deliberately done everything possible to make it sound like you’re "missing the boat" if you aren’t moving to this newer technology.

    The problem with this strategy is that it forgets a very important point. Almost every modern ISV with applications of any relevance whatsoever have written their code in C++. We have to deploy these applications to our customers, we have to support them, and guess what – we have to improve them.

    But MS decided to stop helping us to reach those goals. What’s new for C++ in VS2005? Honestly, the truth is nothing. But MS did re-work things in such a way that deploying MSVC++ applications became much harder than it should be (I won’t get into the details here).

    Meanwhile, thousands of commercial applications out there continue to use C++/MFC/STL to reach their customers, and stuggle mightily as Microsoft turns their backs on us with no improvements to the technologies or libraries.

    At the end of the day, managed code is just a higher level abstraction. It’s right for many things, but not everything. To Microsoft, every code base suddenly looks like a nail, and their favorite hammer is managed code.

  20. Hello,

       I find all the information developers have been posting to be very informative.  My company has actually decided to adopt Microsoft’s latest .NET technology to build our document management solution called EDM.NET.  I come from a strong VC++ background and have built many applications using "Native" code.  Our company does prefer to use Managed Code because it is much easier to develop enterprise level products and quickly turn around new functionality.  Many of the new features are aimed at making our lives easier such as ClickOnce deployment and removal of the "DLL Hell" issues we ran into in the past. I believe that "Native" code is not going anywhere anytime soon.  I also believe that Microsoft should do its best to balance both technologies and keep the interoperability.  I have also used Java and SUN tools for development – including WebLogic. There does seem to be a push now to a common platform Eclipse for using Java technology that I find interesting.  It is good to have competition between all these technologies.  I still believe in using the best technology and tools to solve the problem as opposed to trying to force an incompatible technology.  Look forward to additional Blogs on the subject.

  21. Jeff Lewis says:

    Actually – my question isn’t why is there so much managed code – I think Managed is the way to go.

    My question is: why is there so much ASP.NET? ASP.NET solves one very specific problem, but most of us still want to use desktop applications, and most of us want to make and sell them.

    That’s not likely to change any time soon, contrary to the views of many pundits. Like – this is the year of Unix, which they’ve been saying since 1972, this is the year of the Web App is another one that I think will fill specific niches but not be "the" solution.

    I’d like more focus on desktop apps or "SmartClients" as they’re now called.

    And while we’re at it – Windows Mobile/WinCE – and Smartphones. .NET CF is one of the more painful things to try and work through using MSDN.

  22. Russell AliBey says:

    I find all of the posts to be very informative in providing viewpoints from a wide spectrum of development styles/backgrounds.

    However, one thing that I have noticed is that noone has mentioned .Net front-end code interfacing with native backends/APIs.

    I find this odd considering that the .Net platform appears to have been designed with this use case in mind, although not heavily documented, everytime I see a coding example that can’t/shouldn’t be solved with today’s level of evolution of the .Net platform, I see a reference to P/Invoke (case in point: COM ports). Which begs the question, how many native developers are unaware of the benefit that this backward/lateral compatibility can leverage for them in time, money, and frustration. I have written hundreds of lines of C++ code to do something as simple as download a file from an FTP server, where .Net can do this in three lines (slightly more than ten with robust exception handling). I am not stating that .Net is "better", just that the API is there to support more rapid/robust development, why not leverage .Net where you can, and work in native code where you need "ultimate" control/performance.

    Every animal has its strengths and weaknesses, so does every development tool. Use the hammer for the nail and the screwdriver for the screw.

    I don’t find that MS has abandoned the native developers, just that there are alot more questions about the new tools than there are about tools that have been around for almost 20 years (C++), not to mention the documentation base for the older tools is so large, there shouldn’t be any question that is unanswerable with good use of today’s search engines.

    My $0.02


  23. says:

    我覺得就是一種商業策略 實際上整個.NET也是一種商業策略下的產物 它不是必需的 用VC++還有什麽不能實現的?沒有。現在的Windows和VS.NET爲了這種策略改得亂七八糟。比如VC6的IDE風格對於MFC/ATL開發者是再合適不過了,但是爲了統一使用一种風格,M$不惜犧牲了6的那個科學方便的IDE,改用那種VB式的愚蠢的風格。說實話這讓人覺得噁心,我和許多人一樣現在仍然使用6,也許我以後必須忍受那個令人生厭的IDE,但如果真到了那天我想我會儘快轉到UNIXBSDLinux。

  24. Stephen says:

    I find it difficult to understand why so many developers are so hostile to new technologies such as .NET. If more developers would stop listening to all the negativity coming out of the camps who can’t cope with change or progress, they just might find out that .NET does provide for better, more efficient, secure, and rapid application development.

    I have seen numerous posts just here in this blog talking about how native code would live long after .NET was dead and gone. People have to come to the realization that we aren’t living in the 80s or 90s when vendors could take 3-4 years to ship a product. If you do that today you’ll be left in the dust.

    Productivity is ultimately where .NET will win. Productivity equals profits, which equals adoption by business executives, which will eventually force developers to do what they should be doing in the first place. Current projects may not need to be ported, but for any new projects I can’t find a good reason not to use .NET if you’re developing on the Windows platform. It cuts development time in half at least, but that’s a conservative estimate.

    Stop fighting progress and upgrade your skills for the 21st century. Those who don’t will truly be left behind.

  25. Hello Microsoft management, you reading any of this?

    Thanks for answering this question Tom. I also don’t buy the “Reporting the news” metaphor. I’ve noticed not many people have responded with “right on, I only care about .NET”

    I personally really like .NET and managed code. The richness of functionality in the .NET portfolio saves huge amounts of time over constantly re-inventing the wheel with WIN32. I have spent so much time trying to glue together different libraries that have different ideas about object management, allocation and deallocation in Native Code. With managed code all this becomes so much simpler. (Good riddance ATL) I can now pass data between applications and not worry about who owns it.

    .Net has some really great attributes, but the (assumed) bloat and performance problems make it unusable for many applications.

    What is the guideline for knowing when .NET / Managed code is usable? What is the performance penalty versus the equivalent (well coded) native implementations? Is the only solution for each developer to just try it? Is the JIT compiler for C# much better than we think? (and this isn’t as bad of a problem as we all think it is)

    Assuming managed code performs as bad as rumor has it. I have a prediction:

    The main stream is all going to mottle about (like me) and all reach the same conclusion. Managed code is really great for passing objects between large blobs of code developed by different groups and .NET is really great for its rich set of functions, but you still need unmanaged code for speed. So most devs will decide they want C++ with managed extensions. I can now switch between managed objects and unmanaged data as much as I want. I can code “inner loop” type functions using unmanaged data types all day long

    So why am I reading the C++ with managed extensions is being deprecated for CLR? CLR doesn’t look like C++ to me.

  26. David S says:

    The guy above just highlited the biggest short comming of managed code … speed.  Managed code is all fine for productivity for business applications where performance isn’t paramount and rapid development times are crucial but it doesn’t suit all applications. Applications that require performance just wont get the same level as what they would get with native code and often may not even get the required level of performance.  I am not against managed code but I am against it being pushed on us when it can’t possible cover every applications needs.

  27. Jeff Lewis says:

    I’ve known about the reality of Microsoft (as explained here).. well, always. It’s pretty obvious when you think about it.

    Still, something I think we often forget is that this is true for every other computer company out there. Putting out SDKs and developer tools costs money. It’s also a market that in the long run, rarely is exceptionally profitable. That’s why we’ve seen such a consolidation in this field.

    Microsoft has changed over the years – I remember when it was almost impossible for a new programmer to afford even the most basic of MS tools (well, except for GWBasic… which was free). Now we have VS Express, the eV tools – tons of stuff we can use to build apps WE can profit from and share.

    The MSDN library is almost unique: well written, fairly comprehensive, deep in scope. Is it perfect? No. Neither is the Encycloaedia Britannica. That doesn’t stop it from being good though.

    As for the managed vs unmanaged API, first I think people have to grab some perspective. C++ is not going away – managed or unmanaged – especially unmanaged. There are a raft of reasons for this, not the least of which is the most obvious: even with Vista you can’t write a kernel level device driver in C#.

    There are many tasks for which unmanaged C++ is essential, both in and out of system level applications.

    However, the vast bulk of applications are much simpler. For every high performance game, there are hundreds of accounting apps and web apps. These all can not only be done in manage code – but done BETTER in it.

    "Better" is a word I rarely use because it is SO subjective, but this is one rare moment when I can objective list countless reasons for why managed code is better than unmanaged code for the majority of real world apps starting with the most obvious: security, reliability, ease of development, ease of maintenance. Using managed code results in smaller applications that do more, that can be written faster, more reliably, with fewer mistake and simply look and work better.

    Does that mean we’ll never develop in C++? Hardly. The weaknesses of managed code are also significant: it currently runs on just one platform: Windows, although Mono may change that soon. It’s not delivered on the platform – it has to be installed and that’s a killer since it’s 23MB in size. There is a startup delay (although there are ways to reduce that by precaching). The execution speed is slower – although not nearly as much as some people want to believe. Benchmarks show that managed code it on average 10% slower than C++ native code. And the biggest stumbling block: there are areas of unmanaged API which are difficult to reach, or unreachable from managed code.

    Vista will alleviate SOME of this, but not all. And even if Vista did fix all of it – it won’t solve multi-platform compatibility – which C++ has, as long as we’re talking text UI. Otherwise, you’re porting libraries from Unix to Windows or Windows to Unix – and that’s a comparable solution to using Mono on Unix and being in managed code again.

    Eventually, most of the Windows API will be exposed in managed code – and some of it will ONLY be exposed in managed code.

    It’s the future for Windows, guys.

  28. rav says:

    Its obvious why they spend more time promoting managed code such as .net than they spend on unmanaged code.

    Managed code products such as .net is a microsoft product, and to ensure you squeeze a product for every last penny of profit, you promote it and make people believe they cannot go on without it. The future of windows depends on the apps made to run on it. Without the apps an operating system is nothing. Its the same when you go to a used car dealership, you know what you want but you will have to fight off sales personel and their reccomendations to get it. They know if you push hard enough, you will fold.  Its the same marketing strategies that brought forth windows as we know it today. If you don’t want to use managed code, don’t use it at all. I personally use the c language with the good ole win32 api. And when they phase out C and eventually C++ in visual studio, alot of people will stop using it. Alot of people prefer other compilers for this very reason.

    And its a proven fact that managed code has a small performance hit. Its also a proven fact that managed code is no subsitution for bad programming habits. As far as functionality, there really is no differences, you can make the same apps in almost every language. The only thing that changes is compatibilty and portability.

    And as far as vista, i dont know if you know this or not, people generally don’t like to have to buy a gig of ram and a 3 gig cpu just to check their email or browse the net.

    The emphasis on a pc should be the apps and not the os. An os should have the smallest footprint in all aspects and do its job silently and do it good. The performance hit on vista compared to xp is hugh, i hope you guys know that people do care about their pc taking ages to boot.

  29. gizmo says:

    just make sure you tell me when you plan to stop supporting unmanaged code on msdn, it will be the last day i visit the site.

  30. Prithvi Krishna says:

    C++ will remain king of System side programming, .NET will be the future in terms of Enterprise Applications / Business Apps / Smart Apps etc. like Banking and Financial Apps simply because its a lot easier to *productize* something in .NET, i.e. Rapid App Development is the .NET mantra.

    Given the cut-throat competition these days – definitely more Managers and Business Heads will opt for .NET given the fact that it cuts down development time, enables more simpler deployment resulting in more time and support saved.

    Native code is will rule real time apps, embedded software as it does not have the .NET framework telling it what it can and cant do.

  31. SamIamAidiot says:

    MS support for .NET vs public opinion,is a primary error that needs to be debugged not by MS but by developer’s.

    MS does that in which is to their best intrests,as in opposite to developer’s whom do not need any managed code.

    It’s clear that there is more of a fear element that is felt by hard coder’s of something theyve done for years if not decade’s may eventually fade into oblivion.

    Small subtile changes,with a little less information,and learning tools,and functionality that will prevent it from being ported,or integrated,adds to that dismay,some may call it misinformation.

    Further developments require a certain set of basic rules,even if a user sees the rules as instructions,(really no differance).

    Of course I would fear that it may make development easier,and quicker,but also take away a certain quality of a product of which elements of flooding the market with cheap but less functional applications,will change public opinion,causing the masses to purchase more applications from MS than from third parties.

    Now thats what you call marketing! 🙂

  32. William McVey says:

    Bloat?  Performance problems?  Can these allegations be quantified?  No doubt, in some kinds of applications (e.g. those requiring realtime response), a badly timed garbage collection could cause an application to fail.  As for bloat, if the library is properly constructed, only necessary code should ever be loaded into memory.  Large physical memories and paging should make even bloated code work well.

  33. Brian Korzeniowski says:

    Microsoft was criticized for years as shipping "buggy" software so they did something about it. They wrapped all their COM-based technologies into logically referenced units called namespaces.  This new product, dubbed "The .NET Framework", unifies most Microsoft-based technologies under one umbrella and one marketing moniker.

    There is really no "magic" involved with the .NET Framework.  I have used the .NET Framework since version Beta 0 and have found its stability, speed and flexibility only increase with each version. Sure, there are portions of the framework that need tweaking, but overall the framework is stable.  In other words – Microsoft finally found a way to begin to stabilize the developer platform. That’s great news for the future of the Microsoft Platform and all the ISVs, partners and customers of Microsoft!  Thus, QUALITY won the day – not productivity.  The "productivity" gains enjoyed by leveraging the .NET Framework come as a result of the framework’s stability.

    The framework itself appears to be written using a combination of C++/C#, with the C# code interfacing with the native Win32 API via P/Invoke or Com Interop.  Most of the Microsoft Platform SDK is actually shipped as native C++ header files (.h) and COM IDL files (.idl).  Microsoft has no plans, that I am aware of, to abandon its 30 years of C++ experience in API and Platform SDK design in favor of "managed" APIs.  They do, however, provide the ability to write your own managed wrappers for the new 7,000+ APIs that have been written.  Wrapping the APIs you need using managed code is a relatively straightforward exercise using COM-Interop, P/Invoke functionality.

    Microsoft is not forcing developers to choose native code development over managed code development. In reality, the .NET Framework places the pendulum of choice squarely in the hands of each developer.  Need speed and low level power? No problem. Swing to the native side for a moment.  Need quick, rapid productivity and flexibility? Again, no problem, just swing over to C# for a while.  Need interoperability between the two extremes of the pendulum? Again – no problem. Simply use P/Invoke or Com-Interop and you have the best of both worlds.

    Also, ask yourself if it makes sense for Microsoft to canabilize its own development efforts with managed code? The new 7,000+ APIs added as platform SDKs are mostly written using C++/COM/ATL, etc… In fact, Windows Vista continues to embed COM technology in its very operating kernel. Now why would Microsoft suggest that you abandon your native code development efforts when they have not – and have no plans – to abandon their own? Just as they will fail without native code (at least for the next 20 years) so will most ISVs who rely upon the speed and raw low-level power of C++ and inline assembly language (remember the "asm" keyword anyone?)

    I think that this debate distracts companies form the real goal of their existence – focus. If your passion is native code, then write native code. The idea you cannot automate native code writing is not true.  The ideas set forth that C# blows C++ away in terms of productivity is not true either. I know lots of development shops that have code automation tools that just blow away anything the .NET Framework has!  So don’t be too quick to attack either set of development paradigms. Neither has seen its best days yet and the future is yet to be written for both.

    My best prediction? I predict that in the end our customers vote with their pocketbooks. Native code and managed code are really synergistic cousins of each other. remove one, the other suffers. Thus, they will be around to compliment each other for decades to come.

    I think turning a preference into technological dogma is dangerous to one’s career and impedes innovation in a highly competitve industry.

    So here we are – .NET vs. Native Code. May the best technology win! but in my opinion, they are BOTH already winners and will compliment each other for decades to come.

  34. David says:

    I have read many posts on this blog. To me the question really seems to be "Why do we have to change" and the response is "because we can’t sell you new software if you dont". Change is the wheel of the software world and profit greases this wheel. We all find that one niche that we really, really love. Its true, most of us work in environments that we have chosen because of our allegience’s rather then their benefits. C++ was the first language I learned and in the end the one that I still look on with the most favor. However I am a professional developer. I started my career in 1991 building client server applications and migrated with the eb and flow of this wonderful industry we call technology. Today its C# the replacer of glorious Java. I will always love my days with C++, the days as master of my own destiny and holder of all the kingdoms keys. But in the high speed deliver it yesterday or we outsource it world we live now, I have to tip my hat to my present bread earner C#.  I guess my point is that we have to move with the times or time moves past us. To stay competitive you must stay current. Dealing in absolutes "I will not move to managed code" is sure ticket to the unemployment lines. Guys, managed code is the future. Rage againist, scream about it, rail, rebel and yell but when your lungs are empty grab a C# book to read your bank account will thank you for it.


  35. Brian Korzeniowski says:

    The premise behind the question, "Why do we have to change" infers that change is something to be feared or avoided.  Change is precipitated by ideas which spawn technological innovations.  The Microsoft .NET Framework is one such idea that has spawned technological change.  Change is not to be feared but embraced with enthusiasm.  But while embracing change, never forget that your customers vote with their pocketbooks.  One customer’s idea of acceptable change is another’s unbearable nightmare.

    While it is partially true that we work in environments we are comfortable with, it is more accurate to say we work in the environments that are productive, and provide the tools to effectively satisfy our customer’s demands.  The real issue is: What is important to your customers?  For example, avionics software requires the highest level of accuracy and performance possible.  Would you replace real-time operating system, kernel-level code with a JIT-Compiled, virtual machine like the .NET Framework?  Perhaps, but in these cases, embedded systems programming and real-time operating systems rule – and for good reason.  Thus, customer preferences and application requirements play a huge role in the chosen development environments.

    One final point: If everything in your toolbox is a hammer, you will only build what a hammer can build.  While C# is the lingua france of choice, it is not suited for everything.  It is not yet suited for real-time operating systems development, embedded programming, CMOS programming, or performance sensitive applications.  

    Would you use Adobe Photoshop if it were written as a managed application?  Adobe tried converting some of their products to C#, but the performance limitations of a virtualized environment made it an absolute performance sloth.  Thus, they returned to C++.  In essence, they chose the right tool for the right job.  They recognized their customer demands and responded with the correct technology to meet that demand – C++.

    Personlly, I think C# is a great language.  I respect its strengths and its weaknesses.  However, it is not yet truly ready for the mainstream, commercial software world.  P/Invoke and COM-Interop are great tools in the interim, but what will come next is anyone’s guess.

    Be careful when you make assertions that C++, Delphi or any other "older" languages are relegated to the technology landfill.  COBOL is still around.  Perl is in full force use, and Python is gaining a resurgence in popularity.  Microsoft made the language choice irrelevant within the .NET Framework Managed Environment – but unmanaged code will never really go away.  I suspect that the C++ Language Specification will continue to evolve as most languages do.  And I suspect that virtualization will be relegated to just a corporate fad within 10 years.  After all, 88 million baby-boomers don’t care about virtualization.  They care about sending and receiving e-mail, and basic computer operations.  Youth care about the latest gadgets, VoIP Technologies, IM and Text Messaging.  Different technologies for different generations but the same overriding principle: customers vote with their pocketbooks.  The value proposition is any language or technology is directly proportional to how well you meet the customer’s expectation  of what they think your technology will do for them.

    Who will win?  it won’t be the company "greasing" it’s wheel with profits.  It will be the company that most effectively and accurately meets it’s customer’s needs.  Profit follows principle – the principle of meeting customer demand.   And what’s wrong with profit anyway?  That’s a good thing.   🙂

  36. David Hagan says:

    I think manged code is a travesty. I myself do all my development using the command line application DEBUG and find it to be the only IDE i need.


  37. Paul Webb says:

    Great post Tom. I don’t think microsoft has every really let the unmanaged community down at all.  

    I think some people fail to see the value of managed code in enteprise applications – specifically because they have never been involved in writing applications on an enterprise scale where real-time like code performance is not neccessarily the critical factor in delivering business value.  This is especially the case in large distributed business applications whereby performance considerations are rarely measured at the applications code level, but more so at the level of communications channels (eg Web service v remoting) or at a database level. (database optimisation).  In this sense, i think Microsoft’s position is still very well balanced – especially considering that most developers will be writing these sorts of systems. (imho)

    I certainly don’t see Microsoft telling everyone to write real time medical software or trading platforms in managed code. Of course it can be done, but those of us with a little bit of imagination know that there are cetain things that need to be done in the unmanaged world.  Which is why .net allows you to interoperate with unmanaged code.  Write the low level stuff unmanaged in C++ and the other stuff in C#.  As you have mentioned there is still a huge wealth of unamanged resources available and more to come with Vista. I really don’t see what anyone in the unmanaged world would have to worry about? 🙂

  38. Paul Sandeen says:


    Thank you for this interesting blog entry and to those who posted comments.  I would like to add a perspective not yet explored in the discussion.

    This might come as a huge shock to the high-end developers that read MSDN, but many people who develop code are not full-time developers, or even people with formal training in computer science.  

    Outside of Microsoft, Oracle, and big software shops, a lot of software is developed by small business owners, lawyers, MBAs and mechanical/electrical engineers that have been tasked with creating custom, line-of-business applications.  These organizations find that it is easier to train an employee familiar with their industry how to write software than to hire a software guy and teach them about their business.

    This type of programmer clearly gave rise to the popularity of Visual Basic.  It was easy to drop controls on a form, write some BASIC code behind the controls, and deploy.  You can see Java taking the ball and running with it – no pointers, no manually freeing allocated memory, no non-type-safe constructs like templates – all in the name of simplifying software development and reducing ways for a developer to shoot themselves in the foot.  

    Anders Hejlsberg said it best: Developers vote with their feet – and were moving to Java.  Microsoft must compete and was forced to release .NET, which I think can be framed as a grown-up version of classic VB, with type safety, real OOP, and managed memory. All while still being accessible to non-pros.

    I’m an old engineer.  I like to write C with inline assembly and twiddle the bits to wring out the last drop of performance.  I would not right games or an RDBMS in .NET, but this is only a small fraction of the types of programs being written.  You can argue about the performance advantage of C/C++ and the Win32 API over any other development tool.  But performance is often is a small issue compared to security, stability, interoperability, shrinking development time, and the issues of people who actually develop software in the real world.  This is why managed code gets so much attention.

  39. Michael S. Smith says:

    Well, overall I can understand the frustration, because I would prefer the power and complete control of native code.  

    However, being in the IT field at a college, I have had to deal with many computers running native code apps that had either compatability issues or that were so poorly managed (memory management that is) that when you would close the app, it would continue to consume memory.  Dealing with students, of whom the majority had left over P1 machines running windows 98, I had many trying to get me to fix their computers when the software they installed was shotty itself.  Overall, I think for smaller software companies and those who aren’t really adept at computer programming, plus those who are hobbyist or newbies, the .NET thing kind of makes me feel a little safer in that some aspects are protected from their ignorance, and at most will simply not work the way intended, but not as likely mess up the computer.

  40. Jano Petras says:

    Great topic – great responses – bravo! I have been thinking about this topic quite often lately, and have come to the conclusion that the future will probably look something similar to this:

    – Business applications will be done in managed code (Java or .NET) where performance not critical, stability and efficiency in development being the paramount

    – Mission critical systems/real time systems: definitely native code

    – OSes, RDBMSes, Kernels, Drivers, Games: native of course

    – Websites – this is interesting point – but I think apart from very few heavily visited websites with a dose of real time systems (such as stock traders etc) this will be either managed code (ASP.NET or Java) or interpreted solutions (PHP, Perl, etc). As many of these are currently around and the fact that they are interpreted causes no problems – this is probably going to remain the same

    So where is the place for "native" guys (as much as I use .NET for almost every project -> I would like to call myself one of them) in the future?

    Exactly there – OS/Kernels, resource intensive apps (photo processing, video editing, music), RDBMS engines, drivers, games, real time simulations, mission critical systems and most importantly: managed world needs someone to write the routines/APIs/high performance components that their managed solutions would use! Don’t forget: under nice & gentle managed bytecode lays a layer of the native lion doing the lion share of the work!

    NOTE: This post is obviously and shamelessly subjective

    — Jano

  41. J. Galloway says:

    It’s waaaaaaay simpler than all that.

    Native code articles have been published by the tens of thousands for 20 years.

    Managed code articles only date back 3-4 years. They have a LONG way to go to catch up!

  42. Andrew J Lumley says:

    I make a point of reading the sort of discussions which appear on this blog.  Reading though I wonder if anybody has looked at the RAD tool Omnis Studio?

  43. formerly of the exchange forum says:

    I came here to learn something more about Visual Studio role in my program development. Might there be a better place for me to learn more? Right now I am hitting walls which are non-intuitive. When I Google for the messages I get hits so I am not the only one hitting the walls. Speaking of productivity, just how valid is the message that I should be using these productivity ‘enhancers’.

  44. Amir Cicak says:

    Well, for years you are saying that .NET is better, easier, more productive, and as fast as native (within 10%) and you wonder why are people so "thrilled" about it. Of course most of those marketing propaganda are all lies. For example benchmarks are childish. I mean you take one simple loop and few calculations and say, see its only 2% slower. Or DirectX app in which 99% is done in HW and says just 3%. But if we look at real world apps NET is at least 3 times slower than Native. Why? Because NET libraries make a lot of "cheap" objects and when you use 100000 net classes, which you do in any app, millions of "cheap" objects are generated under the hood, that’s why for example even Microsoft made SQL Server management tool is unbelievably slow since they made it in NET. While it was native it run instantly. Any app you run you immediately see it’s made in NET or Java, for example Eclipse, Zend, etc. Why doesn’t Microsoft make Office in NET, or why are Photoshop, 3dsmax, etc all native. I recently converted some database code from VB6 to C#, and guess what VB6 runs MUCH faster for the same functionality.

    Also "you need hundreds of lines in c++, and in NET its 3 lines of code" philosophy is for dummies. Of course if you do everything from scratch and don’t use STL, BOOST, etc. you need hundreds of lines of code, but if you did everything from scratch in NET it would also take "hundreds of lines of code". You could just as easily take ONE OF MANY libraries in c++ for the same task and make same thing in 2 or 3 lines of code, depending on library.

    Anyway its obvious that Microsoft pushes .NET because they don’t like idea of QT, wxWindows, etc. which make perfect multiplatform tools. That was big problem for Microsoft because anyone could make quality products for both Windows and *nix-es, which had to be dealt with. .NET is perfect solution, because it forces people to depend on Microsoft libraries, and people are unable to make portable apps (Mono is a joke). Also with putting so much abstraction in people’s heads (and forcing them to forget real programming), they are sure no one will be able to make serious product which competes with some of their products which are all native (serious ones). However they risk a lot here because software on *nix-es will be of much more quality, since its native, and companies may consider shifting there instead of buying additional hardware to support slow running .NET apps.

    As a programmer, I hate open source movement, and I hope Microsoft will realize its mistake and continue to support native code not only "legacy" support, but also with sincere marketing, like "c++ is 17 times faster than C# in typical serious app, but its harder to learn".

    Dreams, dreams….

  45. to Paul says:

    Since when are templates non-type-safe?

  46. Paul Sandeen says:


    Thanks for calling me out on the ‘Since when are templates non-type-safe?’ question.  I was trying to raise a problem that is more of a type-constraint issue more than a type-safety issue.

    C++ templates are type-checked at compile-time since that is when type substitutions are done.

    For example:

    template <class T>

    T add(T a, T b)    

    { return a+b }

    This will compile under C++:  T will be replaced by the type sent to add().  But you better have a + operator to handle any type T you might send!  (The compiler would issue an error if a type was sent that the + operator did not know how to deal with.)

    CLR generics are not just a feature of the compiler but also a feature of the runtime, meaning that the type substitution is done in the JITer, and constraints are used to limit what types can be sent. It is not possible to call arithmetic operators in a CLR generic class (but user-defined operators are OK).

    Bjarne Stroustrup considered having explicit type constraints in C++, but decided against it.  For better or worse, the result is that a programmer must read the source code to see what types will work with the template, or compile their type against the template and see if there are any errors.  

    In C++/CLI, choosing between  CLR generics and C++ templates is an issue of placing the burden of constraints.  The C++ template implementer has more freedom but the template user must figure out what types are usable (the constraints are implicit). In CLR generics these constraints are stated explicitly (taking freedom away from the generic class implementer, but making it easier for the generic class user).  And making life easier for ‘end-user’ programmers was the point of my original post.


  47. Ed says:

    .Net ir really slow, but its improving with every new version (at least the program start up time is getting shorter).

    I was programming in VB6, then I thought learning .net maybe useful and I went to VB .Net. I liked it for some time (1 year), but it wasn’t enough, so I learned managed C++.

    This is great, since it allows to build complex programs easy, thanks to .Net.

    But then the .Net 2.0 came and made managed C++ worse than ever. There’s so much useless, pointless, slow crap, that the code allmost glows like nuclear waste.

    I QUIT .NET !!!!

  48. Vijay Kumar says:

    Nice discusson.

    I used to write database  apps in vb6 (60%) and other type of apps in vc/vc++(40%). But now I write even database programs in vc++.  Rapid application depends on one’s command over a tool and language. Now I deliver better and faster database apps in vc++ very fast as compared to vb6. GUI is rich and much user friendly and very much in my control.

    Now I have turned 100% VC/VC++ ONLY and I do not regret my decision.

Skip to main content