Windows 2000 64-bit for Alpha AXP
virtuallyfun.com
virtuallyfun.com
They came from Microsoft, although perhaps indirectly, and the drives had all sorts of NT/Windows labels and IIRC had not been wiped.
I have photos of the machines but I don't recall what happened to the drives. I know they were put aside.. somewhere...
The machines were eventually replaced with systems (indirectly) from Pixar. The original machines are long gone.
And earlier builds had the way cooler Watercolor theme[2] (IMHO) than the final Fisher-Price-looking theme.
[1] http://bytepointer.com/resources/old_new_thing/20060111_016_...
As a side note, Google’s Material Design (mentioned in neighbouring comments) actually had a fairly detailed physics (metaphysics? metaphorical physics?) worked out[2] in the first version, but the second regressed to a list of widgets and metrics, and then the everything-is-flat current one arrived.
[1] https://web.archive.org/web/20120314071640/http://kruzeniski...
[2] https://m1.material.io/material-design/material-properties.h...
That would be a cool Dilbert style yearly performance review:
- So what did you do this year?
- Nothing. I just left everything the way it's been for the past 10 years.
- Fantastic! I see a promotion in your future
Same goes for MacOS, iOS and Android UX too. They keep making changes for the sake of changes which are downgrades most of the time because the UI teams need to justify their salaries.
That was an obvious money pit at the time. Also remember that Microsoft had just released the explicitly 32-bit Win32 API, nobody in the PC world was interested in 64-bit architecture. Win32 was the new shiny toy.
Sources:
https://techmonitor.ai/technology/dec_forced_microsoft_into_...
https://www.itprotoday.com/compute-engines/windows-nt-and-vm...
The book "Showstopper!" by G. Pascal Zachary
"Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler to build Windows NT, and many elements of the design reflect earlier DEC experience with Cutler's VMS, VAXELN and RSX-11, but also an unreleased object-based operating system developed by Cutler at Digital codenamed MICA...
"The VMS kernel was primarily written in VAX MACRO [assembler], but Windows NT was designed to run on multiple instruction set architectures and multiple hardware platforms within each architecture. The platform dependencies are hidden from the rest of the system by the HAL (Hardware Abstraction Layer).
While creating Windows NT, Microsoft developers rewrote VMS in C. Although they added the Win32 API, NTFS file system, GUI, and backwards compatibility with DOS, OS/2, and Win16, DEC engineers almost immediately noticed the two operating systems' internal similarities; parts of VAX/VMS Internals and Data Structures, published by Digital Press, accurately describe Windows NT internals using VMS terms. Instead of a lawsuit, Microsoft agreed to pay DEC $65–100 million, help market VMS, train Digital personnel on Windows NT, and continue Windows NT support for the DEC Alpha.
"Windows NT and VMS memory management, processes, and scheduling are very similar. Windows NT's process management differs by implementing threading, which DEC did not implement until VMS 7.0 in 1995, likely to compete with Microsoft.
"Like VMS, Windows NT's kernel mode code distinguishes between the "kernel", whose primary purpose is to implement processor- and architecture-dependent functions, and the "executive". This was designed as a modified microkernel, as the Windows NT kernel was influenced by the Mach microkernel developed by Richard Rashid at Carnegie Mellon University, but does not meet all of the criteria of a pure microkernel. Both the kernel and the executive are linked together into the single loaded module ntoskrnl.exe; from outside this module, there is little distinction between the kernel and the executive. Routines from each are directly accessible, as for example from kernel-mode device drivers."
Windows on AXP allowed Microsoft a place to run SQL Server on 64-bit hardware, getting a foot in the door there. It also allowed DEC to push powerful workstations into large Windows customers. But NT definitely felt sluggish on Alpha- there was a lot of room for optimization, but it was always a bit of an afterthought, vs running VMS or UNIX/OSF-1 on Alpha.
That wasn't enough to save DEC, though. Alpha was an awesome platform at the time. The AlphaServer 8400 "TurboLaser" machines were insanely fast. I'm still looking for an AS 2100 "Sable" machine to restore.
Source: Worked at DEC in the Windows/Alpha team.
We ordered all our alphas with windows. This was because we ran FreeBSD/alpha, and didn't want to pay for the DEC UNIX license. So the first thing we'd do when we got a new box was to switch the firmware from ARC to SRM mode and install FreeBSD. I imagine lots of other places did that, but with Linux rather than FreeBSD.
I do remember running Windows for a few weeks. FX!32 was really impressive, and it felt like normal x86 windows. I can't recall why I did this .. just playing with the OS, and maybe to see what it might take to get FreeBSD booting from ARC (I was one of the 2 people who did the port of FreeBSD to alpha)
That conversation would have been shortly after the merger, but before Compaq started gradually killing everything Alpha related in favor of Itanium. Even if Compaq had a little more foresight on that particular matchup, Alpha could never have survived very long after the HP merger, I guess. HP was already building machines for PA-RISC and Itanium, and then there were the minicomputers... how many processor architectures the world was trying to forget about could one company actually support?
While I was there, we switched over from Alpha to Intel because the performance just wasn't there on Alpha - IIRC the 75MHz Intels blew the 233MHz Alphas out of the water. Most of us chalked it up to the fact that Microsoft wasn't super interested or able to optimize Windows to run on Alpha.
As sort of a "stunt" I got the newer versions of the Multia software that were only available on Intel to run on the old Alpha Multias under a (then internal project) emulator called FX!32
I'm sort of half surprised you're recalling an Intel 75MHz beating a 233MHz Alpha, but, sort of half not. Depends on the type of software you were running I guess. Or do you mean just the general system responsiveness?
I did a lot of work on Alphas w/ Digital UNIX, then Tru64, around the 1999-2002 timeframe, and they were so much fun.
Also, the compilers on Windows NT were from DEC, at least to some extent. In the NT 3.50 SDK there is a manual from DEC explaining what the compiler was - a customised Microsoft C/C++ frontend combined with a port of the GEM backend from Unix or VMS.
I don't know how many EV4 systems shipped with 64bit system bus, but by 1994 AlphaStation 255 models shipped with 128bit system bus and 1MByte L2 cache, and they weren't particularly high end (I found one that was used by Best Buy to run VHS rental shop...)
Sybase SQL Server did just fine on UNIX and 64 bit OSes, we had it running HP-UX 11 64 bit.
AGFA sold Alphas (DEC-branded) running NT4.1 in the mid-1990s along with their Apogee film imaging equipment to run their Apogee RIP software (which may have been G4-TIFF based at the time). I worked at a commercial printer as a prepress operator in 1996, and the Alpha/NT AGFA RIP just stayed on until 1998, at least that's when I moved on. The Mac workstations saw the RIP as an ordinary printer. There was never any reason to touch the RIP, it just did its thing and shot to the imagesetter. What I saw later was RAMpage equipment, an AGFA competitor, and which was 100% PDF, that separated the RIP from the shooter into two machines, both RAMpage-branded PCs.
Do you mean 3.1, the 1st release?
Multiple point releases of NT have received multiple service packs. SPs are absolutely not equivalent to or interchangeable with SPs.
For reference, these are the version numbers of NT:
3.1 -- 3 SPs
3.5 -- 3 SPs
3.51 -- 5 SPs
4 -- 6 SPs
5 (Branded "Windows 2000") -- 4 SPs
5.1 (Branded "Windows XP", "Server 2003") -- 4 SPs
6 (Branded "Windows Vista", "Server 2008") -- 2 SPs
6.1 (Branded "Windows 7", "Server 2008 R2") -- 1 SP
6.2 (Branded "Windows 8", "Server 2012")
6.3 (Branded "Windows 8.1" "Server 2012 R2")
10 (Branded "Windows 10", "Server 2016", "Server 2019", "Server 2022"); 10 numbered build releases issued, then 4 datecoded ones; 14 in all.
11 (Branded "Windows 11"); 2 datecoded releases so far.
In other words, 7 versions of NT with a minor-version point-release so far, and in total 16 service packs for those point-releases which did not change the major or minor version number.
5.1 was XP only, and it had 3 SPs. Windows Server 2003 was 5.2, and it had 2 SPs.
(I've actually wondered how this behavior was supposed to be caused by hardware and that's the first time I've heard the cache-is-split-into-independent-banks-which-are-fully-independently-connected-to-the-main-bus-and-cache-snooping-bus explanation which makes sense)
It all just seems such bad timing, especially the way Itanium flopped, But I don't think Compaq could compete with AMD and the hammer.
Also, a lot of AMD64 tech is Alpha derived, despite Intel buying a lot of it from Compaq. I once heard a rumour that early K8 design changelog supposedly had a line about "dropping VAX floating point support from the FPU". Which would be less believable if Hammer didn't resemble EV7 with DDR2 in place of Rambus and no ethernet-based management bus.
Dependent loads can be reordered! The mental overhead of working in that paradigm is just not worth it.
That said, Alphas were mighty fast during their prime, I don't know if that was enabled by the insane memory model or just coincidence?
There were many of the same people working on:
- First 3 generations of DEC Alpha
- StrongARM
- SiByte MIPS (later purchased and rebranded by Broadcom)
- PASemi POWER
- PASemi was then aqui-hired by Apple for making ARM chips
These don't have any particularly unifying memory model, but were all quite performant, so while this may be a different coincidence, I suspect that the people involved are more likely a contributing factor to the performance than the memory model.
Oh for sure. It's just that it's like saying a nuclear bunker will be fine if you drop a pound of dynamite on it :)
>I don't know if that was enabled by the insane memory model
I have to imagine it was, especially since back then the "optimization" parts of CPUs weren't nearly as advanced as they are today (branch predictors, OOO execution that still maintains the memory model guarantees, etc). Alphas were dead before my time, but I have to imagine the tradeoff was a) their expense, and b) the time it actually took to write software and track down concurrency bugs due to everything being talked about here.
From an OpenBSD perspective, I can see it being valuable to know that it means the code can be safely ported to any random arch that comes out in the future, but for more commercial software, I really can't see that being worth the time worrying about.
To solve that, see the compiler barriers section in https://www.kernel.org/doc/Documentation/memory-barriers.txt
Per the Wikipedia page [1], the similarities became a potential legal liability, which Microsoft managed by continuing to invest in NT on Alpha.
"Although they added the Win32 API, NTFS file system, GUI, and backwards compatibility with DOS, OS/2, and Win16, DEC engineers almost immediately noticed the two operating systems' internal similarities; parts of 'VAX/VMS Internals and Data Structures', published by Digital Press, accurately describe Windows NT internals using VMS terms. Instead of a lawsuit, Microsoft agreed to pay DEC $65–100 million, help market VMS, train Digital personnel on Windows NT, and continue Windows NT support for the DEC Alpha."
Some say it's just a coincidence. I wonder if anyone on HN has first-hand knowledge.
[1] See for example this development documentation https://americanhistory.si.edu/collections/search/object/nma...
This was the era of serious CPU arguments, Itanium was going to be the next big thing, PowerPC was making serious performance claims, etc.
Windows NT ran on IA-32, MIPS, DEC Alpha, PowerPC, Itanium, x64, and ARM. All the cool OSes back then ran on many different architectures.
> That was an obvious money pit at the time. Also remember that Microsoft had just released the explicitly 32-bit Win32 API, nobody in the PC world was interested in 64-bit architecture. Win32 was the new shiny toy.
IIRC, they had Windows NT releases for PowerPC and MIPS, too.
At the time, I think the matra was "CISC is dead, long live RISC." It was prudent on Microsoft's part to be ready if Intel became uncompetitive, to avoid finding themselves it Apple's early-90s situation with Motorola.
I originally wrote "really wanted" but it wasn't a huge deal. The wintel duopoly worked out for them both...until it didn't, and it was Intel who sagged first.
There are emulators for DEC Alpha, but they only support Unix ‘PALcode’ firmware. Windows NT required different PALcode, for which there is no working emulator AFAICT.
https://repo.or.cz/w/qemu/es40.git
If you can try to help, as always much appreciated?!
Maybe you can have better luck contacting Tristan Gingold
https://lists.defectivebydesign.org/archive/html/qemu-devel/...
It does indeed look like it supports emulating PALcode more at the hardware level, than userspace (if that terminology makes sense). However, I am unsure at how to extend...
I need to blog more on it but finding this 64bit alpha kind of was a big surprisie and has eaten more of my time.
Ive been trying to figure out how the clarcrom.exe is decompressed, and comparing it to the cl67srmrom.exe
I'm not entirely sure the es40 can even go into alphabios. it may all be a redherring.
I found an ascii string 'WimC' that seems to start the compressed data, but a simple copy/paste ended in the program terminating.
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000001a45e5ec
Not sure I can help more but I'm easy enough to find @ virtuallyfun.com
I don't know whether you'd want to work from scratch, to do things entirely your own way, or whether you'd look to extend an existing project. Either is of course reasonable.
If the latter, I get the impression AXPbox is currently the best maintained Alpha emulator. There have been a LOT of Alpha emulators over the years: http://www.avanthar.com/healyzh/decemulation/Alpha.html
Without wanting to sound entitled, my preference is NT for Alpha. That's because Visual Basic 6.0 for Alpha exists, but not for PowerPC. Of course, as a retro computing enthusiast, I'll gladly take any.
https://virtuallyfun.com/2021/11/10/revisiting-windows-nt-4-...
The OpenGL is more 1.0 than 1.1... so it makes for interesting ports. I need to touch on that one too. so much to do..
The Wikipedia Netware page laconically mentions all the architectures that it supposedly "ran" on but really it never shipped in production beyond the 368.
As a Netware admin at the time, I think the real killer opportunity that Novell missed was Netware for OS/2. That gave them a real nondedicated Netware 4 server using early 1990s technology, which could've been a web server or an email server or whatever you needed using OS/2 binaries in the background alongside the industry beating performance of Netware at that time, but instead Novell decided to go it alone and wasted a huge amount of time and effort on making Netware 5 and 6 into products capable of running their own native binaries meaning that they re-implemented half of UNIX into what had been a tiny, sleek, dedicated file and print server.