January 10, 2006
@ 04:27 PM

In his blog post Windows DVD Maker Not Managed Code Charles Cook writes

Last week Eric Gunnerson mentioned that he has been working on an application for Vista: Windows DVD Maker. Yesterday he posted a FAQ for the application. The answer to question 4 was disappointing:

4: Is DVD Maker written in managed code?

A: No. Yes, it is ironic that I spent so much time on C# and then spent a ton of time writing something in C++ code. Everybody on the team is a believer in managed code, and we hope we'll be able to use it for future projects.

Given that there is a whole new set of APIs in Vista for writing managed applications - Avalon, WinFX, etc - why has a new self-contained app like this been written in unmanaged C++? Actually writing real applications, instead of just samples, with the new managed APIs would be far more convincing than any amount of hype from Robert Scoble.

I agree with Charles. If Microsoft believed in managed code, we would build applications using the .NET Framework. We do.

In his post Cha-Cha-Changes Dan Fernandez wrote

The Microsoft's not using Managed Code Myth
One of the biggest challenges in my old job was that customers didn't think Microsoft was using managed code. Well, the truth is that we have a good amount of managed code in the three years that the .NET Framework has been released including operating systems, client tools, Web properties, and Intranet applications. For those of you that refuse to believe, here's an estimate of the lines of managed code in Microsoft applications that I got permission to blog about:

  • Visual Studio 2005: 7.5 million lines
  • SQL Server 2005: 3 million lines
  • BizTalk Server: 2 million lines
  • Visual Studio Team System: 1.7 million lines
  • Windows Presentation Foundation: 900K lines
  • Windows Sharepoint Services: 750K lines
  • Expression Interactive Designer: 250K lines  
  • Sharepoint Portal Server: 200K lines
  • Content Management Server: 100K lines

We also use managed code for the online services that power various MSN Windows Live properties from Windows Live Messenger and Windows Live Mail to Live.com and Windows Live Expo. I find it surprising that people continue to think that we don't use managed code at Microsoft.


 

Tuesday, January 10, 2006 4:47:31 PM (GMT Standard Time, UTC+00:00)
I think it comes down to reusability. Why rebuild something in .NET if you already have a perfectly working COM version? Granted, you might want to make a wrapper for easier API interaction or something, but why reinvent the wheel?
Tuesday, January 10, 2006 6:23:18 PM (GMT Standard Time, UTC+00:00)
I've read Media Center is mostly managed code. That would be the only consumer-facing app on the list.
Ricky Dhatt
Tuesday, January 10, 2006 6:35:07 PM (GMT Standard Time, UTC+00:00)
When answering this question, put yourself in the shoes of the developers asking it. There are currently precious few applications "for mom" from Microsoft that use managed code. Hearing about *brand new* applications being written at Microsoft in unmanaged code causes us to ask a great big "WHY?" and really hurts the .NET story. Regardless of how long the list of applications that "technically" use managed code is.
Tuesday, January 10, 2006 6:51:37 PM (GMT Standard Time, UTC+00:00)
Ignoring the IDEs -which have to be strongly managed code, pretty much every "this is managed code" example is something server side. Which is fine; if you are going to deploy something on your own servers then choose a decent language for it.

But the fact remains, the majority of the MS application suites, from IE to Project to office, is unmanaged C++, gaining performance at the expense of buffer overflows. That isnt much of a surprise; legacy code should be left alone, and though managed C++ looks like it was designed to make porting existing C++ possible, it doesn't make it easy.

But the economics at MS client side are that of mass market software: a few developers, many customers, and the costs of developing legacy C++ apps are probably sustainable, not just in the profit source that is MSOffice, but in other things like MS Money, games (obviously), maybe even the mapping things. The benefits of managed code: ease of development, ease of testing and deployment are less important when your company contains almost all the world's Win32/COM experts, separate developers and the ability to issue OS patches if that is what it takes to get your app to work.

None of those arguments apply to organisations outside MS. So why are they not doing Managed apps? Well, no enterprise org in their right mind should be writing any client app: server-side is the only thing that makes sense from a development perspective. Only mass-market apps should be written for specific platforms these days.

One such app, Azereus, is of course the only reason that the mass market want the JRE on their desktops; its the killer app of both Java and the MPAA. I havent seen anything in C# land that is so compelling.

The last mass production app I worked on in 2003 deliberately chose C++ because we didnt want to take on the risk/hassle of forcing people to install the CLR (and take on IE updates in the process). It also wasnt available on all platforms. The consensus was "hold off C# apps until Longhorn ships". The ISVs I worked with were all C++/COM too, and were very pleased by my design of "C++/COM/you create the threads and call us" architecture, showing we were aligned with the rest of the industry. Hey, this new DVDburner should be one of our customers if they want to label their disks in-drive.

I will note, however, that SuSE 10.0 ships with Mono and the Beagle search tool, bonding the latter in to Mozilla such that the mono runtime is active when you bring up firefox. So MS will be second-to-market with an OS that includes a web browser running managed code.

Tuesday, January 10, 2006 7:07:06 PM (GMT Standard Time, UTC+00:00)
Stuff that's written partially in managed code isn't nearly as interesting as stuff that's written entirely in managed code. Applications written partially in managed code only demonstrate that it's still not possible to write a complex, first-class Windows app without having to end up mucking about with all that legacy COM stuff.
Tuesday, January 10, 2006 8:08:15 PM (GMT Standard Time, UTC+00:00)
For other non-windows type, from
http://www.google.com/search?hl=en&ie=UTF-8&btnG=Google+Search&q=define%3Amanaged%20code

Definitions of managed code on the Web:

* Managed code is code executed by a .NET virtual machine, such as Microsoft's .NET Framework Common Language Runtime, The Mono Project, or DotGNU Project.
en.wikipedia.org/wiki/Managed_code

And for a minute, I thought Dare was talking about Program 'Managers' and Development 'Managers' and the code! ;-)

Amit C
Amit C
Wednesday, January 11, 2006 3:05:34 AM (GMT Standard Time, UTC+00:00)
I'm sorry Dare, when you mentioned managed code being used in Windows Live Messenger, do you mean at the backend services?

When I ran the MSIL Disassembler, this was what I saw.
http://thespoke.net/photos/bernard/picture927840.aspx
Wednesday, January 11, 2006 3:20:13 AM (GMT Standard Time, UTC+00:00)
Bernard Oh,
I wrote that the ONLINE SERVICES that powers these properties is written using managed code. So, Yes, this means backend services not client code.
Wednesday, January 11, 2006 5:52:14 AM (GMT Standard Time, UTC+00:00)
There is also MSKLC (Microsoft Keyboard Layout Creator) which is 100% managed code....
Thursday, January 12, 2006 7:51:27 AM (GMT Standard Time, UTC+00:00)
Don't forget the MOM Operator Console, MS CRM, I think Capacity Planner, LArge Parts of Exchange v.next...
Friday, January 20, 2006 1:28:19 PM (GMT Standard Time, UTC+00:00)
Dont forget SQL Server Reporting Services

Adam
www.ssw.com.au
Comments are closed.