15 Mar
1999
15 Mar
'99
9:13 a.m.
At 08:21 PM 3/15/99 -0000, you wrote:
OK, but isn't the general end result of using the Mach kernel, a UNIX system?
I believe it is the fault of the kernel, for without a kernel with a built
in distributed lock manager, you can't implement true clustering. You get
something like IBM AIX with HACMP which is a "...lventy-seven layers of crap
on top of it." to simulate a "cluster" in a UNIX environment, except you
have a system disk on each CPU which must be synchronized with every other
system disk.
Dean Billing <drbilling(a)ucdavis.edu> wrote:
This doesn't sound right to me. I guess there are so many legends about the
NT design team that we would have to name each person and understand their
contribution. Very early on, when NT betas were being distributed free, and
I got one of them, the lore going around that NT core was canabalized from
the new Mach kernel. Later, I heard that one of the VMS gurus was hired by
MS. I find it very difficult to believe that they would hire a DEC VMS guru
before NT was cast in iron and then "...let him design it." If NT was
based, even loosely, on the Mach kernel, why would they hire a VMS guru?
Why not a Mach kernel guru?
After M-Squish designed NT, they hired one of the
VMS gurus from DEC
No, they weren't *that* stupid. They hired him at let him design it.
The actual operating system deep in the bowels of Windows NT isn't so
bad. But they have lventy-seven layers of crap on top of it
to keep
you from seing anything that might be simple and elegant.
Every operating system today has "...lventy-seven layers of crap on top of
it..." including UNIX with an X client and then applications or AIX with
SMIT on top of an X client or even VMS.
...
No,
it isn't. The underlying operating system is nothing like Unix, and
only vaguely like Mach (which are themselves two entirely different things). However, as a "normal" Windows programmer
(for the Win32 subsystem), you
can't even get to the operating system. You can only call the Win32
layer.
VMS protects itself in the same way. If you are writing well behaved
applications, you can only make VMS system calls, even if you are writing
drivers.
Therefore,
they have not been able to implement a true clustering system
and IMHO because the DEC software engineers came late to the game, they
were unable to design the basic reliability into the operating system
software interfaces.
Again, that's not the fault of the kernel. The kernel is pretty good. The
problem is the leventy-seven layers of crap above it. And the I/O architecture is even OK, but unfortunately
you end up with
hundreds of device drivers written by bozos running at ring zero, so
naturally the system isn't as robust as it should be. DEC was in complete
control of the VAX, so most VMS sites didn't run any drivers that were
written by clueless morons.
This is surely not the case of sites that used VAXen for process control,
which was a primary feature of VMS in the early days; VMS being an extension
of RSX-11. DEC also has documentation to write drivers properly, as I would
assume MicroSoft does for NT. I doubt whether all of the problems with NT
are bad drivers written by our local " ... clueless morons." ... since we
don't do that, and our NT systems still crash frequently.
...
Um, what do you mean by "doing development work on them"?
I mean doing any kind of application software development work
simultaneously with using it for a server, which is what we do every day on
our VAXcluster and IBM RS/6000 UNIX servers.
If you want a file server to be as robust as possible,
it should be used for
nothing but serving files. That was true even in the old days.
That would be news to any large VMS or IBM mainframe shop.
Nowdays people load all kinds of crap on their NT file
server. It's no
wonder the things fall over every few days.
We have loaded all kinds of applications and third party software on our
VAXcluster, from Interleaf, Sapiens, Oracle, MEC, and others and it has
never crashed except during hardware failures which have ocurred every few
years.
Of course, if NT didn't have the problems discussed
above, it should have
been able to go weeks or months without falling over.
Agreed.
-- Dean
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dean Billing Phone: 530-752-5956
UC Davis FAX: 530-752-6363
IT-CR EMAIL: drbilling(a)ucdavis.edu
One Shields Way
Davis, CA 95616
Another drawback to NT is that many software
upgrades and application installation/deinstallations require rebooting,
something unheard of with VMS.
This problem is definitely a matter of poor design. I'm pretty sure this
one is also not the fault of the kernel, but of the leventy-seven layers
of crap above it. The programmers were too lazy and/or in too much of a
hurry to bother to figure out how to make changes without rebooting. 
15 Mar
15 Mar
9:46 a.m.
This doesn't sound right to me. I guess there are
so many legends about the
NT design team that we would have to name each person and understand their
contribution. Very early on, when NT betas were being distributed free, and
I got one of them, the lore going around that NT core was canabalized from
the new Mach kernel. Later, I heard that one of the VMS gurus was hired by
MS. I find it very difficult to believe that they would hire a DEC VMS guru
before NT was cast in iron and then "...let him design it." If NT was
based, even loosely, on the Mach kernel, why would they hire a VMS guru?
Why not a Mach kernel guru?
Because it *isn't* based on Mach. Which part of that is hard to understand?
The historical record of this is fairly well documented.
Every operating system today has "...lventy-seven
layers of crap on top of
it..." including UNIX with an X client and then applications or AIX with
SMIT on top of an X client or even VMS.
Most OSes don't have nearly as many layers of crap as NT. I am intimately
familiar with the operation of most of the software on my Linux box, including
the X server and several of the clients, and there just aren't that many
layers.
But at a former job I had to do porting of ATM stuff to NT and 95, and there
are layers upon layers of crap, for no especially good reason. It's just a
result of Microsoft's "Mongolian hordes" programming technique. It was
just
about enough to make me sick.
OK, but isn't the general end result of using the
Mach kernel, a UNIX system?
No.
There are some "UNIX servers" that can be run on top of Mach, but
Mach is not UNIX.
VMS protects itself in the same way. If you are
writing well behaved
applications, you can only make VMS system calls, even if you are writing
drivers.
Yes, but in Win32, you *can't* make OS calls. You can only make Win32
calls. It's an extra layer of mostly useless crap.
I believe it is the fault of the kernel, for without a
kernel with a built
in distributed lock manager, you can't implement true clustering.
IIRC, the NT kernel *has* a built-in distributed lock manager. If not, it
would be easy to add it. The NT kernel is actually small, simple, and
almost elegant. But as I've explained, that's the part that developers
never see. Even driver writers only get to see part of it, but have to
deal with disgusting crap like NDIS for other services.
If you want a
file server to be as robust as possible, it should be used for
nothing but serving files. That was true even in the old days.
That would be news to any large VMS or IBM mainframe shop. 
10:57 a.m.
Eric has the story straight here (plus or minus a couple minor details).
Around Oct. 1991, Rick Rashid, the principle investigator of the Mach
project, left Carnegie Mellon to establish the newly established Microsoft
Research group. I was a graduate student of Rick's and a member of the Mach
project since 1986. In June 1992 I left CMU to follow Rick. When I got to
Microsoft, NT was already in usable beta form (you could actually run it on
your machine and get work done). One of the first things we did was to get
to know the internals of NT. Believe me, in neither code nor philosophy is
NT based on Mach. NT's VM system is completely different: it sort of treats
everything like an x86, whereas Mach has a "pmap" layer which provides a
higher level of abstraction than just emulating the x86 MMU. NT is also
handle-based, whereas Mach is port-based. In Mach, all operations on system
objects (threads, tasks[=processes], memory, etc.) are performing by sending
a message to that object -- thus it doesn't matter if the object is local
(on the same machine) or remote. In NT, some operations are remoted for you
(e.g. registry operations) but most aren't.
The resemblance between NT and VMS, on the other hand, is quite strong,
especially when it came to I/O, with IRPs and APCs mapping onto VMS's IRPs
and AST's.
A good book to read about the development of NT, and its relationship to
Mach and MSR, is "Show-Stopper! The Breakneck Race to Create Windows NT..."
by Zachary, G. Pascal. If you search on www.abebooks.com for
title="showstopper", you will find about 20 copies available.
Yes, but in Win32, you *can't* make OS calls. You
can only make Win32
calls. It's an extra layer of mostly useless crap.
Actually, a Win32 process can call NT system calls directly. It's just not
encouraged :-)
- Joe
12:19 p.m.
Actually, a Win32 process can call NT system calls
directly. It's just not
encouraged :-)
I stand corrected.
Has this always been true?
I once asked MS tech support, and was told that NT system calls couldn't
be made from a Win32 application, because the Win32 subsystem would trap
them and not pass them to the kernel.
Third parties have figured out how to write native NT programs (which are
effectively peers to the subsystems). However, in the general case there's
not much reason to do so. Although it might be fun to write a replacement
for the POSIX subsystem that was actually sufficiently full-featured to
be useful (vs. the current implementation which was deliberately made to
be minimally conformant for the sole purpose of making NT POSIX-compliant
for government procurement purposes).
12:59 p.m.
> Actually, a Win32 process can call NT system
calls directly. It's just
not
encouraged :-)
I stand corrected.
Has this always been true? I once asked MS tech support, and was told that NT
system calls couldn't
be made from a Win32 application, because the Win32 subsystem would trap
them and not pass them to the kernel.
Nope, this is wrong.
- Joe
9415
days inactive
9415
days old
4 comments
3 participants
participants (3)
-
drbilling＠ucdavis.edu -
eric＠brouhaha.com -
joe＠barrera.org