Re: Philosophical Rant [was Re: Writing Drivers in Ja va]

What, nostalgic? VMS still is available, still runs.
Whether it is more or less complex than NT is also fairly unclear.

Now, it is true that CPQ writes most of the drivers. If you aren’t in
a position to get hardware vendors to do that, that’s all you can do.
The drivers do support most devices out there, though, although the
number of such that have been formally qualified is quite small. Much of
the difficulty comes from the fact that VMS supports a quite complex I/O
model which most devices are unable to use in full generality. Thus unless
the SCSI devices really use tagged queueing and multi-initator code *right*
VMS won’t in general allow their use, save on single busses and at times
with diminished speed (because unless the device can handle tags right,
the idea is not to use tagged queueing at all, lest rare error conditions
cause data corruption).

Ask some internals people who are familiar with both systems and you will
find out that the two systems are remarkably similar at kernel level.
Of course, VMS has been a 64 bit system for some time now, on alpha (and
soon on IA64 and possibly Hammer after…)…and has gone through the
pain of that conversion. It offers a counterexample to claims that modern
OSs cannot be built secure and maintained secure.

It is true that driver and device qual has been highly expensive in lots of
cases. That doesn’t come from simplicity of the OS; it comes from the
system placing extreme demands on its I/O hardware. Yes, this has made
the cycle longer than NT folks are used to, but it has also turned up
numerous firmware bugs and indirectly benefitted everyone in the industry
as these bugs got fixed eventually in the vendor’s “generic” firmware too.
The larger system players (DEC, Sun, IBM, etc.) all do device qual and
their work all feeds into this standard firmware. Meanwhile those wanting
to use generic off the shelf stuff (e.g., I have an Alcita ideplex with
several big but generic IDE drives hanging off one alpha that runs VMS or
Linux. VMS is quite happy accessing these.) can do so. The situation is then
much the same for VMS and Linux: you rely on other users to help with
where things misbehave.

The VMS i/o system is btw rather highly tuned and causes problems during
development too; it has had a history for years of being the one that makes
adapter hardware fail. Some of its port drivers have no-op padding here and
there as evidence of where this happened.

If I should want to run RSX11M+ again, I will do so in emulation :wink: since
16 bit system is difficult to get large code in and I have no wish to go
to writing 8-cotree overlaid programs to get everything to fit on such a

As for protocol conformance tests, the DECnet protocols have been published
and freely available since about 1976. You’d need to do formal tests to get
formal DEC support back when, but there were a number of implementations
evidently did not do that kind of thing. OTOH if the volunteer labor of the
Samba group got costed out at a market rate, would it surprise anyone if the
costs were up in 7 figure territory? That testing has been running for years
as new targets and functions are put in.

A number of us have years ago also written VMS drivers and just put them out
people to use, freely. They were never qual’d formally. Some of them worked
and some are still in some use. Occasionally some of the older ones even get
a few fixes and updates. I think someone’s DECtape driver got patched two or
three years ago, for example, though the number of loose TU56 drives left in
the world is getting mighty small.

Anyhow, I think that claiming the best that can be hoped for is 80% correct
drivers is a counsel of despair and darn well better not be true. If getting
drivers (or OSs) right takes time and a culture that cares about detail,
that is what should be needed to be in the game for money. If you want to
do a quick and dirty driver, you have business advertising it that way so
that at least people trying it know what to expect. If you want to take
your several hundred dollars for an industrial strength OS, well, there are
Windows versions that cost that much. So does VMS…

If you want something less costly, there are a number of Unix or Linux
though you need then to pay separately for support.

-----Original Message-----
From: Peter Viscarola []
Sent: Monday, April 29, 2002 1:14 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Philosophical Rant [was Re: Writing Drivers in

“Gregory G. Dyess” wrote in message news:xxxxx@ntdev…
> VMS, despite its reputation as a CPU and memory hog, ran circles around NT
> in terms of responsiveness and it NEVER crashed on the exact same
> [snip]
> Everyone should start buying only hardware that has successfully passed
> MS quality tests.

Let’s not wax too nostalgic about VMS, OK? I mean, RSX-11M crashed less
than VMS. Maybe we should go back to using RSX-11M Plus?

VMS is a simpler operating system than NT. It was pretty cool in the 1970’s
when it was designed but, like RSX before it, it’s features do not allow it
to compete with NT.

In addition, VMS supports a tiny subset of peripheral devices compared to
NT. Further, Compaq nee Digital writes practically all the drivers.

And, of course, the world has changed very substantially from the days when
vendors could command huge sums for proprietary workstations. While much of
that money went to profit, and was subsequently invested in expensive suits
for the CEO, lots of that money want to “quality assurance.” The investment
in terms of money and time for qualifying a driver for NT the way we
qualified drivers for VMS would literally bankrupt most IHVs and make them
miss their market window. For example, ten years ago, it cost a couple of
hundred thousand dollars a year (1992 dollars) just to do the protocol
conformance testing for a DECnet VMS release. A four month testing period
was not at all unusual. This doesn’t include unit test, QA, and the rest.
And this was all using Digital-developed hardware.

In terms of the “MS quality tests” (I assume you mean tests for the Windows
Logo, right?)… do you really think they’re stringent enough to ensure
drivers don’t crash the system? I have personally loaded Logo’ed drivers on
the checked build of the system, and seen such drivers fail to even get
through the boot processes without assert-ing.

Nah. Times have changed. 80% correct drivers are all that we can hope for.
The O/S has to be resilient to Stupid Driver Writers. To coin a phrase:
“There will be poor driver writers always, pathetically struggling” to ship
their code. Why not just make it so that the consequence of their stupidity
doesn’t cause the REST of us to look bad.


You are currently subscribed to ntdev as:
To unsubscribe send a blank email to %%email.unsub%%

This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you