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.
