MattPietrek访谈，谈他对.NET的看法及Numega工作情况（英文）

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 oclearcase/" target="_blank" >ccasions, 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.