COM之后的世界（Don Box访谈录）

这篇访谈录中Don Box谈论了一些比较有趣而略带火药的话题，无论是老的COM开发人员还是C++程序员都是可以从中获益，甚至对Java开发人员也颇有诱惑力。必须承认其中有些秘密的故事，Don Box讲起来会更有戏剧感。

一些比较突出的标题和结论：

1。Is COM dead? Yes: OLE32.DLL。回答得这么肯定，当然了是OLE32.DLL

2。dotNET交叉平台的问题。MS乐意资助或支持任何的交叉平台的dotNET，但是对于GPL，无论Don Box还是Microsoft都是谨慎的态度。“Viral licences”是不是新名词？

3。深度的COM-Interop。Don Box讲述这个问题更有权威一些，因为GetManagedThunkForUnmanagedMethodPtr这样的函数不是每个人都听说过，并且真的会用它。

“Then I was at DevWeek earlier this year and I said, "I bet I could do that in C#. I bet I could do that in completely managed space." I looked around and IMoniker, which was the interface I needed, wasn't available - there was no CLR version of it. So I did the translation and it took me five minutes. I had IMoniker and at that point I wrote the thing in two minutes. ”

4。C++的未来，C++用在Enterprise applications和Templates的问题，一些C++老手最关心的话题。必须看到Stanley B. Lippman和Don Box对这些问题的看法是有差异的，如果可以选择我更喜欢Don Box现在的观点，因为更乐观和现代。

5。平台之战。dotNET和Java的争论已经有一段时间了“So .NET versus Java is a misnomer”

“So now the leading vendor in the Java space is IBM. Not only because they have a VM [Virtual Machine] which is pretty good, but mainly because they recognised the importance of XML. Now the problem is that IBM's approach to XML is different to Sun's, which is different to Oracle's. There is no broad, over-arching vision for how to do Java XML that's the same with every vendor. It's really become Microsoft versus IBM versus Oracle versus Sun. There's all kinds of triangulation there, for example Microsoft and IBM are doing very close collaboration, and Sun's being left on the sidelines. It's a very very different landscape.

So .NET versus Java is a misnomer. It's much more interesting to talk about .NET versus WebSphere, or .NET versus SunOne, whatever that's going to be.”

最后Don Box划分了一线和二线的差别，结果IBM,Microsoft,Oracle在一起而BEA和Sun被划在了第二线。

“Oracle, IBM and Microsoft are in a good spot to do that. Sun and BEA aren't. ”

小气的神

2002.03.12

Life after COM

Is COM dead? What's the future for C++? Is the Windows war with Java over? Matt Nicholson and Tim Anderson talk to Don Box about these and other issues.

Don Box is a well known and flamboyant conference speaker, as well as co-author of the Simple Object Access Protocol (SOAP). He co-founded training company Developmentor but has recently joined Microsoft as an architect in the Microsoft .NET Developer and Platform Evangelism Group. Matt Nicholson and Tim Anderson caught up with him at Microsoft's .NET Developer Conference in London to talk about .NET, programming languages, Java, GPL and life after COM.

Matt: Before .NET, you were really quite disparaging about the attitude Microsoft had towards developers. How's that changed?

Don: Microsoft has done a 180 degree turn. The dark moments of Microsoft were 1998/99 when they seemed so focused on the enterprise that grassroots hearts and mind battles were being ignored. It probably started in 1997 and I think it was over by 2000. It's totally different now. Microsoft has 20 million ways to reach out to developers and they're using every single one of them. That's good for Microsoft and good for people who use the Microsoft platform.

Why the change? It could have been a re-organisation. Every half year or so they re-organise the whole company, or so it seems. Or it could have been a realisation that they were doing it wrong. Or maybe this platform is such a significant sea change that the only way they were going to be able to survive was if the developers came.

Matt: You're talking about the .NET platform?

Don: Right. Up until that the last significant change was 1992. Between 1992 and 2000 we saw the same thing every year. In 1992 we saw Win32, OLE and Windows NT. From then to 2000 there were just incremental improvements. It got better, but there was no radical change in the way we write programs, in the underlying technology or the surface area of the platform.

