.NETDJ Editor-in-Chief Derek Ferguson chatted with Microsoft Software Legend Jeffrey Richter at Microsoft's Professional Developers Conference 2003. In this exclusive interview, Richter talks about sharing his working life between Wintellect and Microsoft, and what it's like to help shape Microsoft products.

.NETDJ: Tell me about yourself.
JR: I am a cofounder of Wintellect. I do a lot of training for the company and occasionally some of the debugging and consulting work. I have authored and teach Wintellect's .NET course, and will be coauthoring and teaching our Indigo course, as well. I used to do a bunch of Win32 stuff, but not so much anymore.

.NETDJ: Is the Win32 stuff the reason you are famous?
JR: Actually, I had written a Win16 book for Windows 3.0. It was, I think, the first advanced Windows book that went beyond Charles Petzold's book. It was more for the commercial software developer - which is what I was at the time - whereas Petzold's was more for initial familiarity.

The book didn't sell well, but it kind of put me on the map. Microsoft Press became aware of it and at the first Win32 PDC Microsoft found me at the conference and asked me if I wanted to write their official Win32 programming book. I agreed, and that became the first Win32 programming book out there, which really established me.

.NETDJ: Have you continued working for Microsoft since then?
JR: On the other side of my career, I have been consulting with Microsoft on and off for over 10 years now in various groups: Visual Studio, Windows Sound System, Research, Microsoft Golf, and TerraServer, just to name a few. Then, in October of 1999, I was asked to consult on the .NET Framework team. I've been doing this ever since, except for a five- month period from January to May of 2003, when I was consulting with the Indigo team.

.NETDJ: How do you manage to work for both Wintellect and Microsoft?
JR: I live three miles from Microsoft's main campus. When I'm not on the road doing Wintellect stuff, I have an office in Building 42, and I go in there and work. I can also do some Microsoft stuff while I'm on the road.

.NETDJ: That's a heck of a lifestyle! Why do you do it?
JR: I like the freedom. I like the control. There have been times at Microsoft when I've made suggestions and - due to resource constraints, time constraints, or various other constraints - those changes haven't gotten in, and that can be frustrating - especially when it is known that it is the technically correct thing to do.

I also enjoy the variety. I really like architecting and programming a lot. That's how I got started in this business. It taps into the creative side of me. I like the training, too. It's not as creative, but I enjoy meeting people at other companies, learning about what they do, seeing their faces light up when I explain something and I see it click. And, honestly, I have an ego.

.NETDJ: What do you do when you're at Microsoft?
JR: Most of my time at Microsoft has been spent working on the Common Language Runtime (CLR), but I was on the Indigo team for five months. I am now back at Microsoft as a part of the Version Architecture group, working on preventing and minimizing "DLL Hell" and coming up with a new "Add-in model" for dynamically extensible applications.

.NETDJ: I thought that .NET had already gotten rid of "DLL Hell!"
JR: In Win32, we made it very easy for developers to create new versions of their DLLs. However, we made it really difficult for end users and administrators to keep their stuff working in the face of a new DLL that broke something.

In the .NET Framework - up through Whidbey - we took a 180-degree turn on that. We made it very difficult for developers to do the right thing, but very easy for end users and administrators to do nothing and still have a program continue working as it was initially created, even with a new DLL.

Since developers really want an easy way to create and deploy a new version of an assembly that can be used by existing apps, we realized that we needed to deliver a mechanism that gives them this flexibility but ensures that we don't end up with DLL Hell again, with developers doing their own thing to solve this.

What we want to do in the Orcas and Longhorn time frame is to get a better balance going.

.NETDJ: What can you share with us about what will be done?
JR: One thought is to make every assembly strongly named. We can offer a lot of additional functionality if we have a lot of information, which you just don't have with weakly named assemblies. If we do this, then Visual Studio .NET will have to have better support for strongly named assemblies to make them easier to create.

