[HN Gopher] Windows 2000 64-bit for Alpha AXP
___________________________________________________________________
Windows 2000 64-bit for Alpha AXP
Author : zdw
Score : 82 points
Date : 2023-05-15 14:58 UTC (8 hours ago)
(HTM) web link (virtuallyfun.com)
(TXT) w3m dump (virtuallyfun.com)
| hef19898 wrote:
| One of my favorite Windows editions of all times! But I might
| confuse it with NT, it's been a while...
| tracker1 wrote:
| Yeah, been on a discussion thread recently, and really
| conflating and mixing up memories of NT4 and Win2k from around
| 1996-2002 or so.
| hef19898 wrote:
| I guess, I did like both so!
| bediger4000 wrote:
| 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.
| ch_123 wrote:
| 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
| krylon wrote:
| 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.
| chasil wrote:
| 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
| ch_123 wrote:
| 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
| gumby wrote:
| 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.
| retrac wrote:
| 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.
| cbm-vic-20 wrote:
| 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.
| drewg123 wrote:
| 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)
| inconceivable wrote:
| 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.
| justin66 wrote:
| 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?
| pjmlp wrote:
| 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.
| formerly_proven wrote:
| 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)
| mosburger wrote:
| 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
| trentnelson wrote:
| 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.
| davidgnz wrote:
| 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.
| krylon wrote:
| 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.
| bitwize wrote:
| Just imagine a Beowulf cluster of them, amirite?
| krylon wrote:
| At the time I was a Windows user who used his PC mainly
| for video games. Other than Minesweeper and Solitaire,
| the gaming situation on Windows for Alpha was probably
| not great.
| Maursault wrote:
| > 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.
| krylon wrote:
| Thanks!
| scruffyherder wrote:
| 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.
| icedchai wrote:
| 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...)
| toast0 wrote:
| 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.
| xxpor wrote:
| 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.
| toast0 wrote:
| 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?
| xxpor wrote:
| >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.
| aidenn0 wrote:
| > 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.
| meepmorp wrote:
| Don't forget forget AMD
| zdw wrote:
| 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.
| xxpor wrote:
| 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.
| nyanpasu64 wrote:
| 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.
| xxpor wrote:
| 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
| dblohm7 wrote:
| 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.
| sjsdaiuasgdia wrote:
| 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
| mikerg87 wrote:
| Not surprising given the commong father in Dave Cutler
|
| https://en.wikipedia.org/wiki/Dave_Cutler
| evanelias wrote:
| 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.
| fredoralive wrote:
| 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...
| bombcar wrote:
| 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.
| hulitu wrote:
| The thing that brought x86 to supremacy was Itanium and its
| suppresion of established CPU architectures: Alpha, MIPS, PA-
| RISC
| nikanj wrote:
| It's a hedge against Intel.
| [deleted]
| scruffyherder wrote:
| I think it's how they got Cutler to come over. And of course
| Cutler didn't come alone.
| tivert wrote:
| > 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.
| cowmix wrote:
| 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.
| pavlov wrote:
| AMD's x86-64 architecture was designed around 1999, but the
| first actual hardware was released in 2003 (the K8 Opteron).
| jasoneckert wrote:
| 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).
| OatmealDome wrote:
| 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.
| chungy wrote:
| 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.
| runjake wrote:
| 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
| causi wrote:
| 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.
| hulitu wrote:
| Because they saw Google and said: Hei, this is the future.
| ChuckNorris89 wrote:
| 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.
| gumby wrote:
| 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.
| darkhelmet wrote:
| I'm having flashbacks to some Alpha machines that were donated to
| FreeBSD.org in the early 2000s for an Alpha build cluster.
|
| 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.
| [deleted]
| failsecure wrote:
| 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.
| johnea wrote:
| [flagged]
| orra wrote:
| 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.
| dmitrygr wrote:
| Challenge accepted. I had been looking for my next emulation
| target
| scruffyherder wrote:
| 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/...
| orra wrote:
| 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...
___________________________________________________________________
(page generated 2023-05-15 23:02 UTC)