Now the whole thing's over - that stuff's dead. We're moving onto something new. That's a very risky move, especially when the migration path for VB programmers, which is Microsoft's bread and butter, is the hardest of all.

C++ programmers have a lot of choices with .NET; they don't have to leave C++, they can keep C++ and just move forward with this platform, and life is great. But the Visual Basic programmer - and lets face it that's where the money is - has to start over. Their existing code isn't going to work on this new platform. C++ programmers can actually keep their code working. There's some amazing technological stuff that makes that happen. But for VB, there's a new compiler, with a new language, with subtly different semantics.

It was really interesting to watch the change from Beta 1 to Beta 2. When Microsoft released Beta 1 you had guys like Bill Vaughn up in arms saying "This is no longer VB". It was amazing to watch Microsoft retract some of the changes they'd made and basically appease those people, because they realised if the VB programmers don't come they don't have a platform. I think they understand that they have to make the customers happy, and the developer is their primary customer right now.

Matt: If you look at the history of .NET, Microsoft has been working on this new platform for a considerable time.

Don: At the San Diego PDC [Professional Developers Conference] in 1998 they gave out a C++ compiler that emitted this new executable file format, and they delivered a version of the runtime. It's amazing! In 1998! Nobody installed it, nobody cared. People had no idea of what they were actually seeing.

Matt: During that period Microsoft knew it was going to replace all that stuff. It knew that all the developers it was talking to were going to have their world turned upside down at some point in the near future.

Don: Definitely. I did. I think it was tough for people who knew. Microsoft probably started talking to partners in 1997. It was very challenging to give talks on COM in 1998 and 1999. That's why I didn't do a second edition of Essential COM. Technically there was reason to do it, because COM had changed enough and I could tell the story better. But it was pointless - it was over. What I tried to do was to steer people in the right direction by de-emphasising things that I knew were going to go away and were going to become irrelevant, and getting people to focus on core concepts that ultimately would last. It's interesting that the original name for the Common Language Runtime was COM3. It was designed to be the next implementation of the COM programming model. I'm really glad .NET got revealed. It's a very interesting platform.

The death of COM

Matt: When it first came out, a lot of people said "That's COM gone, .NET is something totally new". You were quite vocal in saying "No it's not. This is still COM". Can you explain that? Do you still hold by that now?

Don: That's a great question. In the broader term, ignoring the CLR specifically, I see .NET being about integrating software. That's exactly what COM was about. COM focussed us, not on our programs, but on how our programs communicated - how we brought our programs together. That's exactly the focus of the CLR: that's exactly the focus of XML Web Services. It's really interesting, having spent a lot of time with all three, to see these common themes permeate the whole thing. I believe there's a very consistent path to XML Web Services and the CLR. They are both an evolution of the original vision of COM, so in that respect they're the next natural step.

Is COM dead? Yes: OLE32.DLL, long may it rest in peace. But bringing software together with strongly typed contracts, and having encapsulation on either side of that wall - that was what COM was about and that's what this stuff's about. I see it as a very natural succession. If Microsoft had stuck with OLE32, and kept adding more and more stuff to that DLL, the thing would have imploded. So there's something to be said for trying again.

Matt: Much of Microsoft's official specification of COM is in terms of what COM is supposed to do rather than how it does it. It's still there, its not changed.

Don: This is an interesting idea. Back when I was in the COM world, when COM was viable as a real technology, people used to ask me "What's the best thing that I can read about COM?" I would routinely say, "It isn't my book, it's the COM spec", because I always thought the COM spec best articulated what the architectural ideas were.

Now that I've been doing a lot of work with .NET, people ask me the same question about .NET. Despite the fact that I'm writing a book and I think people should buy it because I need the money; easily the most articulate description of this platform, the CLR part of it, is the ECMA specs by Jim Miller and friends. That so clearly delineates the ideas, the architectural vision, and the motivation.

When I was working on my book, I realised it was really two books rather than one: the in-memory story, which is the CLR; and the remote story with XML. I wrote the first one, but felt I didn't really have a hook for the second. I went back and read the ECMA specs and it was there; it was about trying to move towards semantic contracts.

