My take on the Microsoft booth here at LinuxWorld2002


OK. So in an attempt to not be childish, I went and spent a happy hour
chatting with the guys at the MS booth yesterday.
Brief conclusion? They don't know what the hell they're doing.

They're here advertising two main products: The bastard son of Interix
[if you remember that] and embedded "stuff"

The basic premise of Interix's bastard son ["Unix interoperability",
as they're calling it] is that it provides a unix-alike environment in
XP, and that it can provide and/or recieve unix-alike services.

They've picked Korn Shell to be their baby. So they've produced what is
in fact a port. Interix is running at a level closer to the kernel than
your average app, which is their selling point over CygWin - the Interix
programs have access to commands like fork(), exec() and friends,
which makes porting stuff a load easier, and I heard mention of a word
like "reliable". If it blows up, I don't wanna be there to see it.

Note that what I mean here is that the XP, right down near the kernel,
provides functions like fork() and exec() - something CygWin really does
only emulate. For their own private reasons, MS choose not to make those
functions available at higher levels [ie, to normal applications]

Fine. But the guy could at no point tell me why running a weird port of
KSH is actually any better than running genuine KSH with CygWin dlls,
other than "we're not emulating, so we're better". Personally, I'm more
inclined to trust CygWin...

Also, I asked about running X things, so he demonstrated how amazing
X apps will run - except he only fessed up when I said "I recognise
exceed. That looks like exceed." They've not actually done any work on
X. Hmmmmmm.

The "services" they provide essentially boil down to "we can serve NIS
and NFS out of an Active Directory server". Which is, to be honest,
exactly what people want. It's neat, but I'm having trouble imagining
the market; who is running an NT server, but then requiring NFS out to
the clients?


And then there's the embedded stuff. Which is slightly more "my thing".

They haven't a clue.

The guy starts off by showing me an app, it runs in a DOS window really
quickly, and it produces what is basically an XML dump of what you get
when you right-click "My Computer", the properties.

Fine. The idea of this is that it's a diagnostic tool to tell you what
modules you want to put into your embedded kernel. I see two main problems:
1) It was running in windows. When questioned, he said it also ran in
DOS6. "OK", say I, "How the hell do you make it run on an embedded device
in order to get the information for the device? I'm pretty certain a
fully-fledged XP install won't run, and there's no way in hell you can
bootstrap DOS on half these things...", which neatly takes me onto my
second point;
2) It only runs on x86. I don't know how much you know, but x86 pretty
much sucks for embedded work. It's got huge power consumption, and it
gets seriously hot. Neither of which are good things in, say, a pacemaker.

Most importantly, I can bootstrap Linux on pretty much anything you can
give me. And with Linux's /proc filing system, I can put together a simple
shell script in about 5 mins that gives me just as much information as
this amazing offering from MS does. The guy's response to that was along
the lines of "Well, it's been a while since I looked at Linux, and when I
last looked, /proc wasn't as good as this". Take from that what you will.

So he moved me onto the other couple things he was advertising, one for
building x86 systems, and one for building others [eg, MIPS, StrongARM]

Something I should quickly say; he was at no point making it clear what
OS we were looking at. CE or XP?

So. The first tool. Having got your XML data, you go through and drag
modules from one side of the screen to the other, then ask it to "do
stuff". It checks things like dependencies, etc, then builds an image
of sorts that you blow into a device/CF/whatever. Note that at this point,
it's not actually compiling anything. - We're still on x86.
Just the kernel, plus enough .dlls to drive all the necessary
hardware. Clocking in at 1 to 2 meg, possibly more depending on the
device.

Next [the guy's /piece de resistance/], the StrongARM/MIPS/whatever
development kit:
First impression: the user-interface is backwards. These two flagship
embedded development kits have exactly opposite UIs. Take from that what
you will, but I swear MS need to take a step back and read ANY of the
simple UI 101s out there. Consistency - Good - Moving Shit about - Bad.

So he shows me this toy that takes the modules you've selected for your
ARM-based toy [no diagnostic tool for you, man] and actually compiles
them for your architecture.
Yes. There is source for this stuff available. And note:
The license is a single sheet of A4 saying "You can look, but touch
and we cut your knackers off". With implied "you look, we screw you for
derivative works for the rest of time".

No, I neglected to look.

Again, this produces something on the order of 1-2M.

Just by way of comparison, you're looking at Linux kernels with similar
numbers of drivers, etc, at probably half the size of the equivalent
embedded windows one. And is designed to run on any hardware.

In a word, I think Microsoft have simply seen that there's an embedded
market out there that they're not getting a piece of, and have just
forged ahead without thinking about what they're doing or where they're
trying to get to.

.02

Gary (-;