We will divide assemblies into two main groups: Platform and Library. Platform assemblies will include components for which Microsoft promises to always maintain backwards compatibility, like the Win32 API. Library assemblies, in contrast, are files that contain components that we feel free to make radical changes to over time - this will be the default.

Also, we will probably have just one CLR on any given machine - no longer supporting side-by-side runtime engines. Microsoft may consider refactoring some of their existing types into Library and Platform assemblies, and they will offer a technology so that existing technologies that bind to those assemblies do not break.

.NETDJ: And you also mentioned "a new Add-in model for dynamically extensible applications?"
JR: More and more applications are being built in such a way that components can be added to them in a late-binding fashion. Visual Studio is completely architected this way; Office supports this with things like Smart Tags.

We want to have an architecture that allows the hosting application and the company that is building add-in components to be able to version either side independently of the other side. That's very important to us.

For example, the Windows Shell team may define an abstract base class that other developers can derive from in order to extend the Shell with some new component. Over time, the Shell team may want to modify and change this abstract base class in such a way that might break the other developers' components. The Add-in model that I'm working on allows the Shell team to define new ways of talking to components without giving up the ability to work with older components. From another perspective, this means that a component could be developed that works with multiple versions of the Windows Shell.

In addition, we want to have an architecture that allows applications to say that they trust some components to run in their application domain, but require others to run in separate application domains. For example, suppose that Microsoft has a bunch of partners that it wants to allow to run in the same application domain as the Shell. On the other hand, there are probably lots of partners out there who aren't as trusted, so we want their stuff to run in a separate application domain. This way, if their stuff blows up, the Shell won't go down.

We might even offer the ability to run components in their own processes.

.NETDJ: How would that work?!
JR: A component and a host would negotiate this. The component might ask for "in-process" status, but the host would say that it has to run out-of-process. Right now, we just call this the "Add-in Model."

.NETDJ: The last thing you mentioned was Indigo. Can you tell me about that?
JR: I like what the Indigo team is trying to do - basically to abstract the network away and to separate infrastructure for communications from information that will be processed as a part of that communication.

.NETDJ: So you like the abstracted nature of Indigo?
JR: Not just its level of abstraction. I like the idea that the SOAP message is divided into an envelope and a body. I like that the envelope contains the infrastructure pieces for how to do security, routing, transactions, etc. I like that this is all formally described and standardized.

.NETDJ: And what do you do in the Indigo team?
JR: What I was contracted to do with Indigo was to build an application with Jason Clark that was on top of their M4 platform, so we got to do transaction, reliability, routing, security, etc.

.NETDJ: I'm sorry - what is M4?
JR: That was their milestone for the stuff that they wanted to have for the PDC. One thing that we really learned from that was that doing messaging with RPC-like methods and return values isn't going to work for anything that isn't really simple.

It takes - at the programmer level - knowing that you are working with a message, plus you have to have access to the header information! We were doing content-based routing and we needed to put a value into the header so that the router could pass the message along. When you're doing RPC, you don't have access to the info in the header.

Another thing we learned is that - for a large distributed application - almost nowhere in the application did we have request/reply as a pattern. When you're working with RPC, it looks like you're doing method invocations, but in our case it was actually going to a server, getting routed, and getting a response back later on from another machine.

When we had architected some of this as RPC, we found out that we needed to rip it all apart and go lower. Today, I would not do the RPC thing at all. I would write at a lower level.

.NETDJ: But isn't going lower also making things harder for the programmer?
JR: Working at the lower level is not that much more complicated and offers significant benefit. RPC is easier because of familiarity - people know how to do method invocations. Indigo will offer that model to you, but I would strongly discourage its use for all but the simplest of scenarios.

.NETDJ: So how did you get started working on Indigo?
JR: Indigo happened because of a conversation I had with Don Box over dinner. He said, "Wouldn't it be fun to work together? Come over to Indigo!" He helped to make that happen. I was there pretty much to the completion of their M4 milestone.