I had this picture in my book, which goes from TSRs to DLLs to COM components to CLR components. The end point is semantic contracts. Ultimately, if I write a piece of code and I want you to use it, I'd love to just be able to tell you "This piece of code will mow your lawn. If you ask it to mow your lawn, it'll make the lawn a certain height." We all know what it means. If we look at COM, it tried to get us in that realm.

COM was a good step forward because it brought type, which is how programmers hook semantics into their programs, into the loader and into the boundaries between components in ways it wasn't there before. But the details were so onerous. What we really want is, "You ask me to mow your lawn, I'll mow your lawn". The reality is, "If you put this 16 byte GUID up on the stack and then another pointer, take this pointer and de-reference it, then de-reference it again. I'll give you back yet another pointer, then you give me a pointer to a data structure, and this is what its layout will be." So much detail was in the binary contract of COM.

Matt: It wasn't encapsulated? You had to deal with it if you wanted to deal with that object?

Don: Yes. The good news about COM was we dealt with types; that is we shared type definitions across component boundaries. That was a step forward. The problem was we shared the semantics of the type, because we had to, but we were also forced to share the in-memory representation of the type. So in COM we had this notion of binary compatibility, which meant the in-memory representation of everything that you gave me was statically known when we built the components. So the binary aspects of your code, which are not semantic but details, get embedded into the code stream.

Moving forward with the CLR, we take a hands-off approach. We share types, which is good, because that's the way we render semantics in programming languages, but we defer the calculation of the in-memory representation until we get to the user's machine. We actually have all the code, the exact precise versions, and at that moment - and only at that moment - do we actually determine the physical reality of the program. That's why we have rich meta data, which we only vaguely had before. That's also why we use IL. We don't use IL because we want to run on any processor. We want to be able to defer the physical binding of these types until we're on the user's machine, so we don't have the brittleness of that binary contract, because the binary contract is fast but brittle.

Cross-platform issues

Tim: What tarnishes this slightly is the cross-platform issue. Because of the Web, the whole cross-platform issue is totally different than it was 10 years ago. I love the idea of downloading an application from the Web and running it in a secure environment. But the Mac, Linux and UNIX people will say, "Well it's not going to work on my machine". Do you see it being resolved?

Don: No.

Tim: Won't that impede the take-up?

Don: No, because in the future there will be many, many environments where you will be able to count on the CLR being there. Today you can't rely on that. But Microsoft has signed a deal with Kellogg, so when you get your cornflakes in the morning you'll find a .NET Framework CD. Together with Windows Update, and the American Red Cross dropping CDs from little parachutes, it will ensure that anybody with a Windows box will have the CLR. That's a huge number of people.

The cross-platform story is a very interesting one. The CLR may not get on Linux in any way that people can rely on. I don't know that the CLR will be on Mac OS.

The approach Microsoft took is actually pretty sound: the CLR is for this platform but, for integrating over the Internet, the only thing we're going to mandate is XML and HTTP. On all those other platforms XML and HTTP are widely available. People who want to write client applications against those platforms have so many issues to deal with besides the CLR. If I'm writing a Mac OS app, do I use Cocoa, Carbon or Classic Mac OS 9? If I'm writing for Linux do I use Gnome or KDE [K Desktop Environment]? Whether there is a CLR or JVM is largely immaterial because that's a totally different problem.

Tim: But it does mean that, if I'm running a broad reach web site, I can't actually take advantage of this fantastic facility.

Don: I totally disagree. I can build my web site or web service using all this technology, such as the CLR and XML Web Services, without mandating anything on the client. I can't deploy rich client applications to a Mac OS X box without writing Carbon or Cocoa code.

Tim: You're limited to what ASP .NET provides, rather than what all the rich client stuff can do? Or do you create separate client applications that use web services to overcome that barrier?

Don: Yes. If users running Mac OS X are statistically in your radar then you've got to make them happy. The same with KDE users. Here's the open question: "Everybody points to Mono. How will it work on KDE?"

