Re: Well they want to stay relevant
There were very practical reasons why DEC did not do a 486 port of VMS, most of them architectural. VMS made good use of a number of VAX specific instructions, including IIRC some arbitrary length string and number instructions, and others with implied loops in the instruction itself. As I understand it, the re-write that had to happen to allow VMS to transition to the Alpha, even though this had some instructions to ease this work, was significant, as was the following one to Itanium (under HPs stewardship).
Now there is an Intel port, my guess is that the x86_64 port will be much easier.
In the '80s, one of DECs aims was to try to produce lower priced systems that could run VMS, starting with the MicroVAX II (the first MicroVAX had significant restrictions that made it difficult to do anything with), and continuing with a number of small MicroVAX systems including desktop VAXStations (not to be confused with the MIPS based DECStations which ran BSD/Ultirix/Digital UNIX).
These were actually quite good value, but were priced in the same sort of bands as equivalent Sun, or Apollo workstations and servers.
What DEC did, which was unforgivable in marketing terms, was to announce the Alpha based VAXes a long time before they were ready. This literally killed about three quarters worth of VAX sales, as customers decided to wait to buy new systems until the Alpha based systems were available. Unsurprisingly, this gave DEC cash flow problems, which IMHO, they never recovered from, leaving them vulnerable to takeover offers at a later time.
I never really understood the rational behind Compaq buying DEC. but I suppose Windows NT on Alpha was probably one of them.
I find your commend about PDP11 strange. The PDP11 never ran VMS (VAXes were called things like VAX 11/780), The closest thing to VMS that PDP11s ran was RSX/11m, which is widely regarded as the direct ancestor of VMS, and was managed by one Dave Cutler, later of VMS and Windows NT fame.
The PDP11, although being a classic architecture IMHO, was a system of it's time. It was a purely 16 bit ISA, although to make it more useful, there were some addressing extensions bolted on to larger and later systems. No PDP11 was able to address more than 4MB of memory, and the process address space was strictly 16 bit, with an instruction and data separation feature on larger and later systems that extended this to 112K or maybe 120KB, as the top 8KB was reserved for memory mapped I/O devices ( I can't remember if the I/O page was in both the I&D spaces, or just the Data space).
Even when PDP11 was a common architecture, the 56KB process limit on the non-separate I&D systems was a severe limitation, which lead to large applications having to use memory resident overlays and also split the applications into multiple processes using IPC to communicate to do anything serious. I ran Ingres on a PDP11/34e with 22 bit addressing ('34s did not normally have 22-bit addressing - it was a SYSTIME kludge) under UNIX edition 7 for some time, and the data manager had to be split into something like 7 different processes to allow it to work.
There were micro PDP11 implementations, some of which made it into desktop systems (the F11 and J11 micro PDP11s), but these were really just offered for continuity for customers who would or could not transition to VAX. The main reason for people staying with PDP11 was for it's I/O system, which made it exceptionally suitable for lab instrumentation, process control and real time implementations, and for operating systems not similar to VMS, like RSTS/e.
I would still be interested in buying a desktop 11/83 at the right price, even though I would probably use a PC more powerful than it as it's console.