<html>
<body>
At 02:01 PM 10/22/2007, Peter St. John wrote:<br>
<blockquote type=cite class=cite cite="">Jim,<br>
I think we agree on some things (e.g., modular design is not conducive to
Digital Rights Management) and I must defer to your expertise on most of
what's left, but I have to speak up on a couple.<br><br>
<br>
On 10/22/07, <b>Jim Lux</b>
<<a href="mailto:James.P.Lux@jpl.nasa.gov">James.P.Lux@jpl.nasa.gov</a>
> wrote: <br>
<dl>
<dd>...<br>
<dd>I don't know that Windows (at least since NT) isn't actually
already<br>
<dd>a small kernel surrounded by (dare I say "embraced and extended
by") <br>
<dd>a lot of utilities. Sure, they're not command line utilities
with<br>
<dd>cryptic 2 letter names <br><br>
</dl> <br>
It's trivial to overlay aliases on any cryptic two-letter commands you
like. Fortune offered a menu-driven user interface for folks who didn't
like "creat" or "su" in Sys V, in '81 ish.
</blockquote><br><br>
Sure.. but the basic design model of kernel surrounding by cluster of
little utilities is how NT started out. It has, as several have
pointed out, morphed, for performance reasons, among others.<br><br>
<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dl>
<dd>and a man page full of switches. However, an<br>
<dd>awful lot of what people talk about as "Windows" isn't the
kernel (a <br>
<dd>lot of the GDI, for instance, has been separate from the
"kernel",<br>
<dd>per se, since pre WinNT)<br><br>
</dl> <br>
I misread that, at first, as "GUI". I see that MS has the term
"Graphics Device Interface" and I'll allow that is separate
from the "kernel".</blockquote><br>
Was separate, now part, now not. It sort of changes, as graphics
cards change and the "preferred coding model" changes (DirectX,
etc.). <br><br>
The game industry is responsible for a lot of the intertwining in
Windows. With the nice abstracted interfaces, they couldn't get
enough performance, so they did things like pull some graphics ops into
the kernel mode, provide all sorts of "hooks" and
"bypasses" to use the accelerators, etc.<br><br>
Linux doesn't have a huge gamer user base, and there's no single point
that a game publisher and video card mfr could go hammer on to say
"give me speed!", so there's no tendency to try and
shortcircuit the architecture.<br><br>
<br><br>
<blockquote type=cite class=cite cite="">
<dl>
<dd>It does all this now. The question is whether you can get rid of
a<br>
<dd>lot of the other stuff, since at a very fundamental level, windows
<br>
<dd>follows an event driven model, where the events are largely from
user<br>
<dd>interaction. <br><br>
</dl> <br>
Ding. The "event driven model" that is "fundamental"
in MSWin (since W95 or W98) comes from the GUI (but not the GDI) being
integrated with the OS. Which is not conducive to
interoperability.</blockquote><br>
But.. in the original NT (3.x) it was still separated, and you could
actually run NT pretty much headless (I did this for some remote site
applications). I think over the years, it's gotten worse, because
of the demands to dispatch the events more quickly.<br><br>
<br>
<blockquote type=cite class=cite cite=""> <br>
For a long time, the only way to remotely administer a NT box was with a
third party application pushing the pixels of the remote GUI over the
phone line to the troubleshooter's client. To me, using MSW as a server
was ...not efficacious. Programs don't talk to each other using bitmaps
and mouse clicks, unless there is a layer of OCR in between. Imagine
replacing every occurance of "|" is a shellscript with a call
to OCR AI. </blockquote><br>
I used to remotely administer NT 4.0 boxes with essentially only command
line utilities. The BORK was my friend.. it provided lots of
command line equivalents to the GUI management utilities.<br><br>
<br><br>
<br>
<x-sigsep><p></x-sigsep>
Jim</body>
</html>