Tim: If I were Microsoft, I'd be supporting Mono; they're doing a great job.

Don: Here's the problem: I think Microsoft does want to support it. Microsoft has been very friendly to lots of people. The problem is that Mono is GPL [General Public License, GNU] and Microsoft is very very cautious about getting involved with viral licensing agreements.

Tim: And surely also cautious about reducing the need for Windows, which is the other aspect of this?

Don: I think the desktop is a fait accompli - it's done. Linux is never going to be significant on the desktop. The real battle is over the server world. Microsoft has locked horns with Linux, which is probably competitor number one right now in the sever space. Bit I think if Mono was done with a Free BSD or Apache license, or something similar, Microsoft would be much more amenable. The problem is Miguel [de Icaza of Ximian] is very militant about GPL.

Viral licences

Matt: What's your attitude towards GPL?

Don: I hated it before I knew anything about Microsoft. Programmers should get paid to program. Being creative and making money from software is a good thing. GPL tries to cut off at least one avenue of that and it's viral - I think it heinous.

Tim: Microsoft could use it itself. Particularly on Mac OS, it has a long track record of producing good software.

Don: You know what's ironic about that? Microsoft's doing a Free BSD port of the CLR but it only supports Intel, so it won't run on Mac OS X. I don't know of any plans to support the Power PC, which would be neat. The problem is, architecturally, there isn't really much that ties it to Intel except all the JIT infrastructure which is very specific to X86.

Matt: What do you mean by GPL being viral?

Don: If I accidentally use GPL code, my code becomes GPL. It's infectious. One of Microsoft's big fears is that if it uses a piece of GPL code then Windows would become GPL. Imagine that. That would be really damaging. It's really sad, because having people work on software in a shared, friendly way is a good thing. There is a history of Microsoft doing that. But these fanatics who follow Stallman [founder of the GNU Project] off the cliff are crazy. They remind me of a cult. These people are so willing to sacrifice the ability to make money and create wealth for people. Those are really good things.

Matt: What about other Open Source licenses?

Don: The general principle of Open Source is fine. I'm neutral on it. I don't have a lot of controversial stuff to say that would be fun to print. It's a red herring. Those guys have had their day. The heady days of the late 90s, where there was just so much money floating around, allowed them to get far more visibility than they ever would have got normally. Now we're in much more fiscally conservative times the importance of Open Source is going to fall off the radar screen. People start worrying more about web server security, and the new platform wars that are emerging. I think the Open Source world has had its moment in the sun.

Working with COM-Interop

Tim: Are you happy with the COM Interop in the Framework? There seem to be some things that you can't do. For example in a Web Form application, if you want to embed the editing component of Internet Explorer there are some interfaces that you can't do. There are limitations to the COM Interop.

Don: There are no limitations to the COM Interop. I've spent a lot of time with it. I have been pleasantly surprised that I've been able to do anything I've ever wanted to. It's not always obvious - there's not a Visual Studio button to pull off everything you want. But the degree to which the inner workings are exposed is just amazing. Spend some time looking at System.Runtime.InteropServices.Marshal. It's a simple class with some static methods. Look at those and you'll say, "My goodness, look at what I can do. Look at the trouble I can get into with this thing". My favourite methods are GetUnmanagedThunkForManagedMethodPtr and GetManagedThunkForUnmanagedMethodPtr. They actually expose the ability to do the transition frame - to go from managed execution mode to unmanaged mode. There's so much amazing stuff you can do.

Tim: So do you think there's likely to be a way around the particular case that I mentioned?

Don: Yes. Somebody has to want to solve it. Myself and a colleague, we wrote the .NET moniker way back in Beta 1 days. Developmentor had a very rich history of writing monikers around anything. That was one of the rites of passage of a COM guy - you had to write a custom moniker to get into the club.

One day we said, "Lets write the .NET moniker", because I'd just figured out how to host the runtime. So I wrote the hosting code and my colleague wrote the moniker front end. We wrote it in C++ using ATL, the old school way, because that's what we knew best.