.NETDJ: Didn't Don Box cofound a training company that competes with Wintellect?
JR: Don and I have been friends for many years, even though our companies compete. We have very similar tastes in music, and have stayed at each other's houses - he even fixed me up on dates before I was married.

.NETDJ: What is your taste in music?
JR: Progressive Rock - King Crimson, Yes, Genesis... and some jazz.

.NETDJ: Cool! I could talk about that all day, but I guess we should stick to .NET. Besides Indigo and the versioning stuff, what else do you think will be cool in Longhorn?
JR: I think WinFS is good - Windows will come with a database now. And this is really nice, because a lot of applications today have built their own database systems - Quicken, Outlook, etc. Now there will be a database engine that is built into the OS, and because the schemas are discoverable, all kinds of tools can be written to give you other views on the information; for instance, the Shell will allow me to do things like search for all checks that have ever been written to my electric company.

.NETDJ: How about Whidbey? What do you like there?
JR: I think the team I am most impressed with in general is the ASP.NET team. (For another perspective on the ASP.NET team, see the .NETDJ interview with Scott Guthrie [.NETDJ, Vol. 1, issue 3, http://sys-con.com/dotnet/article. cfm?id=256].) They seem to listen to their customers better than any other team and focus on solutions that are easy to understand, easy to take advantage of - and the quality of their code and developers seems to be really high. I'm consistently impressed by them.

From the CLR perspective, probably the biggest feature is the performance and robustness. The CLR team has added a bunch of features that customers have screamed for, like serial port access, improvements to the console window, improvements to threading - where I helped suggest a lot of changes that went in.

.NETDJ: Can you tell us about some of those changes?
JR: They've done a lot of cleanup. For example, they are going to add a Semaphore class. Also, there used to be a way to create kernel objects, but no way to open them - which made them a little unusable. In Whidbey, you will be able to open them.

.NETDJ: How is security being dealt with at Microsoft as you work on both Whidbey and Longhorn?
JR: Security comes up in every conversation we ever have. For instance, the "add-in model" - we talk every time about how the host "news up" an add-in without potentially allowing the add-in to inject some malicious code into the host.

I think security is very important. I think that regular people have to get to a point where they can trust their computers without giving it any thought. It is a requirement of the industry.

.NETDJ: Do you think that Microsoft deserves its bad reputation on this point, though?
JR: I think it's the reality of the situation that's valid. If some virus gets out there that brings down some machines, it costs companies millions - if not billions - of dollars. And it causes frustration for the companies and their customers. I think Microsoft had been focusing on adding new features for years and years and years and neglecting the ease of use, and in some cases the security and the robustness. This has to change, and they realize that now.

.NETDJ: Do you think this new focus has anything to do with the state of the IT economy?
JR: I'm sure the economy has slowed .NET adoption rates. Companies are afraid to take anything functional and shift it to something else - especially when it's so difficult to quantify and imagine what the benefits of the switch are going to be in terms of real dollars.

I think the PDC showed people that Microsoft really is behind the managed-code runtime. It is my belief that the PDC message of "Write managed code today" will help.

I also feel that the economy has been recovering some, and companies are now thinking less about staying afloat and more about how to be better than the competition. Now is when they can start looking forward to the true value of .NET!

About Jeffrey Richter
Jeffrey Richter is a cofounder of Wintellect (www.wintellect.com), a training, debugging, and consulting firm dedicated to helping companies build better software, faster. He is the author of several best-selling .NET and Win32 programming books, including Applied Microsoft .NET Framework Programming (Microsoft Press). Jeff is also a contributing editor to MSDN Magazine, where he authors the .NET column. Jeff has been consulting with Microsoft's .NET Framework team since October 1999 and has also been consulting with Microsoft's XML Web Services and Messaging ("Indigo") team since January 2003.