|
|
Dave Cutler, Prism, DEC, Microsoft, etc.
Since any idiot can put up a web page these days, you know it all
can't be true. So imagine my surprise when I bumped into this:
http://radsoft.net/rants/20040831,00.shtml
<quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
C. As soon as he'd finished VMS he suggested the rewrite. He was
turned down flat. Several years later he found himself in Seattle and
essentially was doing the rewrite in C when word came DEC were tired
of him.</quote>
This article contains lots of other (possibly) questionable facts, but
think about the statement above "rewrite VMS in C". If this had
happened, we would have VMS or OpenVMS on any platform including
x86-64
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/6/2009 11:53:18 AM |
|
Neil Rieck wrote:
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> C. As soon as he'd finished VMS he suggested the rewrite. He was
> turned down flat. Several years later he found himself in Seattle and
> essentially was doing the rewrite in C when word came DEC were tired
> of him.</quote>
>
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
>
> NSR
Not ANY platform! There are architectural requirements; things like
number and sizes of registers, processor modes, etc.
Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
like command language, and VMS-like system services. It was NOT VMS.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/6/2009 12:27:51 PM
|
|
In article <78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com>,
Neil Rieck <n.rieck@sympatico.ca> writes:
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
And:
"Dave took his engineers and his new operating system called 'Prism' cross town
to the Redmond campus."
How that?
Presumably everything he did at M$ would be IP of DEC,
so he couldn't just "take it with him", unless DEC permitted it.
AFAIK he left as a "disgruntled employee" so DEC would have had
even less reason to give it away.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/6/2009 12:43:13 PM
|
|
In article <78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com>,
Neil Rieck <n.rieck@sympatico.ca> writes:
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> C. As soon as he'd finished VMS he suggested the rewrite. He was
> turned down flat. Several years later he found himself in Seattle and
> essentially was doing the rewrite in C when word came DEC were tired
> of him.</quote>
>
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
That's funny. I have always wanted to see a project started to take
FreeBSD and rewrite it in Pascal or even better, Ada. :-)
Oh well, I suppose that could be another of those retirement projects
I keep piling up.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/6/2009 12:46:03 PM
|
|
On Nov 6, 6:53=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> C. As soon as he'd finished VMS he suggested the rewrite. He was
> turned down flat. Several years later he found himself in Seattle and
> essentially was doing the rewrite in C when word came DEC were tired
> of him.</quote>
>
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
>
> NSR
Neil,
"Written in C" and "architecture independent" are two very different
things. With all due respect, I will take exception to the "on any
platform" observation in the original post.
The are hardware dependencies for each of the architectures, and there
are hardware presumptions that all three current architectures have in
common. Some of the most important were noted in my July 2001
"Thoughts on the Alpha->Itanium Announcement" (see http://www.rlgsc.com/alp=
haitanium.html).
In any event, the use of MACRO-32 is not the impediment. It has been
proven twice (e.g., ALPHA, Itanium) that a compiler can be
straightforwardly constructed to convert MACRO-32 in to the native
binary needed. In fact, having worked on portable code generators
during my university research time, I could observe that one could
write a MACRO-32 -> C translator, which would then "solve" the initial
problem of getting onto a new architecture. Admittedly, such a
bootstrapping approach has efficiency issues, but they can be dealt
with.
The more significant problems are the details of the hardware
presumptions I mentioned in my July 2001 comments, and the
architecture specific code for any new architecture. If it is
technically doable, it remains a significant financial item.
Admittedly, I have not done an indepth review of X86-64 in these
respects, my comments are meant in the general sense.
- Bob Gezelter, http://www.rlgsc.com
|
|
0
|
|
|
|
Reply
|
gezelter (537)
|
11/6/2009 1:11:38 PM
|
|
In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Neil Rieck wrote:
>> Since any idiot can put up a web page these days, you know it all
>> can't be true. So imagine my surprise when I bumped into this:
>>
>> http://radsoft.net/rants/20040831,00.shtml
>>
>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>> turned down flat. Several years later he found himself in Seattle and
>> essentially was doing the rewrite in C when word came DEC were tired
>> of him.</quote>
>>
>> This article contains lots of other (possibly) questionable facts, but
>> think about the statement above "rewrite VMS in C". If this had
>> happened, we would have VMS or OpenVMS on any platform including
>> x86-64
>>
>> NSR
>
>Not ANY platform! There are architectural requirements; things like
>number and sizes of registers, processor modes, etc.
>
>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>like command language, and VMS-like system services. It was NOT VMS.
Wendin Associate. I had a copy too when I was working at Lakehurst
NAEC. It was considered a toy and little more.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/6/2009 1:45:24 PM
|
|
>-----Original Message-----
>From: info-vax-bounces@rbnsn.com [mailto:info-vax-bounces@rbnsn.com] On Be=
half Of Michael Kraemer
>Sent: Friday, November 06, 2009 7:43 AM
>To: info-vax@rbnsn.com
>Subject: Re: [Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.
>In article <78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.c=
om>,
>Neil Rieck <n.rieck@sympatico.ca> writes:
>> Since any idiot can put up a web page these days, you know it all
>> can't be true. So imagine my surprise when I bumped into this:
>>
>> http://radsoft.net/rants/20040831,00.shtml
>>
>And:
>"Dave took his engineers and his new operating system called 'Prism' cross=
town
>to the Redmond campus."
>How that?
>Presumably everything he did at M$ would be IP of DEC,
>so he couldn't just "take it with him", unless DEC permitted it.
>AFAIK he left as a "disgruntled employee" so DEC would have had
>even less reason to give it away.
Speaking as an old personal friend of one of his top team members I think I=
can say that the description is reasonably accurate.
Dan
|
|
0
|
|
|
|
Reply
|
daniel.allen (3)
|
11/6/2009 1:57:33 PM
|
|
You will need to forgive me this week. Last Thursday (Oct 29) I
presented H1N1 symptoms and have been banished to my house until
Monday (Nov-9). I was totally out of commission for 2-days and it took
another 3-days before I stopped presenting symptoms. I'm still
sleeping way too long each night.
During this time, some UNIX heads were sending me questions regarding
"Dave Cutler, Prism, Emerald, Mica" on my OpenVMS page so I decided to
continue my research to find out what really happened. That's when I
stumbled onto these two articles:
http://www.nationmaster.com/encyclopedia/DEC-PRISM (read to last
paragraph talking about Olsen and Alpha)
-AND-
http://windowsitpro.com/Articles/Print.cfm?ArticleID=7153 (read whole
article as well as readers' comments posted to the end)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/6/2009 2:06:33 PM
|
|
VAXman- @SendSpamHere.ORG wrote:
> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Neil Rieck wrote:
>>> Since any idiot can put up a web page these days, you know it all
>>> can't be true. So imagine my surprise when I bumped into this:
>>>
>>> http://radsoft.net/rants/20040831,00.shtml
>>>
>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>> turned down flat. Several years later he found himself in Seattle and
>>> essentially was doing the rewrite in C when word came DEC were tired
>>> of him.</quote>
>>>
>>> This article contains lots of other (possibly) questionable facts, but
>>> think about the statement above "rewrite VMS in C". If this had
>>> happened, we would have VMS or OpenVMS on any platform including
>>> x86-64
>>>
>>> NSR
>> Not ANY platform! There are architectural requirements; things like
>> number and sizes of registers, processor modes, etc.
>>
>> Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>> like command language, and VMS-like system services. It was NOT VMS.
>
> Wendin Associate. I had a copy too when I was working at Lakehurst
> NAEC. It was considered a toy and little more.
>
It might have become more than a toy but it would not build on the then
current version of Microsoft C.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/6/2009 2:10:06 PM
|
|
On Nov 6, 8:11=A0am, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Nov 6, 6:53=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
>
[...snip...]
>
> Neil,
>
> "Written in C" and "architecture independent" are two very different
> things. With all due respect, I will take exception to the "on any
> platform" observation in the original post.
>
Bob,
I couldn't agree more. But whenever a new hardware platform appears,
it is always *nix/c that gets there first because, as we all know, C
is not much more than a portable assembler. Is the first port any
good? Nope, it is usually just a very first step. Regarding your
comments on MACRO32, I guess I was thinking more of other weirdness
like BLISS.
I wonder what Cutler was think about.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/6/2009 2:15:09 PM
|
|
OK so this is the first time I've ever seen this stuff. It contains
lots of original PDFs published by DECwest Engineering in the late
1980's
http://bitsavers.org/pdf/dec/prism/
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/6/2009 2:26:46 PM
|
|
Neil Rieck wrote:
> On Nov 6, 8:11 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>> On Nov 6, 6:53 am, Neil Rieck <n.ri...@sympatico.ca> wrote:
>>
> [...snip...]
>> Neil,
>>
>> "Written in C" and "architecture independent" are two very different
>> things. With all due respect, I will take exception to the "on any
>> platform" observation in the original post.
>>
> Bob,
>
> I couldn't agree more. But whenever a new hardware platform appears,
> it is always *nix/c that gets there first because, as we all know, C
> is not much more than a portable assembler. Is the first port any
> good? Nope, it is usually just a very first step. Regarding your
> comments on MACRO32, I guess I was thinking more of other weirdness
> like BLISS.
I'm sure I'll get someone flaming me for this, but there is nothing
wrong with portability in BLISS (BLISS-10 and BLISS-11, yes). Common
BLISS was used to write a number of software packages including
DECnet, RUNOFF and others (including compilers) that were portable
(or certain portions anyway) across PDP-10, VAX and PDP-11. Not to
mention the fact that BLISS was the original implementation language
for the GEM compiler backend. That has been ported natively to IA-32,
IA-64, Alpha and MIPS as well as cross-compiling off of the VAX.
As for the statement that C is little more than a portable
assembler...well, that like a whole bunch of other stuff gets
flung around on a regular basis. BLISS is much more like a portable
assembler than C. Especially when it comes to type (mis-)matching.
Almost all languages have their place. It is the coders and their
standards that make the big difference in portable code.
>
> I wonder what Cutler was think about.
>
Who knows? Although you can point your browser to the link below
for a whole bunch of information on MICA as well as some internal
mail messages regarding the cancellation of PRISM, Mica and Ozix.
http://www.bitsavers.org/pdf/dec/prism/
Let's also not forget Titan, SAFE, H-32 and all the other designs
that, from what I understand, were eventually consolidated into
the PRISM project.
Tim.
|
|
0
|
|
|
|
Reply
|
tim.sneddon (59)
|
11/6/2009 4:10:09 PM
|
|
Bob Gezelter wrote:
> In any event, the use of MACRO-32 is not the impediment. It has been
> proven twice (e.g., ALPHA, Itanium) that a compiler can be
> straightforwardly constructed to convert MACRO-32 in to the native
I think that might be a bit of a stretch of the meaning of
straightforward.
> binary needed. In fact, having worked on portable code generators
> during my university research time, I could observe that one could
Portable code generators almost always go:
High-Level-Language --> Intermediate-Language --> Machine-Code
They rarely go back the other way.
> write a MACRO-32 -> C translator, which would then "solve" the initial
> problem of getting onto a new architecture. Admittedly, such a
> bootstrapping approach has efficiency issues, but they can be dealt
> with.
I think that might be a pretty *huge* generalisation there. Source
to source translating is not generally a big task (depending on the
languages), but certainly going from machine level to a high level
language is. I think there would be much more than some "efficiency
issues". There especially needs to be careful consideration of the
target architecture's calling standard and how it compares to the
source. As I am sure you are aware writing code in assembly allows
the coder to do all sorts of neat "tricks" that just cannot be
replicated by a high level language.
Actually, a recent post by VAXman is the perfect example. It sites
a piece of code that passes information through registers R1-R3.
How do you translate that to a HLL like C using a compiler and
without significant hand-made changes? You couldn't even move that
to BLISS without a special linkage definition that would need to
be hand constructed. How can you pass out-of-band information on
an architecture that doesn't have enough registers?
Tim.
|
|
0
|
|
|
|
Reply
|
tim.sneddon (59)
|
11/6/2009 4:24:37 PM
|
|
In article
<78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com>, Neil
Rieck <n.rieck@sympatico.ca> writes:
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
??????
|
|
0
|
|
|
|
Reply
|
helbig (4870)
|
11/6/2009 6:38:29 PM
|
|
"Tim E. Sneddon" <tim.sneddon@bigpond.com> writes:
>Bob Gezelter wrote:
>> In any event, the use of MACRO-32 is not the impediment. It has been
>> proven twice (e.g., ALPHA, Itanium) that a compiler can be
>> straightforwardly constructed to convert MACRO-32 in to the native
>I think that might be a bit of a stretch of the meaning of
>straightforward.
It certainly is. There are lots and lots of "tricks" used on VAX
assembly code that the Macro-32 compiler on Alpha/Itanic won't tolerate.
(Believe me, I know from experience)
>> write a MACRO-32 -> C translator, which would then "solve" the initial
>> problem of getting onto a new architecture. Admittedly, such a
>> bootstrapping approach has efficiency issues, but they can be dealt
>> with.
>I think that might be a pretty *huge* generalisation there. Source
>to source translating is not generally a big task (depending on the
>languages), but certainly going from machine level to a high level
>language is. I think there would be much more than some "efficiency
>issues". There especially needs to be careful consideration of the
>target architecture's calling standard and how it compares to the
>source. As I am sure you are aware writing code in assembly allows
>the coder to do all sorts of neat "tricks" that just cannot be
>replicated by a high level language.
One of the biggies is accessing portions of the stack not written by
the current routine. About the simplest example is messing with the
return address such as this:
JSB FOO
....
FOO:
....
ADDL #4,SP ; throw away return value
RSB ; return to the caller's caller
This returns not to the instruction after the JSB, but to the caller of
the routine that called FOO. Not uncommon in some code. Other code often
has "parameters" embedded in the code stream after the JSB instruction,
the called routine fetches the parameters and manipulates the return
address to return to the instruction after the parameters, not to the
first parameter itself.
>Actually, a recent post by VAXman is the perfect example. It sites
>a piece of code that passes information through registers R1-R3.
>How do you translate that to a HLL like C using a compiler and
>without significant hand-made changes? You couldn't even move that
>to BLISS without a special linkage definition that would need to
>be hand constructed. How can you pass out-of-band information on
>an architecture that doesn't have enough registers?
I won't bore everyone with dozens of examples of code snippets that
won't reverse translate into C or something, and aren't even accepted by
the Itanic Macro-32 compiler.
|
|
0
|
|
|
|
Reply
|
moroney (973)
|
11/6/2009 7:02:44 PM
|
|
Allen, Daniel P. schrieb:
>
>>-----Original Message-----
>>From: info-vax-bounces@rbnsn.com [mailto:info-vax-bounces@rbnsn.com] On Behalf Of Michael Kraemer
>>Sent: Friday, November 06, 2009 7:43 AM
>>To: info-vax@rbnsn.com
>>Subject: Re: [Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.
>
>
>>In article <78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com>,
>>Neil Rieck <n.rieck@sympatico.ca> writes:
>>
>>>Since any idiot can put up a web page these days, you know it all
>>>can't be true. So imagine my surprise when I bumped into this:
>>>
>>>http://radsoft.net/rants/20040831,00.shtml
>>>
>
>
>>And:
>
>
>>"Dave took his engineers and his new operating system called 'Prism' cross town
>>to the Redmond campus."
>
>
>>How that?
>>Presumably everything he did at M$ would be IP of DEC,
>>so he couldn't just "take it with him", unless DEC permitted it.
>>AFAIK he left as a "disgruntled employee" so DEC would have had
>>even less reason to give it away.
>
>
>
> Speaking as an old personal friend of one of his top team members I think I can say that the description is reasonably accurate.
>
So this means he stole DECs IP and got away with it?
(where are the IP zealots when they're needed?)
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/6/2009 7:38:13 PM
|
|
On Fri, 06 Nov 2009 13:45:24 +0000, VAXman- wrote:
> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard B.
> Gilbert" <rgilbert88@comcast.net> writes:
>>Neil Rieck wrote:
>>> Since any idiot can put up a web page these days, you know it all
>>> can't be true. So imagine my surprise when I bumped into this:
>>>
>>> http://radsoft.net/rants/20040831,00.shtml
>>>
>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>> turned down flat. Several years later he found himself in Seattle and
>>> essentially was doing the rewrite in C when word came DEC were tired
>>> of him.</quote>
>>>
>>> This article contains lots of other (possibly) questionable facts, but
>>> think about the statement above "rewrite VMS in C". If this had
>>> happened, we would have VMS or OpenVMS on any platform including
>>> x86-64
>>>
>>> NSR
>>
>>Not ANY platform! There are architectural requirements; things like
>>number and sizes of registers, processor modes, etc.
>>
>>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>>like command language, and VMS-like system services. It was NOT VMS.
>
> Wendin Associate. I had a copy too when I was working at Lakehurst
> NAEC. It was considered a toy and little more.
It's wasn't a serious attempt. The real product was a small OS kernel,
with multiple 'personalities' laid on top. There was a PC-UNIX which was
equally unlike UNIX.
I have disks and manuals for PC-VMS somewhere...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/6/2009 8:58:27 PM
|
|
Neil Rieck wrote:
> You will need to forgive me this week. Last Thursday (Oct 29) I
> presented H1N1 symptoms and have been banished to my house until
> Monday (Nov-9).
Is it safe for you to send emails ? Someone running a microsoft PC might
get infected reading your messages :-)
Were you confirmed H1N1, or did you just get a a bad flue ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/6/2009 10:32:22 PM
|
|
On Fri, 6 Nov 2009 at 20:38 +0100, Michael Kraemer wrote:
> So this means he stole DECs IP and got away with it?
> (where are the IP zealots when they're needed?)
According to some of the links that NSR gave us, DEC sued Microsoft
over this, and won. Although as also seemed to happen in DEC's suit
against Intel, DEC came out on the short end of the settlement.
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
|
|
0
|
|
|
|
Reply
|
mylastname3 (505)
|
11/6/2009 11:55:11 PM
|
|
In article <7ljgvjF3e5hd8U2@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>On Fri, 06 Nov 2009 13:45:24 +0000, VAXman- wrote:
>
>> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard B.
>> Gilbert" <rgilbert88@comcast.net> writes:
>>>Neil Rieck wrote:
>>>> Since any idiot can put up a web page these days, you know it all
>>>> can't be true. So imagine my surprise when I bumped into this:
>>>>
>>>> http://radsoft.net/rants/20040831,00.shtml
>>>>
>>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>>> turned down flat. Several years later he found himself in Seattle and
>>>> essentially was doing the rewrite in C when word came DEC were tired
>>>> of him.</quote>
>>>>
>>>> This article contains lots of other (possibly) questionable facts, but
>>>> think about the statement above "rewrite VMS in C". If this had
>>>> happened, we would have VMS or OpenVMS on any platform including
>>>> x86-64
>>>>
>>>> NSR
>>>
>>>Not ANY platform! There are architectural requirements; things like
>>>number and sizes of registers, processor modes, etc.
>>>
>>>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>>>like command language, and VMS-like system services. It was NOT VMS.
>>
>> Wendin Associate. I had a copy too when I was working at Lakehurst
>> NAEC. It was considered a toy and little more.
>
>It's wasn't a serious attempt. The real product was a small OS kernel,
>with multiple 'personalities' laid on top. There was a PC-UNIX which was
>equally unlike UNIX.
>
>I have disks and manuals for PC-VMS somewhere...
I have the disks (or images of) but no manuals. Can you scan them and
make them available? I'll put them on-line with the disk images if you
would.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/7/2009 2:08:26 AM
|
|
On Sat, 07 Nov 2009 02:08:26 +0000, VAXman- wrote:
> In article <7ljgvjF3e5hd8U2@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>>On Fri, 06 Nov 2009 13:45:24 +0000, VAXman- wrote:
>>
>>> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard
>>> B. Gilbert" <rgilbert88@comcast.net> writes:
>>>>Neil Rieck wrote:
>>>>> Since any idiot can put up a web page these days, you know it all
>>>>> can't be true. So imagine my surprise when I bumped into this:
>>>>>
>>>>> http://radsoft.net/rants/20040831,00.shtml
>>>>>
>>>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but
>>>>> loved C. As soon as he'd finished VMS he suggested the rewrite. He
>>>>> was turned down flat. Several years later he found himself in
>>>>> Seattle and essentially was doing the rewrite in C when word came
>>>>> DEC were tired of him.</quote>
>>>>>
>>>>> This article contains lots of other (possibly) questionable facts,
>>>>> but think about the statement above "rewrite VMS in C". If this had
>>>>> happened, we would have VMS or OpenVMS on any platform including
>>>>> x86-64
>>>>>
>>>>> NSR
>>>>
>>>>Not ANY platform! There are architectural requirements; things like
>>>>number and sizes of registers, processor modes, etc.
>>>>
>>>>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>>>>like command language, and VMS-like system services. It was NOT VMS.
>>>
>>> Wendin Associate. I had a copy too when I was working at Lakehurst
>>> NAEC. It was considered a toy and little more.
>>
>>It's wasn't a serious attempt. The real product was a small OS kernel,
>>with multiple 'personalities' laid on top. There was a PC-UNIX which was
>>equally unlike UNIX.
>>
>>I have disks and manuals for PC-VMS somewhere...
>
> I have the disks (or images of) but no manuals. Can you scan them and
> make them available? I'll put them on-line with the disk images if you
> would.
Yes, but since Vista has broken my scanner driver, it may take a while...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/7/2009 8:04:19 AM
|
|
Rob Brown schrieb:
> On Fri, 6 Nov 2009 at 20:38 +0100, Michael Kraemer wrote:
>
>> So this means he stole DECs IP and got away with it?
>> (where are the IP zealots when they're needed?)
>
>
> According to some of the links that NSR gave us, DEC sued Microsoft over
> this, and won. Although as also seemed to happen in DEC's suit against
> Intel, DEC came out on the short end of the settlement.
Only if one presumes that DEC actually wanted to win the lawsuit.
It is more likely that DEC simply wanted to put some
pressure on intel so they could get rid of Alpha.
From this point of view DEC actually succeeded.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/7/2009 8:58:36 AM
|
|
Michael Kraemer wrote:
> Only if one presumes that DEC actually wanted to win the lawsuit.
> It is more likely that DEC simply wanted to put some
> pressure on intel so they could get rid of Alpha.
> From this point of view DEC actually succeeded.
Palmer was already in talks with Pfeiffer when the Intel stuff came up.
So it was really Compaq telling DEC that it wasn't interested in buying
the chip business, so Palmer found a way to get rid of the money losing
stuff.
This is quite different from Cutler since at the time Cutler left,
Digital had not yet begun to self cannabalise so it would be small
enough to be bought by someone. Although DEC had stopped growing, it
wasn't clear at that time that its had begun what would end up being a
terminal decline a decade later. DEC's desire to be Microsoft's poodle
had not yet begun, so when Cutler left, there would have been no reason
for DEC to "give away" its valuable IP to a competitor.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 9:22:56 AM
|
|
In the VMS 20th anniversary PDF, it is revealed that Cutler designed the
Microvax I on the west coast. This is circa 1982-1984.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 12:25:48 PM
|
|
On Nov 6, 7:43=A0am, m.krae...@gsi.de (Michael Kraemer) wrote:
> In article <78797018-2cfb-402d-9eb9-b1f109c76...@p8g2000yqb.googlegroups.=
com>,
>
> Neil Rieck <n.ri...@sympatico.ca> writes:
> > Since any idiot can put up a web page these days, you know it all
> > can't be true. So imagine my surprise when I bumped into this:
>
> >http://radsoft.net/rants/20040831,00.shtml
>
> And:
>
> "Dave took his engineers and his new operating system called 'Prism' cros=
s town
> to the Redmond campus."
>
> How that?
> Presumably everything he did at M$ would be IP of DEC,
> so he couldn't just "take it with him", unless DEC permitted it.
> AFAIK he left as a "disgruntled employee" so DEC would have had
> even less reason to give it away.
Here is one page of several I recently found (I am still looking)
http://www.roughlydrafted.com/2009/07/30/readers-write-how-microsoft-got-wi=
ndows-nt/
<quote>
=93So, Cutler walked down the street to Microsoft and offered them Mica
which became NT. Later DEC sued MS and, in an out of court settlement,
got royalties for the filched technology. Part of the deal included
targeting NT (back) onto the Alpha platform.
=94BTW, this was not an usual procedure at DEC. Many employees left the
company with intellectual property from a cancelled project under
their arm, with the understanding that if they made it a commercial
success then DEC would come back knocking on the door for for
royalties.=93
</quote>
This page, as well as others, claim the back-porting of WindowsNT to
Alpha was part of the settlement. Microsoft was the true beneficiary
of this deal when Compaq decided to walk away from the WindowsNT on
Alpha business.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
http://www3.sympatico.ca/n.rieck/docs/dave_cutler-prism-mica-emerald-etc.ht=
ml
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/7/2009 1:15:44 PM
|
|
In article <7lko03F3e5hd8U4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>On Sat, 07 Nov 2009 02:08:26 +0000, VAXman- wrote:
>
>> In article <7ljgvjF3e5hd8U2@mid.individual.net>, Bob Eager
>> <rde42@spamcop.net> writes:
>>>On Fri, 06 Nov 2009 13:45:24 +0000, VAXman- wrote:
>>>
>>>> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard
>>>> B. Gilbert" <rgilbert88@comcast.net> writes:
>>>>>Neil Rieck wrote:
>>>>>> Since any idiot can put up a web page these days, you know it all
>>>>>> can't be true. So imagine my surprise when I bumped into this:
>>>>>>
>>>>>> http://radsoft.net/rants/20040831,00.shtml
>>>>>>
>>>>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but
>>>>>> loved C. As soon as he'd finished VMS he suggested the rewrite. He
>>>>>> was turned down flat. Several years later he found himself in
>>>>>> Seattle and essentially was doing the rewrite in C when word came
>>>>>> DEC were tired of him.</quote>
>>>>>>
>>>>>> This article contains lots of other (possibly) questionable facts,
>>>>>> but think about the statement above "rewrite VMS in C". If this had
>>>>>> happened, we would have VMS or OpenVMS on any platform including
>>>>>> x86-64
>>>>>>
>>>>>> NSR
>>>>>
>>>>>Not ANY platform! There are architectural requirements; things like
>>>>>number and sizes of registers, processor modes, etc.
>>>>>
>>>>>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>>>>>like command language, and VMS-like system services. It was NOT VMS.
>>>>
>>>> Wendin Associate. I had a copy too when I was working at Lakehurst
>>>> NAEC. It was considered a toy and little more.
>>>
>>>It's wasn't a serious attempt. The real product was a small OS kernel,
>>>with multiple 'personalities' laid on top. There was a PC-UNIX which was
>>>equally unlike UNIX.
>>>
>>>I have disks and manuals for PC-VMS somewhere...
>>
>> I have the disks (or images of) but no manuals. Can you scan them and
>> make them available? I'll put them on-line with the disk images if you
>> would.
>
>Yes, but since Vista has broken my scanner driver, it may take a while...
Ah, Vista (Visual Interface Similar To Apple's) Just buy a Mac! ;)
I have a Canon LiDE. It works like a charm with Ubuntu Linux and
on my Mac.
If you'd snail mail them to me, I'd make the copies and smail mail
the originals back to you.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/7/2009 1:21:40 PM
|
|
In article <00ae7e22$0$6694$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>In the VMS 20th anniversary PDF, it is revealed that Cutler designed the
>Microvax I on the west coast. This is circa 1982-1984.
I didn't know that Cutler was a hardware guy.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/7/2009 1:23:11 PM
|
|
On Nov 7, 3:58=A0am, Michael Kraemer <M.Krae...@gsi.de> wrote:
> Rob Brown schrieb:
>
> > On Fri, 6 Nov 2009 at 20:38 +0100, Michael Kraemer wrote:
>
> >> So this means he stole DECs IP and got away with it?
> >> (where are the IP zealots when they're needed?)
>
> > According to some of the links that NSR gave us, DEC sued Microsoft ove=
r
> > this, and won. =A0Although as also seemed to happen in DEC's suit again=
st
> > Intel, DEC came out on the short end of the settlement.
>
> Only if one presumes that DEC actually wanted to win the lawsuit.
> It is more likely that DEC simply wanted to put some
> pressure on intel so they could get rid of Alpha.
> =A0From this point of view DEC actually succeeded.
Not sure here if you are interchanging the names "DEC" and "Compaq" on
purpose or not. I never for a moment thought DEC (pre Palmer) wanted
to get rid of Alpha. I had lots of personal contact with DEC between
1978 through to 1993 and can tell you that this company exuded "a
passion for computing" which was infectious. However, I was working in
Maynard Massachusetts in April-1993 and can tell you that "DEC felt
different" (BTW, Palmer replaced Olsen in 1992).
Now if you were referring to DEC after Olsen, it is anyone's guess
what was going on at DEC. I'll tell you one thing, Robert Palmer did
not have a passion for computing that was anywhere close to that of
Ken Olsen.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/7/2009 1:30:36 PM
|
|
On Nov 6, 5:32=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > You will need to forgive me this week. Last Thursday (Oct 29) I
> > presented H1N1 symptoms and have been banished to my house until
> > Monday (Nov-9).
>
> Is it safe for you to send emails ? Someone running a microsoft PC might
> get infected reading your messages :-)
>
> Were you confirmed H1N1, or did you just get a a bad flue ?
I was advised not to leave my house unless I had problems breathing,
or was coughing up blood. However, if adults presented either diarrhea
or vomiting then H1N1 was considered a certainty (I had both). They
told me it would take 5-days to clear up and it did.
Oh well. Still alive and kicking.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/7/2009 1:35:19 PM
|
|
Has anyone seen these DEC-document archives yet? Contains lots of
stuff including: PRISM Specs, emails including one confirming the
resignation of Dave Cutler, etc.
http://bitsavers.org/pdf/dec/prism/
http://computer-refuge.org/bitsavers/pdf/dec/prism/
http://ftp7.freebsd.org/sites/www.bitsavers.org/pdf/dec/prism/
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/7/2009 1:40:45 PM
|
|
In article <00A942AD.BEF180FC@sendspamhere.org>,
VAXman- @SendSpamHere.ORG writes:
> In article <7ljgvjF3e5hd8U2@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>>On Fri, 06 Nov 2009 13:45:24 +0000, VAXman- wrote:
>>
>>> In article <iNqdnfhzKIfVi2nXnZ2dnUVZ_jSdnZ2d@giganews.com>, "Richard B.
>>> Gilbert" <rgilbert88@comcast.net> writes:
>>>>Neil Rieck wrote:
>>>>> Since any idiot can put up a web page these days, you know it all
>>>>> can't be true. So imagine my surprise when I bumped into this:
>>>>>
>>>>> http://radsoft.net/rants/20040831,00.shtml
>>>>>
>>>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>>>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>>>> turned down flat. Several years later he found himself in Seattle and
>>>>> essentially was doing the rewrite in C when word came DEC were tired
>>>>> of him.</quote>
>>>>>
>>>>> This article contains lots of other (possibly) questionable facts, but
>>>>> think about the statement above "rewrite VMS in C". If this had
>>>>> happened, we would have VMS or OpenVMS on any platform including
>>>>> x86-64
>>>>>
>>>>> NSR
>>>>
>>>>Not ANY platform! There are architectural requirements; things like
>>>>number and sizes of registers, processor modes, etc.
>>>>
>>>>Many years ago, somebody wrote PCVMS. I bought a copy. It had a DCL
>>>>like command language, and VMS-like system services. It was NOT VMS.
>>>
>>> Wendin Associate. I had a copy too when I was working at Lakehurst
>>> NAEC. It was considered a toy and little more.
>>
>>It's wasn't a serious attempt. The real product was a small OS kernel,
>>with multiple 'personalities' laid on top. There was a PC-UNIX which was
>>equally unlike UNIX.
>>
>>I have disks and manuals for PC-VMS somewhere...
>
> I have the disks (or images of) but no manuals. Can you scan them and
> make them available? I'll put them on-line with the disk images if you
> would.
Or send them to bitsavers. I am sure Dave would be glad to hos them.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/7/2009 1:52:41 PM
|
|
In article <00A9430C.01C2519F@sendspamhere.org>,
VAXman- @SendSpamHere.ORG writes:
> In article <00ae7e22$0$6694$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>In the VMS 20th anniversary PDF, it is revealed that Cutler designed the
>>Microvax I on the west coast. This is circa 1982-1984.
>
> I didn't know that Cutler was a hardware guy.
I heard he was God. At least that's what is usually sounds like here.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/7/2009 2:12:22 PM
|
|
On Sat, 07 Nov 2009 13:21:40 +0000, VAXman- wrote:
> If you'd snail mail them to me, I'd make the copies and smail mail the
> originals back to you.
A bit too expensive given their size, and the distance.
I may just set up a spare machine with XP...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/7/2009 4:15:14 PM
|
|
Neil Rieck schrieb:
> <quote>
> �BTW, this was not an usual procedure at DEC. Many employees left the
> company with intellectual property from a cancelled project under
> their arm, with the understanding that if they made it a commercial
> success then DEC would come back knocking on the door for for
> royalties.�
> </quote>
And still people wonder why DEC went down the drain.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/7/2009 4:49:09 PM
|
|
"Neil Rieck" <n.rieck@sympatico.ca> wrote in message
news:78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com...
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> C. As soon as he'd finished VMS he suggested the rewrite. He was
> turned down flat. Several years later he found himself in Seattle and
> essentially was doing the rewrite in C when word came DEC were tired
> of him.</quote>
>
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
>
> NSR
I don't believe a word of it. VAXELN wasn't written in C, but EPASCAL.
PRISM was going to have its own implementation language (a Don MacClaren
invention) that was going to be a mixture of Pascal, a dash of PL/I, and
some new language features. I have one of the numbered preliminary language
manuals stuffed in a box.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/7/2009 4:53:18 PM
|
|
Neil Rieck schrieb:
> On Nov 7, 3:58 am, Michael Kraemer <M.Krae...@gsi.de> wrote:
>>
>>Only if one presumes that DEC actually wanted to win the lawsuit.
>>It is more likely that DEC simply wanted to put some
>>pressure on intel so they could get rid of Alpha.
>> From this point of view DEC actually succeeded.
>
>
> Not sure here if you are interchanging the names "DEC" and "Compaq" on
> purpose or not.
Alpha was sold to intel in 1997, so still DEC/Palmer were in charge.
> I never for a moment thought DEC (pre Palmer) wanted
> to get rid of Alpha.
How could they, Alpha was announced the same year
Palmer took over.
> I had lots of personal contact with DEC between
> 1978 through to 1993 and can tell you that this company exuded "a
> passion for computing" which was infectious. However, I was working in
> Maynard Massachusetts in April-1993 and can tell you that "DEC felt
> different" (BTW, Palmer replaced Olsen in 1992).
Because they were already in deep sh**?
> Now if you were referring to DEC after Olsen, it is anyone's guess
> what was going on at DEC. I'll tell you one thing, Robert Palmer did
> not have a passion for computing that was anywhere close to that of
> Ken Olsen.
The same could be said for most other IT companies in the 1990s
when compared to the decades before.
SGI and old HP being sad examples.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/7/2009 5:08:10 PM
|
|
-----Original Message-----
>From: info-vax-bounces@rbnsn.com [mailto:info-vax-bounces@rbnsn.com] On Be=
half Of John Reagan
>Sent: Saturday, November 07, 2009 11:53 AM
>To: info-vax@rbnsn.com
>Subject: Re: [Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.
>>"Neil Rieck" <n.rieck@sympatico.ca> wrote in message
>>news:78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com...
>> Since any idiot can put up a web page these days, you know it all
>> can't be true. So imagine my surprise when I bumped into this:
>>
>> http://radsoft.net/rants/20040831,00.shtml
>>
>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>
>I don't believe a word of it. VAXELN wasn't written in C, but EPASCAL.
>PRISM was going to have its own implementation language (a Don MacClaren
>invention) that was going to be a mixture of Pascal, a dash of PL/I, and
>some new language features. I have one of the numbered preliminary langua=
ge
>manuals stuffed in a box.
>John
PILLAR - the manual is in the PRISM/MICA directories on bitsaver.
Dan
_______________________________________________
Info-vax mailing list
Info-vax@rbnsn.com
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
|
|
0
|
|
|
|
Reply
|
daniel.allen (3)
|
11/7/2009 5:31:24 PM
|
|
Michael Kraemer wrote:
> Neil Rieck schrieb:
>
>> <quote>
>> �BTW, this was not an usual procedure at DEC. Many employees left the
>> company with intellectual property from a cancelled project under
>> their arm, with the understanding that if they made it a commercial
>> success then DEC would come back knocking on the door for for
>> royalties.�
>> </quote>
>
> And still people wonder why DEC went down the drain.
>
It was never a mystery to me! DEC was totally out of touch with the
market place. The the RAM for the Rainbow that DEC sold for ~$700, I
bought at the Trenton Computer Festival for $30 US! The 20 MB disk
drive that DEC sold for $2200, I bought for $300. The 5-1/4" floppy
disks that DEC sold for $5 US each, I bought for $0.50 each and
formatted them myself in spite of the fact that my Rainbow "could not
properly format a floppy disk!"
There were about 20 different models of a 20MB disk from DEC! The
differences between the models? It was the mounting hardware! I could
go on but I hope you get the idea.
Storage-Works was nothing short of brilliant but it was rather late and
the marketing was nothing short of idiocy!
I could go on but most of you know the litany as well as I do!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/7/2009 6:12:51 PM
|
|
On Nov 7, 12:08=A0pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
[...snip...]
> > I never for a moment thought DEC (pre Palmer) wanted
> > to get rid of Alpha.
>
> How could they, Alpha was announced the same year
> Palmer took over.
>
Not wanting to split hairs here, but I was in attendance at the Alpha
21064 announcement in Toronto, and it was at an industry trade show
Feb-1992. All the handouts were cheap photocopies and most people
wondered if this announcement was for real. I was a real a-hole in
those days (more so than now, anyway) and so jokingly asked if DEC had
any free chip samples. This caused the DEC rep to reach into his
briefcase to hand me a bag of potato chips with a taped-on label of
the space shuttle with the moniker "Alpha Chips". I still have the
unopened bag of chips on top of my book case.
Anyway, the 21064 appeared later that September and Palmer took over
in October. Speaking of a-holes, Palmer was employed by DEC since 1985
so he must have known something of Alpha. The way he decided to sell
off pieces of DEC (like RDB) makes me think he was just a hatchet man.
No company could have survived that many cuts in so short a time
without bleeding to death.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/7/2009 9:04:03 PM
|
|
VAXman- @SendSpamHere.ORG wrote:
> I didn't know that Cutler was a hardware guy.
OK, I had opened the document in quicklook and couldn'to select text
from it. (quicklook is apple's implementation of
dir/show=formatted_content filename)
Now, I have it on a PDF reader:
##
Evolution of the architecture
For almost a year, the VAX development
and review teams worked
back and forth on the VAX architecture.
After four versions, the
proposed architecture was found
to be too complex, too expensive,
and too complicated to execute.
The company formed a group that
became known as �The Blue Ribbon
Committee� that included three
hardware engineers: Bill Strecker,
Richie Lary, and Steve Rothman,
and three software engineers: Dave
Cutler, Dick Hustvedt, and Peter
Lipman
##
##
With the VAX hardware development underway, the software
development�code named Starlet�began a few months later in June of
1975. Roger Gourd led the project and software engineers Dave Cutler, Dick
Hustvedt, and Peter Lipman were technical project leaders, each responsible
for a different part of the operating system.
##
##
After the 750, DIGITAL
designed the MicroVAX I�one of the first DIGITAL projects to include
silicon compilers�with the consulting help of Carver Meade, a pioneer in
integrated circuit design. Building on the experience of the MicroVAX I,
the company soon followed with the more powerful MicroVAX II.
While the V-11 was designed as a full VAX implementation, the MicroVAX I
was designed as a VAX subset. The MicroVAX I system was developed
in the company�s Seattle facility, headed by Dave Cutler. Because the
MicroVAX I was a much simpler design than the V-11, and because of the
use of the silicon compiler tools, it was completed before the V-11.
##
##
�The sense I always had was that there were four key technical
visionaries at
the beginning of MicroVAX: Dave Cutler, with his creation of the MicroVAX
I system for early software development; Bob Supnik, who headed up
MicroVAX chip development and also wrote the microcode; Jesse Lipcon
who headed up MicroVAX II Server Development; and Dick Hustvedt, who
drove the MicroVMS Software Strategy.�
�Jay Nichols
Computer Special Systems, Manager of Engineering
##
##
Prism: VMS on RISC technology
DIGITAL began working on RISC technology in 1986 when Jack Smith,
VP of Operations, tapped Dave Cutler on the shoulder and said, �You will be
RISC Czar for DIGITAL. Organize a program.� The program, code named
Prism, was to develop the company�s RISC machine. Its operating system
would embody the next generation of design principles and have a
compatibility layer for UNIX and VMS.
##
##
Alpha was very much the �son of Prism.� The primary changes made to
produce Alpha were for VMS compatibility. The original Prism design had
serious compatibility problems with the VAX and VMS in two areas�
numerical data types and privileged architecture.
##
##
�When our customers had beta
copies of Windows NT, they told us
that it felt like they were revisiting
an old friend. That�s not surprising
because the chief architect of both
operating systems was Dave Cutler.
So there is a natural affinity from a
technical perspective between the two
environments. Wes Melling is often
quoted calling it the �Cutler effect.��
�Mary Ellen Fortier
Director, OpenVMS Marketing
##
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 10:32:41 PM
|
|
Neil Rieck wrote:
> Now if you were referring to DEC after Olsen, it is anyone's guess
> what was going on at DEC. I'll tell you one thing, Robert Palmer did
> not have a passion for computing that was anywhere close to that of
> Ken Olsen.
I think there maybe stuff we don't know about Palmer's mandate.
About the same time Olsen was ousted, IBM had begun plans to dismantle
itself to pay off debts and be sold and/or avoid bankrupcy.
It is possible that the board realised that Digital was going in the
same direction and gave Palmer a mandate to "rationlize" instead of
"fix" Digital and then, seeing how rationalisation was making things
worse, told him to sell off parts that could be sold and seek a buyer
for the rest to try to maximize shareholder value.
Meanwhile, IBM hired Gerstner and he decided to put an end to the
"dismantle IBM" right away and fix the company, which he succeeded.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 10:43:38 PM
|
|
In article <hd49hq$m91$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> Neil Rieck schrieb:
>> On Nov 7, 3:58 am, Michael Kraemer <M.Krae...@gsi.de> wrote:
>>>
>>>Only if one presumes that DEC actually wanted to win the lawsuit.
>>>It is more likely that DEC simply wanted to put some
>>>pressure on intel so they could get rid of Alpha.
>>> From this point of view DEC actually succeeded.
>>
>>
>> Not sure here if you are interchanging the names "DEC" and "Compaq" on
>> purpose or not.
>
> Alpha was sold to intel in 1997, so still DEC/Palmer were in charge.
No. It was not. One more time, from Wikipedia:
"The Alpha architecture was sold, along with most parts of DEC,
to Compaq in 1998. Compaq, already an Intel customer, decided to
phase out Alpha in favor of the forthcoming Hewlett-Packard/Intel
Itanium architecture, and sold all Alpha intellectual property to
Intel in 2001"
I suspect that you are confusing the sale of the Hudson fab with
the sale of the IP.
George Cook
WVNET
|
|
0
|
|
|
|
Reply
|
cook (261)
|
11/7/2009 10:47:05 PM
|
|
Michael Kraemer wrote:
>> Not sure here if you are interchanging the names "DEC" and "Compaq" on
>> purpose or not.
>
> Alpha was sold to intel in 1997, so still DEC/Palmer were in charge.
Palmer began to discuss merger with Compaq's Pfeiffer in 1996. Talks
lasted 3 years. (The 3 year counter stopped on the day of the merger
announcement, not when it was signed/sealed/delivered, so perhaps the
talks began in 1995).
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 10:47:49 PM
|
|
George Cook wrote:
> I suspect that you are confusing the sale of the Hudson fab with
> the sale of the IP.
In exchange for Digital apologizing to Intel, Intel agreed to relieve
Digital of its money losing Hudson Plant.
Basically, Digital found a way to get rid of a money losing plant which
Compaq was not interested in by leveraging the fact that Intel had
stolen Alpha technologies years before.
DEC should have sued Intel well before that time. It is only because
Compaq had told Palmer to shed the chip making business (Compaq did't
want it) that Palmer suddently decided to pursue this matter.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/7/2009 10:51:51 PM
|
|
Michael Kraemer wrote:
> Neil Rieck schrieb:
>> <quote>
>> �BTW, this was not an usual procedure at DEC. Many employees left the
>> company with intellectual property from a cancelled project under
>> their arm, with the understanding that if they made it a commercial
>> success then DEC would come back knocking on the door for for
>> royalties.�
>> </quote>
>
> And still people wonder why DEC went down the drain.
The projects were cancelled at DEC, so I doubt that
preventing other from using the ideas would have made
much of a difference.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:11:52 AM
|
|
Richard B. Gilbert wrote:
> Michael Kraemer wrote:
>> Neil Rieck schrieb:
>>
>>> <quote>
>>> �BTW, this was not an usual procedure at DEC. Many employees left the
>>> company with intellectual property from a cancelled project under
>>> their arm, with the understanding that if they made it a commercial
>>> success then DEC would come back knocking on the door for for
>>> royalties.�
>>> </quote>
>>
>> And still people wonder why DEC went down the drain.
>
> It was never a mystery to me! DEC was totally out of touch with the
> market place. The the RAM for the Rainbow that DEC sold for ~$700, I
> bought at the Trenton Computer Festival for $30 US! The 20 MB disk
> drive that DEC sold for $2200, I bought for $300. The 5-1/4" floppy
> disks that DEC sold for $5 US each, I bought for $0.50 each and
> formatted them myself in spite of the fact that my Rainbow "could not
> properly format a floppy disk!"
>
> There were about 20 different models of a 20MB disk from DEC! The
> differences between the models? It was the mounting hardware! I could
> go on but I hope you get the idea.
That explanation sounds a lot more convincing than IP going
out the door.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:13:31 AM
|
|
Michael Kraemer wrote:
> Allen, Daniel P. schrieb:
>>> On Behalf Of Michael Kraemer
>>> Neil Rieck <n.rieck@sympatico.ca> writes:
>>> "Dave took his engineers and his new operating system called 'Prism'
>>> cross town
>>> to the Redmond campus."
>>
>>> How that?
>>> Presumably everything he did at M$ would be IP of DEC,
>>> so he couldn't just "take it with him", unless DEC permitted it.
>>> AFAIK he left as a "disgruntled employee" so DEC would have had
>>> even less reason to give it away.
>>
>> Speaking as an old personal friend of one of his top team members I
>> think I can say that the description is reasonably accurate.
>
> So this means he stole DECs IP and got away with it?
> (where are the IP zealots when they're needed?)
Would it have made a big difference?
VMS was not the only multiuser OS.
They could have used ideas from Unix, Multics etc. instead.
No NT user, sysadm or user mode code developer could tell
the difference anyway.
It would have been different from driver writers and
other kernel mode code developers, but even though they may
be the guys that know most about the OS, then I don't think
they have much influence on decisions on what OS to use.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:18:53 AM
|
|
George Cook schrieb:
> In article <hd49hq$m91$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
> No. It was not. One more time, from Wikipedia:
>
> "The Alpha architecture was sold, along with most parts of DEC,
> to Compaq in 1998. Compaq, already an Intel customer, decided to
> phase out Alpha in favor of the forthcoming Hewlett-Packard/Intel
> Itanium architecture, and sold all Alpha intellectual property to
> Intel in 2001"
>
> I suspect that you are confusing the sale of the Hudson fab with
> the sale of the IP.
>
No, I'm well aware of the difference,
but I think it does not matter really.
The 1997 deal with intel (and a similar one with Samsung)
effectively marked alpha's sell out,
even if DEC kept IP rights on paper.
Moreover,
intel agreed to manufacture Alpha, a possible competitor to their
upcoming IA64.
At about the same time it was planned to port DEC Unix to IA64.
All that makes only sense if alpha's death was already sealed,
maybe secretly, with the 1997 deal.
Compaq just had to do the cleanup when
the time was right, in 2001, with the HP takeover in sight.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 2:21:26 AM
|
|
Bill Gunshannon wrote:
> In article <78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com>,
> Neil Rieck <n.rieck@sympatico.ca> writes:
>> Since any idiot can put up a web page these days, you know it all
>> can't be true. So imagine my surprise when I bumped into this:
>>
>> http://radsoft.net/rants/20040831,00.shtml
>>
>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>> turned down flat. Several years later he found himself in Seattle and
>> essentially was doing the rewrite in C when word came DEC were tired
>> of him.</quote>
>>
>> This article contains lots of other (possibly) questionable facts, but
>> think about the statement above "rewrite VMS in C". If this had
>> happened, we would have VMS or OpenVMS on any platform including
>> x86-64
>
> That's funny. I have always wanted to see a project started to take
> FreeBSD and rewrite it in Pascal or even better, Ada. :-)
> Oh well, I suppose that could be another of those retirement projects
> I keep piling up.
C is undoubtedly easy to write OS code in (no surprise since
it was designed for this type of purpose), but it has proven to
relative hard to avoid buffer overruns, memory leaks etc.
(buffer runs are probably more relevant than memory leaks for OS).
It would be rather interesting with an OS in Ada or Modula-2/Oberon
(standard Pascal lacks too much - DEC Pascal may do).
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:25:22 AM
|
|
Neil Rieck wrote:
> Since any idiot can put up a web page these days, you know it all
> can't be true. So imagine my surprise when I bumped into this:
>
> http://radsoft.net/rants/20040831,00.shtml
>
> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> C. As soon as he'd finished VMS he suggested the rewrite. He was
> turned down flat. Several years later he found himself in Seattle and
> essentially was doing the rewrite in C when word came DEC were tired
> of him.</quote>
>
> This article contains lots of other (possibly) questionable facts, but
> think about the statement above "rewrite VMS in C". If this had
> happened, we would have VMS or OpenVMS on any platform including
> x86-64
If the various owners of VMS had believed in the market for
VMS/x86-64, then I don't think getting Bliss and Macro-32 for
x86-64 would have been the showstopper. My guess is that it
would have been a small part of the overall project. Porting
an OS to a new platform is more than just building the
source code.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:27:54 AM
|
|
Richard B. Gilbert wrote:
> Neil Rieck wrote:
>> Since any idiot can put up a web page these days, you know it all
>> can't be true. So imagine my surprise when I bumped into this:
>>
>> http://radsoft.net/rants/20040831,00.shtml
>>
>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>> turned down flat. Several years later he found himself in Seattle and
>> essentially was doing the rewrite in C when word came DEC were tired
>> of him.</quote>
>>
>> This article contains lots of other (possibly) questionable facts, but
>> think about the statement above "rewrite VMS in C". If this had
>> happened, we would have VMS or OpenVMS on any platform including
>> x86-64
>
> Not ANY platform! There are architectural requirements; things like
> number and sizes of registers, processor modes, etc.
Not any platform.
But if there is let us call it flexibility to redesign to match
the new HW, then I would assume that all HW capable of running
OS/400, Unix, Linux, Windows NT could be made to run VMS.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:30:14 AM
|
|
Michael Moroney wrote:
> "Tim E. Sneddon" <tim.sneddon@bigpond.com> writes:
>> Bob Gezelter wrote:
>>> In any event, the use of MACRO-32 is not the impediment. It has been
>>> proven twice (e.g., ALPHA, Itanium) that a compiler can be
>>> straightforwardly constructed to convert MACRO-32 in to the native
>
>> I think that might be a bit of a stretch of the meaning of
>> straightforward.
>
> It certainly is. There are lots and lots of "tricks" used on VAX
> assembly code that the Macro-32 compiler on Alpha/Itanic won't tolerate.
> (Believe me, I know from experience)
Sure there would be problems.
But I don't think the problems would be great enough to stop
a porting projects with funding and support from the top.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 2:32:50 AM
|
|
Neil Rieck schrieb:
>
> Not wanting to split hairs here, but I was in attendance at the Alpha
> 21064 announcement in Toronto, and it was at an industry trade show
> Feb-1992. All the handouts were cheap photocopies and most people
> wondered if this announcement was for real. I was a real a-hole in
> those days (more so than now, anyway) and so jokingly asked if DEC had
> any free chip samples. This caused the DEC rep to reach into his
> briefcase to hand me a bag of potato chips with a taped-on label of
> the space shuttle with the moniker "Alpha Chips". I still have the
> unopened bag of chips on top of my book case.
So who was the a-hole then? :-)
> Anyway, the 21064 appeared later that September and Palmer took over
> in October. Speaking of a-holes, Palmer was employed by DEC since 1985
> so he must have known something of Alpha.
Sure, he was a semiconductor guy, iirc.
Of course pre-Palmer DEC did not want to get rid
of alpha, it was barely on the market then
(that's what I wanted to say).
One can't even say that Palmer-DEC wanted to get rid
of it in the early years, only later, when it turned
out to be an economic failure.
> The way he decided to sell
> off pieces of DEC (like RDB) makes me think he was just a hatchet man.
well, DEC was in such deep sh*t, maybe such a guy was needed?
> No company could have survived that many cuts in so short a time
> without bleeding to death.
Without selling parts of DEC, the company may have been
finished even earlier.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 2:46:11 AM
|
|
Michael Kraemer wrote:
> One can't even say that Palmer-DEC wanted to get rid
> of it in the early years, only later, when it turned
> out to be an economic failure.
The Hudson FAB wasn't underused because of lack of demand. From what I
was told, there were plenty of customers wanting DEC to build their
chips, but Palmer wanted to reserve FAB capacity in case Alpha became
popular. But by failing to address pricing, Alpha never became pppular
and Hudson FAB remain underused for years until it became obsolete at
which point DEC wanted to get rid of it without losing face. Hence the
Intel deal.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/8/2009 2:56:18 AM
|
|
JF Mezei schrieb:
> ##
> �When our customers had beta
> copies of Windows NT, they told us
> that it felt like they were revisiting
> an old friend. That�s not surprising
> because the chief architect of both
> operating systems was Dave Cutler.
> So there is a natural affinity from a
> technical perspective between the two
> environments. Wes Melling is often
> quoted calling it the �Cutler effect.��
> �Mary Ellen Fortier
> Director, OpenVMS Marketing
> ##
>
But why is it that,
whenever I'm forced to sit in front of a Windoze box,
I never feel "hey, this is just like VMS, only better"?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 2:57:12 AM
|
|
Neil Rieck <n.rieck@sympatico.ca> writes:
>This page, as well as others, claim the back-porting of WindowsNT to
>Alpha was part of the settlement. Microsoft was the true beneficiary
>of this deal when Compaq decided to walk away from the WindowsNT on
>Alpha business.
I remember it as Microsoft cancelling NT on Alpha after Compaq did
something (I don't remember what) to piss Microsoft off.
There were persistant rumors when I was in Compaq/late Digital that
the sources to VMS were part of the IP that M$ had access to, with the
idea that they could use the clustering technology, but M$ could never
figure it out.
|
|
0
|
|
|
|
Reply
|
moroney (973)
|
11/8/2009 3:09:44 AM
|
|
Arne Vajh�j schrieb:
> The projects were cancelled at DEC, so I doubt that
> preventing other from using the ideas would have made
> much of a difference.
It still was DECs IP, and it was used to create
one of VMS' fiercest competitors.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:20:25 AM
|
|
Arne Vajh�j schrieb:
>
> That explanation sounds a lot more convincing than IP going
> out the door.
>
And yet another take on the whole DEC thing:
http://www.sigcis.org/files/Goodwin_paper.pdf
(gotta love armchair history :-)
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:26:15 AM
|
|
Michael Kraemer wrote:
> Arne Vajh�j schrieb:
>> The projects were cancelled at DEC, so I doubt that
>> preventing other from using the ideas would have made
>> much of a difference.
>
> It still was DECs IP, and it was used to create
> one of VMS' fiercest competitors.
But would its non-usage have had much impact?
Unix, OS/400, Linux seems to have worked out fine
without it.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 3:29:29 AM
|
|
Michael Kraemer wrote:
> JF Mezei schrieb:
>
>> ##
>> �When our customers had beta
>> copies of Windows NT, they told us
>> that it felt like they were revisiting
>> an old friend. That�s not surprising
>> because the chief architect of both
>> operating systems was Dave Cutler.
>> So there is a natural affinity from a
>> technical perspective between the two
>> environments. Wes Melling is often
>> quoted calling it the �Cutler effect.��
>> �Mary Ellen Fortier
>> Director, OpenVMS Marketing
>> ##
>>
>
> But why is it that,
> whenever I'm forced to sit in front of a Windoze box,
> I never feel "hey, this is just like VMS, only better"?
>
Well, it's clearly better in some ways! When $700 US buys the computer
and a licensed copy of Windows? ISTR that a VMS license sold for almost
$2000 per seat.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/8/2009 3:30:35 AM
|
|
Arne Vajh�j schrieb:
> Michael Kraemer wrote:
>
>>
>> So this means he stole DECs IP and got away with it?
>> (where are the IP zealots when they're needed?)
>
>
> Would it have made a big difference?
>
I was wondering that an (apparently disgruntled) employee
can walk out of his previous employer's door,
with a tape (real or virtual) under his arm,
essentially offering that stuff to a competitor.
Without being sued.
Iirc SCO has sued IBM for lesser evidence.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:32:07 AM
|
|
JF Mezei schrieb:
> Michael Kraemer wrote:
>
>>One can't even say that Palmer-DEC wanted to get rid
>>of it in the early years, only later, when it turned
>>out to be an economic failure.
>
> The Hudson FAB wasn't underused because of lack of demand. From what I
> was told, there were plenty of customers wanting DEC to build their
> chips, but Palmer wanted to reserve FAB capacity in case Alpha became
> popular.
Is there any first hand information on this one,
or do we have to rely, once again, to "heard it through the grapevine"?
> But by failing to address pricing, Alpha never became pppular
there are more reasons that Alpha did not succeed
(late market entry, ISVs not interested, development costs).
> and Hudson FAB remain underused for years until it became obsolete at
> which point DEC wanted to get rid of it without losing face.
I think they lost quite a bit of their face in that deal.
It signalled the end of Alpha. At least for those
who were able to read the signs on the wall.
> Hence the
> Intel deal.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:37:49 AM
|
|
Michael Moroney schrieb:
> Neil Rieck <n.rieck@sympatico.ca> writes:
>
>
>>This page, as well as others, claim the back-porting of WindowsNT to
>>Alpha was part of the settlement. Microsoft was the true beneficiary
>>of this deal when Compaq decided to walk away from the WindowsNT on
>>Alpha business.
>
>
> I remember it as Microsoft cancelling NT on Alpha after Compaq did
> something (I don't remember what) to piss Microsoft off.
In 1999 Compaq announced discontinuance of
"support for NT" (whatever that means) on their Alpha machines
and withdrew their personnel from joint projects with M$.
Apparently Compaq found NT/x86 to be good enough
and counted on a future NT/itanic.
In turn M$ discontinued their apps for NT/alpha.
Compaq not only pissed off M$, but also loyal Alpha customers
who were allowed by their management to buy Alphas (with VMS)
because "they can also run NT".
Now this excuse had evaporated, another blow to Alpha (and VMS).
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:48:35 AM
|
|
Arne Vajh�j schrieb:
> Michael Kraemer wrote:
>>
>> It still was DECs IP, and it was used to create
>> one of VMS' fiercest competitors.
>
> But would its non-usage have had much impact?
>
> Unix, OS/400, Linux seems to have worked out fine
> without it.
Inspecting other OSs from outside is one thing,
but having a competitors' chief developer
on board, together with source code and
implementation details, gives a much better
head start.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 3:55:40 AM
|
|
Michael Kraemer wrote:
> Arne Vajh�j schrieb:
>> Michael Kraemer wrote:
>>> So this means he stole DECs IP and got away with it?
>>> (where are the IP zealots when they're needed?)
>>
>> Would it have made a big difference?
>
> I was wondering that an (apparently disgruntled) employee
> can walk out of his previous employer's door,
> with a tape (real or virtual) under his arm,
> essentially offering that stuff to a competitor.
> Without being sued.
> Iirc SCO has sued IBM for lesser evidence.
Things were different in 1988 than in 2009 when
it comes to IP.
Ken Olsen was an engineer not a lawyer.
And besides: how much was really copied?
Code was not copied - C instead of Bliss & Macro.
Shell was not copied - CMD instead of DCL (lousy change BTW).
GUI was not copied - MS Windows instead of DECWindows.
File system was not copied - NTFS instead of ODS-2.
Memory management and IO subsystem were apparently extremely
identical.
But if it ended up in court - how much of it was originall DEC and
not known from Multics/Unix/various IBM/standard computer science ?
(think MS - Apple - Xerox)
Probably still some, but probably not more than could easily be changed.
So DEC could only get as much much money as it would have cost MS
to rewrite N number of kernel modules.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 4:01:19 AM
|
|
Michael Kraemer wrote:
> Arne Vajh�j schrieb:
>> Michael Kraemer wrote:
>>>
>>> It still was DECs IP, and it was used to create
>>> one of VMS' fiercest competitors.
>>
>> But would its non-usage have had much impact?
>>
>> Unix, OS/400, Linux seems to have worked out fine
>> without it.
>
> Inspecting other OSs from outside is one thing,
> but having a competitors' chief developer
> on board, together with source code and
> implementation details, gives a much better
> head start.
Sure.
But that was not my point.
Those that I mention did not have a DEC chief developer
on board but managed to come through anyway.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 4:02:48 AM
|
|
On Nov 7, 9:27=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Neil Rieck wrote:
> > Since any idiot can put up a web page these days, you know it all
> > can't be true. So imagine my surprise when I bumped into this:
>
> >http://radsoft.net/rants/20040831,00.shtml
>
> > <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
> > C. As soon as he'd finished VMS he suggested the rewrite. He was
> > turned down flat. Several years later he found himself in Seattle and
> > essentially was doing the rewrite in C when word came DEC were tired
> > of him.</quote>
>
> > This article contains lots of other (possibly) questionable facts, but
> > think about the statement above "rewrite VMS in C". If this had
> > happened, we would have VMS or OpenVMS on any platform including
> > x86-64
>
> If the various owners of VMS had believed in the market for
> VMS/x86-64, then I don't think getting Bliss and Macro-32 for
> x86-64 would have been the showstopper. My guess is that it
> would have been a small part of the overall project. Porting
> an OS to a new platform is more than just building the
> source code.
>
> Arne
True, but if Cutler wanted to immediately write VMS in C then I'm
thinking he must had a good reason for it. We all know that UNIX
enjoyed an immediate debugging when it was first rewritten from
assembler to "C". I wonder (in hindsight) if all these secondary and
tertiary components (like BLISS and MACRO) might be an indication of
too many chefs in the VMS kitchen :-)
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/8/2009 10:32:26 AM
|
|
On Nov 7, 5:32=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> VAXman- @SendSpamHere.ORG wrote:
> > I didn't know that Cutler was a hardware guy.
>
> OK, I had opened the document in quicklook and couldn'to select text
> from it. (quicklook is apple's implementation of
> dir/show=3Dformatted_content =A0filename)
>
> Now, I have it on a PDF reader:
>
> ##
> Evolution of the architecture
> For almost a year, the VAX development
> and review teams worked
> back and forth on the VAX architecture.
> After four versions, the
> proposed architecture was found
> to be too complex, too expensive,
> and too complicated to execute.
>
> The company formed a group that
> became known as =93The Blue Ribbon
> Committee=94 that included three
> hardware engineers: Bill Strecker,
> Richie Lary, and Steve Rothman,
> and three software engineers: Dave
> Cutler, Dick Hustvedt, and Peter
> Lipman
> ##
>
> ##
> With the VAX hardware development underway, the software
> development=97code named Starlet=97began a few months later in June of
> 1975. Roger Gourd led the project and software engineers Dave Cutler, Dic=
k
> Hustvedt, and Peter Lipman were technical project leaders, each responsib=
le
> for a different part of the operating system.
> ##
>
> ##
> After the 750, DIGITAL
> designed the MicroVAX I=97one of the first DIGITAL projects to include
> silicon compilers=97with the consulting help of Carver Meade, a pioneer i=
n
> integrated circuit design. Building on the experience of the MicroVAX I,
> the company soon followed with the more powerful MicroVAX II.
> While the V-11 was designed as a full VAX implementation, the MicroVAX I
> was designed as a VAX subset. The MicroVAX I system was developed
> in the company=92s Seattle facility, headed by Dave Cutler. Because the
> MicroVAX I was a much simpler design than the V-11, and because of the
> use of the silicon compiler tools, it was completed before the V-11.
> ##
>
> ##
> =93The sense I always had was that there were four key technical
> visionaries at
> the beginning of MicroVAX: Dave Cutler, with his creation of the MicroVAX
> I system for early software development; Bob Supnik, who headed up
> MicroVAX chip development and also wrote the microcode; Jesse Lipcon
> who headed up MicroVAX II Server Development; and Dick Hustvedt, who
> drove the MicroVMS Software Strategy.=94
> =97Jay Nichols
> Computer Special Systems, Manager of Engineering
> ##
>
> ##
> Prism: VMS on RISC technology
> DIGITAL began working on RISC technology in 1986 when Jack Smith,
> VP of Operations, tapped Dave Cutler on the shoulder and said, =93You wil=
l be
> RISC Czar for DIGITAL. Organize a program.=94 The program, code named
> Prism, was to develop the company=92s RISC machine. Its operating system
> would embody the next generation of design principles and have a
> compatibility layer for UNIX and VMS.
> ##
>
> ##
> Alpha was very much the =93son of Prism.=94 The primary changes made to
> produce Alpha were for VMS compatibility. The original Prism design had
> serious compatibility problems with the VAX and VMS in two areas=97
> numerical data types and privileged architecture.
> ##
>
> ##
> =93When our customers had beta
> copies of Windows NT, they told us
> that it felt like they were revisiting
> an old friend. That=92s not surprising
> because the chief architect of both
> operating systems was Dave Cutler.
> So there is a natural affinity from a
> technical perspective between the two
> environments. Wes Melling is often
> quoted calling it the =91Cutler effect.=92=94
> =97Mary Ellen Fortier
> Director, OpenVMS Marketing
> ##
Here is a quote from DEC Engineer Gordon Bell. (you can find the full
text online here: http://americanhistory.si.edu/collections/comphist/bell.h=
tm).
According to this, DEC was drifting from project-to-project and really
didn't know what they had under Cutler
Transition from VAX to Prism, MIPS, and Alpha: Losing momentum
Next, I think what really got DEC into the most significant trouble
was the way it dealt with the transition from to RISC and to a 64-bit
address. Dave Cutler had an architecture called Prism that he had
designed at the Seattle lab. That was all done, the manuals were done,
people were working on chips, and the program was going along well.
Meanwhile, MIPS came to DEC and said: =93Gee, you=92re not there with RISC
or your one chip VAXen, you need a RISC machine for your workstations.
Why don=92t you build a workstation on RISC?=94 And DEC did, introduced
it, and said: =93Oh well, we=92ll stay with MIPS.=94 Then they killed the
Prism project and Mr. Cutler left. They killed it, but Ken didn=92t know
that it wasn=92t dead. It was still alive in the semiconductor group and
it sprung up as Alpha. And so that came back several years later.
Meanwhile other people within the company were looking at building a
fast MIPS architecture machine including a group in Palo Alto which
built something called BIPS =96 a billion instructions per second
processor. In fact they have one. They had one about three years ago.
So all of those projects never came to market. And that=92s why I said
when I left the company that you=92ve got to get rid of VAX, you=92ve got
to go open. The companies that I then started and worked with were
open systems companies. They were all UNIX. But it was deciding to go
to Alpha or deciding to do Prism, then killing Prism and going to
MIPS, and then coming back to Alpha and killing MIPS again. DEC could
have survived any of those decisions. It could have stayed with Prism,
got it out there a year earlier, and been significant in the
marketplace. It could have switched to MIPS, and I think that would
have probably been the best strategy. But coming in late, having to
build these very fancy FAB facilities to get the performance was
really costly. And today, there is no way I see that DEC can afford to
be a semiconductor supplier or microprocessor supplier when they have
to build their own, use their own, FAB facilities. So that was a
significant error in judgment and decision making. On the other hand,
the world is better off because Dave Cutler went to Microsoft and
built NT for a much larger market.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/8/2009 10:39:48 AM
|
|
Neil Rieck schrieb:
> True, but if Cutler wanted to immediately write VMS in C then I'm
> thinking he must had a good reason for it. We all know that UNIX
> enjoyed an immediate debugging when it was first rewritten from
> assembler to "C". I wonder (in hindsight) if all these secondary and
> tertiary components (like BLISS and MACRO) might be an indication of
> too many chefs in the VMS kitchen :-)
The dish was different.
Unix was designed to run on just about any hardware,
whereas VMS' sole purpose was to help sell VAXen.
In the latter case one doesn't care much about
portability.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 10:59:57 AM
|
|
On 2009-11-07, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>
> It was never a mystery to me! DEC was totally out of touch with the
> market place. The the RAM for the Rainbow that DEC sold for ~$700, I
> bought at the Trenton Computer Festival for $30 US! The 20 MB disk
> drive that DEC sold for $2200, I bought for $300. The 5-1/4" floppy
> disks that DEC sold for $5 US each, I bought for $0.50 each and
> formatted them myself in spite of the fact that my Rainbow "could not
> properly format a floppy disk!"
>
It's still going on.
I currently have a quote on my desk for a Alpha server. The pricing
for 512MB of memory is over 900 UKP (which is around 1500 USD at current
exchange rates according to Google). (I don't have the exact price as I'm
not at work at the moment).
I don't expect commodity pricing in a server, but that's more than a bit
excessive.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
|
|
0
|
|
|
|
Reply
|
clubley (1184)
|
11/8/2009 12:15:10 PM
|
|
On Nov 8, 7:15=A0am, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2009-11-07, Richard B. Gilbert <rgilber...@comcast.net> wrote:
>
>
>
> > It was never a mystery to me! =A0DEC was totally out of touch with the
> > market place. =A0The the RAM for the Rainbow that DEC sold for ~$700, I
> > bought at the Trenton Computer Festival for $30 US! =A0The 20 MB disk
> > drive that DEC sold for $2200, I bought for $300. =A0The 5-1/4" floppy
> > disks that DEC sold for $5 US each, I bought for $0.50 each and
> > formatted them myself in spite of the fact that my Rainbow "could not
> > properly format a floppy disk!"
>
> It's still going on.
>
> I currently have a quote on my desk for a Alpha server. The pricing
> for 512MB of memory is over 900 UKP (which is around 1500 USD at current
> exchange rates according to Google). (I don't have the exact price as I'm
> not at work at the moment).
>
> I don't expect commodity pricing in a server, but that's more than a bit
> excessive.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world
I agree. A few years back, I purchased a 1GB kit for AS-DS20e and we
paid $700 Canadian. The system ran so fast that we went back to them
for a second kit only to discover that the kit was now $600. We
purchased the kit from www.systemresale.ca who may have partners in
the UK (maybe they would ship to the UK?)
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/8/2009 12:28:05 PM
|
|
Not sure if anyone has seen this book.
Show Stopper!: The Breakneck Race to Create Windows NT and the Next
Generation at Microsoft by G. Pascal Zachary
http://www.amazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/0029356717
Showstopper! is a vivid account of the creation of Microsoft Windows
NT, perhaps the most complex software project ever undertaken. It is
also a portrait of David Cutler, NT's brilliant and, at times,
brutally aggressive chief architect.
Cutler surely ranks as one of the most impressive software engineers
the field has ever produced. After leading the team that created the
VMS operating system for Digital's VAX computer line--an
accomplishment that most would regard as a lifetime achievement--he
went on to conceive and lead the grueling multi-year project that
ultimately produced Windows NT. Both admired and feared by his team,
Cutler would let nothing stand in the way of realizing his design and
often clashed with his programmers, senior Microsoft management, and
even Gates himself. Yet no matter how involved he became in managing
his 100-programmer team, he continued to immerse himself in every
technical detail of the project and write critical portions of the
code himself.
Showstopper! is also a fascinating look at programmer and managerial
culture behind the Microsoft facade. The portraits of the men and
women who created NT not only reveal the brilliance of their work but
the crushing stress and the dislocating effects that new wealth had on
their lives. For some team members, the NT project ultimately
destroyed their marriages, friendships, and virtually every human
relationship outside of work. Showstopper! also reveals the
uncertainties, false starts, and blind alleys that dogged the project
as Microsoft repositioned NT from an improved OS/2 to something that
would ultimately challenge both OS/2 and Unix for the title of the
world's most powerful operating system.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/8/2009 12:30:31 PM
|
|
Neil Rieck wrote:
> On Nov 7, 9:27 pm, Arne Vajh�j <a...@vajhoej.dk> wrote:
>> Neil Rieck wrote:
>>> Since any idiot can put up a web page these days, you know it all
>>> can't be true. So imagine my surprise when I bumped into this:
>>> http://radsoft.net/rants/20040831,00.shtml
>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but loved
>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>> turned down flat. Several years later he found himself in Seattle and
>>> essentially was doing the rewrite in C when word came DEC were tired
>>> of him.</quote>
>>> This article contains lots of other (possibly) questionable facts, but
>>> think about the statement above "rewrite VMS in C". If this had
>>> happened, we would have VMS or OpenVMS on any platform including
>>> x86-64
>> If the various owners of VMS had believed in the market for
>> VMS/x86-64, then I don't think getting Bliss and Macro-32 for
>> x86-64 would have been the showstopper. My guess is that it
>> would have been a small part of the overall project. Porting
>> an OS to a new platform is more than just building the
>> source code.
>
> True, but if Cutler wanted to immediately write VMS in C then I'm
> thinking he must had a good reason for it. We all know that UNIX
> enjoyed an immediate debugging when it was first rewritten from
> assembler to "C". I wonder (in hindsight) if all these secondary and
> tertiary components (like BLISS and MACRO) might be an indication of
> too many chefs in the VMS kitchen :-)
Today OS in C may be the standard.
But back in the mid 70's where the VMS decision were made, then
it was not the standard.
And my understanding is that VMS inherited this from
the PDP-11 OS's.
And when it was decided for them, then C was not available
(at least according to many C was invented to port Unix
to PDP-11).
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/8/2009 1:39:10 PM
|
|
In article <hd59v6$1pi$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> George Cook schrieb:
>> In article <hd49hq$m91$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
>>
>> No. It was not. One more time, from Wikipedia:
>>
>> "The Alpha architecture was sold, along with most parts of DEC,
>> to Compaq in 1998. Compaq, already an Intel customer, decided to
>> phase out Alpha in favor of the forthcoming Hewlett-Packard/Intel
>> Itanium architecture, and sold all Alpha intellectual property to
>> Intel in 2001"
>>
>> I suspect that you are confusing the sale of the Hudson fab with
>> the sale of the IP.
>>
>
> No, I'm well aware of the difference,
> but I think it does not matter really.
I guess it may not "really" matter in the grand scheme of the
universe, but in that case nothing at all matters "really". In
1997, DEC still claimed (and appeared) to believe in Alpha. I
went to all the same non-disclosure presentations as I suspect
others here did.
> The 1997 deal with intel (and a similar one with Samsung)
> effectively marked alpha's sell out,
> even if DEC kept IP rights on paper.
> Moreover,
> intel agreed to manufacture Alpha, a possible competitor to their
> upcoming IA64.
> At about the same time it was planned to port DEC Unix to IA64.
> All that makes only sense if alpha's death was already sealed,
> maybe secretly, with the 1997 deal.
Sounds a lot like "double secret probation" to me. IBM also agreed
to manufacture Alpha. If nothing else IBM is not stupid, and would not
have gotten involved in some super secret conspiracy to kill Alpha.
George Cook
WVNET
|
|
0
|
|
|
|
Reply
|
cook (261)
|
11/8/2009 2:53:45 PM
|
|
George Cook schrieb:
>
> I guess it may not "really" matter in the grand scheme of the
> universe, but in that case nothing at all matters "really". In
> 1997, DEC still claimed (and appeared) to believe in Alpha. I
> went to all the same non-disclosure presentations as I suspect
> others here did.
I think we all know the value of committments on paper.
Actions speak louder than words.
Handing over the flagship product to a direct competitor
in 1997, just 5 years after Alpha's introduction,
sent a strong negative signal.
It really didn't matter whether DEC still kept IP rights
or not.
Customers' comments in the trade press (at least in German),
including DECUS board members, were mainly negative,
certainly not enthusiastic.
> Sounds a lot like "double secret probation" to me.
What I hear is, that the guys from Microprocessor Report
came up with that "secret amendments" assumption.
But it makes a lot more sense to me than the rose-coloured pictures,
IMHO.
> IBM also agreed
> to manufacture Alpha. If nothing else IBM is not stupid, and would not
> have gotten involved in some super secret conspiracy to kill Alpha.
No conspiracy here. From 2000 onwards IBM manufactured Alpha's,
just as they produced HP's PA-RISC chips.
By that time such things weren't taboo anymore,
and no problem either, since both were a dying breed anyway.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 4:21:53 PM
|
|
On Nov 8, 8:39=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Neil Rieck wrote:
> > On Nov 7, 9:27 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> >> Neil Rieck wrote:
> >>> Since any idiot can put up a web page these days, you know it all
> >>> can't be true. So imagine my surprise when I bumped into this:
> >>>http://radsoft.net/rants/20040831,00.shtml
> >>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but love=
d
> >>> C. As soon as he'd finished VMS he suggested the rewrite. He was
> >>> turned down flat. Several years later he found himself in Seattle and
> >>> essentially was doing the rewrite in C when word came DEC were tired
> >>> of him.</quote>
> >>> This article contains lots of other (possibly) questionable facts, bu=
t
> >>> think about the statement above "rewrite VMS in C". If this had
> >>> happened, we would have VMS or OpenVMS on any platform including
> >>> x86-64
> >> If the various owners of VMS had believed in the market for
> >> VMS/x86-64, then I don't think getting Bliss and Macro-32 for
> >> x86-64 would have been the showstopper. My guess is that it
> >> would have been a small part of the overall project. Porting
> >> an OS to a new platform is more than just building the
> >> source code.
>
> > True, but if Cutler wanted to immediately write VMS in C then I'm
> > thinking he must had a good reason for it. We all know that UNIX
> > enjoyed an immediate debugging when it was first rewritten from
> > assembler to "C". I wonder (in hindsight) if all these secondary and
> > tertiary components (like BLISS and MACRO) might be an indication of
> > too many chefs in the VMS kitchen :-)
>
> Today OS in C may be the standard.
>
> But back in the mid 70's where the VMS decision were made, then
> it was not the standard.
>
> And my understanding is that VMS inherited this from
> the PDP-11 OS's.
>
> And when it was decided for them, then C was not available
> (at least according to many C was invented to port Unix
> to PDP-11).
>
> Arne
As I have mentioned to others privately, if DEC would have listened to
Cutler and rewritten VMS in C, then porting VMS to Alpha, Itanium and
anything else would already have saved them tons of money.
Now if it is HP's intention to never port OpenVMS ever again, then
they should just sit back and milk it for all it's worth. However,
they might wish to consider tasking their Indian code-warriors to
quietly start a conversion to C. Even if the project was never fully
completed, future code maintenance and porting efforts would benefit
from this action.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/8/2009 6:15:03 PM
|
|
On Nov 7, 2009, at 8:18 PM, Arne Vajh=F8j wrote:
> Michael Kraemer wrote:
>> Allen, Daniel P. schrieb:
>>>> On Behalf Of Michael Kraemer
>>>> Neil Rieck <n.rieck@sympatico.ca> writes:
>>>> "Dave took his engineers and his new operating system called =20
>>>> 'Prism' cross town
>>>> to the Redmond campus."
>>>
>>>> How that?
>>>> Presumably everything he did at M$ would be IP of DEC,
>>>> so he couldn't just "take it with him", unless DEC permitted it.
>>>> AFAIK he left as a "disgruntled employee" so DEC would have had
>>>> even less reason to give it away.
>>>
>>> Speaking as an old personal friend of one of his top team members =20=
>>> I think I can say that the description is reasonably accurate.
>> So this means he stole DECs IP and got away with it?
>> (where are the IP zealots when they're needed?)
>
> Would it have made a big difference?
>
> VMS was not the only multiuser OS.
>
> They could have used ideas from Unix, Multics etc. instead.
>
> No NT user, sysadm or user mode code developer could tell
> the difference anyway.
>
> It would have been different from driver writers and
> other kernel mode code developers, but even though they may
> be the guys that know most about the OS, then I don't think
> they have much influence on decisions on what OS to use.
>
> Arne
Not to mention that there is at least as much "borrowed" technology =20
from UNIX in NT there is from VMS.
And when you hit Windows XP, there is far more UNIX based technology =20
cloned into NT than from VMS.
I have never fully understood this, since in some ways, VMS is clearly =20=
superior to the contemporary UNIX
implementations of that time.
I suppose it was that DEC was still shuttered tightly with the idea =20
that computers would never be ubiquitious,
and therefor they should squeeze every nickle out of a limited market. =20=
A shame that Olsen never realized
it was an essentially unlimited market. (*sigh*)
HP is faced with that legacy. If they were to release VMS as a free =20
OS, it would invade the data center's of the
world like wildfire. Especially if they went ahead and gave in to =20
porting it to Intel.
-Paul
|
|
0
|
|
|
|
Reply
|
paul298 (265)
|
11/8/2009 6:31:07 PM
|
|
On Nov 7, 2009, at 8:25 PM, Arne Vajh=F8j wrote:
> Bill Gunshannon wrote:
>> In article =
<78797018-2cfb-402d-9eb9-b1f109c76092@p8g2000yqb.googlegroups.com=20
>> >,
>> Neil Rieck <n.rieck@sympatico.ca> writes:
>>> Since any idiot can put up a web page these days, you know it all
>>> can't be true. So imagine my surprise when I bumped into this:
>>>
>>> http://radsoft.net/rants/20040831,00.shtml
>>>
>>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but =20
>>> loved
>>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>>> turned down flat. Several years later he found himself in Seattle =20=
>>> and
>>> essentially was doing the rewrite in C when word came DEC were tired
>>> of him.</quote>
>>>
>>> This article contains lots of other (possibly) questionable facts, =20=
>>> but
>>> think about the statement above "rewrite VMS in C". If this had
>>> happened, we would have VMS or OpenVMS on any platform including
>>> x86-64
>> That's funny. I have always wanted to see a project started to take
>> FreeBSD and rewrite it in Pascal or even better, Ada. :-)
>> Oh well, I suppose that could be another of those retirement projects
>> I keep piling up.
>
> C is undoubtedly easy to write OS code in (no surprise since
> it was designed for this type of purpose), but it has proven to
> relative hard to avoid buffer overruns, memory leaks etc.
> (buffer runs are probably more relevant than memory leaks for OS).
>
> It would be rather interesting with an OS in Ada or Modula-2/Oberon
> (standard Pascal lacks too much - DEC Pascal may do).
>
> Arne
> _______________________________________________
Mmm- it is not difficult to avoid buffer overruns or memory leaks or =20
any other
problems that a lot of people think are endemic to C. You just have to =20=
know
what you are doing, and *that* is true no matter what language you use.
Indeed, it is true of *anything* you do, but especially so in an =20
programming
exercise.
-Paul
|
|
0
|
|
|
|
Reply
|
paul298 (265)
|
11/8/2009 6:33:56 PM
|
|
In article <dcc19519-d252-4324-a3e3-fde4c3505ad3@s15g2000yqs.googlegroups.com>, Neil Rieck <n.rieck@sympatico.ca> writes:
>On Nov 8, 8:39=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
>> Neil Rieck wrote:
>> > On Nov 7, 9:27 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
>> >> Neil Rieck wrote:
>> >>> Since any idiot can put up a web page these days, you know it all
>> >>> can't be true. So imagine my surprise when I bumped into this:
>> >>>http://radsoft.net/rants/20040831,00.shtml
>> >>> <quote>Dave always wanted to rewrite VMS in C. He hated Unix but love=
>d
>> >>> C. As soon as he'd finished VMS he suggested the rewrite. He was
>> >>> turned down flat. Several years later he found himself in Seattle and
>> >>> essentially was doing the rewrite in C when word came DEC were tired
>> >>> of him.</quote>
>> >>> This article contains lots of other (possibly) questionable facts, bu=
>t
>> >>> think about the statement above "rewrite VMS in C". If this had
>> >>> happened, we would have VMS or OpenVMS on any platform including
>> >>> x86-64
>> >> If the various owners of VMS had believed in the market for
>> >> VMS/x86-64, then I don't think getting Bliss and Macro-32 for
>> >> x86-64 would have been the showstopper. My guess is that it
>> >> would have been a small part of the overall project. Porting
>> >> an OS to a new platform is more than just building the
>> >> source code.
>>
>> > True, but if Cutler wanted to immediately write VMS in C then I'm
>> > thinking he must had a good reason for it. We all know that UNIX
>> > enjoyed an immediate debugging when it was first rewritten from
>> > assembler to "C". I wonder (in hindsight) if all these secondary and
>> > tertiary components (like BLISS and MACRO) might be an indication of
>> > too many chefs in the VMS kitchen :-)
>>
>> Today OS in C may be the standard.
>>
>> But back in the mid 70's where the VMS decision were made, then
>> it was not the standard.
>>
>> And my understanding is that VMS inherited this from
>> the PDP-11 OS's.
>>
>> And when it was decided for them, then C was not available
>> (at least according to many C was invented to port Unix
>> to PDP-11).
>>
>> Arne
>
>As I have mentioned to others privately, if DEC would have listened to
>Cutler and rewritten VMS in C, then porting VMS to Alpha, Itanium and
>anything else would already have saved them tons of money.
Keep it in Bliss and write a compiler for the target architecture,
if you believe it is that simple, would be the better solution.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/8/2009 8:14:11 PM
|
|
Michael Kraemer wrote:
> I think we all know the value of committments on paper.
> Actions speak louder than words.
> Handing over the flagship product to a direct competitor
> in 1997, just 5 years after Alpha's introduction,
> sent a strong negative signal.
It wasn't so much the gift of the chip manufacturing that was the issue
but rather the fine print at the end of the deal where Digital committed
to porting Digital Unix (Tru64) to that then imaginary IA64 thing, but
did not commit to porting VMS to it. It is ironic that under HP, the
opposite happened.
The theft of Alpha IP happened before Pentium 3 was released, years
before. DEC let it go unchallenged for years before finally using that
card to get something from Intel (releive DEC of its chip business which
Compaq didn't want).
> Customers' comments in the trade press (at least in German),
> including DECUS board members, were mainly negative,
> certainly not enthusiastic.
At that point, it wasn't so much Alpha but Digital. People noticed
Palmer breaking up the company piece by piece.
> No conspiracy here. From 2000 onwards IBM manufactured Alpha's,
> just as they produced HP's PA-RISC chips.
From the time when Digital sold its chip manufacturing business, it was
perfectly normal that Digital would outsource manufacturing of its own
chips to the remaining manufacturers, whether Intel, IBM or any other.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/8/2009 10:24:26 PM
|
|
Neil Rieck wrote:
> As I have mentioned to others privately, if DEC would have listened to
> Cutler and rewritten VMS in C, then porting VMS to Alpha, Itanium and
> anything else would already have saved them tons of money.
I disagree with this. When DEC ported VMS to Alpha, it wasn't the
compilers that cost it money, it was the fact that they went with a
split code base.
When they ported from Alpha to that IA64 thing, they decided to do it
right and make the code more portable with a single code base. Once that
work is done, porting to another platform becomes much easier.
It is my understanding that all they need is a native assembler for the
really deep down stuff, MACRO compiler, C, and BLISS. Anything else ? I
think that they ported the last bits written in PL1 to something else,
right ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/8/2009 10:30:24 PM
|
|
On Nov 8, 12:15=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2009-11-07, Richard B. Gilbert <rgilber...@comcast.net> wrote:
>
>
>
> > It was never a mystery to me! =A0DEC was totally out of touch with the
> > market place. =A0The the RAM for the Rainbow that DEC sold for ~$700, I
> > bought at the Trenton Computer Festival for $30 US! =A0The 20 MB disk
> > drive that DEC sold for $2200, I bought for $300. =A0The 5-1/4" floppy
> > disks that DEC sold for $5 US each, I bought for $0.50 each and
> > formatted them myself in spite of the fact that my Rainbow "could not
> > properly format a floppy disk!"
>
> It's still going on.
>
> I currently have a quote on my desk for a Alpha server. The pricing
> for 512MB of memory is over 900 UKP (which is around 1500 USD at current
> exchange rates according to Google). (I don't have the exact price as I'm
> not at work at the moment).
>
> I don't expect commodity pricing in a server, but that's more than a bit
> excessive.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world
I don't know what memory you're buying but the fact it's for an Alpha
(Server) means its a long way from current generation memory and
therefore whether it's for an AlphaServer or a similar era Proliant or
whatever, you get to pay a premium for legacy memory. You're also
almost certainly paying the premium for ECC memory. ECC memory is more
expensive than non-ECC, far more than you'd justify just by the extra
bits, whether it's for DEC or anybody else. And you're payint the
premium for someone holding stock long after the volume market has
moved on.
Find out what kind of memory it is, find an equivalent memory for a
Proliant and compare the prices. If you want cheaper and unwarranted,
buy the Proliant (at your own risk :)). If you want really cheap
desktop-style prices, you have to go non-ECC, and that probably just
doesn't work. In between, there are various shades of grey; not all
1GB DDR400 36bit DIMMs are equal, for example. If you want someone to
warrant that it's going to work, someone's going to have to carry the
risk. You can carry that risk yourself by buying cheap, or you can pay
to have someone worry about it for you.
A similar story used to apply with DEC vs non-DEC SCSI drives. I used
to have one particular system builder that bought assorted non-DEC
drives and then complained when odd storage-related things happened.
"Reproduce the problem with any drive listed on the SPD and we can
talk about it further". His problems never were reproducible. RAM's
simpler than SCSI (e.g. no firmware) but not all RAM of a given size
and technology is the same.
One last thing re RAM prices: the cheap RAM traditionally came from
people buying it on the spot market whereas DEC in general bought
their RAM on contract at committed prices (and in committed
quantities) many months ahead. This mean that DEC prices were often
late following the market down, but it also meant that in times of RAM
shortage, DEC had a chance of getting supplies, whereas the folks
relying on the spot market could advertise whatever prices they want,
it didn't matter because the spot market folks had no chance of
actually delivering anything, because the contracted RAM customers had
all the supplies. You may not have known this, it wasn't the only
reason why DEC prices were seen as OTT, but it was a factor in the RAM
prices.
I don't know if there was a spot market as well as a contract market
in SCSI storage but it wouldn't be a surprise if there was and if the
same price-related logic applied to storage as well as RAM.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/8/2009 10:58:33 PM
|
|
JF Mezei schrieb:
> It wasn't so much the gift of the chip manufacturing that was the issue
> but rather the fine print at the end of the deal where Digital committed
> to porting Digital Unix (Tru64) to that then imaginary IA64 thing,
Sure. It doesn't require a lot of conspiracy theory
to guess what was negotiated behind the scenes.
Sell off Alpha to intel, who will manufacture it
as a stop-gap until Itanics arrive.
> but
> did not commit to porting VMS to it. It is ironic that under HP, the
> opposite happened.
well, collateral damage. HP found itself with two Unices
(three if one includes Linux) in the portfolio,
so the stepchild with least marketshare had to go.
This time it was an advantage that there is no other flavor of VMS.
> The theft of Alpha IP happened before Pentium 3 was released, years
> before. DEC let it go unchallenged for years before finally using that
> card to get something from Intel (releive DEC of its chip business which
> Compaq didn't want).
Maybe the "theft" wasn't that evident.
IIRC it was never proven that intel "stole" anything.
> At that point, it wasn't so much Alpha but Digital. People noticed
> Palmer breaking up the company piece by piece.
1997 it was quite a bit late to recognize that.
Alpha was about the last part to sell before the rest
went to Compaq.
> From the time when Digital sold its chip manufacturing business, it was
> perfectly normal that Digital would outsource manufacturing of its own
> chips to the remaining manufacturers, whether Intel, IBM or any other.
If they had such a fabless Alpha strategy right from the start,
just as Sun and SGI had with their CPUs,
they might have fared much better economically.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/8/2009 11:08:23 PM
|
|
On Nov 8, 6:08=A0pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
[...snip...]
>
> well, collateral damage. HP found itself with two Unices
> (three if one includes Linux) in the portfolio,
> so the stepchild with least marketshare had to go.
> This time it was an advantage that there is no other flavor of VMS.
>
> > The theft of Alpha IP happened before Pentium 3 was released, years
> > before. =A0DEC let it go unchallenged for years before finally using th=
at
> > card to get something from Intel (releive DEC of its chip business whic=
h
> > Compaq didn't want).
>
> Maybe the "theft" wasn't that evident.
> IIRC it was never proven that intel "stole" anything.
>
> > At that point, it wasn't so much Alpha but Digital. People noticed
> > Palmer breaking up the company piece by piece.
>
> 1997 it was quite a bit late to recognize that.
> Alpha was about the last part to sell before the rest
> went to Compaq.
>
> > From the time when Digital sold its chip manufacturing business, it was
> > perfectly normal that Digital would outsource manufacturing of its own
> > chips to the remaining manufacturers, whether Intel, IBM or any other.
>
> If they had such a fabless Alpha strategy right from the start,
> just as Sun and SGI had with their CPUs,
> they might have fared much better economically.
When you go back and read documents like this:
http://americanhistory.si.edu/collections/comphist/bell.htm#Transition%20fr=
om%20VAX%20to%20Prism
....you get the feeling that various groups of technical people were
pulling DEC in various directions while management was not
coordinating the activities of these very talented people. Statements
like this:
<quote>
Then they (DEC management) killed the Prism project and Mr. Cutler
left. They killed it, but Ken (Olsen) didn=92t know that it wasn=92t dead.
It was still alive in the semiconductor group and it sprung up as
Alpha.
</quote>
....indicates to me that "either the semiconductor group was not
notified that PRISM was dead" or "the semiconductor group ignored the
order to stop working on it" or "the semiconductor group was so far
along that DEC management told them to finish their current
activities".
Any one of these scenarios means that Alpha was as welcome as an
unplanned birth (at least to some people). This is strange because DEC
manufactured and sold way more Alpha-based equipment than VAX.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/9/2009 11:00:29 AM
|
|
Neil Rieck wrote:
> ...indicates to me that "either the semiconductor group was not
> notified that PRISM was dead" or "the semiconductor group ignored the
> order to stop working on it" or "the semiconductor group was so far
> along that DEC management told them to finish their current
> activities".
Dead is dead, long live dec is a book that analyses much of what was
wrong at DEC. Fairly depressing read.
From what I remember in that book, it wasn't quite like that.
At the same time, DEC has multiple projects going on, including the VAX
9000, prism and the nvax project (CMOS). Olsen rationalised it and
focused on the 9000. When the 9000 turned out to be an expensive dud
they took thge bits and pieces they had thrown in the trash can and
started the formal nvax and the alpha projects.
The VAX 9000 was a good personification of DEC's problem: Trying to
build mainframes to compete against IBM while ignoring the fact that the
world was moving towards smaller, faster and cheaper machines.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/9/2009 12:12:25 PM
|
|
On Mon, 09 Nov 2009 07:12:25 -0500, JF Mezei wrote:
> Dead is dead, long live dec is a book that analyses much of what was
> wrong at DEC. Fairly depressing read.
Just about to start reading my copy...!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/9/2009 12:36:19 PM
|
|
On Nov 9, 11:00=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> On Nov 8, 6:08=A0pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
> [...snip...]
>
>
>
>
>
> > well, collateral damage. HP found itself with two Unices
> > (three if one includes Linux) in the portfolio,
> > so the stepchild with least marketshare had to go.
> > This time it was an advantage that there is no other flavor of VMS.
>
> > > The theft of Alpha IP happened before Pentium 3 was released, years
> > > before. =A0DEC let it go unchallenged for years before finally using =
that
> > > card to get something from Intel (releive DEC of its chip business wh=
ich
> > > Compaq didn't want).
>
> > Maybe the "theft" wasn't that evident.
> > IIRC it was never proven that intel "stole" anything.
>
> > > At that point, it wasn't so much Alpha but Digital. People noticed
> > > Palmer breaking up the company piece by piece.
>
> > 1997 it was quite a bit late to recognize that.
> > Alpha was about the last part to sell before the rest
> > went to Compaq.
>
> > > From the time when Digital sold its chip manufacturing business, it w=
as
> > > perfectly normal that Digital would outsource manufacturing of its ow=
n
> > > chips to the remaining manufacturers, whether Intel, IBM or any other=
..
>
> > If they had such a fabless Alpha strategy right from the start,
> > just as Sun and SGI had with their CPUs,
> > they might have fared much better economically.
>
> When you go back and read documents like this:
>
> http://americanhistory.si.edu/collections/comphist/bell.htm#Transitio...
>
> ...you get the feeling that various groups of technical people were
> pulling DEC in various directions while management was not
> coordinating the activities of these very talented people. Statements
> like this:
>
> <quote>
> Then they (DEC management) killed the Prism project and Mr. Cutler
> left. They killed it, but Ken (Olsen) didn=92t know that it wasn=92t dead=
..
> It was still alive in the semiconductor group and it sprung up as
> Alpha.
> </quote>
>
> ...indicates to me that "either the semiconductor group was not
> notified that PRISM was dead" or "the semiconductor group ignored the
> order to stop working on it" or "the semiconductor group was so far
> along that DEC management told them to finish their current
> activities".
>
> Any one of these scenarios means that Alpha was as welcome as an
> unplanned birth (at least to some people). This is strange because DEC
> manufactured and sold way more Alpha-based equipment than VAX.
>
> NSR
With the greatest possible respect to the author, and even bearing in
mind the interview is in 1995 (a couple of years after NT first
emerged) what on earth is this quote about:
"Until Microsoft, I though DEC had the greatest engineering
organization, but Microsoft is substantially better."
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/9/2009 12:46:42 PM
|
|
In article <d25c4548-34e1-4d28-b7a0-ef99b9f8683f@37g2000yqm.googlegroups.com>, Neil Rieck <n.rieck@sympatico.ca> writes:
>
> I couldn't agree more. But whenever a new hardware platform appears,
> it is always *nix/c that gets there first because, as we all know, C
> is not much more than a portable assembler. Is the first port any
> good? Nope, it is usually just a very first step. Regarding your
> comments on MACRO32, I guess I was thinking more of other weirdness
> like BLISS.
In every UNIX port, there's some small architecture dependent code
that has to be worked. No language can change that. If that
weren't so, we'd probably say "UNIX recompile" instead of "UNIX
port".
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 12:51:20 PM
|
|
In article <7lko03F3e5hd8U4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>
> Yes, but since Vista has broken my scanner driver, it may take a while...
Get a Macintosh.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 1:11:35 PM
|
|
In article <4af62c13$0$281$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
> C is undoubtedly easy to write OS code in (no surprise since
> it was designed for this type of purpose), but it has proven to
> relative hard to avoid buffer overruns, memory leaks etc.
> (buffer runs are probably more relevant than memory leaks for OS).
BLISS was designed to write OS code in, but it does not have a
reputation for making it easy to write OS code.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 1:15:28 PM
|
|
In article <4af62d35$0$281$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> Not any platform.
>
> But if there is let us call it flexibility to redesign to match
> the new HW, then I would assume that all HW capable of running
> OS/400, Unix, Linux, Windows NT could be made to run VMS.
VMS has needs that UNIX and Linux do not. I'm not sure of OS/400,
or Windows.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 1:16:45 PM
|
|
In article <d75d3d4b-acf8-4b92-a8ba-1d1c21386137@v36g2000yqv.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
{...snip...}
>"Until Microsoft, I though DEC had the greatest engineering
>organization, but Microsoft is substantially better."
What blaspheming fuckwit authored that statement? Albeit non-actionable,
it is absolutely reprehensible to make libelous and defamatory statements
about the dead.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/9/2009 1:20:48 PM
|
|
In article <4af62a8e$0$269$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
> Would it have made a big difference?
>
> VMS was not the only multiuser OS.
>
> They could have used ideas from Unix, Multics etc. instead.
Does it make a difference? Compare MacOS X, which has a Mac GUI on
top of a well known UNIX kernel, with Windows, which has it's own
kernel with some small familiarities between IO subsystems with VMS.
Why is it so many of us VMS enthusiasts love those Mac commercials?
Perhaps we find quality and reliability attractive in both the
software we use as well as the software we write?
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 1:22:52 PM
|
|
>>"Until Microsoft, I though DEC had the greatest engineering
>>organization, but Microsoft is substantially better."
If it weren't for the first 2 words, the statement would be tolerable
since there is no longer any DEC engineering, so even Microsoft's dismal
engineering would be better.
However, when you consider Microsoft's engineering when Microsoft
started, it was closer to "how to steal other people's ideas/software"
than writing your own. Microsfoot lived for at least a decade without
any true engineering of its own.
I may be biased (not not completely biased, I don't yet have apple
branded socks and underwear :-), I'd say Apple has some great
engineering these days. Extremey innovative industrial designers, and
ability to integrate technologies (and open source software) into a
slick/sleek product.
Unlike DEC, Apple knows how to advertise. And Apple makes it easy to buy
their products. And their web site is far better organised than HP's.
Customer service ? Server got delayed by about a week. They upgraded the
delivery to "express" at no charge AND included a free iPOD nano with
it. Did Digital ever do that ? Nop because Digital didn't speak to small
customers.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/9/2009 1:50:12 PM
|
|
On Mon, 09 Nov 2009 07:11:35 -0600, Bob Koehler wrote:
> In article <7lko03F3e5hd8U4@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>>
>> Yes, but since Vista has broken my scanner driver, it may take a
>> while...
>
> Get a Macintosh.
No thanks. I actually thought of it recently, in terms of getting a
machine for my son. But 100% mark-up over a non-Mac machine changed my
mind.
Anyway, fixed the scanner now!
I'm very happy with FreeBSD for my everyday work, anyway...having started
with UNIX over 33 years ago...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/9/2009 2:51:09 PM
|
|
In article <4af6c9fc$0$273$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
> And my understanding is that VMS inherited this from
> the PDP-11 OS's.
DEC OS's for PDP-11 tended to be written in Macro-11. A little bit
of BLISS-11 alter on was used for portable stuff like EDT. VMS
was initially mostly Macro-32 and BLISS; much of the Macro-32
was eventually replaced. Lots of other languages were also used.
> And when it was decided for them, then C was not available
> (at least according to many C was invented to port Unix
> to PDP-11).
UNIX was ported to PDP-11, using C, about a decade before VMS
was started. So DEC could have written a C compiler for VAX and
large parts of VMS in C if they'd wanted to. DEC didn't write a
C compiler for VAX early on because no one outside of a few UNIX
users were using C. UNIX was the broken down OS that AT&T couldn't
find customers for. The handwriting on the wall showed that there
was clearly no future for C and/or UNIX.
Then AT&T let some kids at Berkley have a copy of the UNIX source.
They ran it on PDP-11, ported it to VAX, added virtual memory, added
TCP/IP, and somehow got others interested in it. Start up vendors
like Sun and Apollo found they could throw together some commodity
hardware, toss BSD UNIX on it much faster than they could write their
own OS, and sell workstations. When the vendors switched to RISC
they blew away the performance of VAXen and people grudgingly learned
to survive using an OS with a late 1960's human interface, writing
code in a Frankenstein language that escaped from the lab, on hardware
that could grind numbers fast and cheap.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 3:06:59 PM
|
|
In article <mailman.9.1257705243.9279.info-vax_rbnsn.com@rbnsn.com>, Paul Raulerson <paul@raulersons.com> writes:
> Mmm- it is not difficult to avoid buffer overruns or memory leaks or =20
> any other
> problems that a lot of people think are endemic to C. You just have to =20=
>
> know
> what you are doing, and *that* is true no matter what language you use.
Been there, argued that. Why does it keep coming around? Are the
ivory towers still teaching that mantra to the kiddies?
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 3:08:25 PM
|
|
John Wallace wrote:
> On Nov 9, 11:00 am, Neil Rieck <n.ri...@sympatico.ca> wrote:
>> On Nov 8, 6:08 pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
>> [...snip...]
>>
>>
>>
>>
>>
>>> well, collateral damage. HP found itself with two Unices
>>> (three if one includes Linux) in the portfolio,
>>> so the stepchild with least marketshare had to go.
>>> This time it was an advantage that there is no other flavor of VMS.
>>>> The theft of Alpha IP happened before Pentium 3 was released, years
>>>> before. DEC let it go unchallenged for years before finally using that
>>>> card to get something from Intel (releive DEC of its chip business which
>>>> Compaq didn't want).
>>> Maybe the "theft" wasn't that evident.
>>> IIRC it was never proven that intel "stole" anything.
>>>> At that point, it wasn't so much Alpha but Digital. People noticed
>>>> Palmer breaking up the company piece by piece.
>>> 1997 it was quite a bit late to recognize that.
>>> Alpha was about the last part to sell before the rest
>>> went to Compaq.
>>>> From the time when Digital sold its chip manufacturing business, it was
>>>> perfectly normal that Digital would outsource manufacturing of its own
>>>> chips to the remaining manufacturers, whether Intel, IBM or any other.
>>> If they had such a fabless Alpha strategy right from the start,
>>> just as Sun and SGI had with their CPUs,
>>> they might have fared much better economically.
>> When you go back and read documents like this:
>>
>> http://americanhistory.si.edu/collections/comphist/bell.htm#Transitio...
>>
>> ...you get the feeling that various groups of technical people were
>> pulling DEC in various directions while management was not
>> coordinating the activities of these very talented people. Statements
>> like this:
>>
>> <quote>
>> Then they (DEC management) killed the Prism project and Mr. Cutler
>> left. They killed it, but Ken (Olsen) didn�t know that it wasn�t dead.
>> It was still alive in the semiconductor group and it sprung up as
>> Alpha.
>> </quote>
>>
>> ...indicates to me that "either the semiconductor group was not
>> notified that PRISM was dead" or "the semiconductor group ignored the
>> order to stop working on it" or "the semiconductor group was so far
>> along that DEC management told them to finish their current
>> activities".
>>
>> Any one of these scenarios means that Alpha was as welcome as an
>> unplanned birth (at least to some people). This is strange because DEC
>> manufactured and sold way more Alpha-based equipment than VAX.
>>
>> NSR
>
> With the greatest possible respect to the author, and even bearing in
> mind the interview is in 1995 (a couple of years after NT first
> emerged) what on earth is this quote about:
> "Until Microsoft, I though DEC had the greatest engineering
> organization, but Microsoft is substantially better."
DEC is gone! Microsoft is still here. That says it all!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/9/2009 4:23:47 PM
|
|
On Mon, 09 Nov 2009 09:06:59 -0600, Bob Koehler wrote:
>> And when it was decided for them, then C was not available (at least
>> according to many C was invented to port Unix to PDP-11).
>
> UNIX was ported to PDP-11, using C, about a decade before VMS was
> started. So DEC could have written a C compiler for VAX and large
> parts of VMS in C if they'd wanted to. DEC didn't write a C compiler
> for VAX early on because no one outside of a few UNIX users were
> using C. UNIX was the broken down OS that AT&T couldn't find
> customers for. The handwriting on the wall showed that there was
> clearly no future for C and/or UNIX.
>
> Then AT&T let some kids at Berkley have a copy of the UNIX source.
> They ran it on PDP-11, ported it to VAX, added virtual memory, added
> TCP/IP, and somehow got others interested in it. Start up vendors
> like Sun and Apollo found they could throw together some commodity
> hardware, toss BSD UNIX on it much faster than they could write their
> own OS, and sell workstations. When the vendors switched to RISC
> they blew away the performance of VAXen and people grudgingly learned
> to survive using an OS with a late 1960's human interface, writing
> code in a Frankenstein language that escaped from the lab, on
> hardware that could grind numbers fast and cheap.
There are so many inaccuracies there I don't even know where to start...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/9/2009 5:03:39 PM
|
|
On Mon, 09 Nov 2009 09:06:59 -0600, Bob Koehler wrote:
Here's a couple, for starters...
> UNIX was ported to PDP-11, using C, about a decade before VMS
> was started.
In 1973. Are you saying that VMS was started in 1983? I think not...
> So DEC could have written a C compiler for VAX and
> large parts of VMS in C if they'd wanted to. DEC didn't write a C
> compiler for VAX early on because no one outside of a few UNIX users
> were using C. UNIX was the broken down OS that AT&T couldn't find
> customers for.
It was a research project for many years. It had to be pried from their
hands to be used outside Bell Labs.
> The handwriting on the wall showed that there was
> clearly no future for C and/or UNIX.
It survives, though.
> Then AT&T let some kids at Berkley have a copy of the UNIX source.
> They ran it on PDP-11, ported it to VAX
AT&T ported it to the VAX before that.
> added virtual memory
AT&T did that first.
> added TCP/IP
There was an ARPA grant for that, I believe.
> and somehow got others interested in it. Start up vendors
> like Sun and Apollo found they could throw together some commodity
> hardware, toss BSD UNIX on it much faster than they could write their
> own OS, and sell workstations.
But they weren't selling BSD at all....it wasn't a commercial product
until much later. They were selling the AT&T version.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/9/2009 5:15:47 PM
|
|
On Mon, 09 Nov 2009 17:15:47 +0000, Bob Eager wrote:
>> added virtual memory
>
> AT&T did that first.
My apologies. Despite its name, UNIX/32V didn't support virtual memory.
3BSD added that..
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/9/2009 5:25:48 PM
|
|
On Nov 9, 1:20=A0pm, VAXman- @SendSpamHere.ORG wrote:
> In article <d75d3d4b-acf8-4b92-a8ba-1d1c21386...@v36g2000yqv.googlegroups=
..com>, John Wallace <johnwalla...@yahoo.co.uk> writes:
> {...snip...}
>
> >"Until Microsoft, I though DEC had the greatest engineering
> >organization, but Microsoft is substantially better."
>
> What blaspheming fuckwit authored that statement? =A0Albeit non-actionabl=
e,
> it is absolutely reprehensible to make libelous and defamatory statements
> about the dead. =A0
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESIS(=
dot)ORG
>
> =A0http://www.quirkfactory.com/popart/asskey/eqn2.png
>
> =A0 "Well my son, life is like a beanstalk, isn't it?"
Apologies for the unintended effects on anybody's blood pressure.
The author of that particular statement is a name that will be
somewhat known round here: Gordon Bell. I sort of assumed it would
have been obvious from NSR's context, but obviously I assumed wrong,
sorry.
Mr Bell joined Microsoft's Bay Area Research Centre in 1995:
http://research.microsoft.com/en-us/people/gbell/
Personally I can't see any basis for the claim unless perhaps he's
talking about quality of buildings and facilities and other such staff-
only stuff. From a customer/user/developer point of view there was
absolutely no comparison in terms of quality of people and quality of
end product, neither then (1995, when I was using both NT for my stuff
and Windows for Playgroups for the corporate stuff) nor at any time
since when I've been looking (which is most of the time).
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/9/2009 6:07:26 PM
|
|
In article <h2aKOEA9rBpy@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <4af6c9fc$0$273$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>>
>> And my understanding is that VMS inherited this from
>> the PDP-11 OS's.
>
> DEC OS's for PDP-11 tended to be written in Macro-11. A little bit
> of BLISS-11 alter on was used for portable stuff like EDT. VMS
> was initially mostly Macro-32 and BLISS; much of the Macro-32
> was eventually replaced. Lots of other languages were also used.
I wouldn't say Macro-32 was replaced. When and where pieces required
revamping for Alpha or IA64, the routines were rewritten -- sadly, in
C -- but there were no wholesale rewrites of modules just because they
were sourced Macro-32.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/9/2009 7:13:48 PM
|
|
In article
<d75d3d4b-acf8-4b92-a8ba-1d1c21386137@v36g2000yqv.googlegroups.com>,
John Wallace <johnwallace4@yahoo.co.uk> wrote:
> On Nov 9, 11:00�am, Neil Rieck <n.ri...@sympatico.ca> wrote:
>
> > When you go back and read documents like this:
> >
> > http://americanhistory.si.edu/collections/comphist/bell.htm#Transitio...
> >
>
> With the greatest possible respect to the author, and even bearing in
> mind the interview is in 1995 (a couple of years after NT first
> emerged) what on earth is this quote about:
> "Until Microsoft, I though DEC had the greatest engineering
> organization, but Microsoft is substantially better."
I think you have quoted out of context there, John. The full paragraph
plus the first 2 sentences of the next one:
"The more I�ve gotten away from large organizations, the more I feel
that this organizational hierarchy has to be totally supportive up and
down. It starts with the CEO and it goes down from there. Why am I such
a fan of Microsoft?� Look at Gates, Allchin, Maritz � go down the line
of people running the company.� Everyone link in the management chains
is filled with great people. Why I like them is they�re smart, they know
their business, they know technology and they know what they�re doing
and they�ve got this mission of creating this industry and wanting to
put it out there. And I haven�t seen that at other companies. Until
Microsoft, I though DEC had the greatest engineering organization, but
Microsoft is substantially better.
DEC is doing a lot of interesting Internet technology and products right
now[11] and they an advanced development group in the bay area, but it
is managed by an incompetent. I don�t see that they are going to figure
out how to do it as a business."
To me he is talking about the _organization_ there, not the final
products.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/9/2009 7:25:07 PM
|
|
In article <d4786543-cfe1-493a-bb8b-b7cf29e242ee@t2g2000yqn.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
>On Nov 9, 1:20=A0pm, VAXman- @SendSpamHere.ORG wrote:
>> In article <d75d3d4b-acf8-4b92-a8ba-1d1c21386...@v36g2000yqv.googlegroups=
>..com>, John Wallace <johnwalla...@yahoo.co.uk> writes:
>> {...snip...}
>>
>> >"Until Microsoft, I though DEC had the greatest engineering
>> >organization, but Microsoft is substantially better."
>>
>> What blaspheming fuckwit authored that statement? =A0Albeit non-actionabl=
>e,
>> it is absolutely reprehensible to make libelous and defamatory statements
>> about the dead. =A0
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESIS(=
>dot)ORG
>>
>> =A0http://www.quirkfactory.com/popart/asskey/eqn2.png
>>
>> =A0 "Well my son, life is like a beanstalk, isn't it?"
>
>Apologies for the unintended effects on anybody's blood pressure.
>
>The author of that particular statement is a name that will be
>somewhat known round here: Gordon Bell. I sort of assumed it would
>have been obvious from NSR's context, but obviously I assumed wrong,
>sorry.
>
>Mr Bell joined Microsoft's Bay Area Research Centre in 1995:
>http://research.microsoft.com/en-us/people/gbell/
>
>Personally I can't see any basis for the claim unless perhaps he's
>talking about quality of buildings and facilities and other such staff-
>only stuff. From a customer/user/developer point of view there was
>absolutely no comparison in terms of quality of people and quality of
>end product, neither then (1995, when I was using both NT for my stuff
>and Windows for Playgroups for the corporate stuff) nor at any time
>since when I've been looking (which is most of the time).
Gordon Bell, father of my moniker namesake? Sheesh. What the hell
do they put in that Micro$loth Kool-aid that could cause such brain
damage? Even a quicksilver and wormwood cocktail couldn't produce
that level of brain damage.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/9/2009 7:29:46 PM
|
|
On Sun, 8 Nov 2009 12:31:07 -0600, Paul Raulerson
<paul@raulersons.com> wrote:
>
>Not to mention that there is at least as much "borrowed" technology
>from UNIX in NT there is from VMS.
>And when you hit Windows XP, there is far more UNIX based technology
>cloned into NT than from VMS.
>
>I have never fully understood this, since in some ways, VMS is clearly
>superior to the contemporary UNIX
>implementations of that time.
My recollection from that time period is reading a few articles
written in mags from erstwhile VMS Internals experts that NT had VMS
written all over it.
It may not be so true today, but the earlier versions, IIRC, were so
VMS-ish internally that even some of the code was copied verbatim
(i.e., including comments with the initials of VMS engineers).
|
|
0
|
|
|
|
Reply
|
notValid (53)
|
11/9/2009 7:39:17 PM
|
|
On Nov 9, 7:25=C2=A0pm, "P. Sture" <paul.nos...@sture.ch> wrote:
> In article
> <d75d3d4b-acf8-4b92-a8ba-1d1c21386...@v36g2000yqv.googlegroups.com>,
> =C2=A0John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
> > On Nov 9, 11:00=C2=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
>
> > > When you go back and read documents like this:
>
> > >http://americanhistory.si.edu/collections/comphist/bell.htm#Transitio.=
...
>
> > With the greatest possible respect to the author, and even bearing in
> > mind the interview is in 1995 (a couple of years after NT first
> > emerged) what on earth is this quote about:
> > "Until Microsoft, I though DEC had the greatest engineering
> > organization, but Microsoft is substantially better."
>
> I think you have quoted out of context there, John. The full paragraph
> plus the first 2 sentences of the next one:
>
> "The more I=C2=B9ve gotten away from large organizations, the more I feel
> that this organizational hierarchy has to be totally supportive up and
> down. It starts with the CEO and it goes down from there. Why am I such
> a fan of Microsoft?=C2=A0 Look at Gates, Allchin, Maritz =C5=A0 go down t=
he line
> of people running the company.=C2=A0 Everyone link in the management chai=
ns
> is filled with great people. Why I like them is they=C2=B9re smart, they =
know
> their business, they know technology and they know what they=C2=B9re doin=
g
> and they=C2=B9ve got this mission of creating this industry and wanting t=
o
> put it out there. And I haven=C2=B9t seen that at other companies. Until
> Microsoft, I though DEC had the greatest engineering organization, but
> Microsoft is substantially better.
>
> DEC is doing a lot of interesting Internet technology and products right
> now[11] and they an advanced development group in the bay area, but it
> is managed by an incompetent. I don=C2=B9t see that they are going to fig=
ure
> out how to do it as a business."
>
> To me he is talking about the _organization_ there, not the final
> products.
>
> --
> Paul Sture
Fair comment, probably, but the role of the management organization in
a product development company is at least in part to, er, manage
product development successfully. Management can make or break any
business very easily. Management broke DEC and management made
Microsoft what it is today. Engineering management and "the
engineering organization" specifically also made Microsoft products
what they are today.
Back in 1995, when the interview was recorded, it may not have been
quite so obvious that even Windows NT would end up as a laughing stock
in the software security world, trusted by neither its end users nor
the "content owners" who thought Trusted Computing meant an end to end
copy-protected HD delivery channel (that's what Vista was for).
Hindsight's a wonderful thing.
What *should* have already been obvious in 1995 is, as has already
been pointed out in an earlier reply, very few folk in MS Engineering
or engineering management could engineer their way out of a paper bag;
every worthwhile asset had come from outside, either by legitimate or
other means.
Incidentally, there was at least as much VAXELN in NT as there was VMS
in NT. It's acknowledged in Custer's Inside Windows NT book but rarely
mentioned elsewhere, as stealing from an OS hardly anyone ever heard
of doesn't make for such good headlines as stealing an OS that was
once the industry standard.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/9/2009 8:34:36 PM
|
|
In article <00A944CF.51D26CA4@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>
> I wouldn't say Macro-32 was replaced. When and where pieces required
> revamping for Alpha or IA64, the routines were rewritten -- sadly, in
> C -- but there were no wholesale rewrites of modules just because they
> were sourced Macro-32.
In the VMS 3.x to 4.x time frame, and I've been told later, modules
were rewritten from Macro-32 to BLISS when they were being worked on
for other reasons. I think one of the big pieces I ran into was
MNTSHR. $MOUNT was being reworked to add cluster wide volume name
locking. (No two shareable volumes by the same volume name.)
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 8:54:28 PM
|
|
In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>, jls <notvalid@yahoo.com> writes:
>
> My recollection from that time period is reading a few articles
> written in mags from erstwhile VMS Internals experts that NT had VMS
> written all over it.
>
> It may not be so true today, but the earlier versions, IIRC, were so
> VMS-ish internally that even some of the code was copied verbatim
> (i.e., including comments with the initials of VMS engineers).
I recall statments from Culter that VMS -> WNT naming similar to
IBM -> HAL was intentional. But then I also recall statements that
Culter only worked on the I/O subsystem of each, and being familiar
with device drivers in both I can see familiarity, not code, not even
the same API. I'm under the impression that Culter offered to do a
VMS-like well compartmented design to Bill Gates and was turned down.
People who know the Windows kernel much better than I care to have
said the similarity is soley within Culter's I/O subsystem.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/9/2009 9:00:32 PM
|
|
In article <7lr0bbF3e5hd8U15@mid.individual.net>,
Bob Eager <rde42@spamcop.net> writes:
> On Mon, 09 Nov 2009 09:06:59 -0600, Bob Koehler wrote:
>
>>> And when it was decided for them, then C was not available (at least
>>> according to many C was invented to port Unix to PDP-11).
>>
>> UNIX was ported to PDP-11, using C, about a decade before VMS was
>> started. So DEC could have written a C compiler for VAX and large
>> parts of VMS in C if they'd wanted to. DEC didn't write a C compiler
>> for VAX early on because no one outside of a few UNIX users were
>> using C. UNIX was the broken down OS that AT&T couldn't find
>> customers for. The handwriting on the wall showed that there was
>> clearly no future for C and/or UNIX.
>>
>> Then AT&T let some kids at Berkley have a copy of the UNIX source.
>> They ran it on PDP-11, ported it to VAX, added virtual memory, added
>> TCP/IP, and somehow got others interested in it. Start up vendors
>> like Sun and Apollo found they could throw together some commodity
>> hardware, toss BSD UNIX on it much faster than they could write their
>> own OS, and sell workstations. When the vendors switched to RISC
>> they blew away the performance of VAXen and people grudgingly learned
>> to survive using an OS with a late 1960's human interface, writing
>> code in a Frankenstein language that escaped from the lab, on
>> hardware that could grind numbers fast and cheap.
>
> There are so many inaccuracies there I don't even know where to start...
Thank you. I was just going to say the same. Sometimes I really wonder
what kind of an alternate reality some of the people live in.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/9/2009 9:08:58 PM
|
|
Bob Eager wrote:
> No thanks. I actually thought of it recently, in terms of getting a
> machine for my son. But 100% mark-up over a non-Mac machine changed my
> mind.
Actually, the 100% markup is a bit of a misnomer. The Apple vanity logo
does cost a bit (especially the lighted ones:-), but it does let you
parade around the office with pride and it makes you look cool :-) :-)
Seriously, you need to compare oranges with oranges. The entry point for
non-Apple products is much lower. There is no debate about that.
However, when you start to add all of the features/options to get parity
with the Apple equivalent, you'll find the price for Apple is very
competitive.
Now, many people may not need all those additional features and for
them, the price of the Mac is much higher due to the presence of
features they won't use. (for instance, in an office, having digital
optical audio in/out won't be used unless you are in art/movie industry.)
There is however a certain portion of the Apple vanity tax which goes
towards better quality components/design. This becomes important in a
laptop which can get quite a beating.
Digital also had a "better quality" and less compromised designs. And
their proprietary stuff gave added functionality (DSSI vs early SCSI for
instance). The difference is that Apple knows who its competition is and
is fully aware of them and manages to price its systems with just the
right level of the Apple vanity tax whereas Digital refused to accept
that PCs were competition and continued to price its systems relative to
IBM mainframes.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/9/2009 10:43:36 PM
|
|
In article <KD6EMXmHr9Cj@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>, jls <notvalid@yahoo.com> writes:
>>
>> My recollection from that time period is reading a few articles
>> written in mags from erstwhile VMS Internals experts that NT had VMS
>> written all over it.
>>
>> It may not be so true today, but the earlier versions, IIRC, were so
>> VMS-ish internally that even some of the code was copied verbatim
>> (i.e., including comments with the initials of VMS engineers).
>
> I recall statments from Culter that VMS -> WNT naming similar to
> IBM -> HAL was intentional. But then I also recall statements that
HAL was a step up from IBM. WNT was a step down from VMS. In fact,
ZQW seems a more appropriate. Not really but I ran out of alphabet.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/9/2009 10:45:31 PM
|
|
John Wallace wrote:
> Mr Bell joined Microsoft's Bay Area Research Centre in 1995:
> http://research.microsoft.com/en-us/people/gbell/
So he left Digital while it was being sabotaged and dismembered by
Palmer and joined Microsoft at a time where it was working to use the NT
kernel for its mass market machines. Those are large engineering projects.
DEC isn 1995 has finihed the port to Alpha and VMS was in a "Digital is
killing VMS" stage, so my guess is that engineering wasn't given very
interesting projects.
So the "Until Microsoft" should have been "Until I joined Microsoft".
This changes the context of Gordon Bell's statement.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/9/2009 10:54:52 PM
|
|
JF Mezei wrote:
> John Wallace wrote:
>
>> Mr Bell joined Microsoft's Bay Area Research Centre in 1995:
>> http://research.microsoft.com/en-us/people/gbell/
>
> So he left Digital while it was being sabotaged and dismembered by
> Palmer and joined Microsoft at a time where it was working to use the NT
> kernel for its mass market machines. Those are large engineering projects.
No. Bell left DEC in 1983 after 23 years with the company. If you listen
to the PDP-10 crowd he left after ensuring the death of 36-bit computing.
Tim.
|
|
0
|
|
|
|
Reply
|
tim.sneddon (59)
|
11/9/2009 11:40:07 PM
|
|
Bob Eager <rde42@spamcop.net> writes:
> On Mon, 09 Nov 2009 09:06:59 -0600, Bob Koehler wrote:
> Here's a couple, for starters...
Some further bits of correction...
>> UNIX was ported to PDP-11, using C, about a decade before VMS
>> was started.
> In 1973. Are you saying that VMS was started in 1983? I think not...
>> So DEC could have written a C compiler for VAX and
>> large parts of VMS in C if they'd wanted to. DEC didn't write a C
>> compiler for VAX early on because no one outside of a few UNIX users
>> were using C. UNIX was the broken down OS that AT&T couldn't find
>> customers for.
> It was a research project for many years. It had to be pried from their
> hands to be used outside Bell Labs.
Actually, while it was "just" a research project, that is, through version 6,
Ken and Dennis were happy to give Unix away (send them a tape, get it back with
Unix on it). Version 7 is where Ma Bell got into the act and started hoarding.
>> The handwriting on the wall showed that there was
>> clearly no future for C and/or UNIX.
> It survives, though.
>> Then AT&T let some kids at Berkley have a copy of the UNIX source.
>> They ran it on PDP-11, ported it to VAX
> AT&T ported it to the VAX before that.
And to the PDP-11 before that. The first port, from the PDP-7 to PDP-11, was
in Macro-11 on an 11/20. The C port was to the 11/45. Around 1972.
>> added virtual memory
> AT&T did that first.
on the 11/70.
>> added TCP/IP
> There was an ARPA grant for that, I believe.
>> and somehow got others interested in it. Start up vendors
>> like Sun and Apollo found they could throw together some commodity
>> hardware, toss BSD UNIX on it much faster than they could write their
>> own OS, and sell workstations.
> But they weren't selling BSD at all....it wasn't a commercial product
> until much later. They were selling the AT&T version.
Um, no. SunOS was very much a BSD implementation (with Bill Joy among the
founders, that's hardly surprising); they only went to AT&T System V with
Solaris (= SunOS 5, only !=). Apollo's DomainOS was not Unix (different
filesystem semantics, for example). Of the players that went to Unix, only
Hewlett-Packard was a real AT&T fan _ab initio_.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
11/9/2009 11:50:20 PM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:00b0566a$0$32362$c3e8da3@news.astraweb.com...
> It is my understanding that all they need is a native assembler for the
> really deep down stuff, MACRO compiler, C, and BLISS. Anything else ? I
> think that they ported the last bits written in PL1 to something else,
> right ?
>
Message compiler, SDL, a rogue variant of Macro-64 that is only used with
/PREPROCESS_ONLY to build symbol vectors that should be rewritten into awk
or perl if you ask me, and SET COMMAND/OBJECT.
Pieces of the Pascal RTL are written in Pascal; pieces of the Fortran RTL
written in Fortran; pieces of the C++ RTL written in C++. But no Pascal,
Fortran, or C++ is in the OS so there is no bringup dependency.
No PL/1 remaining.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/9/2009 11:50:40 PM
|
|
Tim E. Sneddon wrote:
> No. Bell left DEC in 1983 after 23 years with the company. If you listen
> to the PDP-10 crowd he left after ensuring the death of 36-bit computing.
So there was a 12 year gap between him leaving Digital and joining the
Redmond devil.
Microsoft is a one product company (ok there are game consoles too). So
it is easy to set a single direction for the Windows suite (OS, Office etc).
Digital has had for some time, multiple competing products, the PDPs,
the DECsystems, the VAX, and then VAX/Alpha. Olsen had a management
style that fostered such competition.
However, during the 80s, Digital seemed to have finally gotten itself
into a single track with the VAX and really built up the application
portofolio for VAX and was poised for great success.
Then, it unravelled as DEC waivered on what to do with VAX and whether
to replace it.
Bell would have experienced the PDP-VAX battles. But he was gone during
the DIgital heydays of the 1980s when those battles were over.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/10/2009 12:18:30 AM
|
|
As usual, public health and the mainstream media have been brewing up
a storm of misinformation regarding H1N1.
As you might guess, the devil lives within the details and forces you
to question what all the fuss is about as the
case for confinement would be more applicable to seasonal influenza.
Here are a couple of links (the second of which is most informative
regarding vaccination complexities).
http://www.google.ca/search?hl=3Den&client=3Dopera&rls=3Den&hs=3D0ce&q=3Dcb=
c+news+swine+flu+public+health&btnG=3DSearch&meta=3D&aq=3Df&oq=3D
http://www.theatlantic.com/doc/200911/brownlee-h1n1
Have a speedy recovery Neil
JohnC
On Nov 7, 8:35=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> On Nov 6, 5:32=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> > Neil Rieck wrote:
> > > You will need to forgive me this week. Last Thursday (Oct 29) I
> > > presented H1N1 symptoms and have been banished to my house until
> > > Monday (Nov-9).
>
> > Is it safe for you to send emails ? Someone running a microsoft PC migh=
t
> > get infected reading your messages :-)
>
> > Were you confirmed H1N1, or did you just get a a bad flue ?
>
> I was advised not to leave my house unless I had problems breathing,
> or was coughing up blood. However, if adults presented either diarrhea
> or vomiting then H1N1 was considered a certainty (I had both). They
> told me it would take 5-days to clear up and it did.
>
> Oh well. Still alive and kicking.
>
> NSR
|
|
0
|
|
|
|
Reply
|
thecookson (15)
|
11/10/2009 12:21:30 AM
|
|
Neil Rieck schrieb:
> <quote>
> Then they (DEC management) killed the Prism project and Mr. Cutler
> left. They killed it, but Ken (Olsen) didn�t know that it wasn�t dead.
> It was still alive in the semiconductor group and it sprung up as
> Alpha.
> </quote>
>
> ...indicates to me that "either the semiconductor group was not
> notified that PRISM was dead" or "the semiconductor group ignored the
> order to stop working on it" or "the semiconductor group was so far
> along that DEC management told them to finish their current
> activities".
How can an activity as expensive as CPU development
(to the tune of several $100M per year, if it's serious development)
go undetected under the radar?
I mean, cut off funding and project is dead.
Or did Cutler&Co find ways of "stealth funding" of the order
of $100M per year? Now, *that* would have been ingenious, more than
Alpha itself.
> Any one of these scenarios means that Alpha was as welcome as an
> unplanned birth (at least to some people).
It seems to me that going MIPS,
though technically, economically and "politically"
sensible (as Mr. Bell himself has stated),
did not please the egos of some of DECs techies.
So Alpha was started, but it came so late
and was so overambitious
that it contributed to the demise of the company.
> This is strange because DEC
> manufactured and sold way more Alpha-based equipment than VAX.
Really? HP website says 1Mio alpha chips were sold during
alpha's existance (1992-2006). Many of them went into
multi-CPU boxes, i.e. the number of equipment would be lower,
in the several hundred thousands.
What I hear is OTOH that by the time alpha was introduced,
more than half a million VAXen had been sold, and some more
would have followed until their discontinuance.
That's not "way" more alphas than VAXen, it seems to me.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/10/2009 2:20:04 AM
|
|
jls schrieb:
>
> My recollection from that time period is reading a few articles
> written in mags from erstwhile VMS Internals experts that NT had VMS
> written all over it.
>
> It may not be so true today, but the earlier versions, IIRC, were so
> VMS-ish internally that even some of the code was copied verbatim
> (i.e., including comments with the initials of VMS engineers).
If WNT == VMS++
then how comes that the allegedly unhackable OS
turned into the most hacked one?
And how comes that absolutely nothing reminds me of
VMS whenever I have to touch a Windoze box?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/10/2009 2:35:09 AM
|
|
JF Mezei schrieb:
> Digital also had a "better quality" and less compromised designs. And
> their proprietary stuff gave added functionality (DSSI vs early SCSI for
> instance). The difference is that Apple knows who its competition is and
> is fully aware of them and manages to price its systems with just the
> right level of the Apple vanity tax whereas Digital refused to accept
> that PCs were competition and continued to price its systems relative to
> IBM mainframes.
DEC tried to be different for the sake of being different
(and charged accordingly).
Apple was/is different when it's worth to be different.
OTOH they try to adhere to standards where appropriate,
see e.g. the inevitable DVI-VGA adapter.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/10/2009 2:52:30 AM
|
|
Michael Kraemer wrote:
> jls schrieb:
>> My recollection from that time period is reading a few articles
>> written in mags from erstwhile VMS Internals experts that NT had VMS
>> written all over it.
>>
>> It may not be so true today, but the earlier versions, IIRC, were so
>> VMS-ish internally that even some of the code was copied verbatim
>> (i.e., including comments with the initials of VMS engineers).
>
> If WNT == VMS++
> then how comes that the allegedly unhackable OS
> turned into the most hacked one?
> And how comes that absolutely nothing reminds me of
> VMS whenever I have to touch a Windoze box?
Because the inherited stuff like memory management
and device drivers architecture are:
- invisible to users
- irrelevant for most security issues
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:02:58 AM
|
|
JF Mezei wrote:
> Microsoft is a one product company (ok there are game consoles too). So
> it is easy to set a single direction for the Windows suite (OS, Office etc).
MS does a whole bunch of software: OS, office, database server,
mail server, web server, development tools. They support standard
x86-64, Itanium, embedded CPU's.
Calling that one product is not an accurate description.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:08:39 AM
|
|
VAXman- @SendSpamHere.ORG wrote:
> In article <KD6EMXmHr9Cj@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>, jls <notvalid@yahoo.com> writes:
>>> My recollection from that time period is reading a few articles
>>> written in mags from erstwhile VMS Internals experts that NT had VMS
>>> written all over it.
>>>
>>> It may not be so true today, but the earlier versions, IIRC, were so
>>> VMS-ish internally that even some of the code was copied verbatim
>>> (i.e., including comments with the initials of VMS engineers).
>> I recall statments from Culter that VMS -> WNT naming similar to
>> IBM -> HAL was intentional. But then I also recall statements that
>
> HAL was a step up from IBM. WNT was a step down from VMS. In fact,
> ZQW seems a more appropriate. Not really but I ran out of alphabet.
Switch to unicode !!
:-)
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:09:50 AM
|
|
jls wrote:
> On Sun, 8 Nov 2009 12:31:07 -0600, Paul Raulerson
> <paul@raulersons.com> wrote:
>> Not to mention that there is at least as much "borrowed" technology
>>from UNIX in NT there is from VMS.
>> And when you hit Windows XP, there is far more UNIX based technology
>> cloned into NT than from VMS.
>>
>> I have never fully understood this, since in some ways, VMS is clearly
>> superior to the contemporary UNIX
>> implementations of that time.
>
> My recollection from that time period is reading a few articles
> written in mags from erstwhile VMS Internals experts that NT had VMS
> written all over it.
I have heard that about device drivers as well.
And it is obvious that the memory management were very "inspired"
by VMS.
> It may not be so true today, but the earlier versions, IIRC, were so
> VMS-ish internally that even some of the code was copied verbatim
> (i.e., including comments with the initials of VMS engineers).
It is a bit difficult to copy Macro-32 & Bliss code over in C code.
I do not not believe that part.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:13:10 AM
|
|
Arne Vajh�j schrieb:
> JF Mezei wrote:
>
>> Microsoft is a one product company (ok there are game consoles too). So
>> it is easy to set a single direction for the Windows suite (OS, Office
>> etc).
>
>
> MS does a whole bunch of software: OS, office, database server,
> mail server, web server, development tools. They support standard
> x86-64, Itanium, embedded CPU's.
>
> Calling that one product is not an accurate description.
And if one takes away Windoze,
what would remain of the above portfolio?
Everything they do is windoze-centric.
Or did I miss MS-Office for Linux?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/10/2009 3:14:23 AM
|
|
Richard B. Gilbert wrote:
> John Wallace wrote:
>> With the greatest possible respect to the author, and even bearing in
>> mind the interview is in 1995 (a couple of years after NT first
>> emerged) what on earth is this quote about:
>> "Until Microsoft, I though DEC had the greatest engineering
>> organization, but Microsoft is substantially better."
>
> DEC is gone! Microsoft is still here. That says it all!
It says something about the output from those organizations
from a commercial perspective.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:16:08 AM
|
|
Bob Koehler wrote:
> In article <4af6c9fc$0$273$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>> And my understanding is that VMS inherited this from
>> the PDP-11 OS's.
>
> DEC OS's for PDP-11 tended to be written in Macro-11. A little bit
> of BLISS-11 alter on was used for portable stuff like EDT.
So they did inherit Macro and Bliss from PDP-11.
> VMS
> was initially mostly Macro-32 and BLISS; much of the Macro-32
> was eventually replaced.
Really.
It was my impression that practically nothing were replaced just
new stuff added in other languages.
> Lots of other languages were also used.
The old story say that there was a tiny part of VMS written in each
language to keep the RTL's mandatory in VMS itself.
I believe the story has been rejected by people that should know.
>> And when it was decided for them, then C was not available
>> (at least according to many C was invented to port Unix
>> to PDP-11).
>
> UNIX was ported to PDP-11, using C, about a decade before VMS
> was started.
Half a decade.
> So DEC could have written a C compiler for VAX and
> large parts of VMS in C if they'd wanted to. DEC didn't write a
> C compiler for VAX early on because no one outside of a few UNIX
> users were using C.
DEC did write C compilers. VAX C 3.1, 3.2 and 3.3 if I remember
correctly.
Absolutely horrible compilers - way below normal DEC compiler
standards. But they did exist.
> Then AT&T let some kids at Berkley have a copy of the UNIX source.
> They ran it on PDP-11, ported it to VAX, added virtual memory, added
> TCP/IP, and somehow got others interested in it. Start up vendors
> like Sun and Apollo found they could throw together some commodity
> hardware, toss BSD UNIX on it much faster than they could write their
> own OS, and sell workstations. When the vendors switched to RISC
> they blew away the performance of VAXen and people grudgingly learned
> to survive using an OS with a late 1960's human interface, writing
> code in a Frankenstein language that escaped from the lab, on hardware
> that could grind numbers fast and cheap.
Maybe not quite accurate, but very funny.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:21:20 AM
|
|
Michael Kraemer wrote:
> Arne Vajh�j schrieb:
>> JF Mezei wrote:
>>> Microsoft is a one product company (ok there are game consoles too). So
>>> it is easy to set a single direction for the Windows suite (OS,
>>> Office etc).
>>
>> MS does a whole bunch of software: OS, office, database server,
>> mail server, web server, development tools. They support standard
>> x86-64, Itanium, embedded CPU's.
>>
>> Calling that one product is not an accurate description.
>
> And if one takes away Windoze,
> what would remain of the above portfolio?
> Everything they do is windoze-centric.
> Or did I miss MS-Office for Linux?
The fact that product X depends on product Y does
not make X and Y one product.
And besides I would not call all Windows versions
a single product. There must be relative big differences
between regular Windows and Windows Mobile code wise.
Arne
|
|
0
|
|
|
|
Reply
|
arne6 (9485)
|
11/10/2009 3:24:00 AM
|
|
Arne Vajh�j wrote:
> MS does a whole bunch of software: OS, office, database server,
> mail server, web server, development tools. They support standard
> x86-64, Itanium, embedded CPU's.
But it is part of a single "suite" that is meant to all work together on
the same platform, just like DEC had in the 1980s with a whole bunch of
software working on VAX-VMS.
Gates has has strong leadership to shape his company's products. Olsen
was more of a kind father letting the kids play in the playground to see
what they would come up with. The playground was large enough that
different groups of kids came up with competing products.
Had Gates instilled the same "quality is important" values in Microsoft
from the time he set out to write an operating system to replace DOS, he
might have come out with something pretty good.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/10/2009 4:09:50 AM
|
|
On Nov 9, 2009, at 6:51 AM, Bob Koehler wrote:
> In article <d25c4548-34e1-4d28-b7a0-ef99b9f8683f@37g2000yqm.googlegroups.com
> >, Neil Rieck <n.rieck@sympatico.ca> writes:
>>
>> I couldn't agree more. But whenever a new hardware platform appears,
>> it is always *nix/c that gets there first because, as we all know, C
>> is not much more than a portable assembler. Is the first port any
>> good? Nope, it is usually just a very first step. Regarding your
>> comments on MACRO32, I guess I was thinking more of other weirdness
>> like BLISS.
>
> In every UNIX port, there's some small architecture dependent code
> that has to be worked. No language can change that. If that
> weren't so, we'd probably say "UNIX recompile" instead of "UNIX
> port".
>
True - but very little. Porting to s/390 involved something like 3,500
lines of assembler
code. That's about it.
That's for Linux of course, which is more portable than Unix, but
still. s/390 is not Intel by
any stretch of the imagination.
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>
|
|
0
|
|
|
|
Reply
|
paul298 (265)
|
11/10/2009 5:34:47 AM
|
|
On Nov 9, 2009, at 9:08 AM, Bob Koehler wrote:
> In article <mailman.9.1257705243.9279.info-vax_rbnsn.com@rbnsn.com>,
> Paul Raulerson <paul@raulersons.com> writes:
>> Mmm- it is not difficult to avoid buffer overruns or memory leaks
>> or =20
>> any other
>> problems that a lot of people think are endemic to C. You just have
>> to =20=
>>
>> know
>> what you are doing, and *that* is true no matter what language you
>> use.
>
> Been there, argued that. Why does it keep coming around? Are the
> ivory towers still teaching that mantra to the kiddies?
>
Mantra or not, it is unassailable truth. <grin> And no, they are
teaching them the same old PAP
about how programmers will be extinct in a few years, because programs
will learn how to
write themselves. (*sigh*)
I get CS grads interviewing who have never written a compiler. :(
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>
|
|
0
|
|
|
|
Reply
|
paul298 (265)
|
11/10/2009 5:40:16 AM
|
|
On Mon, 09 Nov 2009 18:50:20 -0500, Rich Alderson wrote:
>> It was a research project for many years. It had to be pried from their
>> hands to be used outside Bell Labs.
>
> Actually, while it was "just" a research project, that is, through
> version 6, Ken and Dennis were happy to give Unix away (send them a
> tape, get it back with Unix on it).
Yes, that's how I started in mid-1976!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/10/2009 7:39:55 AM
|
|
On Nov 10, 2:35=A0am, Michael Kraemer <M.Krae...@gsi.de> wrote:
> jls schrieb:
>
>
>
> > My recollection from that time period is reading a few articles
> > written in mags from erstwhile VMS Internals experts that NT had VMS
> > written all over it.
>
> > It may not be so true today, but the earlier versions, IIRC, were so
> > VMS-ish internally that even some of the code was copied verbatim
> > (i.e., including comments with the initials of VMS engineers).
>
> If WNT =3D=3D VMS++
> then how comes that the allegedly unhackable OS
> turned into the most hacked one?
> And how comes that absolutely nothing reminds me of
> VMS whenever I have to touch a Windoze box?
A couple of reasons spring to mind. You can probably read more about
them in Custer's book.
When NT was first proposed, all it really had in common with the 16bit
Windows 3.1 of the day was the name. Compatibility with DOS or Win16
was barely a goal. As time goes by, Gates realises a couple of things:
the new OS needs to be more compatible with its predecessors, both in
API terms and in look+feel terms. Gates also realises that on the
hardware of the day, the new OS is going to be SLOWer than the Win16
of the day, and he cannot be having that (this was long before Vista)
even though the new crash-resistant OS would actually be more
productive despite individual benchmarks being slower. So, concepts
such as security are thrown out of the window; e.g. suddenly all kinds
of drivers that don't need to be kernel mode in a common address space
are running in kernel mode in a common address space to make the
system run a bit faster by avoiding context switches and parameter
copying. But the crashes came back and the security went down the
tubes.
The look and feel? DOS box compatibility rather than DCL. VMS's GUI
was X based, Windows wasn't.
Etc.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/10/2009 8:59:31 AM
|
|
JF suggested checking the book "DEC Is Dead, Long Live DEC" (by Edgar
H. Schein). I had read it through once before but had never read the
appendixes. Anyway, last night I re-read the PRISM stuff which starts
on P 206. The author has included 4-5 different versions of the PRISM
story because people interviewed had completely different memories of
what happened. P 211-212 talks about a corporate schism between the
engineers and upper management. The engineers kept referring to
previous research by Gordon Bell which indicated that the correct path
forward was to move toward a microprocessor-based future. Engineering-
managers then tried to shut down projects like VAX 9000 causing people
like Bob Glorioso to go to Ken Olsen and fellow VPs for a reprieve.
Bob is quoted "these engineers have no right to tell us business
people what to do" (sounds like similar stuff I heard from GM +
Chrysler).
On a related topic, DEC management thought PRISM would be late which
was one of the reasons why DEC decided to switch to MIPS. On P 211,
the people interviewed claim that PRISM components not killed were
delivered on time while the new MIPS chips were delivered late -AND-
the MIPS-supplied compilers (which DEC initially was told were
finished products) were total junk requiring a total rewrite by DEC.
I'm going to read the appendixes today (there is some PRISM and MIPS
stuff in there) but one appendix has a subtitle "Digital's Reluctance
to Make Strategic Choices".
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
http://www3.sympatico.ca/n.rieck/docs/dave_cutler-prism-mica-emerald-etc.html
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/10/2009 11:43:33 AM
|
|
In article <hdalqe$vah$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>Arne Vajh�j schrieb:
>> JF Mezei wrote:
>>
>>> Microsoft is a one product company (ok there are game consoles too). So
>>> it is easy to set a single direction for the Windows suite (OS, Office
>>> etc).
>>
>>
>> MS does a whole bunch of software: OS, office, database server,
>> mail server, web server, development tools. They support standard
>> x86-64, Itanium, embedded CPU's.
>>
>> Calling that one product is not an accurate description.
>
>And if one takes away Windoze,
>what would remain of the above portfolio?
>Everything they do is windoze-centric.
>Or did I miss MS-Office for Linux?
Well, some of their WEENDOZE apps have sleazed the Apple Mac environment.
I have "iWorks" (an Apple suite) which does word processing, spreadsheet
and presentations better, nicer and FAR cheaper than just the M$ W(ei)RD
offering on the Mac. iWorks can output formats for WEENDOZE sans all of
the really nice features which are Mac-centric. So, the old excuse that
one needs WEENDOZE because the rest of the world is using M$ W(ei)RD and
M$'s other "office" products is moot. I have Open Office on Ubuntu and
I'm told it mimics M$'s Office quite well too. Open Office is available
on Mac too.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/10/2009 12:31:46 PM
|
|
In article <0069e5b7$0$7048$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
> However, when you start to add all of the features/options to get parity
> with the Apple equivalent, you'll find the price for Apple is very
> competitive.
Especially if you consider one of the features to be software
quality.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 1:44:08 PM
|
|
In article <00A944EC.E5121054@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>
> HAL was a step up from IBM. WNT was a step down from VMS. In fact,
> ZQW seems a more appropriate. Not really but I ran out of alphabet.
Must be a stack. In ASCII 'H'-- 'A'-- 'L'-- == I B M.
'V'++ 'M'++ 'S'++ = 'W' 'N' 'T'.
Maybe Culter knew he was moving lower on the stack.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 1:46:51 PM
|
|
In article <mddljifxnpf.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
> Of the players that went to Unix, only
> Hewlett-Packard was a real AT&T fan _ab initio_.
I've always heard that HP-UX is only SVID on the outside, and the
kernel is BSD. Anyone in HP want to clear that up?
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 1:48:59 PM
|
|
In article <hdaikk$h0f$03$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> It seems to me that going MIPS,
> though technically, economically and "politically"
> sensible (as Mr. Bell himself has stated),
> did not please the egos of some of DECs techies.
> So Alpha was started, but it came so late
> and was so overambitious
> that it contributed to the demise of the company.
It was always clear to me that going to MIPS was a stopgap strategy
to keep DEC from loosing the business to RISC/UNIX when VAXen
fell off the bottom of the price/performance curve.
DEC was a software company that thought it was still a hardware
company but clearly knew that VMS was a major source of revenue
and the center of its growing software portfolio,and would not
readily port to MIPS.
Coming out with Alpha after loosing the business to RISC/UNIX did
not turn out to be a workable business strategy.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 1:56:45 PM
|
|
Richard B. Gilbert wrote:
>
> DEC is gone! Microsoft is still here. That says it all!
Waste Management is still here, too.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 1:58:54 PM
|
|
In article <4af8dc2d$0$277$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>
> So they did inherit Macro and Bliss from PDP-11.
>
Macro-11 is not Macro-32, although there is some similarity because
there is some similarity in architecture,and the thinking of the
folks who wrote the assemblers.
Bliss-11 and Bliss-32 are variants of Common BLISS, as is Bliss-36.
Bliss-36 is more a direct decendant of the original BLISS for PDP-10
(aka BLISS-10). There is a version of Bliss-32 that actually does
64 bit for Alpha, and something for IA64.
Bliss-11 exists only as a cross compiler that runs on PDP-10 or one
that runs on VAX. There's source for a Bliss-11 compiler somewhere
in the DECUS archives, I think it's written in Macro-10.
So if VMS inheritted BLISS from anywhere, I'd say it's from PDP-10,
not PDP-11.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/10/2009 2:29:03 PM
|
|
On Tue, 10 Nov 2009 07:44:08 -0600, Bob Koehler wrote:
> In article <0069e5b7$0$7048$c3e8da3@news.astraweb.com>, JF Mezei
> <jfmezei.spamnot@vaxination.ca> writes:
>>
>> However, when you start to add all of the features/options to get
>> parity with the Apple equivalent, you'll find the price for Apple is
>> very competitive.
>
> Especially if you consider one of the features to be software
> quality.
That would depend which OS one were planning to run on the non-Apple
machine.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/10/2009 2:52:30 PM
|
|
Bob Koehler wrote:
> In article <4af8dc2d$0$277$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>> So they did inherit Macro and Bliss from PDP-11.
>>
>
> Macro-11 is not Macro-32, although there is some similarity because
> there is some similarity in architecture,and the thinking of the
> folks who wrote the assemblers.
>
> Bliss-11 and Bliss-32 are variants of Common BLISS, as is Bliss-36.
Not to be too pedantic, but...Common BLISS (or the DEC BLISSes) are
derived from BLISS-11. However, there are significant differences.
BLISS-32, -36 and -16 are all Common BLISS compilers. Depending on
the variant it may be a native compiler or a cross-compiler (there
is even a BLISS-36 variant that outputs BLISS-10).
BLISS-11 is the language described in 'The Design of an Optimizing
Compiler'.
> Bliss-36 is more a direct decendant of the original BLISS for PDP-10
> (aka BLISS-10). There is a version of Bliss-32 that actually does
> 64 bit for Alpha, and something for IA64.
BLISS-36 is actually Common BLISS. BLISS-10 does not bare much
resemblance to BLISS-36 code. As you say, there are BLISS-32
compilers for both Alpha and IA-64. There are also compilers
for MIPS, PRISM and IA-32.
>
> Bliss-11 exists only as a cross compiler that runs on PDP-10 or one
> that runs on VAX. There's source for a Bliss-11 compiler somewhere
> in the DECUS archives, I think it's written in Macro-10.
>
I don't believe there was ever a BLISS-11 that ran on the VAX. I
would have thought it would have been quite difficult to port given
it was written in BLISS-10. There was a BLISS-16 that ran on the
VAX and targeted the PDP-11.
Someone (the name escapes me at the moment) did port BLISS-11 to
BLISS-64. That was a PDP-11 target compiler that ran on either
OpenVMS Alpha or I64.
> So if VMS inheritted BLISS from anywhere, I'd say it's from PDP-10,
> not PDP-11.
>
BLISS came into VMS because of a decision made (according to Ron
Brender) in the Fall of 1976.
Tim.
|
|
0
|
|
|
|
Reply
|
tim.sneddon (59)
|
11/10/2009 4:00:34 PM
|
|
In article <00f1190b$0$23381$c3e8da3@news.astraweb.com>,
jfmezei.spamnot@vaxination.ca says...>
> >>"Until Microsoft, I though DEC had the greatest engineering
> >>organization, but Microsoft is substantially better."
>
> If it weren't for the first 2 words, the statement would be tolerable
> since there is no longer any DEC engineering, so even Microsoft's dismal
> engineering would be better.
>
> However, when you consider Microsoft's engineering when Microsoft
> started, it was closer to "how to steal other people's ideas/software"
> than writing your own. Microsfoot lived for at least a decade without
> any true engineering of its own.
He's not talking about Microsoft's engineering. He's talking about
Microsoft's engineering *organization*.
>
> I may be biased (not not completely biased, I don't yet have apple
> branded socks and underwear :-), I'd say Apple has some great
> engineering these days. Extremey innovative industrial designers, and
> ability to integrate technologies (and open source software) into a
> slick/sleek product.
A good organization may not be essential for good engineering, but
it sure helps. I think Apple has a very good organization and very
good engineers, though I think I found a bug in my new iTouch
yesterday...
>
> Unlike DEC, Apple knows how to advertise. And Apple makes it easy to buy
> their products. And their web site is far better organised than HP's.
> Customer service ? Server got delayed by about a week. They upgraded the
> delivery to "express" at no charge AND included a free iPOD nano with
> it. Did Digital ever do that ? Nop because Digital didn't speak to small
> customers.
Among their many organizational problems...
--
John Santos
Evans Griffiths & Hart, Inc.
|
|
0
|
|
|
|
Reply
|
john5 (550)
|
11/11/2009 3:15:58 AM
|
|
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> I recall statments from Culter that VMS -> WNT naming similar to
> IBM -> HAL was intentional. But then I also recall statements that
> Culter only worked on the I/O subsystem of each, and being familiar
> with device drivers in both I can see familiarity, not code, not even
> the same API. I'm under the impression that Culter offered to do a
> VMS-like well compartmented design to Bill Gates and was turned down.
> People who know the Windows kernel much better than I care to have
> said the similarity is soley within Culter's I/O subsystem.
The man's name is _Cutler_.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
11/11/2009 6:56:00 PM
|
|
In article <h7OY9G71ibLB@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
> Richard B. Gilbert wrote:
> >
> > DEC is gone! Microsoft is still here. That says it all!
>
> Waste Management is still here, too.
"Where there's muck there's brass."
(brass being slang for money where I come from)
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/11/2009 8:21:58 PM
|
|
In article <mailman.14.1257831627.9279.info-vax_rbnsn.com@rbnsn.com>,
Paul Raulerson <paul@raulersons.com> wrote:
> Mantra or not, it is unassailable truth. <grin> And no, they are
> teaching them the same old PAP
> about how programmers will be extinct in a few years, because programs
> will learn how to
> write themselves. (*sigh*)
>
> I get CS grads interviewing who have never written a compiler. :(
>
I came across a comment the other day questioning why a CS student would
need to go near the command line.
Shudder.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/11/2009 8:24:38 PM
|
|
In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>,
jls <notvalid@yahoo.com> wrote:
> On Sun, 8 Nov 2009 12:31:07 -0600, Paul Raulerson
> <paul@raulersons.com> wrote:
>
>
> >
> >Not to mention that there is at least as much "borrowed" technology
> >from UNIX in NT there is from VMS.
> >And when you hit Windows XP, there is far more UNIX based technology
> >cloned into NT than from VMS.
> >
> >I have never fully understood this, since in some ways, VMS is clearly
> >superior to the contemporary UNIX
> >implementations of that time.
>
> My recollection from that time period is reading a few articles
> written in mags from erstwhile VMS Internals experts that NT had VMS
> written all over it.
>
> It may not be so true today, but the earlier versions, IIRC, were so
> VMS-ish internally that even some of the code was copied verbatim
> (i.e., including comments with the initials of VMS engineers).
There was a series of articles in Windows NT Magazine in 1997 exploring
NT process and memory management. I remember thinking that I could have
written large chunks of it myself, based purely on VMS knowledge.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/11/2009 8:42:42 PM
|
|
In article <hdajgu$1c8$00$1@news.t-online.com>,
Michael Kraemer <M.Kraemer@gsi.de> wrote:
> jls schrieb:
>
> >
> > My recollection from that time period is reading a few articles
> > written in mags from erstwhile VMS Internals experts that NT had VMS
> > written all over it.
> >
> > It may not be so true today, but the earlier versions, IIRC, were so
> > VMS-ish internally that even some of the code was copied verbatim
> > (i.e., including comments with the initials of VMS engineers).
>
> If WNT == VMS++
> then how comes that the allegedly unhackable OS
> turned into the most hacked one?
> And how comes that absolutely nothing reminds me of
> VMS whenever I have to touch a Windoze box?
As I recall the Windows APIs were forced on it. There was also an outcry
from people who knew about operating systems when it was decided to put
the graphics in the kernel at NT 4.0. The motivation behind that was
allegedly to improve performance with games.
What irritates me looking back at that time is that NT ws being actively
promoted by many as being reliable _because_ of its VMS heritage.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/11/2009 8:47:43 PM
|
|
In article <00A944EC.E5121054@SendSpamHere.ORG>,
VAXman- @SendSpamHere.ORG wrote:
> In article <KD6EMXmHr9Cj@eisner.encompasserve.org>,
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> >In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>, jls
> ><notvalid@yahoo.com> writes:
> >>
> >> My recollection from that time period is reading a few articles
> >> written in mags from erstwhile VMS Internals experts that NT had VMS
> >> written all over it.
> >>
> >> It may not be so true today, but the earlier versions, IIRC, were so
> >> VMS-ish internally that even some of the code was copied verbatim
> >> (i.e., including comments with the initials of VMS engineers).
> >
> > I recall statments from Culter that VMS -> WNT naming similar to
> > IBM -> HAL was intentional. But then I also recall statements that
>
> HAL was a step up from IBM. WNT was a step down from VMS. In fact,
> ZQW seems a more appropriate. Not really but I ran out of alphabet.
WINNT had HAL too - Hardware Abstraction Layer.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/11/2009 8:50:48 PM
|
|
Rich Alderson wrote:
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
>> I recall statments from Culter that VMS -> WNT naming similar to
>> IBM -> HAL was intentional. But then I also recall statements that
>> Culter only worked on the I/O subsystem of each, and being familiar
>> with device drivers in both I can see familiarity, not code, not even
>> the same API. I'm under the impression that Culter offered to do a
>> VMS-like well compartmented design to Bill Gates and was turned down.
>
>> People who know the Windows kernel much better than I care to have
>> said the similarity is soley within Culter's I/O subsystem.
>
> The man's name is _Cutler_.
>
It's not easy being dylsexic!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/11/2009 9:02:33 PM
|
|
P. Sture wrote:
> In article <mailman.14.1257831627.9279.info-vax_rbnsn.com@rbnsn.com>,
> Paul Raulerson <paul@raulersons.com> wrote:
>
>> Mantra or not, it is unassailable truth. <grin> And no, they are
>> teaching them the same old PAP
>> about how programmers will be extinct in a few years, because programs
>> will learn how to
>> write themselves. (*sigh*)
>>
>> I get CS grads interviewing who have never written a compiler. :(
>>
>
> I came across a comment the other day questioning why a CS student would
> need to go near the command line.
>
> Shudder.
>
"Click and Drool conquers the world!"
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/11/2009 9:09:08 PM
|
|
Richard B. Gilbert mentioned on 11-11-2009 22:02:
> Rich Alderson wrote:
>> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>>> I recall statments from Culter that VMS -> WNT naming similar to
>>> IBM -> HAL was intentional. But then I also recall statements
>>> that Culter only worked on the I/O subsystem of each, and being
>>> familiar with device drivers in both I can see familiarity, not
>>> code, not even the same API. I'm under the impression that Culter
>>> offered to do a
>>> VMS-like well compartmented design to Bill Gates and was turned down.
>>
>>> People who know the Windows kernel much better than I care to have
>>> said the similarity is soley within Culter's I/O subsystem.
>>
>> The man's name is _Cutler_.
>>
>
> It's not easy being dylsexic!
That is surely one condition that should be renamed for the benefit of
those suffering from it!
/W
|
|
0
|
|
|
|
Reply
|
w6.boerhout (112)
|
11/11/2009 9:10:39 PM
|
|
On Wed, 11 Nov 2009 21:24:38 +0100, P. Sture wrote:
> In article <mailman.14.1257831627.9279.info-vax_rbnsn.com@rbnsn.com>,
> Paul Raulerson <paul@raulersons.com> wrote:
>
>> Mantra or not, it is unassailable truth. <grin> And no, they are
>> teaching them the same old PAP
>> about how programmers will be extinct in a few years, because programs
>> will learn how to
>> write themselves. (*sigh*)
>>
>> I get CS grads interviewing who have never written a compiler.
>>
>>
> I came across a comment the other day questioning why a CS student would
> need to go near the command line.
Shudder indeed. We make ours use the UNIX command line!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/11/2009 9:10:58 PM
|
|
On Wed, 11 Nov 2009 16:02:33 -0500, Richard B. Gilbert wrote:
> Rich Alderson wrote:
>> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>>> I recall statments from Culter that VMS -> WNT naming similar to
>>> IBM -> HAL was intentional. But then I also recall statements that
>>> Culter only worked on the I/O subsystem of each, and being familiar
>>> with device drivers in both I can see familiarity, not code, not
>>> even the same API. I'm under the impression that Culter offered to
>>> do a VMS-like well compartmented design to Bill Gates and was
>>> turned down.
>>
>>> People who know the Windows kernel much better than I care to have
>>> said the similarity is soley within Culter's I/O subsystem.
>>
>> The man's name is _Cutler_.
>>
>>
> It's not easy being dylsexic!
Actually....Culter....cult....it sorta works...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/11/2009 9:11:34 PM
|
|
P. Sture wrote:
> In article <hdajgu$1c8$00$1@news.t-online.com>,
> Michael Kraemer <M.Kraemer@gsi.de> wrote:
>
>> jls schrieb:
>>
>>> My recollection from that time period is reading a few articles
>>> written in mags from erstwhile VMS Internals experts that NT had VMS
>>> written all over it.
>>>
>>> It may not be so true today, but the earlier versions, IIRC, were so
>>> VMS-ish internally that even some of the code was copied verbatim
>>> (i.e., including comments with the initials of VMS engineers).
>> If WNT == VMS++
>> then how comes that the allegedly unhackable OS
>> turned into the most hacked one?
>> And how comes that absolutely nothing reminds me of
>> VMS whenever I have to touch a Windoze box?
>
> As I recall the Windows APIs were forced on it. There was also an outcry
> from people who knew about operating systems when it was decided to put
> the graphics in the kernel at NT 4.0. The motivation behind that was
> allegedly to improve performance with games.
>
> What irritates me looking back at that time is that NT ws being actively
> promoted by many as being reliable _because_ of its VMS heritage.
>
It took a while ;-) but W/XP is rock solid. I haven't tried Vista, and
won't!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/11/2009 9:28:03 PM
|
|
In article <paul.nospam-8ACEF0.21504811112009@pbook.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
>In article <00A944EC.E5121054@SendSpamHere.ORG>,
> VAXman- @SendSpamHere.ORG wrote:
>
>> In article <KD6EMXmHr9Cj@eisner.encompasserve.org>,
>> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> >In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>, jls
>> ><notvalid@yahoo.com> writes:
>> >>
>> >> My recollection from that time period is reading a few articles
>> >> written in mags from erstwhile VMS Internals experts that NT had VMS
>> >> written all over it.
>> >>
>> >> It may not be so true today, but the earlier versions, IIRC, were so
>> >> VMS-ish internally that even some of the code was copied verbatim
>> >> (i.e., including comments with the initials of VMS engineers).
>> >
>> > I recall statments from Culter that VMS -> WNT naming similar to
>> > IBM -> HAL was intentional. But then I also recall statements that
>>
>> HAL was a step up from IBM. WNT was a step down from VMS. In fact,
>> ZQW seems a more appropriate. Not really but I ran out of alphabet.
>
>WINNT had HAL too - Hardware Abstraction Layer.
....and WEENDOZE has HALitosis!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/11/2009 10:12:18 PM
|
|
On Nov 11, 8:47=A0pm, "P. Sture" <paul.nos...@sture.ch> wrote:
> In article <hdajgu$1c8$0...@news.t-online.com>,
> =A0Michael Kraemer <M.Krae...@gsi.de> wrote:
>
>
>
> > jls schrieb:
>
> > > My recollection from that time period is reading a few articles
> > > written in mags from erstwhile VMS Internals experts that NT had VMS
> > > written all over it.
>
> > > It may not be so true today, but the earlier versions, IIRC, were so
> > > VMS-ish internally that even some of the code was copied verbatim
> > > (i.e., including comments with the initials of VMS engineers).
>
> > If WNT =3D=3D VMS++
> > then how comes that the allegedly unhackable OS
> > turned into the most hacked one?
> > And how comes that absolutely nothing reminds me of
> > VMS whenever I have to touch a Windoze box?
>
> As I recall the Windows APIs were forced on it. There was also an outcry
> from people who knew about operating systems when it was decided to put
> the graphics in the kernel at NT 4.0. =A0The motivation behind that was
> allegedly to improve performance with games.
Not just games, but particularly anything which was video intensive.
This was back in the days when a Matrox Millenium was a high end
graphics card.
The originally proposed NT architecture had everything nicely
separated, so there was little risk of total system crash/BSOD, but in
order to achieve this there had to be a lot of parameter copying and
context switching, and consequently there was a performance price to
pay. Performance is trivial to measure with benchmarks. Productivity,
however, was better under NT than the pre-NT OSes because there were
fewer hangs, fewer "out of memory" errors, fewer BSODs, etc. But
productivity isn't easy to measure. So the benchmarks won and
productivity was the loser.
Oddly enough the Trusted Computing stuff in Vista, with its end to end
HD content protection provided by cryptographically signed remotely
revokable drivers with tamper protection so any unauthorised driver
tinkering potentially results in inability to decrypt DRM-protected HD
content [1], sort of reintroduced some of the same inter-subsystem
protections and isolations (but for somewhat different reasons), and
not just in the video subsystem either. And look how well Vista
worked, a decade or more after the drivers initially all got lumped in
to kernel mode.
I haven't yet been able to find out whether this DRM stuff has
vanished from Windows 7.
>
> What irritates me looking back at that time is that NT ws being actively
> promoted by many as being reliable _because_ of its VMS heritage.
>
Indeed. And it could in principle have been that way, if Gates and his
engineering organisation had wanted it to be that way. But it didn't
work out that way, and the rest is history.
[1] Slide 4 in (URL will wrap):
http://download.microsoft.com/download/0/5/0/050a2d04-7432-4325-a5c3-dcbd54=
cf6695/Kernel%20Mode%20Code%20Signing%20on%20Windows%20Vista%20and%20Window=
s%20Server%20Longhorn.ppt
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/11/2009 11:17:08 PM
|
|
Question: Is is possible that PRISM was killed but Alpha was still
alive and Ken Olsen didn't know it?
Answer: Yes
Excerpt from Page 216 of DEC is Dead, Long Live DEC
I organized Alpha as a program with me as program manager. This had
never worked before in Digital; it had been tried many times, never
worked. You may remember the old saying that Digital ran by the golden
rule, which was, "he that has the gold makes the rules." Yet the Alpha
Program was a team of maybe a half dozen people with never more than a
million and a half bucks to speak of. But the time was right to get
people aligned around a common effort at engineering.
( so the group was small enough to hide, but there is more... )
Excerpt from Page 217 of DEC is Dead, Long Live DEC
And we really did run Alpha as a program. It never resided centrally
in any organization, it was never really owned by any VP. It evolved
from this core of 6 or eight people to spanning about 105 to 110
projects coordinated by the project team. It outlasted Ken and a bunch
of organizational changes and all kinds of chaos in the first layoffs.
When we shipped Alpha, we shipped a new architecture, a new chip, four
systems, three operating systems, 30 products with field training and
the whole works, the the end of '92. It was kind of a defining
experience for me (Bob Supnik, interview by Edgar Schein, 2001)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
http://www3.sympatico.ca/n.rieck/docs/dave_cutler-prism-mica-emerald-etc.html
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/12/2009 2:36:03 AM
|
|
Neil Rieck wrote:
> Question: Is is possible that PRISM was killed but Alpha was still
> alive and Ken Olsen didn't know it?
> Answer: Yes
My understanding is that Prism was killed to focus on VAX 9000. After a
period of time, the Alpha group was formed, and re-used some of the work
done by the defunct Prism project.
My non-parity-correcting memory seems to recall that it was at the
failure of the VAX 9000 that caused Olsen goto plan B. The N-vax group
had already shown they could beat the vax 9000 for a lot less money, and
olsen was shown opportunity for a new architecture and allowed the Alpha
group to be created.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/12/2009 5:58:52 AM
|
|
On Nov 12, 12:58=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > Question: Is is possible that PRISM was killed but Alpha was still
> > alive and Ken Olsen didn't know it?
> > Answer: Yes
>
> My understanding is that Prism was killed to focus on VAX 9000. After a
> period of time, the Alpha group was formed, and re-used some of the work
> done by the defunct Prism project.
>
> My non-parity-correcting memory seems to recall that it was at the
> failure of the VAX 9000 that caused Olsen goto =A0plan B. The N-vax group
> had already shown they could beat the vax 9000 for a lot less money, and
> olsen was shown opportunity for a new architecture and allowed the Alpha
> group to be created.
According to this interview by Gordon Bell...
http://americanhistory.si.edu/collections/comphist/bell.htm
http://www3.sympatico.ca/n.rieck/docs/dave_cutler-prism-mica-emerald-etc.ht=
ml#prism-links
....the engineers saw the end-of-life of CISC and VAX and wanted to go
RISC. They thought that Aquarius (VAX 9000) would never make a dime so
repeatedly tried to shut down Aquarius but DEC VP Bob Glorioso would
repeatedly go to Olsen to get a reprieve, and Olsen would always
support Glorioso. DEC was bleeding money so upper management killed
PRISM then went with MIPS (supposedly a much cheaper alternative).
According to the Gordon Bell interview at the Smithsonian Institute as
well as the book "DEC is Dead, Long Live DEC", upper management
thought the whole PRISM thing was dead. They had no knowledge that
Alpha was still alive in the semiconductor division because it was
such a small (skunk works?) 6-person operation with no direct VP
support.
p.s. how many people know that Aquarius (VAX-9000) was originally
going to be a water-cooled machine? (Hence the name)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/12/2009 11:58:45 AM
|
|
Anyone who owns a copy of the book "DEC is Dead, Long Live DEC" should
reread it from the middle to the end.
Although this book contains lots of technical info about poor
decisions (introducing three PCs, switching to MIPS without first
checking the truthfulness of their claims, deciding to complete
VAX-9000, trying to directly take on IBM), it contains some other
stuff like this:
Ken Olsen had an inner circle of friends who would help keep Ken
grounded. One person was Gordon Bell who had the technical knowledge
to trump arguments from other VPs. Bell had a heart-attack in 1983 so
decided to leave DEC. The other person was General Georges Doriot (an
original investor) who was a mentor to Ken until Doriot's death in
1987.
quote: Once Doriot died, it became "Olsen's Board"
Be sure to read Appendix-E titled "What Happened? A Postscript"
written by Gordon Bell. In my opinion, this contains contains the best
postmortem of DEC.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/12/2009 12:21:49 PM
|
|
From page-294 of the book "DEC is Dead, Long Live DEC"
<quote>
In June 1998 Compaq purchased DEC for 4.5 billion.
In June 1999 Compaq sold AltaVista to CMGI for 2.3 billion.
</quote>
Is this second line correct? If so, then Compaq acquired all of DEC's
intellectual property for 2.2 Billion.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/12/2009 12:29:37 PM
|
|
In article <00A9467A.963636BC@SendSpamHere.ORG>,
VAXman- @SendSpamHere.ORG wrote:
> In article <paul.nospam-8ACEF0.21504811112009@pbook.sture.ch>, "P. Sture"
> <paul.nospam@sture.ch> writes:
> >
> >WINNT had HAL too - Hardware Abstraction Layer.
>
> ...and WEENDOZE has HALitosis!
Might have known you'd find another meaning in there ;-)
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/12/2009 12:38:35 PM
|
|
In article <zNmdncjkqOr3u2bXnZ2dnUVZ_h9i4p2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> It's not easy being dylsexic!
Damn, I still can't spell and type at the same time.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/12/2009 1:13:53 PM
|
|
"P. Sture" <paul.nospam@sture.ch> wrote in message
news:paul.nospam-97E4EE.21424211112009@pbook.sture.ch...
> In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>,
> jls <notvalid@yahoo.com> wrote:
>
>> On Sun, 8 Nov 2009 12:31:07 -0600, Paul Raulerson
>> <paul@raulersons.com> wrote:
>>
>>
>> >
>> >Not to mention that there is at least as much "borrowed" technology
>> >from UNIX in NT there is from VMS.
>> >And when you hit Windows XP, there is far more UNIX based technology
>> >cloned into NT than from VMS.
>> >
>> >I have never fully understood this, since in some ways, VMS is clearly
>> >superior to the contemporary UNIX
>> >implementations of that time.
>>
>> My recollection from that time period is reading a few articles
>> written in mags from erstwhile VMS Internals experts that NT had VMS
>> written all over it.
>>
>> It may not be so true today, but the earlier versions, IIRC, were so
>> VMS-ish internally that even some of the code was copied verbatim
>> (i.e., including comments with the initials of VMS engineers).
>
> There was a series of articles in Windows NT Magazine in 1997 exploring
> NT process and memory management. I remember thinking that I could have
> written large chunks of it myself, based purely on VMS knowledge.
>
Interesting discussion.
A couple things. First is that even when you start with a relatively blank
slate, the end results tend to flow from your past work. The NT kernel is
what you would expect as the next generation from someone who had a main
role in the RSX and VMS kernels. You have some fundamentals, you know what
worked well, and you know what you would have done better in retrospect.
In terms of code with "initials of VMS engineers"... I find that a bit
suspect, unless of course you remember that a lot of ex-VMS engineers
journeyed to DECwest and eventually to Microsoft, like my mentor Rod
Gamache. At the time there was little to no kernel code in VMS written in
C. I'll avoid discussion of the Prism stuff, since while I know some things
from interesting people - none of it is anything I could claim as 100%
picture of the truth.
Lastly, what most people forget is that NT wasn't designed as the next
Windows. It was designed as a kernel that could host multiple executive
environments. At the time OS2, Windows, and UNIX executives were envisioned
and I recall this being talked about during the first NT Developers
Conference. Over time Windows became the focus and the bright line between
the kernel and Windows ended up being compromised - IMHO for performance
reasons - like the changes in the graphics subsystem.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/12/2009 1:19:10 PM
|
|
Bob Koehler wrote:
> In article <zNmdncjkqOr3u2bXnZ2dnUVZ_h9i4p2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> It's not easy being dylsexic!
>
> Damn, I still can't spell and type at the same time.
>
Thunderbird's spelling checker saves me from disgrace about five times a
week! Since Thunderbird can't/won't tell me the correct spelling, I
keep a dictionary handy for those occasions when I don't know how to fix it!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/12/2009 2:20:52 PM
|
|
"P. Sture" <paul.nospam@sture.ch> writes:
> In article <mailman.14.1257831627.9279.info-vax_rbnsn.com@rbnsn.com>,
> Paul Raulerson <paul@raulersons.com> wrote:
>> Mantra or not, it is unassailable truth. <grin> And no, they are
>> teaching them the same old PAP
>> about how programmers will be extinct in a few years, because programs
>> will learn how to write themselves. (*sigh*)
>> I get CS grads interviewing who have never written a compiler. :(
> I came across a comment the other day questioning why a CS student would
> need to go near the command line.
> Shudder.
It depends on how one views the discipline. In departments in which it is
viewed as a mathematical discipline, there is little need for programming
skills, or exposure to any user interface, whether command line or graphical,
to move forward in one's studies. Analysis of algorithmic complexity, proof
of correctness, etc. are the bread and butter of the field.
In departments in which it is viewed as an engineering discipline, compiler
construction and other issues of language implementation, design of operating
systems, and the like, are studied.
Neither is the whole story, but the two kinds of CS departments rarely mix,
in my experience.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
11/12/2009 8:49:59 PM
|
|
On Thu, 12 Nov 2009 15:49:59 -0500, Rich Alderson wrote:
> It depends on how one views the discipline. In departments in which it
> is viewed as a mathematical discipline, there is little need for
> programming skills, or exposure to any user interface, whether command
> line or graphical, to move forward in one's studies. Analysis of
> algorithmic complexity, proof of correctness, etc. are the bread and
> butter of the field.
>
> In departments in which it is viewed as an engineering discipline,
> compiler construction and other issues of language implementation,
> design of operating systems, and the like, are studied.
One of my colleagues is fond of describing the CS degree at one of the
very oldest universities in the UK thus:
"A core of mathematics, surrounded by....mathematics."
There are obvious cases where the reverse applies, and it's largely to do
with the university department that originally spawned the CS department
there.
Where I work, the department grew up independently so it's pretty well in
the middle.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/12/2009 9:42:34 PM
|
|
"Rich Alderson" <news@alderson.users.panix.com> wrote in message
news:mddk4xvtqmg.fsf@panix5.panix.com...
>
> It depends on how one views the discipline. In departments in which it is
> viewed as a mathematical discipline, there is little need for programming
> skills, or exposure to any user interface, whether command line or
> graphical,
> to move forward in one's studies. Analysis of algorithmic complexity,
> proof
> of correctness, etc. are the bread and butter of the field.
>
> In departments in which it is viewed as an engineering discipline,
> compiler
> construction and other issues of language implementation, design of
> operating
> systems, and the like, are studied.
>
> Neither is the whole story, but the two kinds of CS departments rarely
> mix,
> in my experience.
>
Then things must have changed. When I was at Purdue (77-81), I did
algorithm proof & complexity classes; OS design classes; compiler
construction classes; database design classes; etc. That was all from the
CS dept.
That said, the compiler I built at Purdue was a toy compared to the real
world compilers I found at DEC. It parsed a subset of Pascal and generated
a homebrew bytestream that was executed by a provided interpreter. (it was
on punched cards as well on a CDC6600 if that shows my age).
When folks came to the compiler group (including myself), there was still a
long aprenticeship program before you got to invent real stuff. Compilers
aren't magic. Lots of table lookups, hashtables, linked lists, trees, etc.
You just need to know what order they go in. :)
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/12/2009 9:46:28 PM
|
|
In article <77b4cc0c-85ab-4fab-9bfd-a1333099f95e@37g2000yqm.googlegroups.com>,
Neil Rieck wrote:
[...]
>p.s. how many people know that Aquarius (VAX-9000) was originally
>going to be a water-cooled machine? (Hence the name)
We knew it was water-cooled when we bought two, because the computer room had
to be modified to accomodate water-cooled equipment.
I don't think DEC could have made the sale without revealing that vital fact
up front!
One of them worked great, the other was a lemon, until a forklift replace was
accomplished. They were upgraded to Vax-10000s shortly thereafter.
Of course, I could be completely mis-understanding your remark...
[...]
|
|
0
|
|
|
|
Reply
|
BRAD77 (76)
|
11/13/2009 12:32:24 AM
|
|
John Wallace schrieb:
> On Nov 11, 8:47 pm, "P. Sture" <paul.nos...@sture.ch> wrote:
>
>>
>>As I recall the Windows APIs were forced on it. There was also an outcry
>>from people who knew about operating systems when it was decided to put
>>the graphics in the kernel at NT 4.0. The motivation behind that was
>>allegedly to improve performance with games.
>
>
> Not just games, but particularly anything which was video intensive.
> This was back in the days when a Matrox Millenium was a high end
> graphics card.
>
>
>>What irritates me looking back at that time is that NT ws being actively
>>promoted by many as being reliable _because_ of its VMS heritage.
>>
>
>
> Indeed. And it could in principle have been that way, if Gates and his
> engineering organisation had wanted it to be that way. But it didn't
> work out that way, and the rest is history.
>
So once and for all times we could bury this
"Cutler created NT as a VMS offspring and hence NT must be good"
legend?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 1:16:44 AM
|
|
Neil Rieck schrieb:
> Question: Is is possible that PRISM was killed but Alpha was still
> alive and Ken Olsen didn't know it?
> Answer: Yes
>
> Excerpt from Page 216 of DEC is Dead, Long Live DEC
> I organized Alpha as a program with me as program manager. This had
> never worked before in Digital; it had been tried many times, never
> worked. You may remember the old saying that Digital ran by the golden
> rule, which was, "he that has the gold makes the rules." Yet the Alpha
> Program was a team of maybe a half dozen people with never more than a
> million and a half bucks to speak of. But the time was right to get
> people aligned around a common effort at engineering.
>
> ( so the group was small enough to hide, but there is more... )
I find it hard to believe that serious CPU development can be done
with half a dozen people and and an annual budget of $1M.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 1:21:38 AM
|
|
Neil Rieck schrieb:
> From page-294 of the book "DEC is Dead, Long Live DEC"
>
> <quote>
> In June 1998 Compaq purchased DEC for 4.5 billion.
> In June 1999 Compaq sold AltaVista to CMGI for 2.3 billion.
> </quote>
>
> Is this second line correct? If so, then Compaq acquired all of DEC's
> intellectual property for 2.2 Billion.
I doubt the first line is correct.
Weren't it 9+x billion Compaq paid?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 1:26:56 AM
|
|
Neil Rieck schrieb:
> On a related topic, DEC management thought PRISM would be late which
> was one of the reasons why DEC decided to switch to MIPS. On P 211,
> the people interviewed claim that PRISM components not killed were
> delivered on time while the new MIPS chips were delivered late
ex-Prism people badmouthing the Mips decision - no surprise here.
And what does it mean, "... components delivered on time "?
It is my understanding that the VAX workstation business was
under pressure from the (RISC) competitors, so just "components"
would have been not good enough. Mips R2000/R3000 OTOH
were real silicon which could be used in the DECstation series
just in time, 1989. These helped DEC to catch customers
leaving VAX for Unix.
> -AND-
> the MIPS-supplied compilers (which DEC initially was told were
> finished products) were total junk requiring a total rewrite by DEC.
Indeed, the compilers initially shipped with the Ultrix systems
(can't remember whether Mips or DEC) leave something to be desired.
But so did first compilers on Alpha, and ISTR stupid bugs in OSF1
compilers as late as 1996.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 1:45:54 AM
|
|
"Michael Kraemer" <M.Kraemer@gsi.de> wrote in message
news:hdidoj$skb$01$1@news.t-online.com...
> Indeed, the compilers initially shipped with the Ultrix systems
> (can't remember whether Mips or DEC) leave something to be desired.
> But so did first compilers on Alpha, and ISTR stupid bugs in OSF1
> compilers as late as 1996.
>
MIPS Ultrix was the first target for the GEM backend. Fortran used GEM. C
and Pascal used the MIPS techology. We had a working DEC Pascal
frontend/GEM backend on MIPS Ultrix as well but we never sold it since we
already had a MIPS-based Pascal on the platform.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/13/2009 2:06:25 AM
|
|
On Nov 12, 2009, at 3:46 PM, John Reagan wrote:
>=20
> "Rich Alderson" <news@alderson.users.panix.com> wrote in message=20
> news:mddk4xvtqmg.fsf@panix5.panix.com...
>=20
>>=20
>> It depends on how one views the discipline. In departments in which =
it is
>> viewed as a mathematical discipline, there is little need for =
programming
>> skills, or exposure to any user interface, whether command line or=20
>> graphical,
>> to move forward in one's studies. Analysis of algorithmic =
complexity,=20
>> proof
>> of correctness, etc. are the bread and butter of the field.
>>=20
>> In departments in which it is viewed as an engineering discipline,=20
>> compiler
>> construction and other issues of language implementation, design of=20=
>> operating
>> systems, and the like, are studied.
>>=20
>> Neither is the whole story, but the two kinds of CS departments =
rarely=20
>> mix,
>> in my experience.
>>=20
>=20
> Then things must have changed. When I was at Purdue (77-81), I did=20
> algorithm proof & complexity classes; OS design classes; compiler=20
> construction classes; database design classes; etc. That was all from =
the=20
> CS dept.
>=20
> That said, the compiler I built at Purdue was a toy compared to the =
real=20
> world compilers I found at DEC. It parsed a subset of Pascal and =
generated=20
> a homebrew bytestream that was executed by a provided interpreter. =
(it was=20
> on punched cards as well on a CDC6600 if that shows my age).
>=20
> When folks came to the compiler group (including myself), there was =
still a=20
> long aprenticeship program before you got to invent real stuff. =
Compilers=20
> aren't magic. Lots of table lookups, hashtables, linked lists, trees, =
etc.=20
> You just need to know what order they go in. :)
>=20
> John=20
>=20
>=20
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>=20
And my experience, in the same time frame (maybe a year earlier or so) =
is the same. And=20
on top of it, to claim any kind of engineering state, you had to learn =
how to weld. Most annoying,
as I do not *like* to weld. But still had to learn it.=20
We had to take plenty of math as well, up through tensor calc along with =
sides of matrix=20
algebra and complex variables.=20
-Paul
|
|
0
|
|
|
|
Reply
|
paul298 (265)
|
11/13/2009 2:27:14 AM
|
|
Bob Koehler schrieb:
> In article <hdaikk$h0f$03$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
> It was always clear to me that going to MIPS was a stopgap strategy
> to keep DEC from loosing the business to RISC/UNIX when VAXen
> fell off the bottom of the price/performance curve.
>
> DEC was a software company that thought it was still a hardware
> company but clearly knew that VMS was a major source of revenue
> and the center of its growing software portfolio,and would not
> readily port to MIPS.
Of course they were a hardware company,
and customers bought mainly due to hardware,
the OS being a nice add-on.
Otherwise people wouldn't have left VAX for better price/performance.
> Coming out with Alpha after loosing the business to RISC/UNIX did
> not turn out to be a workable business strategy.
Moving customers to Mips/Ultrix first and expecting them to
do another migration to alpha only three years later
didn't pan out, of course.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 2:31:25 AM
|
|
John Reagan schrieb:
> "Michael Kraemer" <M.Kraemer@gsi.de> wrote in message
> news:hdidoj$skb$01$1@news.t-online.com...
>
>
>>Indeed, the compilers initially shipped with the Ultrix systems
>>(can't remember whether Mips or DEC) leave something to be desired.
>>But so did first compilers on Alpha, and ISTR stupid bugs in OSF1
>>compilers as late as 1996.
>>
>
>
> MIPS Ultrix was the first target for the GEM backend. Fortran used GEM. C
> and Pascal used the MIPS techology. We had a working DEC Pascal
> frontend/GEM backend on MIPS Ultrix as well but we never sold it since we
> already had a MIPS-based Pascal on the platform.
>
> John
>
>
ISTR having more trouble with "Fortran for RISC",
but that may have been due to more heavy usage of Fortran rather than C.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/13/2009 2:39:58 AM
|
|
<BRAD@rabbit.turquoisewitch.com> wrote in message
news:slrnhfpa8n.dkg.BRAD@rabbit.turquoisewitch.com...
> In article <77b4cc0c-85ab-4fab-9bfd-a1333099f95e@37g2000yqm.googlegroups.com>,
>>p.s. how many people know that Aquarius (VAX-9000) was originally
>>going to be a water-cooled machine? (Hence the name)
>
> We knew it was water-cooled when we bought two, because the computer room had
> to be modified to accomodate water-cooled equipment.
This is surprising, since the water-cooled design was scrapped,
supposedly before any were sold. Maybe they were prototypes.
|
|
0
|
|
|
|
Reply
|
R.Brodie (551)
|
11/13/2009 10:59:41 AM
|
|
Bob Eager <rde42@spamcop.net> writes:
>On Thu, 12 Nov 2009 15:49:59 -0500, Rich Alderson wrote:
>> It depends on how one views the discipline. In departments in which it
>> is viewed as a mathematical discipline, there is little need for
>> programming skills, or exposure to any user interface, whether command
>> line or graphical, to move forward in one's studies. Analysis of
>> algorithmic complexity, proof of correctness, etc. are the bread and
>> butter of the field.
>>
>> In departments in which it is viewed as an engineering discipline,
>> compiler construction and other issues of language implementation,
>> design of operating systems, and the like, are studied.
>
>One of my colleagues is fond of describing the CS degree at one of the
>very oldest universities in the UK thus:
hmmm. you wouldn't be thinking of a university that's invented an 800
year history for itself?
>"A core of mathematics, surrounded by....mathematics."
because that's not really true of this place. lots of practical
courses; the students get to choose whether they specialise in
mathematical disciplines or in practical ones. either way, they have
to demonstrate practical ability in assessed exercises.
>There are obvious cases where the reverse applies, and it's largely to do
>with the university department that originally spawned the CS department
>there.
>
>Where I work, the department grew up independently so it's pretty well in
>the middle.
here, the department was founded in 1935 by a chemist and morphed to
digital computing to build the edsac (starting 1947, first ran 1949).
when i came here to for my diploma (1960s) there were still hand
calculators on the students' desks, but i avoided numerical analysis
altogether.
mind you, i've not built a *real* compiler in all my working life, and
certainly not as a student. (things like lex and yacc derived from
monsters like the "compiler compiler" that took the whole of the
mainframe's memory in the 60s to run, and so wasn't used much...)
--
Robin Fairbairns, Cambridge
|
|
0
|
|
|
|
Reply
|
rf10 (3555)
|
11/13/2009 11:32:59 AM
|
|
On Fri, 13 Nov 2009 11:32:59 +0000, Robin Fairbairns wrote:
> Bob Eager <rde42@spamcop.net> writes:
>>On Thu, 12 Nov 2009 15:49:59 -0500, Rich Alderson wrote:
>>> It depends on how one views the discipline. In departments in which
>>> it is viewed as a mathematical discipline, there is little need for
>>> programming skills, or exposure to any user interface, whether command
>>> line or graphical, to move forward in one's studies. Analysis of
>>> algorithmic complexity, proof of correctness, etc. are the bread and
>>> butter of the field.
>>>
>>> In departments in which it is viewed as an engineering discipline,
>>> compiler construction and other issues of language implementation,
>>> design of operating systems, and the like, are studied.
>>
>>One of my colleagues is fond of describing the CS degree at one of the
>>very oldest universities in the UK thus:
>
> hmmm. you wouldn't be thinking of a university that's invented an 800
> year history for itself?
Not that one, perish the thought. Our department was modelled in many
ways on your own.
>>"A core of mathematics, surrounded by....mathematics."
>
> because that's not really true of this place. lots of practical
> courses; the students get to choose whether they specialise in
> mathematical disciplines or in practical ones. either way, they have to
> demonstrate practical ability in assessed exercises.
Absolutely. Mind, we did nick one of your students recently!
>>There are obvious cases where the reverse applies, and it's largely to
>>do with the university department that originally spawned the CS
>>department there.
>>
>>Where I work, the department grew up independently so it's pretty well
>>in the middle.
>
> mind you, i've not built a *real* compiler in all my working life, and
> certainly not as a student. (things like lex and yacc derived from
> monsters like the "compiler compiler" that took the whole of the
> mainframe's memory in the 60s to run, and so wasn't used much...)
Oh, I did. But in the 1970s, and by hand...a fairly simple recursive
descent one. That was given to second year students at Essex (as an
option) and also to the MSc students (of which I was one).
I then taught compiler writing for a number of years, and we did make
them write a simple compiler. And I've also written a couple for money...
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/13/2009 11:49:38 AM
|
|
In article <hdh1vd$7fj$1@usenet01.boi.hp.com>,
"FredK" <fred.nospam@dec.com> wrote:
> "P. Sture" <paul.nospam@sture.ch> wrote in message
> news:paul.nospam-97E4EE.21424211112009@pbook.sture.ch...
> > In article <rqrgf5l0duc5n8247ofodn728nd2gbbld4@4ax.com>,
> > jls <notvalid@yahoo.com> wrote:
> >
> >> On Sun, 8 Nov 2009 12:31:07 -0600, Paul Raulerson
> >> <paul@raulersons.com> wrote:
> >>
> >>
> >> >
> >> >Not to mention that there is at least as much "borrowed" technology
> >> >from UNIX in NT there is from VMS.
> >> >And when you hit Windows XP, there is far more UNIX based technology
> >> >cloned into NT than from VMS.
> >> >
> >> >I have never fully understood this, since in some ways, VMS is clearly
> >> >superior to the contemporary UNIX
> >> >implementations of that time.
> >>
> >> My recollection from that time period is reading a few articles
> >> written in mags from erstwhile VMS Internals experts that NT had VMS
> >> written all over it.
> >>
> >> It may not be so true today, but the earlier versions, IIRC, were so
> >> VMS-ish internally that even some of the code was copied verbatim
> >> (i.e., including comments with the initials of VMS engineers).
> >
> > There was a series of articles in Windows NT Magazine in 1997 exploring
> > NT process and memory management. I remember thinking that I could have
> > written large chunks of it myself, based purely on VMS knowledge.
> >
>
> Interesting discussion.
>
> A couple things. First is that even when you start with a relatively blank
> slate, the end results tend to flow from your past work. The NT kernel is
> what you would expect as the next generation from someone who had a main
> role in the RSX and VMS kernels. You have some fundamentals, you know what
> worked well, and you know what you would have done better in retrospect.
Very true. Which one of us _hasn't_ used ideas and concepts learnt on
previous projects, and taken the tried and tested approach?
> In terms of code with "initials of VMS engineers"... I find that a bit
> suspect, unless of course you remember that a lot of ex-VMS engineers
> journeyed to DECwest and eventually to Microsoft, like my mentor Rod
> Gamache. At the time there was little to no kernel code in VMS written in
> C. I'll avoid discussion of the Prism stuff, since while I know some things
> from interesting people - none of it is anything I could claim as 100%
> picture of the truth.
That reminds me of a post (possibly back in CompuServe days) where one
DEC employee on his way home from an interview with MS met another DEC
employee on his his way to an interview with MS at the airport. The
comment was "So you too?". I gather that plenty of DEC folks did end up
at MS in that period (mid to late 90s).
> Lastly, what most people forget is that NT wasn't designed as the next
> Windows. It was designed as a kernel that could host multiple executive
> environments. At the time OS2, Windows, and UNIX executives were envisioned
> and I recall this being talked about during the first NT Developers
> Conference. Over time Windows became the focus and the bright line between
> the kernel and Windows ended up being compromised - IMHO for performance
> reasons - like the changes in the graphics subsystem.
Thanks. I didn't realise that. Support for the MIPS and Power PC
platforms as well as Alpha was there in NT4, so it was also
multi-platform, even if that was short lived in practice.
<http://en.wikipedia.org/wiki/Windows_NT#Supported_platforms>
Itanium gets a brief mention there.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/13/2009 2:08:05 PM
|
|
In article <slrnhfpa8n.dkg.BRAD@rabbit.turquoisewitch.com>, BRAD@rabbit.turquoisewitch.com () writes:
>
> We knew it was water-cooled when we bought two, because the computer room had
> to be modified to accomodate water-cooled equipment.
That's odd, we had a 9000 and I've seen several others, and every one
I've seen was air cooled. Could yours have been a field test?
(We had a field test DEC 10000 before Alpha first ship.)
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/13/2009 5:28:14 PM
|
|
In article <hdidoj$skb$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> These helped DEC to catch customers
> leaving VAX for Unix.
Carefull, that supports a common misconception. Lots of customers
were running UNIX on thier VAX; we hired CS guys who learned on
VAXen running ULTRIX.
Customers left VAX for a variety of RISC processors, most of which were
also running UNIX.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/13/2009 5:31:22 PM
|
|
In article <hdigdt$fpl$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
> Of course they were a hardware company,
> and customers bought mainly due to hardware,
> the OS being a nice add-on.
> Otherwise people wouldn't have left VAX for better price/performance.
Anybody who had a (Gould) SEL 32 knew VAX was not impressive hardware.
People bought VAXen mostly because VMS was so easy to use. SEL 32
had them beat on performance, but the OS was downright painfull.
We didn't leave VAX until after Alpha came out precisely because
we needed VMS on what ever hardware ran it. Others left VAX earlier
because they needed raw number crunching power no matter what OS.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/13/2009 5:35:23 PM
|
|
On Nov 13, 12:28=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
>
> > We knew it was water-cooled when we bought two, because the computer ro=
om had
> > to be modified to accomodate water-cooled equipment.
>
> =A0 =A0That's odd, we had a 9000 and I've seen several others, and every =
one
> =A0 =A0I've seen was air cooled. =A0Could yours have been a field test?
>
The book ("DEC is Dead, Long Live DEC") said that the initial design
involved water cooled ECL (which is why it was code named Aquarius)
but production machines were air cooled.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/13/2009 10:56:26 PM
|
|
In article <hRBJaOlrjHnT@eisner.encompasserve.org>, Bob Koehler wrote:
>In article <slrnhfpa8n.dkg.BRAD@rabbit.turquoisewitch.com>, BRAD@rabbit.turquoisewitch.com () writes:
>>
>> We knew it was water-cooled when we bought two, because the computer room had
>> to be modified to accomodate water-cooled equipment.
>
> That's odd, we had a 9000 and I've seen several others, and every one
> I've seen was air cooled. Could yours have been a field test?
>
Possibly; I'm not privy to that kind of information. It certainly would have
been dicey to have done that, seeing as how they were production machines!
|
|
0
|
|
|
|
Reply
|
BRAD77 (76)
|
11/14/2009 12:06:30 AM
|
|
Show Stopper!: The Breakneck Race to Create Windows NT and the Next
Generation at Microsoft (Hardcover) 1994 by G. Pascal Zachary
http://www.amazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/0029356717
Showstopper! the Breakneck Race to Create Windows NT and the Next
Generation at Microsoft (Paperback) 2009 by G. Pascal Zachary
http://www.amazon.com/Showstopper-Breakneck-Windows-Generation-Microsoft/dp/0759285780/
Quote: Showstopper! is a vivid account of the creation of Microsoft
WindowsNT, perhaps the most complex software project ever undertaken.
It is also a portrait of David Cutler, NT's brilliant and, at times,
brutally aggressive chief architect.
OK so I couldn't help myself. I just ordered this book.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/14/2009 12:13:05 PM
|
|
On Nov 13, 4:56=A0pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
> On Nov 13, 12:28=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
>
> Koehler) wrote:
>
> > > We knew it was water-cooled when we bought two, because the computer =
room had
> > > to be modified to accomodate water-cooled equipment.
>
> > =A0 =A0That's odd, we had a 9000 and I've seen several others, and ever=
y one
> > =A0 =A0I've seen was air cooled. =A0Could yours have been a field test?
>
> The book ("DEC is Dead, Long Live DEC") said that the initial design
> involved water cooled ECL (which is why it was code named Aquarius)
> but production machines were air cooled.
>
> NSR
We had a 9000. It was air cooled.
|
|
0
|
|
|
|
Reply
|
DaveG
|
11/15/2009 1:33:11 AM
|
|
DaveG wrote:
> On Nov 13, 4:56 pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
>> On Nov 13, 12:28 pm, koeh...@eisner.nospam.encompasserve.org (Bob
>>
>> Koehler) wrote:
>>
>>>> We knew it was water-cooled when we bought two, because the computer room had
>>>> to be modified to accomodate water-cooled equipment.
>>> That's odd, we had a 9000 and I've seen several others, and every one
>>> I've seen was air cooled. Could yours have been a field test?
>> The book ("DEC is Dead, Long Live DEC") said that the initial design
>> involved water cooled ECL (which is why it was code named Aquarius)
>> but production machines were air cooled.
>>
>> NSR
>
> We had a 9000. It was air cooled.
Likewise.
We variously called it the grey elephant and the 1000lb gorilla.
We often remarked that it was remarkable engineering.
http://groups.google.com/group/comp.sys.dec/msg/77d961626bcaed51
|
|
0
|
|
|
|
Reply
|
Mark.Daniel (68)
|
11/15/2009 1:53:23 AM
|
|
DaveG wrote:
> We had a 9000. It was air cooled.
Knowing how Digital didn't do things "simple", it could have been a
system made up of a internal water loop to cool the electronics, a
freon compressor with a water-freon heat exchange at one end, and a
freon-air exchanger at the other , along with fans that drew cool
outside air through the exchanger and exausted warm air out.
So, to the end user, it looks, acts and feels like air cooled, but to
the engineers, they still retained their water cooled electronics deep
inside the machine.
And if you're only going to build a handful of VAX 9000s, it would cost
less to add that freon compressor than to redesign the water cooled
electronics.
There are precedents for freon compressors in Digital cabinets:
http://toyvax.glendale.ca.us/~vance/vaxbar.html
:-) :-) :-) :-) :-) :-) :-)
Seriously though, how many VAX9000s were sold ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/15/2009 1:59:17 AM
|
|
DaveG wrote:
> On Nov 13, 4:56 pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
>> On Nov 13, 12:28 pm, koeh...@eisner.nospam.encompasserve.org (Bob
>>
>> Koehler) wrote:
>>
>>>> We knew it was water-cooled when we bought two, because the computer room had
>>>> to be modified to accomodate water-cooled equipment.
>>> That's odd, we had a 9000 and I've seen several others, and every one
>>> I've seen was air cooled. Could yours have been a field test?
>> The book ("DEC is Dead, Long Live DEC") said that the initial design
>> involved water cooled ECL (which is why it was code named Aquarius)
>> but production machines were air cooled.
>>
>> NSR
>
> We had a 9000. It was air cooled.
Yet another likewise. Ours was the ex-benchmark system that DEC
had in Valbonne - VAX 9000-420 + 2 vector processors.
Power-up used to sound like a jumbo jet ;-)
|
|
0
|
|
|
|
Reply
|
Roy.Omond (379)
|
11/15/2009 7:56:07 AM
|
|
On Nov 14, 8:59=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> DaveG wrote:
> > We had a 9000. =A0It was air cooled.
>
> Knowing how Digital didn't do things "simple", it could have been a
> system made up of a internal water loop to cool the electronics, =A0a
> freon compressor with a water-freon heat exchange at one end, and a
> freon-air exchanger at the other , along with fans that drew cool
> outside air through the exchanger and exausted warm air out.
>
> So, to the end user, it looks, acts and feels like air cooled, but to
> the engineers, they still retained their water cooled electronics deep
> inside the machine.
>
> And if you're only going to build a handful of VAX 9000s, it would cost
> less to add that freon compressor than to redesign the water cooled
> electronics.
>
> There are precedents for freon compressors in Digital cabinets:
>
> http://toyvax.glendale.ca.us/~vance/vaxbar.html
>
> :-) :-) :-) :-) :-) :-) :-)
>
> Seriously though, how many VAX9000s were sold ?
Didn't Seymour Cray have a prototype which ran in an aquarium filled
with cleaning fluid? Not sure if his production machine was built that
way.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/15/2009 12:17:34 PM
|
|
On Nov 14, 7:13=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> Show Stopper!: The Breakneck Race to Create Windows NT and the Next
> Generation at Microsoft (Hardcover) 1994 by G. Pascal Zacharyhttp://www.a=
mazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/...
>
> Showstopper! the Breakneck Race to Create Windows NT and the Next
> Generation at Microsoft (Paperback) 2009 by G. Pascal Zacharyhttp://www.a=
mazon.com/Showstopper-Breakneck-Windows-Generation-Micros...
>
> Quote: Showstopper! is a vivid account of the creation of Microsoft
> WindowsNT, perhaps the most complex software project ever undertaken.
> It is also a portrait of David Cutler, NT's brilliant and, at times,
> brutally aggressive chief architect.
>
> OK so I couldn't help myself. I just ordered this book.
>
> Neil Rieck
> Kitchener / Waterloo / Cambridge,
> Ontario, Canada.http://www3.sympatico.ca/n.rieck/
There is probably something weird happening when people entertain
themselves with the accomplishments of a bygone era.
1) The 1981 book "The Soul Of A New Machine" was republished in 2000.
2) The 1984 book "Hackers: Heroes of the Computer Revolution" was
republished in 2001.
3) The 1994 book "Show Stopper!: The Breakneck Race to Create Windows
NT and the Next" was republished in 2009.
Just an observation.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/15/2009 12:28:51 PM
|
|
"Neil Rieck" <n.rieck@sympatico.ca> wrote in message
news:f87abdc1-4084-4ba1-bee5-44b182e3a5ff@k19g2000yqc.googlegroups.com...
On Nov 14, 8:59 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> DaveG wrote:
> > We had a 9000. It was air cooled.
>
> Knowing how Digital didn't do things "simple", it could have been a
> system made up of a internal water loop to cool the electronics, a
> freon compressor with a water-freon heat exchange at one end, and a
> freon-air exchanger at the other , along with fans that drew cool
> outside air through the exchanger and exausted warm air out.
>
> So, to the end user, it looks, acts and feels like air cooled, but to
> the engineers, they still retained their water cooled electronics deep
> inside the machine.
>
> And if you're only going to build a handful of VAX 9000s, it would cost
> less to add that freon compressor than to redesign the water cooled
> electronics.
>
> There are precedents for freon compressors in Digital cabinets:
>
> http://toyvax.glendale.ca.us/~vance/vaxbar.html
>
> :-) :-) :-) :-) :-) :-) :-)
>
> Seriously though, how many VAX9000s were sold ?
Didn't Seymour Cray have a prototype which ran in an aquarium filled
with cleaning fluid? Not sure if his production machine was built that
way.
I saw a Cray-2 at Cray headquaters once that reminded me of a large cube
(about 4ft high, 5ftx5ft if I remember correctly). It had a glass top so
you can see the Fluorinert inside. The production Cray-2s looked different
than the one I saw.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/15/2009 4:31:12 PM
|
|
Neil Rieck wrote:
> There is probably something weird happening when people entertain
> themselves with the accomplishments of a bygone era.
>
> 1) The 1981 book "The Soul Of A New Machine" was republished in 2000.
In hindsight, that period may end up being a crucial period in history
for computing. Back in the 1980s, we just lived through it.
But when you look back, you look at Digital's heydays, the huge projects
such as Microvax II, VAX9000 and Alpha, and look at IBM doing a 180�
and reluctantly agreeing to make its IBM PC, apple unveiling the
MacIntosh in 1984, and the "bunch" of smaller computer makers
disapearing/merging.
The industry has since consolidated and apart from Microsoft and Apple,
there aren't any "big" projects anymore. Companies like HP and Dell are
out to maximize profit and lower costs, and there are no product
revolutions like we had in the 1980s.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/15/2009 9:31:14 PM
|
|
John Reagan wrote:
> Didn't Seymour Cray have a prototype which ran in an aquarium filled
> with cleaning fluid? Not sure if his production machine was built that
> way.
Can't remember where I saw it, but thre are hackers who did just that
when overclocking their PCs. They litterally dunked their motherboard
into an aquarium filled with some kind of oil that was non-conductive
yet provided serious cooling.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/15/2009 9:33:30 PM
|
|
JF Mezei wrote:
> Neil Rieck wrote:
>
>> There is probably something weird happening when people entertain
>> themselves with the accomplishments of a bygone era.
>>
>> 1) The 1981 book "The Soul Of A New Machine" was republished in 2000.
>
> In hindsight, that period may end up being a crucial period in history
> for computing. Back in the 1980s, we just lived through it.
>
> But when you look back, you look at Digital's heydays, the huge projects
> such as Microvax II, VAX9000 and Alpha, and look at IBM doing a 180�
> and reluctantly agreeing to make its IBM PC, apple unveiling the
> MacIntosh in 1984, and the "bunch" of smaller computer makers
> disapearing/merging.
>
> The industry has since consolidated and apart from Microsoft and Apple,
> there aren't any "big" projects anymore. Companies like HP and Dell are
> out to maximize profit and lower costs, and there are no product
> revolutions like we had in the 1980s.
I think 1984 might be the key year! That was when, IIRC, IBM started
pushing out the PC/XT to educational institutions. The DEC Rainbow 100
came along a year or so after the PC/XT and the race was on. Somebody
did a "clean" rewrite of the IBM BIOS code by having Team A analyze the
code and produce a specification for a BIOS; e.g. what it did but not
how. Team B used the specification to write the clean BIOS.
The actual IBM BIOS was copyright but since the reverse engineered BIOS
was not a copy, copyright did not get in the way of the clone makers.
Radio Shack and the TRS80 or "Trash 80" brought computing within reach
of just about anyone. Various third parties remedied many of the
initial design defects. Radio Shack used tin on card edge connectors
where they should have used gold, which made the machine somewhat less
than reliable. Various vendors offered remedies for these deficiencies.
DEC got into the act with the Rainbow 100. The chief virtue of this box
was that it gave me VT100 compatibility. Plug it into a MODEM and I
could talk to my machines at work!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/15/2009 10:08:48 PM
|
|
On Sun, 15 Nov 2009 17:08:48 -0500, Richard B. Gilbert wrote:
> I think 1984 might be the key year! That was when, IIRC, IBM started
> pushing out the PC/XT to educational institutions. The DEC Rainbow 100
> came along a year or so after the PC/XT and the race was on. Somebody
> did a "clean" rewrite of the IBM BIOS code by having Team A analyze the
> code and produce a specification for a BIOS; e.g. what it did but not
> how. Team B used the specification to write the clean BIOS.
Are you talking about the Rainbow? Because the Rainbow BIOS wasn't
anywhere near IBM compatible...the interface definition was substantially
different. (I once actually had the Rainbow BIOS manual, and was amazed
just how different it was).
But the Rainbow was neat - running CP/M-80 and CP/M-86 programs as well!
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/15/2009 11:48:28 PM
|
|
Bob Eager wrote:
> On Sun, 15 Nov 2009 17:08:48 -0500, Richard B. Gilbert wrote:
>
>> I think 1984 might be the key year! That was when, IIRC, IBM started
>> pushing out the PC/XT to educational institutions. The DEC Rainbow 100
>> came along a year or so after the PC/XT and the race was on. Somebody
>> did a "clean" rewrite of the IBM BIOS code by having Team A analyze the
>> code and produce a specification for a BIOS; e.g. what it did but not
>> how. Team B used the specification to write the clean BIOS.
>
> Are you talking about the Rainbow? Because the Rainbow BIOS wasn't
> anywhere near IBM compatible...the interface definition was substantially
> different. (I once actually had the Rainbow BIOS manual, and was amazed
> just how different it was).
No I was talking about PC clones. The Rainbow 100 was not, strictly
speaking, a PC clone.
>
> But the Rainbow was neat - running CP/M-80 and CP/M-86 programs as well!
>
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/16/2009 1:18:36 AM
|
|
In article <00f85b72$0$23355$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> DaveG wrote:
>
>> We had a 9000. It was air cooled.
>
> Knowing how Digital didn't do things "simple", it could have been a
> system made up of a internal water loop to cool the electronics, a
> freon compressor with a water-freon heat exchange at one end, and a
> freon-air exchanger at the other , along with fans that drew cool
> outside air through the exchanger and exausted warm air out.
On production systems, there was a large, lightweight box that
directed air directly onto the CPU chip holders. No water.
DEC was proud enough to make a point of that the first time they
brought a 9000 to a DECUS symposium.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/16/2009 12:57:22 PM
|
|
I just received a copy of =93Showstopper! The Breakneck Race to Create
Windows NT and the Next Generation at Microsoft=94 and find it a
riveting description of the activities of Cutler and other DEC people
at Microsoft (I=92ve only read the first four chapters)
1. Dave Cutler was the lead s/w designer of VMS but, emotionally-
socially, was a diamond in the rough.
2. Gordon Bell was Cutler=92s patron at DEC who thought that Cutler was
the most productive s/w developer at DEC.
3. Cutler wanted to leave Digital in 1981, but Bell convinced him to
set up a research arm away from Maynard (which turned out to be
Seattle)
4. When Bell left DEC in 1983 after suffering a heart attack, Cutler
lost his patron
5. Nathan Myrhvold was concerned about three major things at
Microsoft: UNIX, RISC, and portability (and kept sending memos to Bill
Gates reminding him of these potential problems in Microsoft's
future)
6. Without Bell around to protect Cutler=92s group in Seattle, DEC was
able to shut it down (other groups had patrons, Cutler=92s group did
not)
7. Nathan Myrhvold heard about the demise of Cutler=92s RISC project and
set up the meeting between Cutler and Gates
8. Gates only wanted Cutler=92s s/w people but Cutler wouldn=92t agree to
a deal without bringing along his hardware people.
9. Cutler wanted to bring along DEC hardware people who would help
Microsoft change the technical direction of the PC industry
10. Gates became Cutler's patron at Microsoft (it seems that Cutler
always needed a patron to compensate for his gruff personality)
11. The first version of this multi-personality (DOS, OS/2, Windows,
whatever) portable OS was called =93Portasys=94 and ran on a custom PC
designed by Cutler=92s group based upon the Intel i860 CPU. It was never
meant to be sold; only used internally to develop a portable OS.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/19/2009 12:24:12 PM
|
|
In article <hdic1s$jrq$03$1@news.t-online.com>,
Michael Kraemer <M.Kraemer@gsi.de> wrote:
> John Wallace schrieb:
> > On Nov 11, 8:47 pm, "P. Sture" <paul.nos...@sture.ch> wrote:
> >
>
> >>
> >>As I recall the Windows APIs were forced on it. There was also an outcry
> >>from people who knew about operating systems when it was decided to put
> >>the graphics in the kernel at NT 4.0. The motivation behind that was
> >>allegedly to improve performance with games.
> >
> >
> > Not just games, but particularly anything which was video intensive.
> > This was back in the days when a Matrox Millenium was a high end
> > graphics card.
> >
>
> >
> >>What irritates me looking back at that time is that NT ws being actively
> >>promoted by many as being reliable _because_ of its VMS heritage.
> >>
> >
> >
> > Indeed. And it could in principle have been that way, if Gates and his
> > engineering organisation had wanted it to be that way. But it didn't
> > work out that way, and the rest is history.
> >
>
> So once and for all times we could bury this
> "Cutler created NT as a VMS offspring and hence NT must be good"
> legend?
Yes please.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
11/19/2009 1:19:55 PM
|
|
On Nov 19, 7:24=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> I just received a copy of =93Showstopper! The Breakneck Race to Create
> Windows NT and the Next Generation at Microsoft=94 and find it a
> riveting description of the activities of Cutler and other DEC people
> at Microsoft (I=92ve only read the first four chapters)
>
> 1. Dave Cutler was the lead s/w designer of VMS but, emotionally-
> socially, was a diamond in the rough.
> 2. Gordon Bell was Cutler=92s patron at DEC who thought that Cutler was
> the most productive s/w developer at DEC.
> 3. Cutler wanted to leave Digital in 1981, but Bell convinced him to
> set up a research arm away from Maynard (which turned out to be
> Seattle)
> 4. When Bell left DEC in 1983 after suffering a heart attack, Cutler
> lost his patron
> 5. Nathan Myrhvold was concerned about three major things at
> Microsoft: UNIX, RISC, and portability (and kept sending memos to Bill
> Gates reminding him of these potential problems in Microsoft's
> future)
> 6. Without Bell around to protect Cutler=92s group in Seattle, DEC was
> able to shut it down (other groups had patrons, Cutler=92s group did
> not)
> 7. Nathan Myrhvold heard about the demise of Cutler=92s RISC project and
> set up the meeting between Cutler and Gates
> 8. Gates only wanted Cutler=92s s/w people but Cutler wouldn=92t agree to
> a deal without bringing along his hardware people.
> 9. Cutler wanted to bring along DEC hardware people who would help
> Microsoft change the technical direction of the PC industry
> 10. Gates became Cutler's patron at Microsoft (it seems that Cutler
> always needed a patron to compensate for his gruff personality)
> 11. The first version of this multi-personality (DOS, OS/2, Windows,
> whatever) portable OS was called =93Portasys=94 and ran on a custom PC
> designed by Cutler=92s group based upon the Intel i860 CPU. It was never
> meant to be sold; only used internally to develop a portable OS.
>
Okay so I've now finished chapter 8 of 10 of the book =93Showstopper!
The Breakneck Race to Create Windows NT and the Next Generation at
Microsoft=94. Sixty percent of this book is about "Decies" (DEC people
at Microsoft including Dave Cutler) with the remaining stuff being
about the "Microsofties" including Gates, Ballmer and others. If you
enjoyed either one of "Hackers" or "Soul of a New Machine" then you'll
like this book. I consider it to be a natural succession to "DEC is
Dead, Long Live DEC"
p.s. There was a whole lot of stuff I didn't know about Windows-NT
like: many of the Microsofties wanted to keep/extend DOS (FAT32) or
the OS/2 file system. It was the Decies who pushed for NTFS.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/21/2009 2:32:19 PM
|
|
On Sat, 21 Nov 2009 06:32:19 -0800, Neil Rieck wrote:
> p.s. There was a whole lot of stuff I didn't know about Windows-NT like:
> many of the Microsofties wanted to keep/extend DOS (FAT32) or the OS/2
> file system. It was the Decies who pushed for NTFS.
Didn't know that, but I'm not surprised, given the resemblance of NTFS to
ODS-2 etc.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
0
|
|
|
|
Reply
|
rde42 (978)
|
11/21/2009 3:12:49 PM
|
|
Bob Eager wrote:
> On Sat, 21 Nov 2009 06:32:19 -0800, Neil Rieck wrote:
>
>> p.s. There was a whole lot of stuff I didn't know about Windows-NT like:
>> many of the Microsofties wanted to keep/extend DOS (FAT32) or the OS/2
>> file system. It was the Decies who pushed for NTFS.
>
> Didn't know that, but I'm not surprised, given the resemblance of NTFS to
> ODS-2 etc.
>
It has been a very long time but I can remember when DOS/Windows file
systems needed occasional repairs. What we have now seems rock solid.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/21/2009 7:14:09 PM
|
|
In article <vcWdnXRxNbYRppXWnZ2dnUVZ_qidnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> It has been a very long time but I can remember when DOS/Windows file
> systems needed occasional repairs. What we have now seems rock solid.
I've had to repair mine from time to time. Which is extreemly
painfull because of the size of disks we have today, and because
Windows cannot repair a disk the it's boot from, so it remembers
when you want that disk repaired and does it partway through the
next boot. (You can get more than one cup of coffee.)
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/23/2009 1:12:24 PM
|
|
I just finished the book =93Showstopper! The Breakneck Race to Create
Windows NT and the Next Generation at Microsoft=94 and found it a
riveting description of the activities of Cutler and other DEC people
at Microsoft. Here are two final extracts you may find amusing.
P 179: Digital Equipment, his (Cutler's) former employer and current
nemesis, agreed to become the first computer maker to buy NT for the
purpose of porting, or adapting, it to computers powered bu Digital's
own microchip, called Alpha. The very people assigned to do the port
were some of Cutler's old employees at Digital West. Cutler exulted,
"Digital's management ran me out of the company" he said, "and a mere
four years later they knocked on my door." Cutler saw the Mica
operating system , whose cancellation by Digital prompted his
departure, as a rough equivalent of NT. "Digital is now paying for
something they could have had for free".
P 179. But some Digital people privately agreed that Culter's
departure still ranlked top executive and the Digital's adoption of NT
was tantamount to admitting a mistake. "Driving asway Culter was one
of the dumbest f*ck*ng things Digital ever did", on person said. "But
we can't say we screwed up because some of the idiots responsible for
that are still here".
P 266. Windows-NT (version 1.0) was build from 5.6 million lines of
code
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/24/2009 12:49:47 PM
|
|
On Nov 24, 12:49=A0pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
> I just finished the book =93Showstopper! The Breakneck Race to Create
> Windows NT and the Next Generation at Microsoft=94 and found it a
> riveting description of the activities of Cutler and other DEC people
> at Microsoft. Here are two final extracts you may find amusing.
>
> P 179: Digital Equipment, his (Cutler's) former employer and current
> nemesis, agreed to become the first computer maker to buy NT for the
> purpose of porting, or adapting, it to computers powered bu Digital's
> own microchip, called Alpha. The very people assigned to do the port
> were some of Cutler's old employees at Digital West. Cutler exulted,
> "Digital's management ran me out of the company" he said, "and a mere
> four years later they knocked on my door." Cutler saw the Mica
> operating system , whose cancellation by Digital prompted his
> departure, as a rough equivalent of NT. "Digital is now paying for
> something they could have had for free".
>
> P 179. =A0But some Digital people privately agreed that Culter's
> departure still ranlked top executive and the Digital's adoption of NT
> was tantamount to admitting a mistake. "Driving asway Culter was one
> of the dumbest f*ck*ng things Digital ever did", on person said. "But
> we can't say we screwed up because some of the idiots responsible for
> that are still here".
>
> P 266. Windows-NT (version 1.0) was build from 5.6 million lines of
> code
>
> Neil Rieck
> Kitchener / Waterloo / Cambridge,
> Ontario, Canada.http://www3.sympatico.ca/n.rieck/
I don't remember anybody ever calling DECwest "Digital West". The
Internerd remembers lots of relevant references to DECwest but a quick
look finds no relevant references to "Digital West". If that's a
direct quote rather than a transcription hiccup, then I do hope the
rest of the book is a lot more reliable and trustworthy.
As an example of such reliability or otherwise, does the book contain
any references to the untrustworthiness of Microsoft as a "bet your
business" 'partner' organisation? This wasn't necessarily well known
in the Palmer era but plenty of people and plenty of organisations
have had first hand experience of it since then.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/24/2009 1:05:09 PM
|
|
Neil Rieck wrote:
> was tantamount to admitting a mistake. "Driving asway Culter was one
> of the dumbest f*ck*ng things Digital ever did", on person said. "But
> we can't say we screwed up because some of the idiots responsible for
> that are still here".
My impression is that people are putting way too much importance on
Cutler, perhaps because they hear about Cutler bragging about himself.
Digital went to NT because at first it wanted Alpha to become widely
used, and not much later, because it wanted to abandon its own operating
systems to become a Microsoft reseller.
A Cutler-less team managed to build a most excellent Alpha chip
architecture. And it made more sense to port VMS than starting yet
another operating system since VMS has an installed base and still had
an impressive software portfolio.
Considering it took over 10 years before Microsoft had an NT that was
reliable enough, Cutler shouldn't be bragging so much about it.
What Cutler learned at Digital is that corporate life is much like the
TV show "Survivor". It isn't enough to learn to get water and food, you
also need to play the social game to have alliances so that you don't
get voted out. Bragging publically about his accomplishements and his
worth makes him look more valuable and makes it harder for Microsoft to
lose him. And it also forced Microsoft to listen to his ideas "because
he is important".
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/24/2009 8:49:40 PM
|
|
In article <75fcf71f-99c9-4ad6-837f-bcfe8b4024fd@x16g2000vbk.googlegroups.com>,
John Wallace <johnwallace4@yahoo.co.uk> writes:
> On Nov 24, 12:49=A0pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
>> I just finished the book =93Showstopper! The Breakneck Race to Create
>> Windows NT and the Next Generation at Microsoft=94 and found it a
>> riveting description of the activities of Cutler and other DEC people
>> at Microsoft. Here are two final extracts you may find amusing.
>>
>> P 179: Digital Equipment, his (Cutler's) former employer and current
>> nemesis, agreed to become the first computer maker to buy NT for the
>> purpose of porting, or adapting, it to computers powered bu Digital's
>> own microchip, called Alpha. The very people assigned to do the port
>> were some of Cutler's old employees at Digital West. Cutler exulted,
>> "Digital's management ran me out of the company" he said, "and a mere
>> four years later they knocked on my door." Cutler saw the Mica
>> operating system , whose cancellation by Digital prompted his
>> departure, as a rough equivalent of NT. "Digital is now paying for
>> something they could have had for free".
>>
>> P 179. =A0But some Digital people privately agreed that Culter's
>> departure still ranlked top executive and the Digital's adoption of NT
>> was tantamount to admitting a mistake. "Driving asway Culter was one
>> of the dumbest f*ck*ng things Digital ever did", on person said. "But
>> we can't say we screwed up because some of the idiots responsible for
>> that are still here".
>>
>> P 266. Windows-NT (version 1.0) was build from 5.6 million lines of
>> code
>>
>> Neil Rieck
>> Kitchener / Waterloo / Cambridge,
>> Ontario, Canada.http://www3.sympatico.ca/n.rieck/
>
> I don't remember anybody ever calling DECwest "Digital West". The
> Internerd remembers lots of relevant references to DECwest but a quick
> look finds no relevant references to "Digital West". If that's a
> direct quote rather than a transcription hiccup, then I do hope the
> rest of the book is a lot more reliable and trustworthy.
>
> As an example of such reliability or otherwise, does the book contain
> any references to the untrustworthiness of Microsoft as a "bet your
> business" 'partner' organisation? This wasn't necessarily well known
> in the Palmer era but plenty of people and plenty of organisations
> have had first hand experience of it since then.
I thought it was called DECwrl as in "DEC Western Research Lab".
And just out of curiosity, wasn't that where "Gatekeeper" was?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/24/2009 9:15:42 PM
|
|
Neil Rieck schrieb:
>
> P 179: Digital Equipment, his (Cutler's) former employer and current
> nemesis, agreed to become the first computer maker to buy NT for the
> purpose of porting, or adapting, it to computers powered bu Digital's
> own microchip, called Alpha. The very people assigned to do the port
> were some of Cutler's old employees at Digital West. Cutler exulted,
> "Digital's management ran me out of the company" he said, "and a mere
> four years later they knocked on my door." Cutler saw the Mica
> operating system , whose cancellation by Digital prompted his
> departure, as a rough equivalent of NT. "Digital is now paying for
> something they could have had for free".
Can't follow that logic.
As we have stated here, NT as we know it has little to do
with whatever Cutler had come up with before he left DEC.
So DEC would have to pay for NT anyway, even if Cutler never existed.
> P 179. But some Digital people privately agreed that Culter's
> departure still ranlked top executive and the Digital's adoption of NT
> was tantamount to admitting a mistake. "Driving asway Culter was one
> of the dumbest f*ck*ng things Digital ever did", on person said. "But
> we can't say we screwed up because some of the idiots responsible for
> that are still here"
How about proclaiming Cutler the next Messias?
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/24/2009 9:58:57 PM
|
|
"Bill Gunshannon" <billg999@cs.uofs.edu> wrote in message
news:7n30nuF3k3p67U1@mid.individual.net...
>
> I thought it was called DECwrl as in "DEC Western Research Lab".
>
Completely different animals. DECwest was the Seattle team. WRL was in
Pala Alto IIRC. CRL was in Cambridge MA.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/24/2009 10:37:03 PM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:010541fb$0$23355$c3e8da3@news.astraweb.com...
> Neil Rieck wrote:
>> was tantamount to admitting a mistake. "Driving asway Culter was one
>> of the dumbest f*ck*ng things Digital ever did", on person said. "But
>> we can't say we screwed up because some of the idiots responsible for
>> that are still here".
>
>
> My impression is that people are putting way too much importance on
> Cutler, perhaps because they hear about Cutler bragging about himself.
>
I find it amusing to hear the opinions of people who've never met Dave or
any of the original team that built VMS.
"Driving away Cutler..." was all part of a common problem, the OpenVMS group
had reached the 800lb Gorilla mark and had veto power over a lot of things.
It also was the ATM machine. So there was an unwillingness and inability to
implement whatever would replace VMS. Dave leaving was just one of the
symptoms, a very large example of it.
> Digital went to NT because at first it wanted Alpha to become widely
> used, and not much later, because it wanted to abandon its own operating
> systems to become a Microsoft reseller.
>
DEC wanted to be able to make money or at least break even building Alpha
chips. Period. Windows was the potential jackpot in terms of volume.
> A Cutler-less team managed to build a most excellent Alpha chip
> architecture. And it made more sense to port VMS than starting yet
> another operating system since VMS has an installed base and still had
> an impressive software portfolio.
>
Gads. Take this as a lesson: had they been able to produce nVAX on time,
there wouldn't have been a need for Alpha. From the blank-slate
perspective, Alpha is great. BUT it was a DISASTER for VMS regardless of
the performance. It broke binary compatibility, shedding ISV's and products
that were never ported. It caused calendar *years* of effort and millions
and millions of dollars to do. It was ported to VMS because at the time,
VMS was still big business - but by then internally VMS was seen as a
strategic dead end (at the time it was UNIX as the next big thing) and the
UNIX/RISC weed had rooted. VMS never recovered from the VAX running out of
gas, and the port to Alpha. But it was inevitable that it had to happen,
and we (DEC) needed to have been planning what came *after* VMS.
From the parochial viewpoint of the VMS installed base - what they needed
was faster VAXes. Not Alpha.
From a wider perspective, the OS Cutler was working on (not the hardware) at
DEC would have been the key to getting *beyond* VMS. An OS with executive
environments that would allow VMS compatibility (at least at the source and
command interface level), or with UNIX, or with something brand new.
I can hear it now "but VMS is the greatest!" - at the time I thought RSX was
the greatest. Eventually VMS took it's spot. Who knows how *great* the
Next Thing after VMS would have been - especially if manu of the people who
wrote VMS were the ones who helped replace it.
> Considering it took over 10 years before Microsoft had an NT that was
> reliable enough, Cutler shouldn't be bragging so much about it.
>
LOL. I love guys who know so little and say so much. Please distinguish
between the microkernel and "Windows". It's not like Dave designed
"Windows".
> What Cutler learned at Digital is that corporate life is much like the
> TV show "Survivor". It isn't enough to learn to get water and food, you
> also need to play the social game to have alliances so that you don't
> get voted out. Bragging publically about his accomplishements and his
> worth makes him look more valuable and makes it harder for Microsoft to
> lose him. And it also forced Microsoft to listen to his ideas "because
> he is important".
LOL. I'm not exactly sure why you feel compelled to try to tear down people
that you don't know, and infer things about situations you have little or no
direct knowledge of.
As a human being, people love or hate Dave - and that goes for people who
worked for him or with him. On the other hand, as an OS architect this guy
was at the core of RSX, VMS and NT. That isn't to say it was a one man
show. But the guy has made major contributions as an engineer/architect to
OS's - these are real accomplishments at a level that only a handful of
people can make claims of being even close. I remember reading his code
back in the 1980's when I was a Software Specialist in the field. There was
even something approaching a cult of worshipers among the guys who were real
technical dweebs, and stories bordering on epic myths about how certain
subsystems had been written fueled by anger and pizza over a weekend.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/24/2009 11:19:28 PM
|
|
FredK wrote:
>
> "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
> news:010541fb$0$23355$c3e8da3@news.astraweb.com...
>> Neil Rieck wrote:
>>> was tantamount to admitting a mistake. "Driving asway Culter was one
>>> of the dumbest f*ck*ng things Digital ever did", on person said. "But
>>> we can't say we screwed up because some of the idiots responsible for
>>> that are still here".
>>
>>
>> My impression is that people are putting way too much importance on
>> Cutler, perhaps because they hear about Cutler bragging about himself.
>>
>
> I find it amusing to hear the opinions of people who've never met Dave
> or any of the original team that built VMS.
>
> "Driving away Cutler..." was all part of a common problem, the OpenVMS
> group had reached the 800lb Gorilla mark and had veto power over a lot
> of things. It also was the ATM machine. So there was an unwillingness
> and inability to implement whatever would replace VMS. Dave leaving was
> just one of the symptoms, a very large example of it.
>
>> Digital went to NT because at first it wanted Alpha to become widely
>> used, and not much later, because it wanted to abandon its own operating
>> systems to become a Microsoft reseller.
>>
>
> DEC wanted to be able to make money or at least break even building
> Alpha chips. Period. Windows was the potential jackpot in terms of
> volume.
>
>> A Cutler-less team managed to build a most excellent Alpha chip
>> architecture. And it made more sense to port VMS than starting yet
>> another operating system since VMS has an installed base and still had
>> an impressive software portfolio.
>>
>
> Gads. Take this as a lesson: had they been able to produce nVAX on
> time, there wouldn't have been a need for Alpha.
That's highly questionable. It was already known that a RISC
architecture plus an optimizing compiler could blow the doors off a CISC
system.
Did anyone here ever try to run DECWindows on a VAXStation 2000? The
Alpha Station 200 does it without even breathing hard. Both machines
might be properly described as the slowest machines in their respective
architectures.
> From the blank-slate
> perspective, Alpha is great. BUT it was a DISASTER for VMS regardless
> of the performance. It broke binary compatibility, shedding ISV's and
> products that were never ported. It caused calendar *years* of effort
> and millions and millions of dollars to do. It was ported to VMS
> because at the time, VMS was still big business - but by then internally
> VMS was seen as a strategic dead end (at the time it was UNIX as the
> next big thing) and the UNIX/RISC weed had rooted. VMS never recovered
> from the VAX running out of gas, and the port to Alpha. But it was
> inevitable that it had to happen, and we (DEC) needed to have been
> planning what came *after* VMS.
>
Are there *any* CISC systems being manufactured today? Even the 80x86
family is RISC at the core; the CISC instruction set is layered on top
of a RISC processor.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/24/2009 11:42:31 PM
|
|
In article
<afab19db-4377-47d6-8353-42e17716d64b@1g2000vbm.googlegroups.com>, Neil
Rieck <n.rieck@sympatico.ca> writes:
> Neil Rieck
> Kitchener / Waterloo / Cambridge,
> Ontario, Canada.
> http://www3.sympatico.ca/n.rieck/
I always thought that this meant you built kitchens until I recently saw
a reference to a town called Kitchener on television in connection with
winter sports.
Do you live in Kitchener, do you build kitchens or both?
|
|
0
|
|
|
|
Reply
|
helbig (4870)
|
11/25/2009 12:07:37 AM
|
|
>
> Gads. =A0Take this as a lesson: had they been able to produce nVAX on tim=
e,
> there wouldn't have been a need for Alpha. =A0From the blank-slate
> perspective, Alpha is great. =A0BUT it was a DISASTER for VMS regardless =
of
> the performance. =A0It broke binary compatibility, shedding ISV's and pro=
ducts
> that were never ported. =A0It caused calendar *years* of effort and milli=
ons
> and millions of dollars to do. =A0It was ported to VMS because at the tim=
e,
> VMS was still big business - but by then internally VMS was seen as a
> strategic dead end (at the time it was UNIX as the next big thing) and th=
e
> UNIX/RISC weed had rooted. =A0VMS never recovered from the VAX running ou=
t of
> gas, and the port to Alpha. =A0But it was inevitable that it had to happe=
n,
> and we (DEC) needed to have been planning what came *after* VMS.
>
> From the parochial viewpoint of the VMS installed base - what they needed
> was faster VAXes. =A0Not Alpha.
>
I'm not sure I agree with these points. In the book "DEC is Dead, Long
Live DEC" it was stated that clock-for-clock comparisons between CISC
and RISC showed that RISC out performed CISC two-to-one without any
special tuning. Also, research present to DEC management by Gordon
Bell stated that the computer industry was going through major changes
every approx every ten years so that the end of VAX was in sight.
Let's also remember that DEC/Compaq sold more Alphas than
VAX.Apparently Intel has sold more Itaniums than VAX + Alpha combined
so the world didn't exactly fall to pieces with the end of VAX.
What I really question is the speedup specs from Itanium (EPIC). Many
have said that the EPIC compilers never lived up to the hype, but that
Itanium is still twice as fast as Alpha. Well, we all know a system
will enjoy a huge speed increase just going from DDR memory to DDR2 so
maybe the biggest waste of money involved replacing Alpha (and PA-
RISC) with Itanium. And considering the Itanium delays, HPQ should
have followed EV7 with EV8. Intel should have followed x86 with XEON
versions of x86-64 and forgotten about Itanium. Anyway, Itanium is
with us now and we'll all have to migrate there or forget about any
future with OpenVMS (shudder)
NSR
p.s. This week I purchased an HP PC based upon the Intel Core-i7 which
contains CSI (common system interconnect) aka QPI (Quick Path
Interconnect) which was developed by DEC for Alpha. This technology,
which DEC had in 2002, took 6 years to make it into other Intel
products. Can you imagine what the CPU industry would be like today if
Curly + Carly hadn't killed Alpha?
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/25/2009 12:55:52 AM
|
|
Richard B. Gilbert wrote:
> Did anyone here ever try to run DECWindows on a VAXStation 2000? The
> Alpha Station 200 does it without even breathing hard. Both machines
> might be properly described as the slowest machines in their respective
> architectures.
Well, duh. How much newer is the Alpha system? 1995 -
1989? My VAXstation 2000 has 6MB of memory and MFM disks.
(Anyone with a 12MB card in the free-to-good-home price range
is welcome to contact me.) My AlphaStation 200 4/233 has
768MB of memory and fast-wide SCSI disks. It certainly
_ought_ to be faster, even if the CPU itself were not.
I seem to recall that there were earlier, slower Alpha
systems, but that one is slow enough. "without even breathing
hard"? Try a Web browser. Of course, if you think that plain
DECwindows is slow on a VAXsta 2000, try Motif (with too
little memory and slow disks).
|
|
0
|
|
|
|
Reply
|
sms.antinode (932)
|
11/25/2009 5:24:32 AM
|
|
Richard B. Gilbert schrieb:
> FredK wrote:
>
>>
>> Gads. Take this as a lesson: had they been able to produce nVAX on
>> time, there wouldn't have been a need for Alpha.
>
> That's highly questionable. It was already known that a RISC
> architecture plus an optimizing compiler could blow the doors off a CISC
> system.
The VAX 4000 line wasn't too bad.
At least it would have prolonged the life of VAX/VMS a few more
years without the immediate necessity to port to sth else.
In the meantime DEC could have continued to improve the Mips line
for Unix and NT and maybe by mid-1990s decided whether it was
worth to port VMS too - or dump it.
Much less money to spend and much less hassle.
> Did anyone here ever try to run DECWindows on a VAXStation 2000? The
> Alpha Station 200 does it without even breathing hard. Both machines
> might be properly described as the slowest machines in their respective
> architectures.
The problem with the VS2000 is not enough RAM.
More RAM can do wonders.
> Are there *any* CISC systems being manufactured today? Even the 80x86
> family is RISC at the core; the CISC instruction set is layered on top
> of a RISC processor.
You can still buy most of the 68K chips.
Whether they are freshly manufactured or just catching
dust on some shelf I don't know.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/25/2009 8:16:21 AM
|
|
Neil Rieck schrieb:
>>
>>From the parochial viewpoint of the VMS installed base - what they needed
>>was faster VAXes. Not Alpha.
>>
>
> I'm not sure I agree with these points. In the book "DEC is Dead, Long
> Live DEC" it was stated that clock-for-clock comparisons between CISC
> and RISC showed that RISC out performed CISC two-to-one without any
> special tuning.
This is not generally true.
In 1990 e.g. 68040-based workstations (from HP) were
roughly on par with Mips-based DECstations and somewhat faster
than Sparc's. The 68040 executed almost one instruction per cycle,
just like the contemporary RISCs, and the 68060 follow-up was
even superscalar. The RISCs, however, were easier to crank up
clock speed and that was it.
> Let's also remember that DEC/Compaq sold more Alphas than
> VAX.
We had that one before. How many more Alphas than VAX?
I presume much less than a factor of 2.
> Apparently Intel has sold more Itaniums than VAX + Alpha combined
And how many of them run VMS?
> so the world didn't exactly fall to pieces with the end of VAX.
Effectively VAX ended with the introduction of Alpha, 1992.
> What I really question is the speedup specs from Itanium (EPIC). Many
> have said that the EPIC compilers never lived up to the hype,
How could they?
They are based on unrealistic assumptions,
i.e. perfectly predictable program execution and
indefinitely parallelizable program code.
> but that
> Itanium is still twice as fast as Alpha.
No surprise here. Itanics are clocked roughly
a factor two higher than the last Alpha's
and have an obscene amount of cache.
So this isn't exactly an Epic breakthrough
but rather old-fashioned tricks borrowed from
the RISC camp
(HP snake CPUs of 1991 vintage come to mind).
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/25/2009 8:49:06 AM
|
|
In article <d86e0f77-a874-423f-8b41-e580db480d4e@c34g2000yqn.googlegroups.com>, Steven Schweda <sms.antinode@gmail.com> writes:
>Richard B. Gilbert wrote:
>
>> Did anyone here ever try to run DECWindows on a VAXStation 2000? The
>> Alpha Station 200 does it without even breathing hard. Both machines
>> might be properly described as the slowest machines in their respective
>> architectures.
>
> Well, duh. How much newer is the Alpha system? 1995 -
>1989? My VAXstation 2000 has 6MB of memory and MFM disks.
>(Anyone with a 12MB card in the free-to-good-home price range
>is welcome to contact me.) My AlphaStation 200 4/233 has
>768MB of memory and fast-wide SCSI disks. It certainly
>_ought_ to be faster, even if the CPU itself were not.
_My_ first VAX, but not the first VAX I had ever worked, was a VAXstation
2000. It has 14MB, the expansion plate and an expansion cabinet. I have
2 Maxtor-XT2190s (RD54s) MFMs. DECwindows does load on it, albeit, it is
inordinately slow to start. I used to us the quick boot feature when I'd
used this system to help shorten the boot time. It was only B&W too. I
remember I paid a pretty penny to get my hands on my own VAX too. Anyway,
I eventually stopped using it with DECwindows. Simple terminal access was
much faster. Besides, it was just a box for hacking kernel code. Crash-
ing production boxes was a no-no.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
|
|
0
|
|
|
|
Reply
|
VAXman
|
11/25/2009 11:48:36 AM
|
|
Neil Rieck wrote:
> I'm not sure I agree with these points. In the book "DEC is Dead, Long
> Live DEC" it was stated that clock-for-clock comparisons between CISC
> and RISC showed that RISC out performed CISC two-to-one without any
> special tuning.
One need not forget that the VAX instruction set is far more complex
than the 8086 or IBM 360/370/390 or whatever it is called this week.
The 8086 and 360 architectures are more compatible with a CISC to RISC
translator inside the chip.
To me, one of the biggest mistake is to not make "VEST" standard AND
more integrated. If they had done a VAX emulators with the same
flexibility and transprency as Apple did the 68k emulator when it moved
to PowerPC (or the Rosetta PPC emulator when it moved to Intel), then
the VAX to Alpha migration would have been far more succesfull with
fewer VAX->SUN migrations. And DEC wouldn't have had to terminate a
whole chunk of the VMS softwre base since it could have continued to run
on VMS in emulated mode until it would have been recompiled to run Alpha
native. This would have greatly reduced the costs and allowed the whole
software library to run on Alpha, even for defunct software whose owners
were no longer there to recompile for Alpha.
> Let's also remember that DEC/Compaq sold more Alphas than
> VAX.
Nice statistic, but it would need to be put into context. In the 1970s
and early/mid 1980s, DEC grew at the same pace as the market. But in
the 1990s, DEC shrank while the market expanded a lot. So while hard
numbers may show more alpha sold, I would say that when put relative to
market, Alpha was far less significant to the whole market in its
lifetime than VAX was during it tenure.
>Apparently Intel has sold more Itaniums than VAX + Alpha combined
> so the world didn't exactly fall to pieces with the end of VAX.
And Intel has sold orders of magnitudes more 8086s than it has I64s
during the same time period. IA64 serves one company (HP) which is now
much bigger than Digital ever was. And the overall market continues to
grow. So yeah, even a low volume proprietary chip like IA64 will have no
problem outselling Alpha.
Also, one needs to consider manufacturing costs. Building a Nehalem
8086 with quickpath requires a huge investment in sophisticated FAB and
you need to produce a lot to get payback on investment. The 8086s have
tons of volume to justify these investments. IA64 gets "hand me downs"
since it is one or two generations behind in process, so it can use
older FABs. The high development costs coupled with low volumes are not
a recipe for success for IA64.
The big question is whether the Alpha architecture, if it had been
adopted by Intel in 1999, could have progressed at a faster pace and
lower development costs than what Intel has been able to achieve with IA64.
But as it stands, IA64 is late to the game and nobody is missing it.
That says a lot about its lack of importance in the market.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/25/2009 12:44:45 PM
|
|
In article <hehpmh$okf$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
>
> "Driving away Cutler..." was all part of a common problem, the OpenVMS group
> had reached the 800lb Gorilla mark and had veto power over a lot of things.
> It also was the ATM machine. So there was an unwillingness and inability to
> implement whatever would replace VMS. Dave leaving was just one of the
> symptoms, a very large example of it.
Replacing VMS was not what DEC needed to do. Porting to to faster,
cheaper chips was needed. DEC made a huge mistake not following
through on Emerald.
Nothing like having software as your 800lb gorilla and insisting on
acting like a hardware company. The response to Emerald clearly
showed that they were not ready to get in bed with Intel, even though
other folks at DEC clearly thought they needed to be an Intel PC
vendor.
>
> Gads. Take this as a lesson: had they been able to produce nVAX on time,
> there wouldn't have been a need for Alpha. From the blank-slate
> perspective, Alpha is great. BUT it was a DISASTER for VMS regardless of
> the performance. It broke binary compatibility, shedding ISV's and products
> that were never ported.
They responded to customer's insistence that speed was the driving
factor, more important than binary compatability. Maybe DEC was
listening to the wrong customers.
Looking at other vendors' successes in moving from 68K to various
RISC, binary compatability isn't always such a big factor. Even
when DEC customers moved from PDP-11 to VAX-11, the only big user
of compatability mode I ever saw was early releases of VMS itself.
> From the parochial viewpoint of the VMS installed base - what they needed
> was faster VAXes. Not Alpha.
Faster and cheaper. We noticed that a $1M+ (US) DEC 9000 had
performance on par with a $30K RISC UNIX workstation. Didn't matter
whether it was running VMS or OSF-1 (UNIX).
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/25/2009 1:46:25 PM
|
|
Richard B. Gilbert wrote:
> Did anyone here ever try to run DECWindows on a VAXStation 2000? The
> Alpha Station 200 does it without even breathing hard. Both machines
> might be properly described as the slowest machines in their respective
> architectures.
Yes, ran DECWindows on VAXStation 2000. Not bad under VWS (looks
a lot like X10) with 4MB RAM and no local disk. When the first
move to X11 came up we grabbed the 12MB and local disk (page
and swap) upgrade that DEC offered and still pretty much stopped
using the 2000's that we had.
I never used All-In-1, but it was sometimes reffered to as hog-in-1
because the recommended RAM allocation was 1MB per user. DECWindows
blew that away as we no longer could support single user workstations
with only 4MB RAM.
And when our MV II ran out of wind supporting a few PCs over
Pathworks, we bought the cheapest, slowest Alpha DEC ever produced
and it blew away everything we had, including or HP RISC and IBM
RS 6000 workstations. Supported a few dozen PCs and never noticed
the load. Made network file access seem as fast as local PC disk.
And that while limited to our 10Mb thinwire.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/25/2009 1:55:29 PM
|
|
In article <heip4l$e36$00$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
> The problem with the VS2000 is not enough RAM.
> More RAM can do wonders.
12MB per user was not enough. This at a time where out typical
application fit in 500KB.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/25/2009 1:56:35 PM
|
|
In article <00c63e2b$0$6711$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
> One need not forget that the VAX instruction set is far more complex
> than the 8086 or IBM 360/370/390 or whatever it is called this week.
For the 8086, I can agree. The mess that is the 80386 is just
about as complex as VAXen. I spent a lot of time doing macro
code in both.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/25/2009 1:58:18 PM
|
|
In article <heir22$a5n$01$1@news.t-online.com>,
Michael Kraemer <M.Kraemer@gsi.de> writes:
> Neil Rieck schrieb:
>
>>>
>>>From the parochial viewpoint of the VMS installed base - what they needed
>>>was faster VAXes. Not Alpha.
>>>
>>
>> I'm not sure I agree with these points. In the book "DEC is Dead, Long
>> Live DEC" it was stated that clock-for-clock comparisons between CISC
>> and RISC showed that RISC out performed CISC two-to-one without any
>> special tuning.
>
> This is not generally true.
> In 1990 e.g. 68040-based workstations (from HP) were
> roughly on par with Mips-based DECstations and somewhat faster
> than Sparc's. The 68040 executed almost one instruction per cycle,
> just like the contemporary RISCs, and the 68060 follow-up was
> even superscalar. The RISCs, however, were easier to crank up
> clock speed and that was it.
>
>
>> Let's also remember that DEC/Compaq sold more Alphas than
>> VAX.
>
> We had that one before. How many more Alphas than VAX?
> I presume much less than a factor of 2.
>
>> Apparently Intel has sold more Itaniums than VAX + Alpha combined
>
> And how many of them run VMS?
>
>> so the world didn't exactly fall to pieces with the end of VAX.
>
> Effectively VAX ended with the introduction of Alpha, 1992.
Which brings up an interesting point I may need to do some research
on. I wonder when Mentec released the last upgraded PDP-11 hardware?
Why do I have a feeling that even the PDP-11 outlasted the VAX.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/25/2009 3:29:25 PM
|
|
Bill Gunshannon wrote:
>> Effectively VAX ended with the introduction of Alpha, 1992.
>
> Which brings up an interesting point I may need to do some research
> on. I wonder when Mentec released the last upgraded PDP-11 hardware?
> Why do I have a feeling that even the PDP-11 outlasted the VAX.
A good article about the last generation of VAX chips/systems:
http://www.hpl.hp.com/hpjournal/dtj/vol4num3/toc.htm
(Digital Technical journal, many articles on the varoius NVAX based
systems. This issue dates from "summer 1992".
I was under the impression that the 4000-500/600 were younger and had
gotten a speed bump, but that article speaks of all of the VAX 4000s in
the present tense, so I have to assume the 4000-600 existed as of Summer
1992.
Note that sales and manufacture continued well after that.
QUESTION: Were there any new models of VAX (either workstation or
server) which were announced after 1992 ? Were they NVAX based, and did
the chips get a speed bump or just the same chips with same clock speeds
as the 1992 batch ?
When was the last batch of VAX CPU chips FABbed ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/25/2009 4:13:00 PM
|
|
"FredK" <fred.nospam@dec.com> wrote in message
news:hehpmh$okf$1@usenet01.boi.hp.com...
> As a human being, people love or hate Dave - and that goes for people who
> worked for him or with him. On the other hand, as an OS architect this
> guy was at the core of RSX, VMS and NT. That isn't to say it was a one
> man show. But the guy has made major contributions as an
> engineer/architect to OS's - these are real accomplishments at a level
> that only a handful of people can make claims of being even close.
Actually, while Dave as the Alpha-male of the group, I would say that Dick
Hustvedt, Rich Grove, and Andy Goldstein had a better longterm influence on
the functionality and stability of the OpenVMS systems of today.
John (who only met Dave once but heards LOTS of stories eating lunch with
Rich and Andy over the years)
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/25/2009 4:23:41 PM
|
|
In article <00892730$0$17039$c3e8da3@news.astraweb.com>,
JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Bill Gunshannon wrote:
>
>>> Effectively VAX ended with the introduction of Alpha, 1992.
>>
>> Which brings up an interesting point I may need to do some research
>> on. I wonder when Mentec released the last upgraded PDP-11 hardware?
>> Why do I have a feeling that even the PDP-11 outlasted the VAX.
>
> A good article about the last generation of VAX chips/systems:
>
> http://www.hpl.hp.com/hpjournal/dtj/vol4num3/toc.htm
>
> (Digital Technical journal, many articles on the varoius NVAX based
> systems. This issue dates from "summer 1992".
>
> I was under the impression that the 4000-500/600 were younger and had
> gotten a speed bump, but that article speaks of all of the VAX 4000s in
> the present tense, so I have to assume the 4000-600 existed as of Summer
> 1992.
>
> Note that sales and manufacture continued well after that.
>
>
> QUESTION: Were there any new models of VAX (either workstation or
> server) which were announced after 1992 ? Were they NVAX based, and did
> the chips get a speed bump or just the same chips with same clock speeds
> as the 1992 batch ?
>
> When was the last batch of VAX CPU chips FABbed ?
Mentec M11 was apparently released in 1997. Somehow I doubt there was
still VAX development going on then.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/25/2009 4:47:05 PM
|
|
"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
news:QcidnRdqdO1q85HWnZ2dnUVZ_o2dnZ2d@giganews.com...
> FredK wrote:
>>
>>
>> Gads. Take this as a lesson: had they been able to produce nVAX on time,
>> there wouldn't have been a need for Alpha.
>
> That's highly questionable. It was already known that a RISC architecture
> plus an optimizing compiler could blow the doors off a CISC system.
>
There is more to selling systems than raw speed. When SUN was selling
13,000 workstations a year, DEC was selling 5000 VAXstation 2000's a month -
the limit of capacity. Note that Alpha didn't kill the x86, nor did Power,
or Sparc, or PA-RISC. But the real point here is that nVAX was
"competetive", but too late to prevent the shift that occured during the
long, long period of time the the VAX was uncompetetive. Nobody really
knows what a 3GHz VAX with modest changes to the architecture might be
capable of today.
But all that is beside the point. I also said in a different point that I
believe that essentially the VAX running out of gas was inevitable. Even if
it was made faster, the 32-bit VA space was a limitation for the servers -
and technical workstations. Alpha was a brilliant design. I still consider
the EV7 probably the finest chip set ever designed. But Alpha came too late
for VMS, it had lost momentum inside and outside the company.
> Are there *any* CISC systems being manufactured today? Even the 80x86
> family is RISC at the core; the CISC instruction set is layered on top of
> a RISC processor.
>
Define "RISC" and then apply it to the current processors being designed
today. You are obsessing here about the instruction set - when the point of
your last sentence is that the instruction set doesn't matter, just the
underlying core that implements the instruction set presented to the system.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/25/2009 5:36:47 PM
|
|
In article <hejq08$nf0$1@usenet01.boi.hp.com>,
"FredK" <fred.nospam@dec.com> writes:
>
> Nobody really
> knows what a 3GHz VAX with modest changes to the architecture might be
> capable of today.
No, but it sure would be fun to find out!!
> Even if
> it was made faster, the 32-bit VA space was a limitation for the servers -
> and technical workstations.
I always laugh when this item comes up (again and again and again). Why?
Because Intel had o problem taking its wimpy architecture from 8 to 16 to
32 to 64 bits. If a company as bad as that (remember, if IBM hadn't thrown
the PC in teir direction they would not even have remained in business more
than another year or two, tops) could do it with an architecure as bad as
the 80xx(x) surely a company like DEC could have not just matched them
but surpased them with VAX development.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
11/25/2009 5:54:14 PM
|
|
"Neil Rieck" <n.rieck@sympatico.ca> wrote in message
news:72aec01f-1759-4b80-aaa3-1706389f3846@d10g2000yqh.googlegroups.com...
>Let's also remember that DEC/Compaq sold more Alphas than
>VAX.Apparently Intel has sold more Itaniums than VAX + Alpha combined
>so the world didn't exactly fall to pieces with the end of VAX.
And Intel has sold more x86 based chips than all of them combined. My
simple point here is that from the point that VAX became uncompetetive at
any price, to the point that nVAX showed up or Alpha showed up - was the
breaking point - the knee in the curve. We can argue about RISC vs CISC and
the VAX instruction set until we turn blue. We can rave about the
performance of Alpha. It didn't matter. It was a day late and a dollar
short.
Technical dweebs such as most of us are are too focused on the technical
aspects and forget about the business aspects. While the VAX became
uncompetetive at any price, software companies ported code to other
architectures like SPARC. Alpha VMS required a port of the code,
qualification and a new release. So do you backport from UNIX to VMS?
Upgrade the VAX code? Support multiple code streams? During that long span
of bad VAX performance internally DEC had changed focus from VMS to UNIX and
Windows. As had many, many 3rd parties.
At that point in time, there were as many people on boards like this loudly
upset with the demise of VAX as were happy with the birth of Alpha.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/25/2009 5:56:37 PM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:00c63e2b$0$6711$c3e8da3@news.astraweb.com...
>
> To me, one of the biggest mistake is to not make "VEST" standard AND
> more integrated.
VEST was mismanaged due to lag time. By the time customers were insterested
in it, we had already moved on. The early adopters of Alpha ported. So for
a long time nobody really used VEST a lot. By the time the customers who
*had* to leave VAX and needed something like VEST - we really had stopped
investing in it and the company was more interested in the x86 Windows
emulator for Alpha.
VEST also is not a solution for 3rd party software and libraries. The basic
issue is who and how do you support such code. The 3rd party is going to
say "uh, we don't support that code on Alpha, reproduce your problem on
VAX" - that is if the 3rd party even still existed or supported it on VAX.
The niche it fills is legacy code that the customer just simply needs to
run, and doesn't care how or how fast. Today they'd probably be better off
running one of the VAX emulators.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/25/2009 6:03:27 PM
|
|
Update:
http://simh.trailing-edge.com/semi/nvax.html
It reveals that the first batch of NVAX was in 1991, and were the
fastest CISC processors at that time. (71 to 90Mhz a a 0.75 micron
process). NVAX+ was pin compatible with Alpha EV4. (this was used for
the VAX 7000 which could be "in cabinet" upgraded to an Alpha.)
The second batch of the NVAX+ came out in 1994, up to 143Mhz @ 0.5
micron process)
NVAX had a power dissipation of just 18 watts. The above page, written
by Bob Supnik seems quite authoritative as he was involved in that.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/25/2009 6:18:46 PM
|
|
FredK wrote:
> Upgrade the VAX code? Support multiple code streams? During that long span
> of bad VAX performance internally DEC had changed focus from VMS to UNIX and
> Windows. As had many, many 3rd parties.
I was under the impression that the shift to windows occured later
during Palmer's era when he threw in the towel and started to sell the
company away.
Back in 1991-1992, Windows was still at DOS/Windows 3.1 with limited
networking, and word processing that even DECwrite could compete
against. Microsoft didn't have a decent email system.
I can understand Digital having given up on office desktops by
1991/1992, but for the rest, the focus on Windows came later.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/25/2009 6:25:18 PM
|
|
"John Reagan" <johnrreagan@earthlink.net> wrote in message
news:Usmdna62OrCRx5DWnZ2dnUVZ_sqdnZ2d@earthlink.com...
>
> "FredK" <fred.nospam@dec.com> wrote in message
> news:hehpmh$okf$1@usenet01.boi.hp.com...
>> As a human being, people love or hate Dave - and that goes for people who
>> worked for him or with him. On the other hand, as an OS architect this
>> guy was at the core of RSX, VMS and NT. That isn't to say it was a one
>> man show. But the guy has made major contributions as an
>> engineer/architect to OS's - these are real accomplishments at a level
>> that only a handful of people can make claims of being even close.
>
> Actually, while Dave as the Alpha-male of the group, I would say that Dick
> Hustvedt, Rich Grove, and Andy Goldstein had a better longterm influence
> on the functionality and stability of the OpenVMS systems of today.
>
> John (who only met Dave once but heards LOTS of stories eating lunch with
> Rich and Andy over the years)
The alpha-male remark pretty much reflects what everybody has to say about
Dave :-) I also think you have to break down the system into areas of
influence in terms of design. The basic scheduler and IO subsystem were
classic Cutler. But that in itself doesn't comprise the entire system, the
virtual address space management, process structure, calling standards, etc,
etc, etc. Nor is the list near complete, for example Nancy Kronenberg,
Peter Lippman, come to mind offhand.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/25/2009 6:26:36 PM
|
|
In article <00bb899d$0$27930$c3e8da3@news.astraweb.com>, JF Mezei
<jfmezei.spamnot@vaxination.ca> writes:
>
> I was under the impression that the shift to windows occured later
> during Palmer's era when he threw in the towel and started to sell the
> company away.
DEC were in bed with M$ long before Palmer.
Think of the ACE consortium (DEC,M$,Compaq,...) promoting
Mips and NT. IIRC an early version of NT even ran on DECstations.
>
> Back in 1991-1992, Windows was still at DOS/Windows 3.1 with limited
> networking, and word processing that even DECwrite could compete
> against. Microsoft didn't have a decent email system.
>
> I can understand Digital having given up on office desktops by
> 1991/1992,
this I can't understand.
> but for the rest, the focus on Windows came later.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
11/25/2009 6:37:38 PM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:00bb899d$0$27930$c3e8da3@news.astraweb.com...
> FredK wrote:
>
>> Upgrade the VAX code? Support multiple code streams? During that long
>> span
>> of bad VAX performance internally DEC had changed focus from VMS to UNIX
>> and
>> Windows. As had many, many 3rd parties.
>
> I was under the impression that the shift to windows occured later
> during Palmer's era when he threw in the towel and started to sell the
> company away.
>
> Back in 1991-1992, Windows was still at DOS/Windows 3.1 with limited
> networking, and word processing that even DECwrite could compete
> against. Microsoft didn't have a decent email system.
>
> I can understand Digital having given up on office desktops by
> 1991/1992, but for the rest, the focus on Windows came later.
When the VAX ran out of gas, the strategists at DEC decided that UNIX/RISC
would be the next big thing. "Windows" wasn't really that much in the
picture for this scenerio - since they were thinking servers and technical
desktops - not "consumer" computers.
However, during this period the layered product software development groups
were told that they should act like a software business that wasn't tied to
an OS or HW architecture and you saw most of them create UNIX and Windows
versions of many of their products and many lose focus or even abandon new
versions for VMS.
Windows certainly didn't seem to me to be a focus for the design of Alpha at
least when it started, but by the time the first *systems* were being
introduced it had become an area of intense interest by former DEC'ies at
Microsoft and then current employees at DECwest - and became an active area
of new interest inside DEC - the fact that MS had a MIPS based port of
Windows showed it was possible. Certainly it was an evolution in thinking -
otherwise we never would have had the SRM vs AlphaBIOS debacle. - or the
lack of byte/word access.
|
|
0
|
|
|
|
Reply
|
fred.nospam2 (506)
|
11/25/2009 6:43:07 PM
|
|
On 2009-11-25, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> NVAX+ was pin compatible with Alpha EV4.
NVAX+ was *mostly* pin compatible with Alpha EV4. I once built a PCI VAX
using the EV4 support chips (a little board that could be popped into
the CPU socket of a low-end PCI Alphastation); there were some subtle
differences.
--
roger ivie
rivie@ridgenet.net
|
|
0
|
|
|
|
Reply
|
rivie (667)
|
11/25/2009 8:22:02 PM
|
|
"FredK" <fred.nospam@dec.com> wrote in message
news:hejstl$p0h$1@usenet01.boi.hp.com...
> The alpha-male remark pretty much reflects what everybody has to say about
> Dave :-) I also think you have to break down the system into areas of
> influence in terms of design. The basic scheduler and IO subsystem were
> classic Cutler. But that in itself doesn't comprise the entire system,
> the virtual address space management, process structure, calling
> standards, etc, etc, etc. Nor is the list near complete, for example
> Nancy Kronenberg, Peter Lippman, come to mind offhand.
>
That was my point. Folks here in this newsgroup (and in so-called
authoritative books) hold Cutler as the sole-father of VMS. There were many
more cooks in the kitchen. Give Cutler his credit, but please, he's only
human (although I've heard folks say otherwise)
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/26/2009 4:10:11 AM
|
|
In article <Usmdna62OrCRx5DWnZ2dnUVZ_sqdnZ2d@earthlink.com>, "John
Reagan" <johnrreagan@earthlink.net> writes:
> Actually, while Dave as the Alpha-male of the group, I would say that Dick
> Hustvedt, Rich Grove, and Andy Goldstein had a better longterm influence on
> the functionality and stability of the OpenVMS systems of today.
Indeed. Hustvedt in particular seems quite respected by those in the
know. He would probably have continued to make good contributions were
it not for the accident.
|
|
0
|
|
|
|
Reply
|
helbig (4870)
|
11/26/2009 8:31:38 AM
|
|
In article <hejr5f$nvd$1@usenet01.boi.hp.com>, "FredK"
<fred.nospam@dec.com> writes:
> Technical dweebs such as most of us are are too focused on the technical
> aspects and forget about the business aspects.
DEC's middle name was equipment; IBM's middle name is business.
|
|
0
|
|
|
|
Reply
|
helbig (4870)
|
11/26/2009 8:37:03 AM
|
|
On Nov 24, 7:07=A0pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article
> <afab19db-4377-47d6-8353-42e17716d...@1g2000vbm.googlegroups.com>, Neil
>
> Rieck <n.ri...@sympatico.ca> writes:
> > Neil Rieck
> > Kitchener / Waterloo / Cambridge,
> > Ontario, Canada.
> >http://www3.sympatico.ca/n.rieck/
>
> I always thought that this meant you built kitchens until I recently saw
> a reference to a town called Kitchener on television in connection with
> winter sports.
>
> Do you live in Kitchener, do you build kitchens or both?
I live in the city of Kitchener (renamed after a British military
officer during World War One when the city of Berlin, Ontario was
under virtual occupation by the British).
http://maps.google.ca/maps?f=3Dq&source=3Ds_q&hl=3Den&geocode=3D&q=3DKitche=
ner,+Ontario,+Canada&sll=3D49.891235,-97.15369&sspn=3D31.88402,66.708984&ie=
=3DUTF8&hq=3D&hnear=3DKitchener,+Waterloo+Regional+Municipality,+Ontario&z=
=3D12
Cambridge, Kitchener, and Waterloo (home of the university by the same
name as well as RIM, OpenText, Dalsa, and the Perimeter Institute for
Theoretical Physics) are all jammed together in a continuous triple
community. I live so close to Waterloo, I could hit it with a rock.
I do not build kitchens, but I am an OpenVMS developer for a large
Canadian telecommunications company.
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/26/2009 12:45:34 PM
|
|
On Nov 26, 3:37=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> DEC's middle name was equipment; IBM's middle name is business.
Well, if you want to compare apple-to-apples, it's International
Business Machines Corporation versus Digital Equipment Corporation.
So, if "equipment" is DEC's middle name then "corporation" is the
surname. That makes IBM's surname "corporation" as well.
Therefore, IBM's middle name is really "business machines".
:-)
|
|
0
|
|
|
|
Reply
|
sapienza (402)
|
11/26/2009 1:20:31 PM
|
|
FrankS mentioned on 26-11-2009 14:20:
> On Nov 26, 3:37 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> undress to reply) wrote:
>> DEC's middle name was equipment; IBM's middle name is business.
>
> Well, if you want to compare apple-to-apples, it's International
> Business Machines Corporation versus Digital Equipment Corporation.
>
> So, if "equipment" is DEC's middle name then "corporation" is the
> surname. That makes IBM's surname "corporation" as well.
>
> Therefore, IBM's middle name is really "business machines".
Either way, DEC's middle name is "long gone", IBM's is "still existing".
/Wilm
|
|
0
|
|
|
|
Reply
|
w6.boerhout (112)
|
11/26/2009 8:21:51 PM
|
|
On Nov 25, 7:44=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
[...snip...]
>
> One need not forget that the VAX instruction set is far more complex
> than the 8086 or IBM 360/370/390 or whatever it is called this week.
>
Not sure if you are saying this was good or bad. CISC made sense when
memory was expensive but things changed when memory got cheap. Add to
this the fact that the VAX could require something like 200 microcode
cycles executing the POLY instruction then you wonder how they ever
got any work done while serving interrupts. These instructions were
restartable but you could not interrupt them in the middle then pick
up where you left off. Now if the CISC instruction is broken up into
multiple RISC instructions, then an interrupt would let you pick up
you RISC-based-POLY-equivalent where the interrupt happened.
No, while I smile fondly on my PDP and VAX days, I know that RISC and
Alpha where the right moves for the industry. It is too bad upper
management at DEC did not agree (then built VAX-9000)
[...snip...]
>
> Also, one needs to consider manufacturing costs. =A0Building a Nehalem
> 8086 with quickpath requires a huge investment in sophisticated FAB and
> you need to produce a lot to get payback on investment. The 8086s have
> tons of volume to justify these investments. =A0 IA64 gets "hand me downs=
"
> since it is one or two generations behind in process, so it can use
> older FABs. =A0The high development costs coupled with low volumes are no=
t
> a recipe for success for IA64.
>
QPI (CSI) were developed at DEC for Alpha. Had not Curly + Carly
killed off Alpha, the whole industry would have abandoned FSB much
sooner. That said, Intel knows how to make a buck and they stuck QPI
in Core-7 because that is where their volumes AND where they meet AMD
in the market place. With the demise of Alpha, PA-RISC, ROCK, and the
possible demise of SPARC and ULTRA SPARC, the competition against IA64
is lower so they can take their time.
> The big question is whether the Alpha architecture, if it had been
> adopted by Intel in 1999, could have progressed at a faster pace and
> lower development costs than what Intel has been able to achieve with IA6=
4.
>
I agree. Besides, IA64 required new compiler technology which never
really materialized so it was all for nothing. At least DEC had
produced some pretty neat code generators for Alpha.
> But as it stands, IA64 is late to the game and nobody is missing it.
> That says a lot about its lack of importance in the market.
True
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/26/2009 10:39:03 PM
|
|
"Neil Rieck" <n.rieck@sympatico.ca> wrote in message
news:b9757ffd-1cc9-4a35-b566-14f11621a604@d21g2000yqn.googlegroups.com...
>I agree. Besides, IA64 required new compiler technology which never
>really materialized so it was all for nothing. At least DEC had
>produced some pretty neat code generators for Alpha.
Not sure on what you mean. The same GEM code generator for Alpha is the one
we use for Itanium. You get all the optimizations you get on Alpha. Does
it take full advantage of all the Itanium additional features, no it does
not. But you get all the loop optimization, routine inlining, dataflow
analysis, etc. that you get on Alpha.
The code generater used by the HP-UX side is pretty darned good as well as
the Intel code generator. Both know how to use the various data and control
speculation on the chip. Have you looked at them at all?
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/27/2009 5:47:36 AM
|
|
On Nov 27, 12:47=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "Neil Rieck" <n.ri...@sympatico.ca> wrote in message
>
> news:b9757ffd-1cc9-4a35-b566-14f11621a604@d21g2000yqn.googlegroups.com...
>
> >I agree. Besides, IA64 required new compiler technology which never
> >really materialized so it was all for nothing. At least DEC had
> >produced some pretty neat code generators for Alpha.
>
> Not sure on what you mean. =A0The same GEM code generator for Alpha is th=
e one
> we use for Itanium. =A0You get all the optimizations you get on Alpha. =
=A0Does
> it take full advantage of all the Itanium additional features, no it does
> not. =A0But you get all the loop optimization, routine inlining, dataflow
> analysis, etc. that you get on Alpha.
>
> The code generater used by the HP-UX side is pretty darned good as well a=
s
> the Intel code generator. =A0Both know how to use the various data and co=
ntrol
> speculation on the chip. =A0Have you looked at them at all?
>
> John
Sorry for the confusion but I was defending the move from VAX to Alpha
(or CISC to RISC). I have extensive programming experience with both
and can tell you that Alpha lived up to the hype. I've got zero
experience with Itanium (so far) but have heard from customers (here I
am talking exclusively about people who are not Itanium manufacturers
or salesmen) that it does not live up to the hype as far as speed is
concerned. That said, Itanium servers are already smaller and cheaper
than Alpha so all is not lost.
NSR
|
|
0
|
|
|
|
Reply
|
n.rieck (1972)
|
11/27/2009 10:08:08 PM
|
|
In article <7n50qlF3k8008U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>
> Which brings up an interesting point I may need to do some research
> on. I wonder when Mentec released the last upgraded PDP-11 hardware?
> Why do I have a feeling that even the PDP-11 outlasted the VAX.
I'm pretty sure Mentec sold some PDP-11 hardware, and produced
one update to RSX, but I don't recall them building anything new.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/30/2009 2:24:18 PM
|
|
In article <hejq08$nf0$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
> Nobody really
> knows what a 3GHz VAX with modest changes to the architecture might be
> capable of today.
>
> But all that is beside the point. I also said in a different point that I
> believe that essentially the VAX running out of gas was inevitable. Even if
> it was made faster, the 32-bit VA space was a limitation for the servers -
> and technical workstations.
At the time Alpha was introduced, only a few applications were bound
by 32 bit address space. I know the C compiler supports 64 bit
addressing on Alpha, and the Fortran compiler was promised (was it
delivered), but I think most of the native language compilers still
don't.
But just as the 18 bit PDP-10 was updated to 23 bits, and the 32 bit
IA32 was extended to 64 bits, adding extended addressing to VAX would
have been a straightforward thing. Not all single byte opcodes were
used up, and very few two byte opcodes were in use. Vector instructions
were added using two byte opcodes, and 64 bit addressing could have been,
too. Even longer opcodes were possible, extending the same scheme as
two byte opcodes.
But DEC insisted that customers didn't want a 64 bit VAX, and did
need to listen to the wind which was clearly blowing RISC. Only
Intel seemed to resist that wind.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/30/2009 2:36:31 PM
|
|
In article <hejthi$cp5$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:
>
> DEC were in bed with M$ long before Palmer.
> Think of the ACE consortium (DEC,M$,Compaq,...) promoting
> Mips and NT. IIRC an early version of NT even ran on DECstations.
I recall the ACE consortium supporting OSF-1 on MIPS as a standard
OS and chip to rival MS-DOS on x86. Then adding other UNIX on other
chips, before falling apart.
Early versions of NT were supposed to run on x86, Alpha, MIPS,
PPC, ..., they were all supposed to ship on the same CD on the
same date. x86 shipped first even though MS used Alpha heavily
as a development platform, then the other chip vendors all dropped
out. I only recall x86 and Alpha versions of NT ever shipping.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/30/2009 2:42:21 PM
|
|
"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message
news:7absIkSdGMzZ@eisner.encompasserve.org...
> In article <hejq08$nf0$1@usenet01.boi.hp.com>, "FredK"
> <fred.nospam@dec.com> writes:
>
>> Nobody really
>> knows what a 3GHz VAX with modest changes to the architecture might be
>> capable of today.
>>
>> But all that is beside the point. I also said in a different point that
>> I
>> believe that essentially the VAX running out of gas was inevitable. Even
>> if
>> it was made faster, the 32-bit VA space was a limitation for the
>> servers -
>> and technical workstations.
>
> At the time Alpha was introduced, only a few applications were bound
> by 32 bit address space. I know the C compiler supports 64 bit
> addressing on Alpha, and the Fortran compiler was promised (was it
> delivered), but I think most of the native language compilers still
> don't.
>
Pascal has 64-bit pointer support (I added limited support back in 1998 with
much more complete support in the early 2000s). COBOL has USAGE IS
POINTER64. BASIC doesn't have much pointer typing to begin with. Don't
know about Ada right off hand.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/30/2009 4:06:20 PM
|
|
In article <TIGdnaZfkYIdcI7WnZ2dnUVZ_qSdnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
> Pascal has 64-bit pointer support (I added limited support back in 1998 with
> much more complete support in the early 2000s). COBOL has USAGE IS
> POINTER64. BASIC doesn't have much pointer typing to begin with. Don't
> know about Ada right off hand.
Like Fortran-77, you don't need pointers in your code to need a
compiler which is pointer size aware.
For instance, the TOPS-20 Fortran-77 compiler would generate
different opcodes and allocate different space for pass by address
arguments when compiled in 18 bit or 23 bit addressing mode. I
suspect the Alpha Fortran-9x and C compilers can make use of 64 bit
addressing, even if you don't declare a single pointer in your code,
if you compile with the appropriate qualifiers.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/30/2009 5:01:58 PM
|
|
In article <alpine.LFD.2.00.0911301022310.12986@libra.gmcl.internal>, Rob Brown <mylastname@gmcl.com> writes:
>
> I'm not sure whether you consider it "new" or not, but back in 2003
> (or earlier?) they sold the M11 processor board. At
> <http://web.archive.org/web/20031128165506/www.mentec-inc.com/m11specs.htm>
> it says "PDP-11 instructions are implemented by a microprogrammed
> subsystem based on the TI 8832 ALU and the TI 8818A microsequencer."
Yeah, I would call that new. As far as I recall, DEC's last PDP-11
processors were DEC's own single chip CPUs.
And I'm quite certain SIMH can run circles around them.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
11/30/2009 5:04:04 PM
|
|
On Mon, 30 Nov 2009 at 08:24 -0600, Bob Koehler wrote:
>
>
> In article <7n50qlF3k8008U1@mid.individual.net>,
> billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>
>> Which brings up an interesting point I may need to do some research
>> on. I wonder when Mentec released the last upgraded PDP-11
>> hardware? Why do I have a feeling that even the PDP-11 outlasted
>> the VAX.
>
> I'm pretty sure Mentec sold some PDP-11 hardware, and produced
> one update to RSX, but I don't recall them building anything new.
I'm not sure whether you consider it "new" or not, but back in 2003
(or earlier?) they sold the M11 processor board. At
<http://web.archive.org/web/20031128165506/www.mentec-inc.com/m11specs.htm>
it says "PDP-11 instructions are implemented by a microprogrammed
subsystem based on the TI 8832 ALU and the TI 8818A microsequencer."
FWIW
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
|
|
0
|
|
|
|
Reply
|
mylastname3 (505)
|
11/30/2009 5:17:28 PM
|
|
On Mon, 30 Nov 2009 at 08:24 -0600, Bob Koehler wrote:
>
>
> In article <7n50qlF3k8008U1@mid.individual.net>,
> billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>
>> Which brings up an interesting point I may need to do some research
>> on. I wonder when Mentec released the last upgraded PDP-11
>> hardware? Why do I have a feeling that even the PDP-11 outlasted
>> the VAX.
>
> I'm pretty sure Mentec sold some PDP-11 hardware, and produced
> one update to RSX,
Perhaps two updates to RSX. I'm pretty sure that M+ V4.5 was from
Mentec. V4.6 certainly was.
> but I don't recall them building anything new.
I'm not sure whether you consider it "new" or not, but back in 2003
(or earlier?) they sold the M11 processor board. At
<http://web.archive.org/web/20031128165506/www.mentec-inc.com/m11specs.htm>
it says "PDP-11 instructions are implemented by a microprogrammed
subsystem based on the TI 8832 ALU and the TI 8818A microsequencer."
FWIW
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
|
|
0
|
|
|
|
Reply
|
mylastname3 (505)
|
11/30/2009 5:24:20 PM
|
|
RE: new PDP11s post Digital going to VAX.
Didn't Compuserve use customer PDP11 based machines as "nodes" in
different cities where they offered service ?
And after Mentec inherited the PDP, did it have any PDP CPUs fabbed ? Or
did it use stockopiled CPUs made by DEC when it made the last big batch
of them ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/30/2009 6:32:36 PM
|
|
On Nov 27, 5:47=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "Neil Rieck" <n.ri...@sympatico.ca> wrote in message
>
> news:b9757ffd-1cc9-4a35-b566-14f11621a604@d21g2000yqn.googlegroups.com...
>
> >I agree. Besides, IA64 required new compiler technology which never
> >really materialized so it was all for nothing. At least DEC had
> >produced some pretty neat code generators for Alpha.
>
> Not sure on what you mean. =A0The same GEM code generator for Alpha is th=
e one
> we use for Itanium. =A0You get all the optimizations you get on Alpha. =
=A0Does
> it take full advantage of all the Itanium additional features, no it does
> not. =A0But you get all the loop optimization, routine inlining, dataflow
> analysis, etc. that you get on Alpha.
>
> The code generater used by the HP-UX side is pretty darned good as well a=
s
> the Intel code generator. =A0Both know how to use the various data and co=
ntrol
> speculation on the chip. =A0Have you looked at them at all?
>
> John
"you get all the loop optimization, routine inlining, dataflow
analysis, etc. that you get on Alpha."
Whilst these may have been leading edge once upon a time, surely
surely surely (?) they are fairly standard stuff these days, no? Does
gcc 4 do those to any useful extent, for example? Does Visual Studio
do those (either on x86 or on IA64)?
And with IA64 you also afaict get a variety of often unavoidable run-
time penalties (alignment faults etc being the classic example) which
were largely things that Alpha users didn't need to worry too much
about, and are things that AMD64 users don't need to worry too much
about.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/30/2009 6:32:39 PM
|
|
"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message
news:mESFRhh8PZhX@eisner.encompasserve.org...
> In article <TIGdnaZfkYIdcI7WnZ2dnUVZ_qSdnZ2d@earthlink.com>, "John Reagan"
> <johnrreagan@earthlink.net> writes:
>>
>> Pascal has 64-bit pointer support (I added limited support back in 1998
>> with
>> much more complete support in the early 2000s). COBOL has USAGE IS
>> POINTER64. BASIC doesn't have much pointer typing to begin with. Don't
>> know about Ada right off hand.
>
> Like Fortran-77, you don't need pointers in your code to need a
> compiler which is pointer size aware.
>
> For instance, the TOPS-20 Fortran-77 compiler would generate
> different opcodes and allocate different space for pass by address
> arguments when compiled in 18 bit or 23 bit addressing mode. I
> suspect the Alpha Fortran-9x and C compilers can make use of 64 bit
> addressing, even if you don't declare a single pointer in your code,
> if you compile with the appropriate qualifiers.
>
Argument slots (per the Calling Standard) are 64-bits wide period.
Addresses passed as arguments are sign-extended to 64-bits. The called
routines depend on that since system-space addresses rely on that.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/30/2009 7:14:52 PM
|
|
"John Wallace" <johnwallace4@yahoo.co.uk> wrote in message
news:d6cc754e-de17-4506-8460-eb282a1e7d2c@m35g2000vbi.googlegroups.com...
On Nov 27, 5:47 am, "John Reagan" <johnrrea...@earthlink.net> wrote:
>"you get all the loop optimization, routine inlining, dataflow
>analysis, etc. that you get on Alpha."
>Whilst these may have been leading edge once upon a time, surely
>surely surely (?) they are fairly standard stuff these days, no? Does
>gcc 4 do those to any useful extent, for example? Does Visual Studio
>do those (either on x86 or on IA64)?
I was commenting on a statement that our Itanium code-generator is less than
the Alpha version. It isn't.
Yes such optimizations are often common but on most Unix systems I've seen
such optimizations are off by default.
GEM also does various forms of loop analysis, software pipelining, some
limited speculation on Alpha (where there isn't any hardware support like
Itanium's data speculation and NaTs).
>And with IA64 you also afaict get a variety of often unavoidable run-
>time penalties (alignment faults etc being the classic example) which
>were largely things that Alpha users didn't need to worry too much
>about, and are things that AMD64 users don't need to worry too much
>about.
Unavoidable? Just align your data or tell the compiler the data isn't
aligned.
Remember that except for compiler bugs, alignment faults comes from the user
lying to the compiler. The compiler thinks the data is aligned but the
program cheated and violated a rule (like stuffing some odd-byte address
into an "int*"). Either align the data or if you can't, tell the compiler
what you did and we'll avoid the alignment fault.
Those alignment faults even on AMD64 cost time and hardware. They just cost
time on Alpha since there is no hardware support to deal with them. They
ALL get sent at least to the PAL code. On Itanium, the hardware can fix up
some if they fall in the same quadword or get sent to the OS as there is no
PAL code. All of the slowdown for alignment faults on Itanium is not due to
the chip, but due to all the overhead that OpenVMS has to do to resolve the
misaligned memory reference. If Alpha didn't have low-level PAL code, it
would be just as bad if not worse.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/30/2009 7:24:22 PM
|
|
On Nov 30, 7:24=A0pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "John Wallace" <johnwalla...@yahoo.co.uk> wrote in message
>
> news:d6cc754e-de17-4506-8460-eb282a1e7d2c@m35g2000vbi.googlegroups.com...
> On Nov 27, 5:47 am, "John Reagan" <johnrrea...@earthlink.net> wrote:
>
> >"you get all the loop optimization, routine inlining, dataflow
> >analysis, etc. that you get on Alpha."
> >Whilst these may have been leading edge once upon a time, surely
> >surely surely (?) they are fairly standard stuff these days, no? Does
> >gcc 4 do those to any useful extent, for example? Does Visual Studio
> >do those (either on x86 or on IA64)?
>
> I was commenting on a statement that our Itanium code-generator is less t=
han
> the Alpha version. =A0It isn't.
>
> Yes such optimizations are often common but on most Unix systems I've see=
n
> such optimizations are off by default.
>
> GEM also does various forms of loop analysis, software pipelining, some
> limited speculation on Alpha (where there isn't any hardware support like
> Itanium's data speculation and NaTs).
>
> >And with IA64 you also afaict get a variety of often unavoidable run-
> >time penalties (alignment faults etc being the classic example) which
> >were largely things that Alpha users didn't need to worry too much
> >about, and are things that AMD64 users don't need to worry too much
> >about.
>
> Unavoidable? =A0Just align your data or tell the compiler the data isn't
> aligned.
>
> Remember that except for compiler bugs, alignment faults comes from the u=
ser
> lying to the compiler. =A0The compiler thinks the data is aligned but the
> program cheated and violated a rule (like stuffing some odd-byte address
> into an "int*"). =A0Either align the data or if you can't, tell the compi=
ler
> what you did and we'll avoid the alignment fault.
>
> Those alignment faults even on AMD64 cost time and hardware. =A0They just=
cost
> time on Alpha since there is no hardware support to deal with them. =A0Th=
ey
> ALL get sent at least to the PAL code. =A0On Itanium, the hardware can fi=
x up
> some if they fall in the same quadword or get sent to the OS as there is =
no
> PAL code. =A0All of the slowdown for alignment faults on Itanium is not d=
ue to
> the chip, but due to all the overhead that OpenVMS has to do to resolve t=
he
> misaligned memory reference. =A0If Alpha didn't have low-level PAL code, =
it
> would be just as bad if not worse.
>
> John
Thanks for that.
Can I just pick up on one bit this time:
"alignment faults comes from the user lying to the compiler"
That's obviously true from your point of view as a compiler person,
but for the vast majority of folk out there, it would be more accurate
to say:
"alignment faults comes from the >>developer<< lying to the compiler"
And if the end user and the application developer are different
organisations, different companies, etc, getting this fixed may be non
trivial even if it's technically trivial to fix (which it may not
always be). So somebody's promised IA64 performance increase may or
may not be achievable without effort, whereas a mainstream chip is
likely to deliver the performance as advertised, starting from day one
(otherwise someone would get into trouble).
I guess IT's often like that; YMMV etc.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/30/2009 8:25:50 PM
|
|
The Compiler guy was heard typing:
>> Remember that except for compiler bugs, alignment faults comes from the user
>> lying to the compiler.
Excuse me, but are there really circumstances where the programmer
("user" from Mr Reagan point of view) is lying to the compiler ?
if I have a 100 byte record, and bytes 7 though 10 inclusively contain
an integer, and I do:
myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
In what way am I lying ? Does the compiler realise that this will be an
unaligned access or will it be accusing me of lying ?
Out of curiosity, why do some CPUs have so much trouble fetching 4 bytes
from an unaligned location ? Is it the CPU and CPU architecture that is
the problem, or the RAM memory subsystem that can't fetch 4 bytes
starting at an uneven memory address ?
>> if you can't, tell the compiler
>> what you did and we'll avoid the alignment fault.
In C, how can I tell a compiler that trying to move 4 bytes into an
integer variable MAY cause an alignment fault ? With variable record
structures for instance, the location of an integer may vary and
sometimes be un an uneven offset from start of buffer. But you won't
know that at compile time since it would vary from record to record as
you process a file for instance.
BTW, does the X86-64 have similar performance handicap when trying to
fetch an integer from unaligned memory location ?
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
11/30/2009 9:12:54 PM
|
|
"John Wallace" <johnwallace4@yahoo.co.uk> wrote in message
news:d89c89b7-8216-4db2-b51f-ce08782459ac@v37g2000vbb.googlegroups.com...
On Nov 30, 7:24 pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "John Wallace" <johnwalla...@yahoo.co.uk> wrote in message
>
>Can I just pick up on one bit this time:
>"alignment faults comes from the user lying to the compiler"
>That's obviously true from your point of view as a compiler person,
>but for the vast majority of folk out there, it would be more accurate
>to say:
>"alignment faults comes from the >>developer<< lying to the compiler"
Fine with me. I just wanted to point out that it isn't a lack of compiler
optimization that allows alignment faults to occur (again, compiler BUGS may
in fact result in alignment faults - I've fixed several over the years).
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/30/2009 9:44:31 PM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:00cd4d03$0$6691$c3e8da3@news.astraweb.com...
> The Compiler guy was heard typing:
>
>>> Remember that except for compiler bugs, alignment faults comes from the
>>> user
>>> lying to the compiler.
>
>
> Excuse me, but are there really circumstances where the programmer
> ("user" from Mr Reagan point of view) is lying to the compiler ?
>
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
>
> myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
>
> In what way am I lying ? Does the compiler realise that this will be an
> unaligned access or will it be accusing me of lying ?
>
Pointers to ints by defintion point to ints. Ints are aligned on int-sized
boundaries. We'll assume that unless you tell us otherwise.
For this very simple case, you can argue the compiler can see that coming.
However, in more complicated pointer expressions where you share myint with
other routines, we can't tell.
>
> Out of curiosity, why do some CPUs have so much trouble fetching 4 bytes
> from an unaligned location ? Is it the CPU and CPU architecture that is
> the problem, or the RAM memory subsystem that can't fetch 4 bytes
> starting at an uneven memory address ?
Because those 4 bytes might cross a cache line boundary (yes the cache to
main memory interfaces often operate in 32-byte/64-byte/etc. chunks)? They
might cause multiple cache-to-main memory operations? They might cross a
page boundary where you don't have access to some of the bytes? Lots of
reasons.
>
>>> if you can't, tell the compiler
>>> what you did and we'll avoid the alignment fault.
>
> In C, how can I tell a compiler that trying to move 4 bytes into an
> integer variable MAY cause an alignment fault ? With variable record
> structures for instance, the location of an integer may vary and
> sometimes be un an uneven offset from start of buffer. But you won't
> know that at compile time since it would vary from record to record as
> you process a file for instance.
The Calling Standard says that records are aligned on the boundary of their
largest element (see #pragma nomember_align (base) syntax to tell
otherwise). We also know the compile-time offset from the start of the
record to the field. We then know to generate a single load instruction or
multiple smaller load instructions. Only when the record is found via a
pointer (or parameter) can it be sometimes unaligned. For local/global
variables, we allocate the record on the correct boundary.
I'm not sure what you mean by variable record structures? Like Pascal's
schema types with run-time sized and run-time offset fields? In that case,
we just generate the "may be byte aligned sequence" and use multiple smaller
loads (even if it happens to be aligned 99% of the time).
>
>
> BTW, does the X86-64 have similar performance handicap when trying to
> fetch an integer from unaligned memory location ?
The chip will fix it all up but it may involve multiple memory-operations.
I haven't studied that part in great detail.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
11/30/2009 9:53:38 PM
|
|
JF Mezei wrote:
> The Compiler guy was heard typing:
>
>>> Remember that except for compiler bugs, alignment faults comes from the user
>>> lying to the compiler.
>
>
> Excuse me, but are there really circumstances where the programmer
> ("user" from Mr Reagan point of view) is lying to the compiler ?
>
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
>
> myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
>
> In what way am I lying ? Does the compiler realise that this will be an
> unaligned access or will it be accusing me of lying ?
>
>
> Out of curiosity, why do some CPUs have so much trouble fetching 4 bytes
> from an unaligned location ? Is it the CPU and CPU architecture that is
> the problem, or the RAM memory subsystem that can't fetch 4 bytes
> starting at an uneven memory address ?
>
Well VAX certainly did! Alpha, IIRC was even more sensitive to
alignment issues. If you knew that, it was not difficult to satisfy the
machines preferences. The compilers took care of most of the work.
The VAX and Alpha architectures were by no means unique in having this
requirement. The IBM System/360 and System/370 machines also required
proper boundary alignment.
Normally the compiler took care of alignment. There were cases; e.g.
data structures, where things could become unaligned. The machine would
complain and then move the offending data to properly aligned storage.
It meant your program ran a little, or a lot, slower and with warning
messages about the alignment faults.
>>> if you can't, tell the compiler
>>> what you did and we'll avoid the alignment fault.
>
> In C, how can I tell a compiler that trying to move 4 bytes into an
> integer variable MAY cause an alignment fault ? With variable record
> structures for instance, the location of an integer may vary and
> sometimes be an uneven offset from start of buffer. But you won't
> know that at compile time since it would vary from record to record as
> you process a file for instance.
>
So the machine grumps a little, fixes the alignment, and your program
runs a little
or a lot slower! Good programmers try keep things aligned or alignable
and most succeed.
If you do a four byte move, there's no problem. If you try to use
longword instructions to move it, you will get an alignment fault, the
fixup routine will be called and your program is a little slower than it
needs to be.
Smart programmers will go to great lengths to make sure that data in
records gets transferred to properly aligned storage.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
11/30/2009 10:00:14 PM
|
|
On Nov 30, 9:12=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> The Compiler guy was heard typing:
>
> >> Remember that except for compiler bugs, alignment faults comes from th=
e user
> >> lying to the compiler.
>
> Excuse me, but are there really circumstances where the programmer
> ("user" from Mr Reagan point of view) is lying to the compiler ?
>
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
>
> myint =3D (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
>
> In what way am I lying ? =A0Does the compiler realise that this will be a=
n
> unaligned access or will it be accusing me of lying ?
>
> Out of curiosity, why do some CPUs have so much trouble fetching 4 bytes
> from an unaligned location ? Is it the CPU and CPU architecture that is
> the problem, or the RAM memory subsystem that can't fetch 4 bytes
> starting at an uneven memory address ?
>
> >> if you can't, tell the compiler
> >> what you did and we'll avoid the alignment fault.
>
> In C, how can I tell a compiler that trying to move 4 bytes into an
> integer variable MAY cause an alignment fault ? With variable record
> structures for instance, the location of an integer may vary and
> sometimes be un an uneven offset from start of buffer. But you won't
> know that at compile time since it would vary from record to record as
> you process a file for instance.
>
> BTW, does the X86-64 have similar performance handicap when trying to
> fetch an integer from unaligned memory location ?
(overlapped with JR's post) [apologies if duplicate, first allegedly
failed]
Much of this is to do with modern memory subsystem implementation. A
naturally aligned access will not cross a cache line boundary. An
access which isn't known at compile time to be naturally aligned *may*
cross a cache line boundary at run time, and depending on the hardware
and software, that may be quite undesirable in performance terms.
Think of the implications in a high end SMP system which has to keep
its per-CPU caches consistent somehow - that was a large part of the
target IA64 market, and today is effectively the only IA64 market
(outside of VMS). Other chip architectures can't be so choosy. But
even in a single CPU system there are implications if page boundaries
and memory management considerations and the like come into the
picture.
AMD64 hardware and software must make this kind of thing relatively
transparent to the application programmer, because it must provide
compatibility with legacy code and data from the x86 world. For the
reason mentioned above, it cannot make it entirely transparent to the
system designer and OS programmer.
On the dark side, the mechanism used in Visual Studio to tell a
(64bit) compiler that data may be unaligned is __declspec(align
(number)) described in more depth at:
http://msdn.microsoft.com/en-us/library/83ythb65.aspx
Or perhaps, for IA64 only, it's __unaligned
http://msdn.microsoft.com/en-us/library/ms177389.aspx
Not sure about the gcc equivalent (where I work mostly uses the dark
side at the moment). Not even sure whether gcc is relevant to IA64
anyway (at one time a couple of years back, icc was recommended rather
than gcc, don't know about current state of play).
Although the usual response to discussions like this is "design your
code to align your data appropriately", there are times when this
isn't a low cost (or even a possible) option - when compatibility with
existing file or network data formats from other apps is required, for
example.
Hth.
|
|
0
|
|
|
|
Reply
|
johnwallace44 (832)
|
11/30/2009 10:38:43 PM
|
|
On Mon, 30 Nov 2009 at 17:00 -0500, Richard B. Gilbert wrote:
> JF Mezei wrote:
>>
>> Out of curiosity, why do some CPUs have so much trouble fetching 4
>> bytes from an unaligned location ? Is it the CPU and CPU
>> architecture that is the problem, or the RAM memory subsystem that
>> can't fetch 4 bytes starting at an uneven memory address ?
>>
> Well VAX certainly did! Alpha, IIRC was even more sensitive to
> alignment issues. If you knew that, it was not difficult to satisfy
> the machines preferences. The compilers took care of most of the
> work.
>
> The VAX and Alpha architectures were by no means unique in having
> this requirement. The IBM System/360 and System/370 machines also
> required proper boundary alignment.
And the PDP-11! Try a MOV (move word) on an odd address and you trap
through location 4. Fatal unless you wrote your own handler. I don't
know of anybody who ever did. Just align your data!
VAX allowed MOVW and MOVL on unaligned data. It wasn't until much
later that I learned that doing so made the program run slower.
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
|
|
0
|
|
|
|
Reply
|
mylastname3 (505)
|
11/30/2009 10:43:26 PM
|
|
In article <mTKsWd+E2c7X@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7n50qlF3k8008U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>
>> Which brings up an interesting point I may need to do some research
>> on. I wonder when Mentec released the last upgraded PDP-11 hardware?
>> Why do I have a feeling that even the PDP-11 outlasted the VAX.
>
> I'm pretty sure Mentec sold some PDP-11 hardware, and produced
> one update to RSX, but I don't recall them building anything new.
Your falling behind Bob. I already posted the answer. Mentec's last
new PDP-11 was the M11 in 1997.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
12/1/2009 12:31:08 AM
|
|
"Rob Brown" <mylastname@gmcl.com> wrote in message
news:alpine.LFD.2.00.0911301535400.22310@libra.gmcl.internal...
>
> VAX allowed MOVW and MOVL on unaligned data. It wasn't until much later
> that I learned that doing so made the program run slower.
>
On the VAX, the compilers (at least the Pascal compiler and I believe the
Fortran compiler where I stole the code from) align targets of branches and
routine entry points on longword (or quadword boundaries, I forget which).
We pad with NOPs. It made branches and CALLs *MUCH* faster.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
12/1/2009 12:31:11 AM
|
|
Bob Koehler schrieb:
> In article <hejthi$cp5$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:
>
>>DEC were in bed with M$ long before Palmer.
>>Think of the ACE consortium (DEC,M$,Compaq,...) promoting
>>Mips and NT. IIRC an early version of NT even ran on DECstations.
>
>
> I recall the ACE consortium supporting OSF-1 on MIPS as a standard
> OS and chip to rival MS-DOS on x86. Then adding other UNIX on other
> chips, before falling apart.
ACE was focused on Mips (and a bit x86) and NT (and a bit Unix).
They fell apart when DEC, being one of the heavier weights,
went Alpha.
> Early versions of NT were supposed to run on x86, Alpha, MIPS,
> PPC, ..., they were all supposed to ship on the same CD on the
> same date. x86 shipped first even though MS used Alpha heavily
> as a development platform, then the other chip vendors all dropped
> out. I only recall x86 and Alpha versions of NT ever shipping.
WNT 4.0 CDs have executables for all four flavours.
I wouldn't call that "early".
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
12/1/2009 7:38:17 AM
|
|
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
news:00cd4d03$0$6691$c3e8da3@news.astraweb.com...
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
>
> myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
>
> In what way am I lying ?
You are making an incompatible type conversion. If you don't like
the word 'lying', substitute, 'writing a program with undefined behaviour'
instead.
|
|
0
|
|
|
|
Reply
|
R.Brodie (551)
|
12/1/2009 11:10:57 AM
|
|
In article <EaOdnePf1dQshInWnZ2dnUVZ_v6dnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
> Argument slots (per the Calling Standard) are 64-bits wide period.
> Addresses passed as arguments are sign-extended to 64-bits. The called
> routines depend on that since system-space addresses rely on that.
>
And if you're using P2 space, can't you do that without any pointer
variables in your code (like declaring huge arrays that don't all
fit into P0 space).
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/1/2009 1:41:13 PM
|
|
In article <00cd4d03$0$6691$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
> Excuse me, but are there really circumstances where the programmer
> ("user" from Mr Reagan point of view) is lying to the compiler ?
>
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
>
> myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
Almost, I think you want (assuming buffer is of type char):
myint = *((int *) (&buffer + 6));
> In what way am I lying ? Does the compiler realise that this will be an
> unaligned access or will it be accusing me of lying ?
If you allow the compiler to lay out your variables, it will pad
things to prevent that misalignment. If you tell the compiler that
it's not allowed to pad, then it can know to generate the necessary
overhead instructions to access the data without misalignment.
But if you force the compiler to misalign without knowing it by
manipulating pointers, then the compiler doesn't know to deal with
misaligned data.
Examples:
main ()
{
int myint;
#pragma member_alignment // (this is the default)
struct {
char a[6];
int b;
} buffer;
myint = buffer.b;
}
In the above code (main), the C compiler will put padding between and b
so that b is aligned. b actually starts at byte 8, not 7.
able()
{
int myint;
#pragma nomember_alignment
struct {
char a[6];
int b;
} buffer;
myint = buffer.b;
}
In the above code (able), the C compiler knows that there's no padding
between a and b. The compiler can fetch the quadword containing b
the mask off and shift the bits to get the int into the low end of
a register.
baker(int *buffer)
{
int myint = *buffer;
}
charlie()
{
char buffer[10];
baker((int *) &buffer[6]);
}
Now in baker the compiler has been told it has an int pointer, but that
pointer is forced to be misaligned in charlie. The compiler can't see
that, so it doesn't generate the overhead code to avoid the misalignment.
As examples, here is part of the generated code from EISNER. Note than
in MAIN at offset D0, and in BAKER at offset 124, there are LDL
instructions for loading myint. This is the Alpha instruction for
loading an aligned longword (32 bits). Compare these with able starting
at offset F4, where two LDQ_U instructions are used to get pieces of the
buffer surrounding the misaligned address, these instructions fetch
quadwords (64 bits) from the previous and next aligned address without
generating misalignment faults by ignoring the low bits of the address.
Then four more instructions are used to get the correct data into myint.
This all happens in able because the compiler knows it's accessing a
misaligned address, which it didn't know when it compiled baker.
00C4 MAIN::
23DEFFE0 00C4 LDA SP, -32(SP)
Machine Code Listing 1-DEC
MAIN 1-DEC
47FD0412 00C8 MOV FP, R18
47FB041D 00CC MOV R27, FP
A03E0010 00D0 LDL myint, 16(SP)
47E03400 00D4 MOV 1, R0
47F2041D 00D8 MOV R18, FP
23DE0020 00DC LDA SP, 32(SP)
6BFA8001 00E0 RET R26
Routine Size: 32 bytes, Routine Base: $CODE$ + 00C4
00E4 ABLE::
23DEFFE0 00E4 LDA SP, -32(SP)
47FD0414 00E8 MOV FP, R20
47FB041D 00EC MOV R27, FP
223E000E 00F0 LDA R17, 14(SP)
2E510000 00F4 LDQ_U R18, (R17)
2E710003 00F8 LDQ_U R19, 3(R17)
4A5104D2 00FC EXTLL R18, R17, R18
4A710D53 0100 EXTLH R19, R17, R19
46530400 0104 BIS R18, R19, myint
43E00000 0108 SEXTL myint, myint
47F4041D 010C MOV R20, FP
23DE0020 0110 LDA SP, 32(SP)
6BFA8001 0114 RET R26
Routine Size: 52 bytes, Routine Base: $CODE$ + 00E4
0118 BAKER::
47FD0414 0118 MOV FP, R20
47FB041D 011C MOV R27, FP
47F00401 0120 MOV R16, buffer
A0010000 0124 LDL myint, (R1)
47F4041D 0128 MOV R20, FP
2FFE0000 012C UNOP
6BFA8001 0130 RET R26
Routine Size: 28 bytes, Routine Base: $CODE$ + 0118
0134 CHARLIE::
23DEFFE0 0134 LDA SP, -32(SP)
47FA0415 0138 MOV R26, R21
47FD0416 013C MOV FP, R22
47FB041D 0140 MOV R27, FP
221E000E 0144 LDA R16, 14(SP)
237DFFE8 0148 LDA R27, -24(FP)
D35FFFF2 014C BSR R26, BAKER
47F6041D 0150 MOV R22, FP
23DE0020 0154 LDA SP, 32(SP)
6BF58001 0158 RET R21
Routine Size: 40 bytes, Routine Base: $CODE$ + 0134
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/1/2009 2:24:00 PM
|
|
In article <fdWdnb4rXYpO_onWnZ2dnUVZ_q-dnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
> On the VAX, the compilers (at least the Pascal compiler and I believe the
> Fortran compiler where I stole the code from) align targets of branches and
> routine entry points on longword (or quadword boundaries, I forget which).
> We pad with NOPs. It made branches and CALLs *MUCH* faster.
IIRC, that Fortran compiler came out at about the same time as the VAX
6000 series (first NVAX?). And I was left wondering just how fast my
MV II was running though all those NOPs on conditional branches not
taken.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/1/2009 2:27:05 PM
|
|
"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message
news:s+8diLx+uhSu@eisner.encompasserve.org...
> In article <fdWdnb4rXYpO_onWnZ2dnUVZ_q-dnZ2d@earthlink.com>, "John Reagan"
> <johnrreagan@earthlink.net> writes:
>>
>> On the VAX, the compilers (at least the Pascal compiler and I believe the
>> Fortran compiler where I stole the code from) align targets of branches
>> and
>> routine entry points on longword (or quadword boundaries, I forget
>> which).
>> We pad with NOPs. It made branches and CALLs *MUCH* faster.
>
> IIRC, that Fortran compiler came out at about the same time as the VAX
> 6000 series (first NVAX?). And I was left wondering just how fast my
> MV II was running though all those NOPs on conditional branches not
> taken.
>
That was indeed the tradeoff. The hardware groups told us not to worry but
it does take up space in the i-cache after all. We decided the benefit was
worth it at the time. However, we didn't go back and remeasure on newer
VAXen to see where the breakpoint was.
VAX Pascal also executes "useless" instructions (tstb #literal) at various
places as flags to the RTL. The main one is getting UNSIGNED arithmetic not
to fault eventhough you want integer overflow enabled. Since there is only
one ADDL instruction, we followed unsigned adds with a tstb #literal. The
RTL's handler sees that special instruction, looks up the literal to see
what to do, and then bumps the PC and continues. In cases where the ADD
didn't overflow, you execute the tstb #literal anyway.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
12/1/2009 8:25:21 PM
|
|
In article <msidnUqwec8o5ojWnZ2dnUVZ_g2dnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
> VAX Pascal also executes "useless" instructions (tstb #literal) at various
> places as flags to the RTL. The main one is getting UNSIGNED arithmetic not
> to fault eventhough you want integer overflow enabled. Since there is only
> one ADDL instruction, we followed unsigned adds with a tstb #literal. The
> RTL's handler sees that special instruction, looks up the literal to see
> what to do, and then bumps the PC and continues. In cases where the ADD
> didn't overflow, you execute the tstb #literal anyway.
Interesting workaround. I always thought IV should be allowed in
BICPSW/BISPSW.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/2/2009 1:22:14 PM
|
|
JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> RE: new PDP11s post Digital going to VAX.
> Didn't Compuserve use customer PDP11 based machines as "nodes" in
> different cities where they offered service ?
No, they used PDP-10 systems, eventually making a deal with Systems Concepts to
manufacture their own SC-40 CPUs at a license fee per box of 40% of list.
And yes, the SC boxes do count as PDP-10 systems. Bug-compatible with the
KL-10 processor.
> And after Mentec inherited the PDP, did it have any PDP CPUs fabbed ? Or
> did it use stockopiled CPUs made by DEC when it made the last big batch
> of them ?
There's no such thing as "the PDP"! DEC built 4.5 different architectures
which it labeled PDP-<number>, you know.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/3/2009 11:38:44 PM
|
|
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <hejq08$nf0$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com>
> writes:
> But just as the 18 bit PDP-10 was updated to 23 bits,
Actually, it was updated to 30 bits architecturally. 23 bits is the KL-10
implementation, on top of its 22-bit pager (same size as that on the KI10,
though different in implementation). One clone manufacturer, XKL, built a
machine with a full 30-bit pager (the Toad-1).
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/4/2009 12:00:17 AM
|
|
Rich Alderson wrote:
> JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
>> RE: new PDP11s post Digital going to VAX.
>
>> Didn't Compuserve use customer PDP11 based machines as "nodes" in
>> different cities where they offered service ?
>
> No, they used PDP-10 systems, eventually making a deal with Systems Concepts to
> manufacture their own SC-40 CPUs at a license fee per box of 40% of list.
>
> And yes, the SC boxes do count as PDP-10 systems. Bug-compatible with the
> KL-10 processor.
>
>> And after Mentec inherited the PDP, did it have any PDP CPUs fabbed ? Or
>> did it use stockopiled CPUs made by DEC when it made the last big batch
>> of them ?
>
> There's no such thing as "the PDP"! DEC built 4.5 different architectures
> which it labeled PDP-<number>, you know.
>
They might have used "real" PDP-11 CPU's for some time, but the last
models was built using an inhouse emulation of the PDP-11 CPU using
completely different processors...
|
|
0
|
|
|
|
Reply
|
jan-erik.soderholm (2469)
|
12/4/2009 12:04:19 AM
|
|
In article <mddljhj4ohn.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
>
> There's no such thing as "the PDP"! DEC built 4.5 different architectures
> which it labeled PDP-<number>, you know.
I think you underestimate the number of architectures known as PDP,
although a lot of them vary more by word size that top level
concepts.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/4/2009 12:46:13 PM
|
|
In article <mddiqcn4nhq.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>
>> In article <hejq08$nf0$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com>
>> writes:
>
>> But just as the 18 bit PDP-10 was updated to 23 bits,
>
> Actually, it was updated to 30 bits architecturally. 23 bits is the KL-10
> implementation, on top of its 22-bit pager (same size as that on the KI10,
> though different in implementation). One clone manufacturer, XKL, built a
> machine with a full 30-bit pager (the Toad-1).
All my documentation was from DEC, and none of it showed anything
other than 18 and 23 bit addressing, but we probably did not have a
copy of the formal architecture spec.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/4/2009 12:47:23 PM
|
|
In article <mddljhj4ohn.fsf@panix5.panix.com>, Rich Alderson <new@alderson.users.panix.com> writes:
>
> No, they used PDP-10 systems, eventually making a deal with Systems Concepts to
> manufacture their own SC-40 CPUs at a license fee per box of 40% of list.
Never actually saw a PDP-10 that didn't have an -11 as a front end,
although I know systems like the 2020 were built without one.
Our 2050 and 2060 had two PDP-11 each, one for the console front end
and one for DECnet.
Interesting that the 11/40 front end happened to run RSX-11F. Or
was someone at DEC ammused that "F" was unassigned at the time? 8-)
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/4/2009 12:50:46 PM
|
|
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <mddljhj4ohn.fsf@panix5.panix.com>, Rich Alderson
> <new@alderson.users.panix.com> writes:
>> No, they used PDP-10 systems, eventually making a deal with Systems Concepts
>> to manufacture their own SC-40 CPUs at a license fee per box of 40% of list.
> Never actually saw a PDP-10 that didn't have an -11 as a front end,
> although I know systems like the 2020 were built without one.
The KA10 (3 years before the PDP-11) and KI10 (roughly contemparaneous) from
DEC, though both could have PDP-8 comms processors added, and the KI could have
PDP-11s in the same function. *Processing* is done by the PDP-10 CPU.
Then there's the Foonly systems, the Systems Concepts systems (8080 processor,
like the KS10 = 2020), and the XKL Toad-1 (no separate boot or comms processor
at all). I don't know what MAXC at Xerox PARC had.
> Our 2050 and 2060 had two PDP-11 each, one for the console front end
> and one for DECnet.
Every KL10 had one as boot processor/console. Up to three more could be
attached for various comms purposes and card/printer control.
> Interesting that the 11/40 front end happened to run RSX-11F. Or
> was someone at DEC ammused that "F" was unassigned at the time? 8-)
Actually, it's called RSX-20F, derived from -11M and -11D, and it's not the
original software for the KL10 front end. That's KLDCP, which continues in
use as the loader for diagnostics to this day.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/4/2009 9:16:58 PM
|
|
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <mddljhj4ohn.fsf@panix5.panix.com>, Rich Alderson
> <news@alderson.users.panix.com> writes:
>> There's no such thing as "the PDP"! DEC built 4.5 different architectures
>> which it labeled PDP-<number>, you know.
> I think you underestimate the number of architectures known as PDP,
> although a lot of them vary more by word size that top level
> concepts.
18 bit: PDP-1, and PDP-4/-7/-9/-15. The latter were upwards code compatible,
but not the PDP-1. That's 1.5 in my count.
12 bit: PDP-5, PDP-8, -8s, -8i/l, -8e/f/m, -8A. That's another 1, for a total
of 2.5.
36 bit: PDP-6, PDP-10 = KA10, KI10, KL10, KS10. That's another 1, for a total
of 3.5.
16 bit: PDP-11 in all its forms and variations. That's another 1, for a total
4.5.
You're probably talking about the PDP-14 and PDP-16, and you're right, I didn't
count them as separate computer architectures. I still don't. If instead you
are counting the minimal variations among members of those families as separate
architectures, then we have a fundamental disagreement on what that word means
in this context, and have nothing substantial to discuss.
So yeah, 4.5 computer architectures called PDP-<x>.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/4/2009 9:28:45 PM
|
|
Jan-Erik S�derholm <jan-erik.soderholm@telia.com> writes:
> Rich Alderson wrote:
>> JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>> RE: new PDP11s post Digital going to VAX.
>>> Didn't Compuserve use customer PDP11 based machines as "nodes" in
>>> different cities where they offered service ?
>> No, they used PDP-10 systems, eventually making a deal with Systems Concepts
>> to manufacture their own SC-40 CPUs at a license fee per box of 40% of list.
>> And yes, the SC boxes do count as PDP-10 systems. Bug-compatible with the
>> KL-10 processor.
>>> And after Mentec inherited the PDP, did it have any PDP CPUs fabbed ? Or
>>> did it use stockopiled CPUs made by DEC when it made the last big batch
>>> of them ?
>> There's no such thing as "the PDP"! DEC built 4.5 different architectures
>> which it labeled PDP-<number>, you know.
> They might have used "real" PDP-11 CPU's for some time, but the last
> models was built using an inhouse emulation of the PDP-11 CPU using
> completely different processors...
Hmm. Since I was part of the conversation with CIS when they were looking for
a less expensive alternative to the SC40s, and heard the systems programmers
from CIS describe the use of PDP-10 systems as network nodes, I'm pretty sure
I know what I'm talking about here.
There were no PDP-11 systems used in that application.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/4/2009 9:32:18 PM
|
|
Rich Alderson <news@alderson.users.panix.com> wrote:
(snip)
> 18 bit: PDP-1, and PDP-4/-7/-9/-15. The latter were upwards code compatible,
> but not the PDP-1. That's 1.5 in my count.
> 12 bit: PDP-5, PDP-8, -8s, -8i/l, -8e/f/m, -8A. That's another 1, for a total
> of 2.5.
> 36 bit: PDP-6, PDP-10 = KA10, KI10, KL10, KS10. That's another 1, for a total
> of 3.5.
> 16 bit: PDP-11 in all its forms and variations. That's another 1, for a total
> 4.5.
So you don't count VAX as a separate architecture, or not a PDP?
-- glen
|
|
0
|
|
|
|
Reply
|
gah (12253)
|
12/4/2009 9:32:33 PM
|
|
glen herrmannsfeldt wrote:
> Rich Alderson <news@alderson.users.panix.com> wrote:
>
> (snip)
>
>> 18 bit: PDP-1, and PDP-4/-7/-9/-15. The latter were upwards code compatible,
>> but not the PDP-1. That's 1.5 in my count.
>
>> 12 bit: PDP-5, PDP-8, -8s, -8i/l, -8e/f/m, -8A. That's another 1, for a total
>> of 2.5.
>
>> 36 bit: PDP-6, PDP-10 = KA10, KI10, KL10, KS10. That's another 1, for a total
>> of 3.5.
>
>> 16 bit: PDP-11 in all its forms and variations. That's another 1, for a total
>> 4.5.
>
> So you don't count VAX as a separate architecture, or not a PDP?
>
> -- glen
I think VAX was definitely a separate architecture. It was built on a
foundation of what had gone before and it was a howling success. By the
time it was over and done with there were VAXen that you could tuck
underneath your arm and walk off with and and VAXen that needed a fair
size truck.
Then the RISC architectures arrived and blew the doors off the VAXen.
You can't stand still in this business. . . .
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
12/4/2009 9:48:38 PM
|
|
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Rich Alderson <news@alderson.users.panix.com> wrote:
> (snip)
>> 18 bit: PDP-1, and PDP-4/-7/-9/-15. The latter were upwards code
>> compatible, but not the PDP-1. That's 1.5 in my count.
>> 12 bit: PDP-5, PDP-8, -8s, -8i/l, -8e/f/m, -8A. That's another 1, for a
>> total of 2.5.
>> 36 bit: PDP-6, PDP-10 = KA10, KI10, KL10, KS10. That's another 1, for a
>> total of 3.5.
>> 16 bit: PDP-11 in all its forms and variations. That's another 1, for a
>> total 4.5.
> So you don't count VAX as a separate architecture, or not a PDP?
Since all this started with M. Mezei saying something about "the PDP", the
VAX was not relevant to the argument.
The VAX, MIPS, and Alpha architectures were all used in systems by Digital,
but none of them were called "PDP-<number>" in their released forms.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/5/2009 1:26:34 AM
|
|
In article <mddpr6ua0il.fsf@panix5.panix.com>,=20
news@alderson.users.panix.com says...>=20
> Jan-Erik S=F6derholm <jan-erik.soderholm@telia.com> writes:
>=20
> > Rich Alderson wrote:
> >> JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>=20
> >>> RE: new PDP11s post Digital going to VAX.
>=20
> >>> Didn't Compuserve use customer PDP11 based machines as "nodes" in
> >>> different cities where they offered service ?
>=20
> >> No, they used PDP-10 systems, eventually making a deal with Systems Co=
ncepts
> >> to manufacture their own SC-40 CPUs at a license fee per box of 40% of=
list.
>=20
> >> And yes, the SC boxes do count as PDP-10 systems. Bug-compatible with=
the
> >> KL-10 processor.
>=20
> >>> And after Mentec inherited the PDP, did it have any PDP CPUs fabbed ?=
Or
> >>> did it use stockopiled CPUs made by DEC when it made the last big bat=
ch
> >>> of them ?
>=20
> >> There's no such thing as "the PDP"! DEC built 4.5 different architect=
ures
> >> which it labeled PDP-<number>, you know.
>=20
> > They might have used "real" PDP-11 CPU's for some time, but the last
> > models was built using an inhouse emulation of the PDP-11 CPU using
> > completely different processors...
>=20
> Hmm. Since I was part of the conversation with CIS when they were lookin=
g for
> a less expensive alternative to the SC40s, and heard the systems programm=
ers
> from CIS describe the use of PDP-10 systems as network nodes, I'm pretty =
sure
> I know what I'm talking about here.
>=20
> There were no PDP-11 systems used in that application.
I think that last bit was in reference to Mentech, not Compuserve. =20
Mentech only purchased the PDP-***11*** software, and never had
anything to do with PDP-10s (or PDP-anything-elses), AFAIK.
I know Mentech sold PDP-11's of their own design. I don't know if
they ever resold DEC-manufactured PDP-11s, or built their own 11s
from DEC parts (i.e. J-11 or F-11 CPUs.) Other 3rd parties also
built their own PDP-11-compatible machines (QED, Strobe, maybe
Nemonix and probably several others.) Many of these were much faster
than the fastest DEC PDP-11.
--=20
John Santos
Evans Griffiths & Hart, Inc.
|
|
0
|
|
|
|
Reply
|
john5 (550)
|
12/8/2009 4:56:37 AM
|
|
In article <mddskbqa0oi.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
>
> You're probably talking about the PDP-14 and PDP-16, and you're right, I didn't
> count them as separate computer architectures. I still don't. If instead you
> are counting the minimal variations among members of those families as separate
> architectures, then we have a fundamental disagreement on what that word means
> in this context, and have nothing substantial to discuss.
I was aware that the word sizes were often common, but I'm under the
impression there were variations in the register sets and/or
instruction sets. If those were minor, then I'd agree they were the
same architecture.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/8/2009 1:04:10 PM
|
|
In article <hfbv5h$lt8$2@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
> So you don't count VAX as a separate architecture, or not a PDP?
I saw a contract written as PDP-11/70 that was changed to
PDP-VAX-11/780 as a change that the contracting officer could allow
(both parties wanted it). I also know a fellow who calls his
VAX 4000 systems "the PDPs". And I used compatability mode on my
11/780 both for pieces of early VMS, and to run tasks I built on
my 11/34, but I don't know anyone on c.o.v who seriously thinks
of VAX as a PDP.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/8/2009 1:07:57 PM
|
|
On Tue, 8 Dec 2009, Bob Koehler wrote:
> I also know a fellow who calls his VAX 4000 systems "the PDPs".
I saw a set of Alphas in a cabinet at a customer site once; their node
names were VAX1, VAX2, ....
Steve
|
|
0
|
|
|
|
Reply
|
smt (64)
|
12/8/2009 3:45:33 PM
|
|
In article <TZ9Uz01NBwVB@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <hfbv5h$lt8$2@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> So you don't count VAX as a separate architecture, or not a PDP?
>
> I saw a contract written as PDP-11/70 that was changed to
> PDP-VAX-11/780 as a change that the contracting officer could allow
> (both parties wanted it).
Auditor would have had a field day with that one. Contract should have
been re-competed as the two are hardly equivalent and there actuall is
no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
> I also know a fellow who calls his
> VAX 4000 systems "the PDPs". And I used compatability mode on my
> 11/780 both for pieces of early VMS, and to run tasks I built on
> my 11/34, but I don't know anyone on c.o.v who seriously thinks
> of VAX as a PDP.
Or any PDP-11 afficianado who would either!! :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
12/8/2009 3:48:14 PM
|
|
Steve Thompson wrote:
> On Tue, 8 Dec 2009, Bob Koehler wrote:
>
>> I also know a fellow who calls his VAX 4000 systems "the PDPs".
>
> I saw a set of Alphas in a cabinet at a customer site once; their node
> names were VAX1, VAX2, ....
>
To those of us not programming in Macro, the Alpha was just a faster
VAX! Much faster!!!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
12/8/2009 4:25:28 PM
|
|
Steve Thompson wrote:
> On Tue, 8 Dec 2009, Bob Koehler wrote:
>
>> I also know a fellow who calls his VAX 4000 systems "the PDPs".
>
> I saw a set of Alphas in a cabinet at a customer site once; their node
> names were VAX1, VAX2, ....
>
> Steve
Well...
At my current client site, at project meetings, they are always
talking about doing this-n-that "on the VAX", even if it is
over 10 years since the last VAX was shut down. In the beginning
a tried to explain that they are not running "a VAX" anymore,
but I gave up... :-)
And a lot of COM and COB files still talkes about "the PDP"
even if the PDP controlling the cranes in the wharehouse was
replaced by a Power/AIX system long ago.
He, I made a search of the all COB and SCO files and got :
OBJECT-COMPUTER. IBM-370.
OBJECT-COMPUTER. VAX-11.
OBJECT-COMPUTER. VAX-1100.
OBJECT-COMPUTER. VAX-3000.
OBJECT-COMPUTER. VAX-750.
OBJECT-COMPUTER. VAX-8350.
OBJECT-COMPUTER. AlphaServer AS800.
OBJECT-COMPUTER. AlphaServer DS20e.
These are the "plattforms" this code-stock has been
running on over the years... :-) Note the "IBM-370",
this code base was once move from an MVS system to a
VAX 11/750.
I also checked "DATE-WRITTEN." and every year from 1980 to
2009 is there. This is the current production code base...
|
|
0
|
|
|
|
Reply
|
jan-erik.soderholm (2469)
|
12/8/2009 5:57:48 PM
|
|
Jan-Erik S�derholm schrieb:
> Well...
>
> At my current client site, at project meetings, they are always
> talking about doing this-n-that "on the VAX", even if it is
> over 10 years since the last VAX was shut down. In the beginning
> a tried to explain that they are not running "a VAX" anymore,
> but I gave up... :-)
And some people over here were talking about "the Alpha-VAX",
probably as opposed to a true "VAX-VAX".
They referred to a VAX as a box which runs VMS.
So in their mindset the connection between VAX and VMS was much stronger
than between Alpha and VMS.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
12/8/2009 7:49:50 PM
|
|
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <mddskbqa0oi.fsf@panix5.panix.com>, Rich Alderson
> <news@alderson.users.panix.com> writes:
>> You're probably talking about the PDP-14 and PDP-16, and you're right, I
>> didn't count them as separate computer architectures. I still don't. If
>> instead you are counting the minimal variations among members of those
>> families as separate architectures, then we have a fundamental disagreement
>> on what that word means in this context, and have nothing substantial to
>> discuss.
> I was aware that the word sizes were often common, but I'm under the
> impression there were variations in the register sets and/or
> instruction sets. If those were minor, then I'd agree they were the
> same architecture.
The PDP-1 had a 12-bit address, 5 bits of opcode, and an indirect bit. The
other 18-bit systems from DEC had a 13-bit address, 4 bits of opcode, and an
indirect bit; the opcodes were the same from the PDP-4 through the PDP-15. The
differences were in additional IO devices and related conditions. A PDP-15
would run PDP-4 code, but not vice versa.
An XKL Toad-1 will run PDP-6 user mode code, although the I/O instructions are
completely different. The same is true of the KL10 and KS10 processors from
DEC: User-mode PDP-6 code will run on them as well as on earlier PDP-10s.
PDP-5 code will usually run on a PDP-8, although there are a few places (like
the PC being memory 0000 on the -5) that may get you into trouble.
The table of differences between models of PDP-11 is three or four pages in the
processor manual, but no one says "Oh, that's not a PDP-11".
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com --Death, of the Endless
|
|
0
|
|
|
|
Reply
|
news83 (361)
|
12/9/2009 12:57:40 AM
|
|
In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>
> Auditor would have had a field day with that one. Contract should have
> been re-competed as the two are hardly equivalent and there actuall is
> no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
contract. I don't know if they created justification for a protest,
but when I came on the job I was sure glad to be using VAXen.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/9/2009 1:20:26 PM
|
|
In article <H4CdnVlBSu7h44PWnZ2dnUVZ_rNi4p2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> To those of us not programming in Macro, the Alpha was just a faster
> VAX! Much faster!!!
I know there is a lot of junk out there, but all the Macro-32 I had
written before I got my first Alpha compiled much easier than the
Fortran or C. (There were a few missing features in the first ship
Fortran and C compilers.)
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/9/2009 1:22:12 PM
|
|
In article <wswTm.13431$U5.200543@newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
>
> He, I made a search of the all COB and SCO files and got :
>
> OBJECT-COMPUTER. IBM-370.
> OBJECT-COMPUTER. VAX-11.
> OBJECT-COMPUTER. VAX-1100.
> OBJECT-COMPUTER. VAX-3000.
> OBJECT-COMPUTER. VAX-750.
> OBJECT-COMPUTER. VAX-8350.
> OBJECT-COMPUTER. AlphaServer AS800.
> OBJECT-COMPUTER. AlphaServer DS20e.
We had systems who's developer decided that the computer which
generated a tape would be part of thier standard header. During
testing of a port from an 11/34 to an 11/44 someone noted that the
tapes still were still labled 11/34. I told him that the only
possible impact was that the software on the receiving computer
(a DECSYSTEM-2050) might care, and changing it would break that
software.
The developer's standard computer label was not part of my standard.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/9/2009 1:25:59 PM
|
|
In article <hfmaku$jjj$00$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>
> And some people over here were talking about "the Alpha-VAX",
> probably as opposed to a true "VAX-VAX".
> They referred to a VAX as a box which runs VMS.
> So in their mindset the connection between VAX and VMS was much stronger
> than between Alpha and VMS.
We had a major system which was all VAX-VMS. One of the maintenance
contractors described them as computers that "can't run UNIX". At
the time DEC was shipping Ultrix for every model VAX they made.
Some battles are not worth fighting.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/9/2009 1:27:38 PM
|
|
In article <IweRJQ32IoED@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>
>> Auditor would have had a field day with that one. Contract should have
>> been re-competed as the two are hardly equivalent and there actuall is
>> no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
>
> Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
> contract. I don't know if they created justification for a protest,
> but when I came on the job I was sure glad to be using VAXen.
having worked on both sides of the contracting issue, I can assure you
cost has nothing to do with it. If the contract was awarded and any
changes were made in the deliverables the by the winner of the contract
after award it would be grounds for a protest. That's one of the biggest
problems with contracting. especially in the IT world. And also why the
government has gone almost exclusively to COTS for most of it's IT
requirements. Once a contract is signed the contractor is required to
deliver what is in the contract. Aallowing a contractor to change the
deliverable after award is an unfair advantage tot hat contractor and
definitely grounds for a protest. It is why the process takes as long
as it does. If you don't carefully spell out exactly what you want you
could find yourself forced to accept soemthing that will not do the job.
But if it meets the contract specs and the contract has been accepted,
your stuck with it.
Like I said, been there, done that, got the T-shirt.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
12/9/2009 3:01:44 PM
|
|
-----Original Message-----
From: info-vax-bounces@rbnsn.com [mailto:info-vax-bounces@rbnsn.com] On Beh=
alf Of Bill Gunshannon
Sent: Wednesday, December 09, 2009 10:02 AM
To: info-vax@rbnsn.com
Subject: Re: [Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.
In article <IweRJQ32IoED@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bi=
ll Gunshannon) writes:
>>
>> Auditor would have had a field day with that one. Contract should have
>> been re-competed as the two are hardly equivalent and there actuall is
>> no such thing as a PDP-VAX. I can't believe there wasn't a protest file=
d.
>
> Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
> contract. I don't know if they created justification for a protest,
> but when I came on the job I was sure glad to be using VAXen.
having worked on both sides of the contracting issue, I can assure you
cost has nothing to do with it. If the contract was awarded and any
changes were made in the deliverables the by the winner of the contract
after award it would be grounds for a protest. That's one of the biggest
problems with contracting. especially in the IT world. And also why the
government has gone almost exclusively to COTS for most of it's IT
requirements. Once a contract is signed the contractor is required to
deliver what is in the contract. Aallowing a contractor to change the
deliverable after award is an unfair advantage tot hat contractor and
definitely grounds for a protest. It is why the process takes as long
as it does. If you don't carefully spell out exactly what you want you
could find yourself forced to accept soemthing that will not do the job.
But if it meets the contract specs and the contract has been accepted,
your stuck with it.
Like I said, been there, done that, got the T-shirt.
bill
**********
I've been doing this both inside and outside the DOD for nearly 40 years, l=
iterally everything from PDP-11's to multi-million dollar Cray super comput=
ers and their front ends. And while that sounds nice in theory I can assure=
you contracts get modified after award all the time and protests are seldo=
m an issue.
Dan
|
|
0
|
|
|
|
Reply
|
daniel.allen (3)
|
12/9/2009 3:38:51 PM
|
|
Bob Koehler wrote:
> In article <H4CdnVlBSu7h44PWnZ2dnUVZ_rNi4p2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> To those of us not programming in Macro, the Alpha was just a faster
>> VAX! Much faster!!!
>
> I know there is a lot of junk out there, but all the Macro-32 I had
> written before I got my first Alpha compiled much easier than the
> Fortran or C. (There were a few missing features in the first ship
> Fortran and C compilers.)
>
ISTR that a VAX to Alpha port was usually just a matter of compile, link
and run. If your code expected 512 byte pages, you had a problem. Most
of the code I dealt with was written in FORTRAN and didn't know or care
what the page size was. If you did naughty things like bit twiddling
floating point numbers you had to adapt your code to the new floating
point format.
People who had data files with binary floating point had to convert
them. I don't recall it as being a problem although I'm sure some
people did have problems.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
12/9/2009 4:07:12 PM
|
|
"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
news:SpWdncx1SK2tVoLWnZ2dnUVZ_i2dnZ2d@giganews.com...
> Bob Koehler wrote:
>> In article <H4CdnVlBSu7h44PWnZ2dnUVZ_rNi4p2d@giganews.com>, "Richard B.
>> Gilbert" <rgilbert88@comcast.net> writes:
>>> To those of us not programming in Macro, the Alpha was just a faster
>>> VAX! Much faster!!!
>>
>> I know there is a lot of junk out there, but all the Macro-32 I had
>> written before I got my first Alpha compiled much easier than the
>> Fortran or C. (There were a few missing features in the first ship
>> Fortran and C compilers.)
>>
>
> ISTR that a VAX to Alpha port was usually just a matter of compile, link
> and run. If your code expected 512 byte pages, you had a problem. Most
> of the code I dealt with was written in FORTRAN and didn't know or care
> what the page size was. If you did naughty things like bit twiddling
> floating point numbers you had to adapt your code to the new floating
> point format.
>
> People who had data files with binary floating point had to convert them.
> I don't recall it as being a problem although I'm sure some people did
> have problems.
>
For Macro-32, there was a BUNCH of stuff that works on VAX that wasn't
supported on Alpha. The Macro compiler porting guide is chocked full of
them. Plus for almost any non-standard interface, you had to start adding
..CALL_ENTRY, .JSB_ENTRY, and/or .JSB32_ENTRY directives. Macro-32 certainly
wasn't recompile and go.
On the other hand, the higher level langauge compilers were designed to be
recompile and go. The C issue was that was the same time as the VAX C to
DEC C language definition.
Binary floating on VAX vs Alpha isn't a big deal since Alpha has F/G
floating with almost D support minus a few mantissa bits.
John
|
|
0
|
|
|
|
Reply
|
johnrreagan (367)
|
12/9/2009 4:14:25 PM
|
|
In article <7o9seoF3palpdU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> In article <IweRJQ32IoED@eisner.encompasserve.org>,
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>
>>> Auditor would have had a field day with that one. Contract should have
>>> been re-competed as the two are hardly equivalent and there actuall is
>>> no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
>>
>> Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
>> contract. I don't know if they created justification for a protest,
>> but when I came on the job I was sure glad to be using VAXen.
>
> having worked on both sides of the contracting issue, I can assure you
> cost has nothing to do with it. If the contract was awarded and any
> changes were made in the deliverables the by the winner of the contract
> after award it would be grounds for a protest.
I suspect the change was made "just in time" before the contract
award.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/10/2009 2:09:43 PM
|
|
In article <SpWdncx1SK2tVoLWnZ2dnUVZ_i2dnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> ISTR that a VAX to Alpha port was usually just a matter of compile, link
> and run.
Most of my code was like that. Once the second release compilers
came out I was able to back out the workarounds for the early
missing features.
We ported many thousand lines of code with a one or two line change.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/10/2009 2:11:07 PM
|
|
Bob Koehler wrote:
> We ported many thousand lines of code with a one or two line change.
While the port to Alpha was not as painful as some african manhood
ritual, if you went from VAX-C to DEC-C, then it was more than just a
couple lines of code to change. While the changes were fairly mechanical
in nature, you still needed to go through it.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
12/10/2009 3:42:56 PM
|
|
JF Mezei wrote:
> Bob Koehler wrote:
>
>> We ported many thousand lines of code with a one or two line change.
>
>
> While the port to Alpha was not as painful as some african manhood
> ritual, if you went from VAX-C to DEC-C, then it was more than just a
> couple lines of code to change. While the changes were fairly mechanical
> in nature, you still needed to go through it.
I did some porting of VAX C to DEC C. It was mostly things like adding
function declarations to make the compiler stop issuing warning
messages. In the process I discovered and fixed an actual bug. ISTR
that it was a subscript range problem.
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
12/10/2009 3:57:28 PM
|
|
Richard B. Gilbert wrote:
> I did some porting of VAX C to DEC C. It was mostly things like adding
> function declarations to make the compiler stop issuing warning
> messages. In the process I discovered and fixed an actual bug. ISTR
> that it was a subscript range problem.
For me, it was all the use of the & in front of variables containing
character arrays. I had learned C that way. Had to change and review all
character strings references. For instance &mystring was no longer
valid under dec-d, but *mystring[0] was. So I couldn't do just global
changes.
|
|
0
|
|
|
|
Reply
|
jfmezei.spamnot (8814)
|
12/10/2009 4:28:44 PM
|
|
In article <000e0216$0$2113$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
> While the port to Alpha was not as painful as some african manhood
> ritual, if you went from VAX-C to DEC-C, then it was more than just a
> couple lines of code to change. While the changes were fairly mechanical
> in nature, you still needed to go through it.
That depends a lot on your C coding habits. Ours were fairly
compatable with DEC C. But you could get away with a lot of things
in VAX C that DEC C wouldn't accept.
Macro-32 was a lot like that. You can do a lot of things that
won't pass through the compiler on Alpha, but our coding habits
didn't.
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/10/2009 5:20:56 PM
|
|
In article <IweRJQ32IoED@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
> In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bill
> Gunshannon) writes:
> >
> > Auditor would have had a field day with that one. Contract should have
> > been re-competed as the two are hardly equivalent and there actuall is
> > no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
>
> Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
> contract. I don't know if they created justification for a protest,
> but when I came on the job I was sure glad to be using VAXen.
One customer who was being funded by EU money was under intense pressure
to buy an ICL system, but "Must run XYZ software" where "XYZ" only ran
on VMS got them a pair of 11/780s, which was what they really wanted.
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
12/10/2009 7:13:59 PM
|
|
In article <hfmaku$jjj$00$1@news.t-online.com>,
Michael Kraemer <M.Kraemer@gsi.de> wrote:
> Jan-Erik S�derholm schrieb:
>
> > Well...
> >
> > At my current client site, at project meetings, they are always
> > talking about doing this-n-that "on the VAX", even if it is
> > over 10 years since the last VAX was shut down. In the beginning
> > a tried to explain that they are not running "a VAX" anymore,
> > but I gave up... :-)
>
> And some people over here were talking about "the Alpha-VAX",
> probably as opposed to a true "VAX-VAX".
> They referred to a VAX as a box which runs VMS.
> So in their mindset the connection between VAX and VMS was much stronger
> than between Alpha and VMS.
Every now and again a conversation about VMS will crop up somewhere on
the internet, and folks invariably refer to it as "VAX/VMS".
--
Paul Sture
|
|
0
|
|
|
|
Reply
|
paul.nospam (2160)
|
12/10/2009 7:20:08 PM
|
|
Paul Sture wrote:
> In article <hfmaku$jjj$00$1@news.t-online.com>,
> Michael Kraemer <M.Kraemer@gsi.de> wrote:
>
>> Jan-Erik S�derholm schrieb:
>>
>>> Well...
>>>
>>> At my current client site, at project meetings, they are always
>>> talking about doing this-n-that "on the VAX", even if it is
>>> over 10 years since the last VAX was shut down. In the beginning
>>> a tried to explain that they are not running "a VAX" anymore,
>>> but I gave up... :-)
>> And some people over here were talking about "the Alpha-VAX",
>> probably as opposed to a true "VAX-VAX".
>> They referred to a VAX as a box which runs VMS.
>> So in their mindset the connection between VAX and VMS was much stronger
>> than between Alpha and VMS.
>
> Every now and again a conversation about VMS will crop up somewhere on
> the internet, and folks invariably refer to it as "VAX/VMS".
>
When some of us learned, "VAX/VMS" was the only VMS! I think the VAX
left a bigger foot print in the "history of computing" than its successors!
|
|
0
|
|
|
|
Reply
|
rgilbert88 (4359)
|
12/10/2009 8:02:29 PM
|
|
In article <paul.nospam-4E1444.20135910122009@pbook.sture.ch>,
Paul Sture <paul.nospam@sture.ch> writes:
> In article <IweRJQ32IoED@eisner.encompasserve.org>,
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
>
>> In article <7o7aptF3osjr8U2@mid.individual.net>, billg999@cs.uofs.edu (Bill
>> Gunshannon) writes:
>> >
>> > Auditor would have had a field day with that one. Contract should have
>> > been re-competed as the two are hardly equivalent and there actuall is
>> > no such thing as a PDP-VAX. I can't believe there wasn't a protest filed.
>>
>> Cost of the 8 11/70 vs. cost of the 8 11/780 was a tiny part of the
>> contract. I don't know if they created justification for a protest,
>> but when I came on the job I was sure glad to be using VAXen.
>
> One customer who was being funded by EU money was under intense pressure
> to buy an ICL system, but "Must run XYZ software" where "XYZ" only ran
> on VMS got them a pair of 11/780s, which was what they really wanted.
>
That worked both ways. A company I was working for once lost a bid to DEC
(we were bidding Primes) even though the machine DEC was bidding didn't
even exist and while we ran all the required benchmarks and delivered boxes
of fanfold paper with the results DEC provided a letter that said what the
box would do, if it actually existed. They won after we withdrew after
hearing the contract representative say, "I don't care who wins as long
as long as it says VAX on the front of tthe box." We got the last laugh,
DEC was bidding VMS and the site wanted the box to run all the free
software they were going to get from Kitt Peak Observatory. Yes, it was
all BSD Unix software!!
bill
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
12/10/2009 8:19:44 PM
|
|
Bill Gunshannon schrieb:
> That worked both ways. A company I was working for once lost a bid to DEC
> (we were bidding Primes) even though the machine DEC was bidding didn't
> even exist and while we ran all the required benchmarks and delivered boxes
> of fanfold paper with the results DEC provided a letter that said what the
> box would do, if it actually existed. They won after we withdrew after
> hearing the contract representative say, "I don't care who wins as long
> as long as it says VAX on the front of tthe box." We got the last laugh,
> DEC was bidding VMS and the site wanted the box to run all the free
> software they were going to get from Kitt Peak Observatory. Yes, it was
> all BSD Unix software!!
So they could have run Ultrix on the VAX.
|
|
0
|
|
|
|
Reply
|
M.Kraemer (1958)
|
12/10/2009 9:26:59 PM
|
|
In article <hfrp33$pot$01$1@news.t-online.com>,
Michael Kraemer <M.Kraemer@gsi.de> writes:
> Bill Gunshannon schrieb:
>
>> That worked both ways. A company I was working for once lost a bid to DEC
>> (we were bidding Primes) even though the machine DEC was bidding didn't
>> even exist and while we ran all the required benchmarks and delivered boxes
>> of fanfold paper with the results DEC provided a letter that said what the
>> box would do, if it actually existed. They won after we withdrew after
>> hearing the contract representative say, "I don't care who wins as long
>> as long as it says VAX on the front of tthe box." We got the last laugh,
>> DEC was bidding VMS and the site wanted the box to run all the free
>> software they were going to get from Kitt Peak Observatory. Yes, it was
>> all BSD Unix software!!
>
> So they could have run Ultrix on the VAX.
Sure they could have. Or BSD. But they bought and paid for VMS when, in
fact, it was totally worthless to them for the purposes they wanted the
machine. So, being a VAX and running VMS made the sale, but didn't do the
job!!
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
|
|
0
|
|
|
|
Reply
|
billg999 (2588)
|
12/11/2009 11:44:57 AM
|
|
In article <3NCdnRdqNbJKzrzWnZ2dnUVZ_jmdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> When some of us learned, "VAX/VMS" was the only VMS! I think the VAX
> left a bigger foot print in the "history of computing" than its successors!
VAX/VMS? Newbie. When I learned, "VAX" was allways followed by
"-11". As in VAX-11/780, VAX-11/VMS, VAX-11 Fortran, ...
When DEC instroduced the 8000 series, it was just plain weird hearing
"VAX 8...", instead of "VAX-11".
|
|
0
|
|
|
|
Reply
|
koehler2 (8190)
|
12/14/2009 9:38:32 PM
|
|
On 14 dec, 22:38, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <3NCdnRdqNbJKzrzWnZ2dnUVZ_jmdn...@giganews.com>, "Richard B. G=
ilbert" <rgilber...@comcast.net> writes:
>
>
>
> > When some of us learned, "VAX/VMS" was the only VMS! =A0I think the VAX
> > left a bigger foot print in the "history of computing" than its success=
ors!
>
> =A0 =A0VAX/VMS? =A0Newbie. =A0When I learned, "VAX" was allways followed =
by
> =A0 =A0"-11". =A0As in VAX-11/780, VAX-11/VMS, VAX-11 Fortran, ...
>
> =A0 =A0When DEC instroduced the 8000 series, it was just plain weird hear=
ing
> =A0 =A0"VAX 8...", instead of "VAX-11".
Yes, I remember that. Wasn't the 8600 actually named 11/790 initially?
Hans
|
|
0
|
|
|
|
Reply
|
hvlems (888)
|
12/15/2009 9:27:36 AM
|
|
In article <04dd1004-2966-426e-9670-607e9a6e4e4f@m25g2000yqc.googlegroups.com>, H Vlems <hvlems@freenet.de> writes:
>Yes, I remember that. Wasn't the 8600 actua | | | |