Then I was at DevWeek earlier this year and I said, "I bet I could do that in C#. I bet I could do that in completely managed space." I looked around and IMoniker, which was the interface I needed, wasn't available - there was no CLR version of it. So I did the translation and it took me five minutes. I had IMoniker and at that point I wrote the thing in two minutes.

Tim: A lot of developers have got existing COM libraries and they're thinking, "Do I need to port this to C# or am I just as well off leaving it? " What are the issues here?

Don: There are actually several paths. All roads lead to Rome. If the code is written in C++ there are actually a lot of options. If the code's written in VB then there are two options: get to it through COM Interop or port it to VB.NET.

With C++ there's a bit of a wider spectrum. Microsoft did something which nobody ever talks about, but which I try to bring up now in every talk I do because I think it's so important. They've got this switch which used to be called the IJW Switch, meaning "It Just Works". The idea is you can take any C++ program, throw the switch and, amazingly, it's in the runtime. C++ programmers seem to neglect this option, although there's lots of existing C++ source code out there that could easily make the transition into this world with very little engineering effort.

One of the problems with COM Interop, which people don't talk enough about, is that there's a performance hit. The runtime semantics and the type system of the CLR are different than the old world and so, inevitably, you have to do the equivalent of a user kernel switch. It doesn't actually go into kernel mode, but the runtime environment in the kernel is different so we have to do some sort of a mode switch. That's exactly what happens when you do COM Interop.

Tim: The third issue here is security. Code that calls unmanaged code won't run securely.

Don: Yes, but it has to be trusted. Theoretically, by re-compiling your C++ code it's now a managed executable, so it doesn't have the mode switch making it faster to call. The problem is, if we take a C++ app and re-compile it, it's not verifiable. It's an imperfect world.

The future of C++

Matt: What do you think is the future of C++ as a language?

Don: Had you asked me six months ago I would have said it's dead, it's over. When we go visit COM in the cemetery we'll bring two bouquets of flowers, one for the COM grave and one for the C++ grave. In reality, I've actually been doing more and more C++ programming on this platform.

Matt: What are you writing?

Don: Plumbing. I'm a plumber. What I like to do is figure out exactly what holds things together. Unfortunately for C#, as nice a language as it might be, C++ has more power. It's a much more flexible language. For the kinds of programming I've been doing in the last three to six months while finishing my book, where I basically had to know everything, I hit the wall with what you could do from C#. So the next natural thing was C++.

Matt: Were you exploring how the CLR worked?

Don: Yes, that was my personal motivation. But I also like the language. I've been using C++ since 1988.

Matt: Does C++ have a future for Enterprise applications?

Don: Enterprise applications are different. Enterprise applications try to avoid C++ like the plague already. That's going to continue. The nine-to-five developer has no business programming in C++. C++ is a lifestyle, it's a dedication to complexity. You look at the complexity and say, "Hah! I can master you." ISVs [Independent Software Vendors] tend to work in that world, but not enterprise developers. ISVs are important too. They should be heartened that Microsoft is working on managed C++. I think Microsoft is working on some really exiting stuff and it's going to be really good for C++ programmers.

Tim: There's been talk about templates coming into C#.

Don: They won't be C++ templates. Those are far more powerful and complex. You can use the C++ templates now. You can take any C++ program you've got with any language feature and just re-compile it and it works. It's an amazing piece of technology.

Matt: Templates in C# remind me of Developmentor's Gen<X> product.

Don: They're very similar. The whole idea of being able to generalise software is a good idea. You write one solution, then you generalise it. Generics and templates in C++ are about integrating with the language. The good news is the compiler and runtime can do a better job. The idea behind Gen<X>, which I still think was a great idea, was "that's too hard". Parameterising the type system for the enterprise developer is just intractable, and it's a design issue. Gen<X> was about lexical artefacts only. We take the source code and, in essence, do macro pre-processing on it. It's a very different philosophy. There's room for both.

Matt: Is what Microsoft's doing with C# like Gen<X>?

Don: No, it's more like C++ templates. It's burying into the language and the runtime. Ultimately, it's a much more architecturally sound approach. The Gen<X> approach is more pragmatic, which has more flexibility, but it doesn't give the compiler and runtime as good a chance to find redundancy and things like that. It's two different approaches which can co-exist.

