Interview with Matt Pietrek

We've heard Jeff Prosise from Wintellect and Lon Fisher from Microsoft give us their explanations on what .NET means for us. Now Matt Pietrek - the Win32 guy - gives us his thoughts on .NET, working at NuMega, and the future of software development in general. Matt has been writing the 'Under the Hood' column for MSJ and MSDN for years. He is the author of many great programming books, and is currently doing advanced research at the NuMega Lab of Compuware Corp. Check out his homepage for everything there is to know about Matt.

The floor will be open for a few more questions for Matt. Chances are that Matt's answers will raise even more questions, so get them in early and he will try and answer a few more, time permitting.

What do you think about possibility of porting .NET Framework to non-Windows platform? It is technically possible now? Or there are issues must be solved for this? Do you think we'll see such port say on Linux. What are your predictions about this?

I think that .NET could be ported to other platforms now, if somebody was so inclined. After all, MS says they’re considering submitting part or all of it (I forget the exact details) to a standardization body.

If you look at .NET from the standpoint of its runtime classes, its execution engine, and so forth, you’ll see that there are huge chunks that aren’t tied to any specific CPU and/or OS. A string class is a string class (hopefully!)

Sure, .NET has things that may not be portable, such as classic COM interoperability. Those things might not get ported if somebody other than MS was to provide a .NET implementation. That’s life. Don’t use those features if you’re concerned about writing .NET code that may run on some non-MS implementation in the future. And truthfully, the same issues exist today with Java and Unix. If you start using certain cool features specific to some implementation, portability may bite you.

Will we see .NET on Linux? Truthfully, I don’t know. However, based upon projects such as WINE, it would surprise me if there were some group of people who really want to put the effort into making a .NET implementation run on Linux. If so, more power to them.

I was wondering what your opinion is of the future course of Windows CE in light of .Net. I've taken notice of the fact that Compuware/Numega doesn't seem to have any particular support for Windows CE in its tools. Some products don't make sense if you can't recover the investment you make in them, and CE has been a small market I think, but I was wondering what you think the future holds for CE as a target platform. Will it just be a host for the "compact" version of the CLR whenever that comes out?

Hmm… good question. Knowing Microsoft, they’ll probably come out (or help hardware vendors) produce devices that are 100% .NET from the ground up. At the same time, they’ll probably keep pushing CE for at least awhile. Thinking of it as having two horses in the race. If CE eventually becomes a big player, then they’d be stupid to drop it. I can also see a case for a future version of CE hosting a compact CLR implementation. Who knows?

As for Compuware/NuMega support of CE, I know there is/was support for CE in BoundsChecker. Granted, it probably isn’t everything that CE gearheads could ever want, but at least some effort was put into it. I’m sure it’s not a surprise that market demands and market share drive where a company like Compuware/NuMega put their efforts.

I heard that .NET supports COM and Windows API.. And as I think about C# and CLR as I have read its document,(.NET development environment) it could also support platform independence... Platform Independence is very important issue and C# aims for it . And other things in .NET also look like aiming Platform Independence...(XML, SOAP etc...)

Then how can you explain about two contradictory features of .NET framework..?? Platform Independence versus COM, Windows API support...

I don’t see much of a contradiction. C# is a language. You can write portable code in a language, and you can write platform specific code in the same language. This has been the story with the C language for 30 years. There’s nothing in the C# language definitions that I’ve seen in C# that ties it to Windows. Yet, you can choose to use and/or write C# classes that rely on features of Windows, or on the underlying hardware platform.

The same basic story goes for the CLR. I can absolutely see it being hosted someday without Windows underneath it. Yet it has “escape hatches” that let you use Windows, COM, and pretty much whatever else you need. Microsoft was smart to put them in there, because otherwise they’d have a huge effort to get people to abandon their existing code. Heck, Microsoft themselves has this problem. Can you see all of the Office products, and all of the Back Office products being hosted entirely on .NET within the next year? Without using anything like Pinvoke and COM interop?

The short answer: You have to be smart about what features you use, if you want portability. This concept certainly isn’t new with .NET.

What I'd love to hear about is the early days when NuMega was a small shop and you and the team were scrambling to get the next version out. I know that this isn't really a question, but I've been using BoundsChecker for ever, and I'd love to hear you recount some interesting stories about how everything got started. When did you join NuMega? Where you a founder? How did your role there change over time. I have this impression that you started off writing all the code, and then somewhere along the line moved into more of a pure research role.

Ah… excellent questions! Let me answer them somewhat out of order.

I joined NuMega in 1993, after being laid off from Borland. I certainly was not one of the founders, but was well within the first 10 people.

When I joined, there were the two founders, two programmers (one of them off-site), an office manager, and a sales/marketing guy. A few more great people joined shortly after I did, but it was still pretty small for the first two years.

