It probably would have made the article too long to discuss the earlier 12-, 18-, and 36-bit systems, as well as the 16-bit PDP-11 and its outsize influence on later systems.
However, a key point also is lost: DEC's early dismissal of personal computers, only to have them catch up to and eat the entire minicomputer category. Their early micros were half-hearted; the Rainbow 100 ran MS-DOS but was not PC compatible, and even lacked a FORMAT command for formatting floppy disks (you were expected to only buy preformatted disks without hub rings because they damaged the RX50 drive mechanism). The Professional 300 series, based on PDP-11 architecture, was deliberately made not fully compatible to existing PDP-11 minicomputers (and also had that RX50 floppy drive). They were so worried about cannibalizing their own business that they forgot that they could get eaten by their new competitors instead.
>the Rainbow 100 ran MS-DOS but was not PC compatible
Compatibility with computer systems from other manufacturers was such an alien concept to the minicomputer makers that they all pretty much genuinely thought they were doing a great job by being mostly MS/PC-DOS compatible. A common compatibility test was whether a system could run unmodified Microsoft Flight Simulator out of the box. Most couldn't.
It was a thing in computers and mainframes. Lots of IBM copies.
But I think more importantly they literally released 3 different computer personal systems literally on the same day. That was totally ridiclous.
Use your PDP11 stuff to compete head to head with PC or go PC compatable, half and half is bad. And then the also had CM/S at the same time. That a totally crazy and wasteful strategy.
The Rainbow guy then went to Sun and build the i386, another non PC compatable that failed. But arguable that one was actually a good idea.
Fair enough about plug-compatible mainframes. Though that probably was able to happen to at least some degree because IBM was acutely aware of anti-trust scrutiny.
I mean even before IBM was dominate, after IBM moved to 360. Honeywell copied some of the older mainframes and made lots of sales. Cloning has been a thing in computing for a while and there is no legal way to stop it in many cases. But I'm not an expert on that.
Yes. The MicroVAX I and II were IC implementations of the original VAX. Vax on a chip. (Two different implementations. Low and high end.) They were designed and manufactured in-house by DEC, and were for sale in VAX minicomputer products by late 1984, early 1985 in volume.
In 1984, the only full 32-bit microprocessor that was actually available for a workstation or personal computer was the Motorola 68020. The Intel 386 wouldn't be out until late 1985.
> They were so worried about cannibalizing their own business that they forgot that they could get eaten by their new competitors instead.
There is perhaps an alternate history, where DEC started making 32-bit workstations and high-end personal computers around then as a major push, and not in the late 1980s as an afterthought. Though by 1984, IBM was starting to feel the pressure from competition in the low-end PC market. DEC would have felt that pressure! They were selling PC compatibles already. Margins were razor-thin, sales were impersonal. Exact opposite of how DEC usually operated. No surprise management saw it as a risky sector to further expand in.
Yup, I can see how they might not want to become a consumer product maker. Yet they could have parlayed the LSI-11 and successors into the position of Intel, IBM, and Microsoft combined, and flat-out owned a big chunk of personal computing, even if they stayed behind the scenes selling chipsets and software. Indeed it could be said that the PDP-1 was one of the world's first personal computers, but it was still a school/enterprise machine at a school/enterprise price.
And by 1992 they actually had a profitable PC buissness unit.
Plenty of manufactures make mostly server stuff. That really the issue, they failed on continung to be dominate in bigger servers. And much of their revenue depended on support contracts.
If you sell less systems and those systems are less depenpended on you Unix/NT then there is just gone be less revenue.
They also invested $Billions in the VAX 9000, to try and get back at the high-end mainframe market, but it was delayed, and the NVAX chip was almost as fast, but in a desktop form-factor for a fraction of the price.
Windows NT wasn't a new ground-up project. It's based on some OS/2 code and design.
When IBM and MS fell out and divorced over the OS/2 project, there were 3 versions of OS/2 underway:
• OS/2 1, 16-bit, for the 80286
• OS/2 2, 32-bit, for the 80386
• OS/2 3, 32-bit, CPU-independent and cross-platform.
IBM kept v2, finished it, and released OS/2 2, 2.1, 3, 4 & 4.5. V3 and after were codenamed "Warp" but the company failed to negotiate with the owners of Star Trek for a marketing deal.
MS kept OS/2 3, the planned CPU-independent version.
Dave Cutler and his team at DEC were angry at DEC management because DEC cancelled the Mica cross-platform OS and PRISM RISC CPU to run it.
Cutler was head-hunted by MS and given OS/2 3 to finish and make work.
The project was originally developed on the Intel i860 RISC chip, codenamed N10.
While work was underway, Windows 3 became a huge hit. The company worked out a 32-bit version of the Windows API, called Win32, and renamed OS/2 NT to "Windows NT".
Yes, there is a lot of VMS design in the NT design, but it's not direct inheritance: it's because Cutler was planning a CPU-independent VMS with "personalities" that could run binaries from other OSes, such as DOS and UNIX.
And aside from that, there is also a fair chunk of OS/2. NT 3.x could use OS/2 HPFS disk volumes, run text-mode OS/2 binaries, and had an optional extra Presentation Manager add-on to run graphical OS/2 binaries.
also, they had their own FABs, with low volume, which would also be a big financial burden to keep updated. They sold their Hudson Fab to intel in the mid/late 90s.
Most of the ones in common use now are an actual terminal standard, ANSI X3.64 aka ISO 6429 aka ECMA-48¹. Most of the others in common use come from xterm extensions.
> Dan Dobberpuhl was one of the original Alpha designers before he left DEC to start a chip design firm called P.A. Semi, which Apple bought in 1998 for its talent to work on their Arm processors.
P.A. Semi didn't even exist in 1998. It was founded in 2003, and was acquired by Apple in 2008.
That confused me a bit, thanks. In '98, Macs still used PPC architecture, and the IPhone didn't exist. I don't know what kind of CPU the IPod was using at the time -- I'd guess ARM. Still, that seemed like it could get away with an off the shelf CPU -- buying a bunch of chip design talent doesn't seem like it would be super rational then.
iPod was only released in 2001, though, and the idea to make a PMP only really got steam in 2000, with much of the work only happening after Fadell was urgency is how Apple got to contract out much of the work, even he was initially contracted before getting fully hired when his proof of concept got the nod).
OTOH the ill-fated Newton was also ARM-based. As well as the emate pseudo-laptop.
For that matter, PA Semi was itself a Power licensee. They were developing the PA6T, which might have been in whatever the next PowerBook would have been. After the purchase, Apple still had to make promises about its availability because it was being used in some military applications even though they would never use the PA6T in one of their own machines. I think the AmigaOne X1000 was the only generally available computer that ever used it.
I also found this line referring to the advantages of 64 vs 32 bits questionable:
> Bits don’t change the processing power; they just change the amount of addressable memory
Now in my personal experience since the early 1980s, increased addressable memory is the biggest advantage for most personal computer workloads. (At least until software is rewritten to use 64-bit instructions) But there are definite processing power advantages too, and for the target market of DEC’s Alpha chip this was likely an important advantage.
It is questionable and indicates the author doesn't understand CPU bit width.
There are three key bit widths that impact a CPU
Address bus: how much RAM the CPU could theoretically address.
Data bus: how many bits at a time the CPU can read from the RAM it can address.
Register: how much data an instruction can operate on at a time.
The author appears to understand only address bus width and may be influenced by early (valid, depending) complaints that the transition from 32 to 64 bit didn't benefit end users.
Going from 32-bit to 64-bit registers can provide a significant performance improvement. But only if you're doing math on 64-bit values. Without specialized instructions, 32-bit and smaller math won't improve due to the register width improvement.
Increasing the size of the data bus can provide a big performance improvement if the previous bus was narrower than the register width.
Many (most? citation needed) current, mainstream CPUs use the same bit width for all three (address, data, register).
The 8088 was notable back in the day because it had a 20 bit address bus, 16 bit registers, and an 8 bit data bus.
Edit: The Alpha had 64 bit registers -- it wasn't just a 32-bit register / data bus CPU with a 64-bit address bus.
Don’t forget the SIMD registers which can be 128/256/512 wide (neon/avx2/avx512)
It’s very difficult to give just a single number for data bus width. Do you add all the DRAM channels? DDR5 has 2 x 32 bit channels where DDR4 has a 64 bit channel. What does bus width mean for PCIe, which uses very fast differential serial lines? Really, it hasn’t been a useful way to describe system performance since the 1990s.
I remember my time using an Alpha AXP nearly 30 years ago being the fastest computer I've ever used - I imagine my current laptop is far superior in speed by orders of magnitude, but the applications hadn't caught up with the CPU available.
It was also probably the most reliable. We never switched off or even logged out of the machines for 6 months to a year at a time.
We had DECstations. They were great systems for the day. Only a few years later, they were overtaken in speed and price by (IIRC) 486 systems with Linux; I think those were cheaper than the tape cartridge unit on which we got the system updates. DEC never recovered.
Your current _watch_ is faster than an Alpha AXP. (If you have an Apple Watch) the early ones only pushed in the low hundreds of MIPS.
It's crazy to me how my whole-ass DECServer with 2x EV4's wouldn't even be a good peripheral for portable computers today, and it could run hundreds of interactive user sessions.
The big leap up from VMS in terms of performant concurrent users for us was when we switched to using a Sequent Symmetry, now that's another long dead system giant. Poor Dynix.
> It was also probably the most reliable. We never switched off or even logged out of the machines for 6 months to a year at a time.
In 2003 or 2004 I worked with a former DEC engineer who begroaned their reliability. He claimed that their hard drive engineers got obsessed with making sure the drives would last 30 or 40 years, when they would be functionally obsolete (and replaced) in 5 years.
I recall visiting the office on an email administrator at a tech firm in California. There was an important email that got "lost" somehow, and I took the opportunity to meet the person who ran the internal email system. This person was large and in-charge! in their cubicle.. I had never seen them otherwise. Once asked the guy quickly opened his window setup, I think it was some kind of VMS derivitive in the late 1990s, and searched every email sent by anyone in the company for the past year.. quickly! This was impressive to me at that time, and I remember the whole situation very well now.
Very nostalgic to see the recent DEC/digital talk on HN lately. My first job out of college I wrote C++ on OpenVMS (originally on Alpha).
I remember when we had to port to OpenVMS Itanium. Biggest pita was floating point conversion. Alpha used VAX float while Itanium used the IEEE standard.
I laughed the first time I saw the exit code "%SYSTEM-W-FISH, my hovercraft is full of eels".
I still to this day own a copy of "Writing real programs in DCL". Looks like a collectors item, hahaha!
I also somewhat miss the mainframe development. We had a fantastic (albeit homegrown) build system and architecture (thin client, thick server - all C++) that was hugely enabling. Was super slick and easy to build, you could easily create previews for product people to run and test. Really tight development loops... loved it.
My first internship was working on a SCADA system on Vaxstations running VMS. My mom had to help me learn FORTRAN for this. (we were all unix/c at school).
My first job was as a sysadmin starting in 93 for an academic stats dept that used DECstations and were getting their first DEC alphas running OSF/1. A lot of my job at first consisted of getting the open source applications they needed running in 64 bit mode (you would not believe how many int/pointer conversions I had to fix). I remember adding a memory kit to a 3000/500 in the first month of working there. That memory kit had a retail value higher than my annual salary at the time & it was terrifying.
My next job was as research staff at at a comp sci dept doing OS research. I wrote drivers for Myricom NICs for DEC OSF/1. (and had the funniest bug.. we had to use GCC to compile the drivers, and I missed the no-fp-reg directive, so every time the driver was active, it was using floating point registers as general registers and corrupting users fp state.. You'd see applications crashing left and right with FP exceptions).
A few years later, the same dept paid me full time to help port FreeBSD to the DEC alpha, and I maintained FreeBSD/alpha until alpha was walking dead, and we killed the FreeBSD/alpha port. I got one of the first API UP1000s (one of the 3rd party alphas that used the irongate chipset from AMD), and it was my workstation running FreeBSD/alpha for years.
In the early 2000s, I had a gig at AccuWeather rewriting from the ground up a non-weather web application. My work was on Windows 2000. They bought me a new Dell server for that purpose had let me have at it. But at that time, all of their main machines were VAX VMS - including their weather web servers.
Even then it caused me to reminisce on time spent on DEC VT100 and VT220s in the graduate terminal room at CMU.
Anyone remember the DEC Rainbow? My local university where I took classes during high school had some. Great keyboards just like the VT terminals.
DEC keyboards where the benchmark against which I compared all other since - most came up wanting.
The early days of DirecTV were actually a partnership between Hughes Electronics, USSB, Thompson Consumer Electronics (RCA), and DIGITAL. Hughes provided the satellite tech and some FCC licenses, USSB some FCC licenses, Thompson built the set top boxes, and DIGITAL ran all of the technology. Until DirecTV started to in-source their own IT operations in the mid-2000s, all of the systems to run the business were in DIGITAL facilities (the same campus where StorageWorks R&D and early manufacturing was done) in Colorado Springs. To this day, all those Colorado Springs hosted systems running Billing, Account Management and CRM are in the dec.com domain.
HP-UX has replaced most of the OSF/1 stuff by the time I joined in 2011, but OpenVMS was just being upgraded from Alpha to Itanium boxes. I doubt it will survive to make the transition to x86, but it it still the backend for most billing and account management via STMS.
Some of the billing was migrated to AT&T systems, but we halted that project because it substantially increased customer churn just migrating them from STMS to Enabler and changing the bill format, even if amounts didn't change. I guess it reminded folks that AT&T was in charge now.
It is not frequently that one gets really pleased with a computing device so when it happens the memory lingers for a looong time. So it happened with the DEC Alpha. I vaguely recall that its overall desktop experience was less polished than the SUN workstations of that era, but its raw performance made up for it as it woud allow you to accomplish things previously beyond reach.
A similarly memorably experience would be quite elusive these days. For one thing the very concept of a powerful workstation is kinda old fashioned. But who knows, maybe the era of an "AI PC" will recreate some of the magic :-)
There is no actual AI PC as far as I know. But that does not mean that the choice of marketing hype does not provide a signal about current vendor's mindset.
Notice that it is not a "Blockchain PC" or a "VR/AR PC" they are peddling, to mention some plausible recent hype candidates one could use :-).
I would imagine an "AI PC" to have a UI heavily based on the idea of anticipating and preparing for future user actions and needs, making the next likely action easier, as well as being conversational. I also imagine voice-prompted conversational interfaces with multimedia responses, and constant gesture/posture input - as in head tracking for parallax adjustment and eye tracking for prioritizing screen updates.
Seeing David Cutler mentioned brought back memories: Back in the late 1980s I wrote a patent (now long expired) for DEC in which Cutler was one of two co-inventors: "Radix-16 divider using overlapped quotient bit selection and concurrent quotient rounding and correction." [0] I've always faintly regretted that I never got to interact directly with Cutler — although the lead inventor, Dr. Ted Kehl (RIP) [1], was great to work with.
Interesting that Cutler was working on circuit-oriented stuff that late in the 80s? Or was this invented much earlier, just patented later? He was courted by Microsoft in '89, so this patent looks like it went through after he'd left DEC, which I guess explains why you didn't have the opportunity to interact with him.
I'd be interested in hearing more about this though!
The link I posted is public information; I can't say more than that (and don't remember much in any case). Normally the "prosecution history" documents would be available online [0], because they're also a public record, but for this patent that doesn't appear to be the case (it was a long time ago, so possibly the USPTO just hasn't yet digitized the documents). It's been some time since I did patent-application work so I'm probably not up to date on USPTO procedures and resources.
From programming a viterbi codec on a PDP 11 in assembly to writing mapping software in C on the 11/780 running VMS in the 80's, I've had a long exposure to DEC and it's products and it has always been a joy. I don't think there was another period in my entire career where I was more productive, learned so much, and had fun doing it. Even though I'd moved off DEC by that time, it was truly a sad day when DEC was bought by COMPAQ and was no more.
Gotta complain about whoever did the visual layout for this article. Their representative hardware was... a rando mid-80's ECL mainframe and a VAXstation? The company produced some of the most impactful hardware in history and these are the devices you think should be shown?
If there's a VAX, we should see the 11/780. The user-facing device should be a VT100, or plausibly an AlphaStation. Other good choices are a PDP-6 (or PDP-10) or PDP-11/45. The images in the article are just bad clip art.
I have a weekend project to make SimH runnable as a Docker Swarm service like I did with some Hercules images. I need to figure out how to make SimH consoles and terminals appear as listening sockets.
Although the article mentions similarities between VMS and Windows NT, it downplays just how extensive a debt NT owed to VMS.
Microsoft's Azure CTO wrote about it back in the day:
>In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went. This statement is in danger of trivializing their efforts; after all, the designers built a new API (i.e., Win32), a new file system (i.e., NTFS), and a new graphical interface subsystem and administrative environment while maintaining backward compatibility with DOS, OS/2, POSIX, and Win16. Nevertheless, the migration of VMS internals to NT was so thorough that within a few weeks of NT's release, Digital engineers noticed the striking similarities.
Those similarities could fill a book. In fact, you can read sections of VAX/VMS Internals and Data Structures (Digital Press) as an accurate description of NT internals simply by translating VMS terms to NT terms.
... "Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars.
I don't know if this is true, but Microsoft (or Cutler ) allegedly stole some of the MICA source code and used it in Windows NT.
"According to inside sources, many portions of NT’s code and even the comments were identical to Mica. As a result, Digital sued Microsoft. Microsoft and Digital settled out of court and the result was the Digital/Microsoft Alliance. "
[0][1]
One interesting design feature is that NT was designed to expose multiple APIs on top of its kernel services. POSIX was another available from the start, and OS/2, IIRC, was another. Win32 was to make it easier to port Windows software to NT and is more or less equivalent to Unix's libc as a layer on top of the OS.
Also IIRC, the Windows limitation I always make fun of, that of deleting open files (which is a fairly common thing in Unix - opening a file in /tmp, deleting it while keeping the file descriptor for further operation), comes from Win32, not the NT kernel.
DEC made a big impact on me when I was growing up in the late 80s and early 90s, and even through the mid 2000s; from learning C on eagle.wesleyan.edu (VAX/VMS) to writing my undergrad thesis C++ on zoltar.ucsc.edu (alpha running dec UNIX) to socrates.cgl.ucsf.edu (alpha cluster running TruCluster) and later geneland.gene.com (alpha cluster running trucluster). The DECs were uniformly excellent, with great CPU and memory performance, along with good compilers and OS (IMHO TruCluster is the last of the great UNICES). I never bought one myself, too expensive.
Since then I've gone back and learned a lot of history about DEC, specifically how the series of PDPs were made. They had a huge impact on scientific analysis, making high speed experimental data collection and complex realtime logic relatively easy to implement.
The year before my freshman year of college, the Computer Science department required students to purchase either a DECStation or an Alpha. My year the required hardware was an IBM (literal) PC. I was so disappointed. My 75mhz pentium couldn't play mp3s without stuttering. I still dream about what the Alpha would have been like.
I found it strange not to mention Altavista. Granted, google ate AV's lunch when they emerged, but as someone who was on the web as it started hitting CS departments (even the one where the first web spider was created), AltaVista was the thing that made the idea of a "search engine" actually seem like it was going to be a thing.
Sure, sure, pagerank was a huge step up (at the time), and larry & sergey would likely have gone down pretty much that path no matter what. But before Google, there was Altavista: fast, feeling comprehensive and pointing the way into the future.
Wow, I forgot about that Altavista (and Hotbot and ...)
The Hardware Behind AltaVista [0]
AltaVista: AlphaStation 500, 256 MB memory, 6GB disk.
AlphaStation 500's handle all external traffic to the site.
They run a custom multi-threaded Web server which sends
queries to the Web indexer and News indexer.
Web Indexer: AlphaServer 8400 5/300, 10 processors, 6 GB
memory, 210 GB RAID disk. This model is the most powerful
computer built by Digital. These servers run the query
engine. The Web index is larger than 40 GB, but most
requests take less than a second.
Scooter: AlphaServer 4100 5/300, 1.5 GB memory, 30 GB RAID
disk. The super-spider runs from this machine. It fetches
pages from the Web and sends them to Vista, our primary web
indexer.
Vista: AlphaServer 4100 5/300, 2 processors, 2GB memory,
180GB RAID disk. This machine indexes Scooter output and
serves as a central distribution point for new index data.
News Indexer: AlphaServer 600 5/333, 896MB memory, 13 GB
disk. This machine keeps an up-to-date index of the news
spool: since new articles appear and old articles expire all
the time, it is in fact quite busy, even though the index it
serves is much smaller than the Web index.
News Server: AlphaServer 600 5/333, 896MB memory, 24 GB RAID
disks. It maintains a current news spool for the News
Indexer. It also serves the articles via http to those of
you who don't want to know about news servers but want to
read news. "
One of the main instigator of Altavista was Mike Burrows. He left DEC to work for Google in fairly early days of Google. He helped implemented some critical infrastructure including Chubby (a distributed lock manager based on paxos) and always had his hands deep in the "subtle" parts of google3 (threading bits). He's also the 'b' in 'bzip2'- the Burrows-Wheeler algorithm.
I'll always remember him, he wore the same engineering outfit every day (light blue button-down shirt) and sat in his one-person at the top of steps of the main building right outside the Ougadougo(?) meeting room so basically everybody walking into the building walked right past him.
I find it odd that there is no mention of RMS, the userspace filesystem view on VMS. It supported sequential, block (a.k.a. "relative") and indexed files; sequential output (the DCL command was TYPE rather than cat or more) was transparent (i.e. indexed file output was in primary key order). This was done at the file system level.
TLDR: The VMS file system supported key/value storage off the shelf (with multiple key views!).
I accidentally crashed a production VAX from userspace via an unaligned disk read on a unibus compatibility driver (they were also using the disk they assigned me for testing for swap; virtual memory machines don't run so well when the swap drive bug checks and goes offline) while developing a RSTS block I/O emulator.
I later had a small consulting gig writing a USB driver for NT. The people who hired me said that because I had experience with VMS drivers I'd be able to do it; not knowing different I said "ok" and I guess they were right.
Along with RDB (DEC's SQL DB implementation) and DBMS-32 (DEC's CODASYL implementation), the CDD ("Common Data Dictionary") was built on top of the KODA engine.
CDD wasn't really free with the operating system, but it was ubiquitous. I spent some time hacking on that too for the report wizard people.
I concur, the notion of "an army marches on its data" was an intrinsic in those environments. It also extended to related technologies such as networking, messaging, lambdas (DECNet Network Objects), and [edit: distributed, cluster-wide] locking. Obviously there are echos of this in today's cloud and other tightly integrated offerings.
You might not agree with the entirety of the vendor implementation, but there was undeniably one to disagree with. The report wizard people competed directly with Datatrieve, along with being bundled with for instance a large ERP package.
81 comments
[ 2.6 ms ] story [ 141 ms ] threadHowever, a key point also is lost: DEC's early dismissal of personal computers, only to have them catch up to and eat the entire minicomputer category. Their early micros were half-hearted; the Rainbow 100 ran MS-DOS but was not PC compatible, and even lacked a FORMAT command for formatting floppy disks (you were expected to only buy preformatted disks without hub rings because they damaged the RX50 drive mechanism). The Professional 300 series, based on PDP-11 architecture, was deliberately made not fully compatible to existing PDP-11 minicomputers (and also had that RX50 floppy drive). They were so worried about cannibalizing their own business that they forgot that they could get eaten by their new competitors instead.
Compatibility with computer systems from other manufacturers was such an alien concept to the minicomputer makers that they all pretty much genuinely thought they were doing a great job by being mostly MS/PC-DOS compatible. A common compatibility test was whether a system could run unmodified Microsoft Flight Simulator out of the box. Most couldn't.
But I think more importantly they literally released 3 different computer personal systems literally on the same day. That was totally ridiclous.
Use your PDP11 stuff to compete head to head with PC or go PC compatable, half and half is bad. And then the also had CM/S at the same time. That a totally crazy and wasteful strategy.
The Rainbow guy then went to Sun and build the i386, another non PC compatable that failed. But arguable that one was actually a good idea.
In 1984, the only full 32-bit microprocessor that was actually available for a workstation or personal computer was the Motorola 68020. The Intel 386 wouldn't be out until late 1985.
> They were so worried about cannibalizing their own business that they forgot that they could get eaten by their new competitors instead.
There is perhaps an alternate history, where DEC started making 32-bit workstations and high-end personal computers around then as a major push, and not in the late 1980s as an afterthought. Though by 1984, IBM was starting to feel the pressure from competition in the low-end PC market. DEC would have felt that pressure! They were selling PC compatibles already. Margins were razor-thin, sales were impersonal. Exact opposite of how DEC usually operated. No surprise management saw it as a risky sector to further expand in.
And by 1992 they actually had a profitable PC buissness unit.
Plenty of manufactures make mostly server stuff. That really the issue, they failed on continung to be dominate in bigger servers. And much of their revenue depended on support contracts.
If you sell less systems and those systems are less depenpended on you Unix/NT then there is just gone be less revenue.
And MICA/PRISM.
And Unix. And the PDP series. And the OS/2 connection. And so much more.
When IBM and MS fell out and divorced over the OS/2 project, there were 3 versions of OS/2 underway:
• OS/2 1, 16-bit, for the 80286
• OS/2 2, 32-bit, for the 80386
• OS/2 3, 32-bit, CPU-independent and cross-platform.
IBM kept v2, finished it, and released OS/2 2, 2.1, 3, 4 & 4.5. V3 and after were codenamed "Warp" but the company failed to negotiate with the owners of Star Trek for a marketing deal.
MS kept OS/2 3, the planned CPU-independent version.
Dave Cutler and his team at DEC were angry at DEC management because DEC cancelled the Mica cross-platform OS and PRISM RISC CPU to run it.
Cutler was head-hunted by MS and given OS/2 3 to finish and make work.
The project was originally developed on the Intel i860 RISC chip, codenamed N10.
(8086, 286, 386, 486 = X86. 86 * 10 = 860 = i860.)
So it was called OS/2 NT for N-Ten.
While work was underway, Windows 3 became a huge hit. The company worked out a 32-bit version of the Windows API, called Win32, and renamed OS/2 NT to "Windows NT".
Yes, there is a lot of VMS design in the NT design, but it's not direct inheritance: it's because Cutler was planning a CPU-independent VMS with "personalities" that could run binaries from other OSes, such as DOS and UNIX.
And aside from that, there is also a fair chunk of OS/2. NT 3.x could use OS/2 HPFS disk volumes, run text-mode OS/2 binaries, and had an optional extra Presentation Manager add-on to run graphical OS/2 binaries.
also, they had their own FABs, with low volume, which would also be a big financial burden to keep updated. They sold their Hudson Fab to intel in the mid/late 90s.
¹ https://www.ecma-international.org/wp-content/uploads/ECMA-4...
P.A. Semi didn't even exist in 1998. It was founded in 2003, and was acquired by Apple in 2008.
https://en.m.wikipedia.org/wiki/Apple_Newton
OTOH the ill-fated Newton was also ARM-based. As well as the emate pseudo-laptop.
> Bits don’t change the processing power; they just change the amount of addressable memory
Now in my personal experience since the early 1980s, increased addressable memory is the biggest advantage for most personal computer workloads. (At least until software is rewritten to use 64-bit instructions) But there are definite processing power advantages too, and for the target market of DEC’s Alpha chip this was likely an important advantage.
There are three key bit widths that impact a CPU
Address bus: how much RAM the CPU could theoretically address.
Data bus: how many bits at a time the CPU can read from the RAM it can address.
Register: how much data an instruction can operate on at a time.
The author appears to understand only address bus width and may be influenced by early (valid, depending) complaints that the transition from 32 to 64 bit didn't benefit end users.
Going from 32-bit to 64-bit registers can provide a significant performance improvement. But only if you're doing math on 64-bit values. Without specialized instructions, 32-bit and smaller math won't improve due to the register width improvement.
Increasing the size of the data bus can provide a big performance improvement if the previous bus was narrower than the register width.
Many (most? citation needed) current, mainstream CPUs use the same bit width for all three (address, data, register).
The 8088 was notable back in the day because it had a 20 bit address bus, 16 bit registers, and an 8 bit data bus.
Edit: The Alpha had 64 bit registers -- it wasn't just a 32-bit register / data bus CPU with a 64-bit address bus.
This is quite wrong, for most x86_64 processors:
Address bus is 42-48 bits
Data bus is 32-128 bits
Registers are 64 bits but usable as 32/16/8 bits
Even on most ARM processors, neither the address bus nor the data bus are same width as either or the register width.
It’s very difficult to give just a single number for data bus width. Do you add all the DRAM channels? DDR5 has 2 x 32 bit channels where DDR4 has a 64 bit channel. What does bus width mean for PCIe, which uses very fast differential serial lines? Really, it hasn’t been a useful way to describe system performance since the 1990s.
It was also probably the most reliable. We never switched off or even logged out of the machines for 6 months to a year at a time.
It's crazy to me how my whole-ass DECServer with 2x EV4's wouldn't even be a good peripheral for portable computers today, and it could run hundreds of interactive user sessions.
We did reduce the baud rate on the ADM-3 terminals to 1200 so the I/O buffering would smooth over some of the swapping.
They did. Developers just chose to use it on abstractions rather than making faster apps...
In 2003 or 2004 I worked with a former DEC engineer who begroaned their reliability. He claimed that their hard drive engineers got obsessed with making sure the drives would last 30 or 40 years, when they would be functionally obsolete (and replaced) in 5 years.
I remember when we had to port to OpenVMS Itanium. Biggest pita was floating point conversion. Alpha used VAX float while Itanium used the IEEE standard.
I laughed the first time I saw the exit code "%SYSTEM-W-FISH, my hovercraft is full of eels".
I still to this day own a copy of "Writing real programs in DCL". Looks like a collectors item, hahaha!
I also somewhat miss the mainframe development. We had a fantastic (albeit homegrown) build system and architecture (thin client, thick server - all C++) that was hugely enabling. Was super slick and easy to build, you could easily create previews for product people to run and test. Really tight development loops... loved it.
My first internship was working on a SCADA system on Vaxstations running VMS. My mom had to help me learn FORTRAN for this. (we were all unix/c at school).
My first job was as a sysadmin starting in 93 for an academic stats dept that used DECstations and were getting their first DEC alphas running OSF/1. A lot of my job at first consisted of getting the open source applications they needed running in 64 bit mode (you would not believe how many int/pointer conversions I had to fix). I remember adding a memory kit to a 3000/500 in the first month of working there. That memory kit had a retail value higher than my annual salary at the time & it was terrifying.
My next job was as research staff at at a comp sci dept doing OS research. I wrote drivers for Myricom NICs for DEC OSF/1. (and had the funniest bug.. we had to use GCC to compile the drivers, and I missed the no-fp-reg directive, so every time the driver was active, it was using floating point registers as general registers and corrupting users fp state.. You'd see applications crashing left and right with FP exceptions).
A few years later, the same dept paid me full time to help port FreeBSD to the DEC alpha, and I maintained FreeBSD/alpha until alpha was walking dead, and we killed the FreeBSD/alpha port. I got one of the first API UP1000s (one of the 3rd party alphas that used the irongate chipset from AMD), and it was my workstation running FreeBSD/alpha for years.
Even then it caused me to reminisce on time spent on DEC VT100 and VT220s in the graduate terminal room at CMU.
Anyone remember the DEC Rainbow? My local university where I took classes during high school had some. Great keyboards just like the VT terminals.
DEC keyboards where the benchmark against which I compared all other since - most came up wanting.
Eehh.. The VT100 keyboards were good, but the VT220 and beyond use the LK201 and LK401 keyboards, which use mushy rubber-dome switches.
Sounds terrible. They should at least have given you VT230 or 240's, which were capable of Tek 4014 and ReGIS graphics...
HP-UX has replaced most of the OSF/1 stuff by the time I joined in 2011, but OpenVMS was just being upgraded from Alpha to Itanium boxes. I doubt it will survive to make the transition to x86, but it it still the backend for most billing and account management via STMS.
Some of the billing was migrated to AT&T systems, but we halted that project because it substantially increased customer churn just migrating them from STMS to Enabler and changing the bill format, even if amounts didn't change. I guess it reminded folks that AT&T was in charge now.
A similarly memorably experience would be quite elusive these days. For one thing the very concept of a powerful workstation is kinda old fashioned. But who knows, maybe the era of an "AI PC" will recreate some of the magic :-)
Notice that it is not a "Blockchain PC" or a "VR/AR PC" they are peddling, to mention some plausible recent hype candidates one could use :-).
[0] https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...
[1] https://www.legacy.com/us/obituaries/seattletimes/name/theod...
I'd be interested in hearing more about this though!
[0] https://patentcenter.uspto.gov/applications/07233378/ifw/tra...
If there's a VAX, we should see the 11/780. The user-facing device should be a VT100, or plausibly an AlphaStation. Other good choices are a PDP-6 (or PDP-10) or PDP-11/45. The images in the article are just bad clip art.
BTW, just released a new version at https://github.com/rbanffy/vm370
Microsoft's Azure CTO wrote about it back in the day:
>In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went. This statement is in danger of trivializing their efforts; after all, the designers built a new API (i.e., Win32), a new file system (i.e., NTFS), and a new graphical interface subsystem and administrative environment while maintaining backward compatibility with DOS, OS/2, POSIX, and Win16. Nevertheless, the migration of VMS internals to NT was so thorough that within a few weeks of NT's release, Digital engineers noticed the striking similarities.
Those similarities could fill a book. In fact, you can read sections of VAX/VMS Internals and Data Structures (Digital Press) as an accurate description of NT internals simply by translating VMS terms to NT terms.
... "Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars.
https://www.itprotoday.com/compute-engines/windows-nt-and-vm...
"According to inside sources, many portions of NT’s code and even the comments were identical to Mica. As a result, Digital sued Microsoft. Microsoft and Digital settled out of court and the result was the Digital/Microsoft Alliance. " [0][1]
[0] https://www.itprotoday.com/compute-engines/death-alpha-nt
[1] https://techmonitor.ai/technology/dec_forced_microsoft_into_...
One interesting design feature is that NT was designed to expose multiple APIs on top of its kernel services. POSIX was another available from the start, and OS/2, IIRC, was another. Win32 was to make it easier to port Windows software to NT and is more or less equivalent to Unix's libc as a layer on top of the OS.
Also IIRC, the Windows limitation I always make fun of, that of deleting open files (which is a fairly common thing in Unix - opening a file in /tmp, deleting it while keeping the file descriptor for further operation), comes from Win32, not the NT kernel.
Since then I've gone back and learned a lot of history about DEC, specifically how the series of PDPs were made. They had a huge impact on scientific analysis, making high speed experimental data collection and complex realtime logic relatively easy to implement.
I remember it being on the cover of LinuxJournal around 90's I could think/desire nothing else for 6 months :(
RIP!
Sure, sure, pagerank was a huge step up (at the time), and larry & sergey would likely have gone down pretty much that path no matter what. But before Google, there was Altavista: fast, feeling comprehensive and pointing the way into the future.
The Hardware Behind AltaVista [0]
AltaVista: AlphaStation 500, 256 MB memory, 6GB disk. AlphaStation 500's handle all external traffic to the site. They run a custom multi-threaded Web server which sends queries to the Web indexer and News indexer.
Web Indexer: AlphaServer 8400 5/300, 10 processors, 6 GB memory, 210 GB RAID disk. This model is the most powerful computer built by Digital. These servers run the query engine. The Web index is larger than 40 GB, but most requests take less than a second.
Scooter: AlphaServer 4100 5/300, 1.5 GB memory, 30 GB RAID disk. The super-spider runs from this machine. It fetches pages from the Web and sends them to Vista, our primary web indexer.
Vista: AlphaServer 4100 5/300, 2 processors, 2GB memory, 180GB RAID disk. This machine indexes Scooter output and serves as a central distribution point for new index data.
News Indexer: AlphaServer 600 5/333, 896MB memory, 13 GB disk. This machine keeps an up-to-date index of the news spool: since new articles appear and old articles expire all the time, it is in fact quite busy, even though the index it serves is much smaller than the Web index.
News Server: AlphaServer 600 5/333, 896MB memory, 24 GB RAID disks. It maintains a current news spool for the News Indexer. It also serves the articles via http to those of you who don't want to know about news servers but want to read news. "
[0] https://groups.google.com/g/comp.unix.tru64/c/aB_z5YXwNMI
I'll always remember him, he wore the same engineering outfit every day (light blue button-down shirt) and sat in his one-person at the top of steps of the main building right outside the Ougadougo(?) meeting room so basically everybody walking into the building walked right past him.
TLDR: The VMS file system supported key/value storage off the shelf (with multiple key views!).
I accidentally crashed a production VAX from userspace via an unaligned disk read on a unibus compatibility driver (they were also using the disk they assigned me for testing for swap; virtual memory machines don't run so well when the swap drive bug checks and goes offline) while developing a RSTS block I/O emulator.
I later had a small consulting gig writing a USB driver for NT. The people who hired me said that because I had experience with VMS drivers I'd be able to do it; not knowing different I said "ok" and I guess they were right.
Like you mentioned, DEC had RMS(record management systems). IBM System/38 & AS/400 had a built in DB2, and I believe System/36 had something similar.
HP 3000's MPE had records in the filesystem I think (it also came with the TurboImage database, though I think that was on top of the MPE filesystem)
Tandem Guardian had Enscribe.
CDD wasn't really free with the operating system, but it was ubiquitous. I spent some time hacking on that too for the report wizard people.
I concur, the notion of "an army marches on its data" was an intrinsic in those environments. It also extended to related technologies such as networking, messaging, lambdas (DECNet Network Objects), and [edit: distributed, cluster-wide] locking. Obviously there are echos of this in today's cloud and other tightly integrated offerings.
You might not agree with the entirety of the vendor implementation, but there was undeniably one to disagree with. The report wizard people competed directly with Datatrieve, along with being bundled with for instance a large ERP package.