Platform wars

Matt: What do you see as the major differences between .NET and Java?

Don: I think that .NET versus Java is a red herring. Java is going through a transition period, which is good for Java. J2EE hasn't been able to adapt, to evolve to the problems people actually want to solve. If you look at the last J2EE spec, it is a very incremental improvement and in some ways it's incrementally stepping back because those guys are getting even crazier with some of the entity bean stuff. But ultimately the nature of this platform war is really changing - it's no longer Java versus .NET. Java doesn't mean anything anymore. It's becoming like CORBA. Back in the late 1990s, CORBA was a fairly meaningless term because all the interesting aspects of CORBA were buried in a particular vendor's ORB [Object Request Broker], so it was really one vendor versus another. I think we're seeing that all over again because J2EE, as a standard and as a platform, hasn't really tried to address these new problems customers are facing. I believe J2EE as a term is irrelevant.

The reality is people use Java for Servlets, JSP and JDBC. Are all those things in J2EE? Yes. Is that what J2EE is? No, it's all the other technology which nobody wants. The thing that's missing from the J2EE story is a compelling XML web service vision. There's nothing there, mostly because J2EE is driven largely by Sun, who didn't understand the significance of XML. Those guys just believed Java was the answer so they ignored XML - they let XML pass them by. So now the leading vendor in the Java space is IBM. Not only because they have a VM [Virtual Machine] which is pretty good, but mainly because they recognised the importance of XML. Now the problem is that IBM's approach to XML is different to Sun's, which is different to Oracle's. There is no broad, over-arching vision for how to do Java XML that's the same with every vendor. It's really become Microsoft versus IBM versus Oracle versus Sun. There's all kinds of triangulation there, for example Microsoft and IBM are doing very close collaboration, and Sun's being left on the sidelines. It's a very very different landscape.

So .NET versus Java is a misnomer. It's much more interesting to talk about .NET versus WebSphere, or .NET versus SunOne, whatever that's going to be.

Matt: Do you think Sun's effectively missed the boat?

Don: Yes, I think they're peddling very very hard to try to catch up. They were basically on hold for most of 2000 and 2001. The problem is Microsoft's not sitting still waiting for them to catch up. Nor is IBM. So I think Sun has marginalised itself. It's no longer purely about Java, but about which vendor you pick. I think that's good. Ultimately, that's the way it was anyway. With all these crazy J2EE containers and all the funky EJB implementations, writing to the EJB spec was a stupid idea. You really had to pick a vendor and see what worked and didn't work on that particular container. I think EJB was the death-knell of this idea of 'write once run anywhere'. With J2EE and EJB, the containers were so idiomatic and so idiosyncratic that you had no clue whether code was going to work well on all the containers or not. So if you wanted an application to work well, you picked a vendor.

Matt: Do you think it's moving from Microsoft versus Sun, to Microsoft versus IBM?

Don: Absolutely, it's a two horse race. There's no question. It has been for at least a year now, and that's good. It's good having a race and it's good having more than one horse. I can see either one of them succeeding.

Tim: Is just one going to succeed?

Don: That's a good question. Microsoft is not going to drive IBM out of business, or vice versa. So no, they will both succeed. The question is what's going to happen to the Suns or BEAs of the world. BEA is in a really bad position because it doesn't have a database. IBM, Oracle, and Microsoft have a database. More and more, as we want to see this end to end XML solution, we really need to integrate the XML storage engine with the processing logic and the communication protocols. Oracle, IBM and Microsoft are in a good spot to do that. Sun and BEA aren't.

Tim: In theory that could be a strength because you say, "Choose your database, it doesn't matter".

Don: The reality is, especially for the next two to three years, the way XML integrates into these old school databases is going to be very very idiosyncratic, and the vendor's front-end is going to have inevitable advantages. So it's like EJB containers - you pick one and that's the one you go with. The problem is, I don't think BEA can do a great job integrating with the big three databases, plus all the other second tier databases. E