The two founders, Jim and Frank, are great guys. I still see them semi-regularly, and live in the same small town as they do. I wasn’t even formally interviewed. I just talked to them on the phone on two separate occasions, with most of conversation being about what I’d do to improve SoftIce. I was totally shocked when they called with a job offer. I certainly felt under qualified.

The great thing about the early days of NuMega was that it was a very family oriented company. It seemed that all the families knew each other, and we were always doing things together. We didn’t work horrible hours either, like most startups do these days. We were all pretty good at what we did, and we worked pretty normal hours (say, 9-5). If you have good products, and a high barrier to entry, you don’t have the same pressures that it seems everybody’s under today. As I recall, we didn’t even bother to track vacation time. Everybody just intrinsically knew that as long as the job got done, having a lot of formal procedures just got in the way.

When I joined, the primary products were SoftIce for DOS & Windows, and BoundsChecker for DOS. I jumped right into the middle of the first BoundsChecker for Windows release (you have to recall, in 1993, this would have been for 16 bit Windows 3.1) My first big job was to write the parameter validation system. The team was basically Frank, the SoftIce for Windows guru, and myself. You wouldn’t believe how much of the code was stolen from the DOS products.

After BoundsChecker 1.0 was released, I took over, and was the “lead” for BoundsChecker 2.0. Saying “lead” is a bit of a stretch, because it was basically myself and the off-site programmer. The SoftIce/W guy went back to his primary role.

One slightly humorous story is tech support. Back then, if somebody called for support on the DOS products, they talked to one of the founders. If somebody called for support for the Windows products, they talked to SoftIce for Windows guy or myself. Later we got dedicated support people, but it was great getting first hand feedback from the customers on what you did right or wrong.

When it came time to start the Win32 version, I did all the original core work, and brought Frank in later to help with his symbol table code. On the UI side, the off-site guy did a ton of work to convert the 16 bit UI code to 32 bits. Over time, many more great people (including John Robbins) were hired on, and had the misfortune of working with my code J

I’ve pretty much stayed with BoundsChecker throughout my career at NuMega. Starting with the 16 bit code, through the 32 bit code, and more recently, with my 64 bit work. Luckily, I had 5 years to learn from my previous mistakes, so most of my recent work has been on a revamped “engine” for BoundsChecker. It’s this engine that will be used in future 32 and 64 bit versions of BoundsChecker. This same engine also includes .NET support. It’s great being able to start from a clean sheet of paper!

Besides my BoundsChecker related work, I’ve also moved into other areas, including research. The engine I just mentioned started out as a research project. Other research areas might include technology assessments, competitive analysis, and pretty much any area where I can provide reasonable value to the company. I still think of myself as a coder at heart, though.

How do you manage to stay ahead of the curve?

Can a regular programmer guy like myself that works most of the day at work, and has a full home-life, with a wife, and a commute to work, and a yard to mow, stay ahead of the curve like you do?

It’s funny that you’d think I’m ahead of the curve, since I feel perpetually behind it. I try to have a “normal” family life with my wife, 2 year old, and house. To try to balance my life, I don’t work 14 hour days at work, and try to stay off the computer when I’m at home. Sure, sometimes I have to focus intently at home (when writing a column for instance), but I certainly don’t live in front of the computer like I used to.

So… I have to pick my battles carefully. I realize that there are just some areas that I won’t have the time to learn. I know my strengths, and try to keep myself up to speed in at least those areas. I also have the advantage of being an “architect” at NuMega. Because I’m supposed to be keeping up with what’s coming down the pike in the future, I can usually leverage that knowledge to help guide me in my outside activities such as my columns.

What kind of topics do you think you will cover in the future if .NET takes off. Will you (un)cover IL and the JIT, for example? How important do you feel Win32 will be in the future? Will there always be a place for those who know the Win32 API like the back of their hand?

Good questions! I’m already basically up on the underpinnings of .NET, but still have a lot to learn. A lot of great info (such as the IL) is already documented. You just have to dig a little to find what you’re after. There’s just so much to try to understand at once!

A lot of what I do is just taking existing documentation, and putting my own spin on things. Unlike somebody who’s trying to write documentation for an entire API, I have the luxury of picking an area to focus on. I can choose what I feel the important points are, and focus on making those points as clear as possible. So, yes, I do figure I’ll be covering JITting and IL, but it won’t be till I know enough to talk intelligently about them. I also don’t want to jump the gun, and be writing about things that are in flux, and that many people may just not be ready for.

As for the Win32 API, I think it will continue to be important. It’s not so much the API, as it is the knowledge of all the layers in a system, and how they integrate. I’ve said this before, but it bears repeating again: Software is written in layers. The more you understand about the layers, the more valuable you’ll be, both as a coder, and when it comes time to debug. I don’t consider myself a particularly great coder. What I do know is how most of the system fits together.