Windows 2000 64-bit for Alpha AXP(virtuallyfun.com)
virtuallyfun.com
Windows 2000 64-bit for Alpha AXP
https://virtuallyfun.com/2023/05/15/windows-2000-64-bit-for-alpha-axp/
84 comments
[deleted]
Judging by the branding and build string, this is actually an early version of Windows XP! "Whistler" was the codename for the Windows XP project.
Yep.[1]
And earlier builds had the way cooler Watercolor theme[2] (IMHO) than the final Fisher-Price-looking theme.
1. https://simple.wikipedia.org/wiki/Windows_Whistler
2. https://betawiki.net/wiki/Watercolor
And earlier builds had the way cooler Watercolor theme[2] (IMHO) than the final Fisher-Price-looking theme.
1. https://simple.wikipedia.org/wiki/Windows_Whistler
2. https://betawiki.net/wiki/Watercolor
The story of that theme seems strange to me. On one hand, Raymond Chen says[1] it was a decoy in order to avoid leaking in-development Luna outside Microsoft. On the other, Microsoft’s own Office XP and VS .NET (before 2005) have styling that fits Watercolor better than it does Luna. I don’t know how to reconcile these facts.
[1] http://bytepointer.com/resources/old_new_thing/20060111_016_...
[1] http://bytepointer.com/resources/old_new_thing/20060111_016_...
Why do Windows 10/11 windows look like such garbage compared to this? Now window borders are invisible and the title bar is just one single color instead of that nice fade.
Because one of the principal designers of Windows 8 liked print design and thought computer UIs could learn from its literally centuries-long history[1]. I can’t even say he didn’t have a point (in particular, the “wasted space everywhere” cries don’t really provoke that much sympathy from me—waste, yes, everywhere, no). But it does indeed not seem to be working out for conventional KVM interfaces and not even that well for touch.
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...
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...
Everything is just slow, slow, slow. Gotta hunt around for the window border instead of seeing it. Gotta hut for the edges between buttons. Gotta hunt for where the title bar becomes the window content. Gotta try to scroll every list because you can't immediately see which ones continue beyond the visible area.
You don't get promoted or get to keep your job by leaving the UI untouched for years.
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 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.
Because they saw Google and said: Hei, this is the future.
Windows 2000 was build 2195, 2210 is only 15 days later. It's reasonable that branding was switched to Whistler pretty early, working on the next version, but this build is still extremely close to just being a plain Windows 2000.
What did DEC have on Microsoft to get them to port Windows NT to the AXP architecture?
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.
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.
As others have pointed out, NT was created by former DEC engineers, and was heavily based on a canceled DEC project named MICA. DEC sued Microsoft for stealing their IP (or at least threatened to sue), and in return, were compensated with over $100 million and, amongst other things, got a guarantee from MS to port NT to Alpha and provide support for it.
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
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
I found "Showstopper!" a very good read that portrays both the people involved, the environment the NT project grew out of, and some technical aspects of its development.
The wiki on Windows NT also summarizes this, with links to 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."
https://en.wikipedia.org/wiki/Windows_NT#Development
"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."
https://en.wikipedia.org/wiki/Windows_NT#Development
Some details were of NT were more directly copied from MICA than NT. The wiki article on MICA links to a number of DEC documents in bitsavers which describe various details of the OS.
https://en.wikipedia.org/wiki/DEC_MICA
https://en.wikipedia.org/wiki/DEC_MICA
DEC was desperately trying to stay relevant when the "PC revolution" completely ate their lunch throughout the 90s. At the same time, Microsoft was trying to push more deeply into the "enterprise" at a time when minicomputers and the various UNIX vendors (and DECs own VMS) ruled the datacenters.
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.
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.
Do you have any idea what the installed base of Windows/Alpha was? This is not intended to be insulting, but I don't recall hearing of anybody actually running Windows/alpha -- in my circles, it was just a way to order a workstation w/o paying for a UNIX or VMS license.
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)
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)
I supported a few Alpha customers in tech support in the late nineties. Our NT product was the most advanced thing we made (there were Unix and DOS versions as well) and I specifically remember a Unix admin type of guy grumpily observing on a call, "if I have to run Windows I might as well run it on a real computer."
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?
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?
i vaguely remember attempting to install NT alpha on a dec workstation for one of my dad's friends who worked for either MSFT or digital or HP or something (he got a copy from work for eval - i think he worked in sales). it didn't work at all, and would hang after the file copy portion of the installer. i tried for an entire day but none of my usual x86 tricks applied so i just gave up.
My first industry job was a co-op on the DEC Multia team. Multia was another attempt to lure people over from the VMS/Unix world by bundling an X Server and system administration software along with Windows NT.
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
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
Getting performance out of Alphas usually depended heavily on the compiler, and, really, only the DEC compiler really made it shine. GCC was notoriously bad at generating optimized binaries (circa ~2.95), at least compared to compiling the same code on the DEC compiler suite.
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.
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.
The Multia used the cut-down LCA4 or LCA45 (Low Cost Alpha) CPU, the 21066 or 21066A. These apparently performed worse than the more expensive EV4 or EV45 parts.
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.
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.
the 21066 chips were cache and memory bandwidth starved compared to normal EV4 setup, and IIRC many didn't have the larger cache option. Reports seem to indicate that 233MHz models effectively were about Pentium 100MHz speed in integer ops.
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...)
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...)
I have an Alpha in my collection (DS10.) It still feels pretty snappy for a 20 year old box! I upgraded it with an SSD. Alpha was incredible at the time (late 90s...)
Until version 6, SQL Server was a partnership with Sybase, they even shared the C API for data management.
Sybase SQL Server did just fine on UNIX and 64 bit OSes, we had it running HP-UX 11 64 bit.
Sybase SQL Server did just fine on UNIX and 64 bit OSes, we had it running HP-UX 11 64 bit.
I remember some PC vendors selling Alpha based workstations running NT in the mid- to late 1990s. I don't know how well they performed, but the price put them out of my range by such a wide margin I did not really care. I'd just look at the brochure and drool a little, even though in retrospect, I could not really have done anything with one of these.
> I remember some PC vendors selling Alpha based workstations running NT in the mid- to late 1990s.
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.
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.
There was never an "NT 4.1".
Do you mean 3.1, the 1st release?
Do you mean 3.1, the 1st release?
SP1
That is not what anyone ever calls NT releases.
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.
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.
Thanks!
Insanely fast but all descriptions of the Alpha's memory model sound insane to me, too. For example https://news.ycombinator.com/item?id=22283194
(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)
(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)
So I have to ask, were you swept up in the Compaq merger? No doubt NT on alpha wasn't a big seller, the fact the 64bit compiler was hiding in plain sight pretyt much sums that up. But it had to be a simple sales # thing when they killed NT on Alpha?
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.
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.
Compaq announced complete switchover to Itanium and killing off Alpha without any warning (No Itanium chips were available then, iirc), which is how there are Windows 2000 RCs for Alpha - up until the announcement the development was progressing with assumption that Alpha would be launch platform for 2000 just like it was for NT4.
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.
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.
Windows NT was intended to be multi-arch. NT 3.1 (the initial release) ran on x86, mips, and alpha; in 1993, Alpha (and generally, RISC) was clearly the future. NT 3.5 and 4.0 added PPC, also clearly the future. Windows 2000 included Alpha support up through at least Release Candidate 1. Although public builds were all 32-bit only. Having a working 64-bit system to build a 64-bit OS on is pretty useful though, because during the time of windows 2000, 64-bit was clearly the future. The Alpha architecture's very weak memory model is also super helpful as a test platform, because you have to put the right memory fences in or stuff won't work. Going from x86 to Alpha is hard, because all your insufficient fences hit all at once, going from Alpha to x86 is easy, because you've found all the missing fences already.
Some call the Alpha memory model useful, some call it completely fucking insane.
Dependent loads can be reordered! The mental overhead of working in that paradigm is just not worth it.
Dependent loads can be reordered! The mental overhead of working in that paradigm is just not worth it.
I'm not saying it's good for the overall system. Your choice on that. I'm just saying it's a useful memory model for making sure all your memory fences are in place. If you can run your OS/application there, it's hard to find a place it won't run.
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?
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?
> 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.
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.
Don't forget forget AMD
>I'm just saying it's a useful memory model for making sure all your memory fences are in place.
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.
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.
Security folks depend on this for correctness checks - OpenBSD in particular continues to supports Alpha (memory access reordering, alignment requirements) and Sparc64 (big endian, register windows), as well as the usual suspects, which frequently finds bugs that wouldn't be found on platforms without those "unusual" characteristics.
Specifically on memory ordering bugs though, philosophically speaking, are they actually bugs if the condition is impossible to hit on a given platform?
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.
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.
I think compilers are free to reorder code at compile time assuming single-threaded execution, exposing the same bugs that memory ordering exposes at runtime. I'm not sure if MSVC does this or not.
There are a lot of details, but essentially yes.
To solve that, see the compiler barriers section in https://www.kernel.org/doc/Documentation/memory-barriers.txt
To solve that, see the compiler barriers section in https://www.kernel.org/doc/Documentation/memory-barriers.txt
As mentioned in another comment, it started with bringing over a bunch of developers from Digital, hence why NT has a lot of VMS influence in its design.
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."
[1] https://en.wikipedia.org/wiki/Windows_NT
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."
[1] https://en.wikipedia.org/wiki/Windows_NT
Not surprising given the commong father in Dave Cutler
https://en.wikipedia.org/wiki/Dave_Cutler
https://en.wikipedia.org/wiki/Dave_Cutler
I've heard conflicting stories about the VMS/WNT naming thing being a deliberate choice by Cutler. (If you increment each letter of VMS by one, you get WNT i.e. Windows NT.)
Some say it's just a coincidence. I wonder if anyone on HN has first-hand knowledge.
Some say it's just a coincidence. I wonder if anyone on HN has first-hand knowledge.
It's probably a coincidence, seeing as Windows NT started out as "NT OS/2"[1]. Unless "MS NR/1" has a secret inner meaning as well.
[1] See for example this development documentation https://americanhistory.si.edu/collections/search/object/nma...
[1] See for example this development documentation https://americanhistory.si.edu/collections/search/object/nma...
People forget but back in those days, it was NOT a foregone conclusion that x86 would absolutely rule the day. Serious people with serious reasons argued that CISC was a dead end, there were a large variety of other processors that could do other things, and nobody really predicted that AMD and x86-64 would just absolutely ravish the then relatively powerful and large workstation market.
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.
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.
The thing that brought x86 to supremacy was Itanium and its suppresion of established CPU architectures: Alpha, MIPS, PA-RISC
Bit of trivia: the original development platform for Windows NT was the Intel i860, then MIPS. It was ported to x86 later. Design decision to keep x86-isms out. It was always intended to be very portable. Microsoft wanted into the high-end workstation and server market. X86 was not competitive there. Alpha was the fastest chip in the world by a large margin when introduced. x86 would not meet/exceed RISC performance until the late 90s.
Likely speed - I ran Windows 2000 Pro on a Digital Personal Workstation 600au (Miata) Alpha 21164 system back then because the CD for both Windows 2000 Professional and Office 97 for Alpha came in my monthly TechNet subscription. Even though the OS and Office were 32-bit, it was by far the fastest workstation in the building, and new IT staff always came down to see it (to believe it).
> What did DEC have on Microsoft to get them to port Windows NT to the AXP architecture?
> 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.
> 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.
At the time, the Alpha chip WAS the hotness. The first x64 chip was released in 1999 (by AMD, not Intel) and there was some reasonable expectation the Alpha would be THE chip for high capacity computing and even personal computing. Also, many gov contracts at the time had stipulations that you had to be an 'open' computing platform, which included being able to run on multiple architectures.
AMD’s x86-64 architecture was designed around 1999, but the first actual hardware was released in 2003 (the K8 Opteron).
[deleted]
Apart from the DEC issues, MS wanted a hedge against Intel getting too strong.
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.
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.
I think it's how they got Cutler to come over. And of course Cutler didn't come alone.
x86 was not the original target processor for NT in the earlier stages of its development. This was intentionally done to ensure that x86-isms didn't weasel their way into the OS and harm portability.
It's a hedge against Intel.
Gutted there's no emulator, even for a 32-bit OS.
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.
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.
I have found an old branch of qemu that claimed to support ARC, but it didnt do anything. I'm at a loss on where or how to proceede.
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/...
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/...
That's very interesting, and I don't remember seeing it before.
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...
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...
es40 also seems to use lot of the same ideas
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 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
Challenge accepted. I had been looking for my next emulation target
Hot damn, I love your enthusiasm.
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
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
I usually do it myself from scratch. This is partly because I like to learn all the details of how something works, but also because I have a perverse habit of putting emulators of large machines unto microcontrollers, and most existing emulators are not targeted to a world with only a few K of RAM and limited cycles. eg:
http://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard
http://dmitry.gr/?r=05.Projects&proj=25.%20VMU%20Hacking
http://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard
http://dmitry.gr/?r=05.Projects&proj=25.%20VMU%20Hacking
Going off thread, I discovered the uJ project from those links, looks quite cool.
I wonder if you may consider emulating PowerPC NT as well?
Dang, I didn't realise NT for PowerPC can't be emulated. That's also a shame.
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.
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.
As of now there is only MIPS.
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..
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..
OMG brings to mind the competing tech: Processor Independent Netware that was to run on Intel, PPC, MIPS, Alpha, SPARC and PA-RISC. I'm lucky that clusterfuck didn't take years off my life and I apologize to my colleagues who had to spend so much time on it.
The Wikipedia Netware page laconically mentions all the architectures that it supposedly "ran" on but really it never shipped in production beyond the 368.
The Wikipedia Netware page laconically mentions all the architectures that it supposedly "ran" on but really it never shipped in production beyond the 368.
That's a product which seems to have dropped off the World Wide Web. I remember seeing a demonstration of it running on PowerPC at a trade show, but that's the only time I ever saw it running. Most webpages that mention it today just redirect to a definition of the word "pin". It's a bit of a shame -- it was a clever idea, but I think that Novell overestimated the desirability of Netware to corporate clients at that point in time.
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.
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.
If it required a remote kernel debugger to get things going why not add a quick screenshot of the assembly instead of saying there aren't "any identifiable marks for...64 bit build"? Identifiers are everywhere if you think outside the box.
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.