One of the most popular OS built-in games is no doubt Pinball, known by its full name 3D Pinball for Windows – Space Cadet. It started out as Full Tilt! Pinball, developed by Cinematronics and published by Maxis. It offered 3 tables, and one of them, Space Cadet, was licensed to Microsoft to be included in Microsoft Plus! 95 and, later, built into the Windows operating system.

Windows XP was the last version of Windows to include Pinball, and Raymond Chen explained why it didn’t make it to Windows Vista on his blog. The reason was it had a collision detector bug when it was compiled for 64-bit Windows, which caused the ball to pass through various objects – falling off the screen through the plunger instead of being launched, for instance. The bug rendered the game unplayable, and Raymond and his colleague were unable to find a fix in a reasonable amount of time, so he removed it. At least that’s the story we were told, for about a decade.

In 2021, NCommander launched a series of investigations to challenge that, testing Pinball on various 64-bit (IA-64 and AMD64) builds of Windows XP and pre-release Vista. He found that the 64-bit versions of Pinball were all highly playable, with only very minor glitches, and speculated that the reason for its removal was that the UI did not fit into the Windows Vista design.

Not long after NCommander published his video, Raymond followed up with a post that filled in some gaps in the story and shed more light on the bug. He said it was the 64-bit Alpha AXP version of Pinball that had the extremely bad collision detection bug. This claim had been unverifiable for the past 5 years, for the following reasons:

• No 64-bit Windows was ever released for the Alpha AXP – Compaq killed Windows NT support before NT was ported to 64-bit
• One 64-bit Alpha AXP NT build was leaked in 2023, but the included Pinball does not work, as it segfaults immediately upon running

I’ve had an interest in the DEC Alpha for quite some time now, mainly out of my love for DEC architectures and my love for UNIX. VAX is the direct successor of PDP-11, and Alpha is the direct successor of VAX. Earlier, some Alpha emulation breakthroughs dropped, and I was pinged by a few friends that NT 4.0 could now run on a fork of the ES40 emulator, as well as on QEMU. I never thought Alpha NT would ever run under emulation, because unlike the familiar Tru64, Linux and the BSDs, NT uses its own custom PALcode and depends on ARC (Advanced RISC Computing) instead of SRM. Of course, people noted that the emulators couldn’t run the holy grail of Alpha NT – Windows (XP?) build 2210, because its kernel would panic with a memory management error in QEMU, or wouldn’t detect the keyboard and bug out in ES40. A few trips to hell in the symbol-less NT kernel and a few MMU emulation fixes later, I was able to patch up both QEMU and ES40 to boot that only surviving 64-bit build of Alpha NT.

After torturing my brain debugging a symbol-less NT kernel without a kernel debugger, I thought I’d give fixing Pinball a go, to make things worthwhile. One of the benefits of debugging a userland process is that, while there’s still no debugger, there is Dr. Watson, which takes core dumps and performs simple post-mortems. Something is better than nothing, as people would say.

Running Pinball gives the classic crash symptom immediately, with no graphics drawn:

Dr. Watson concludes that it died of a segfault:

It gave a nice dump of registers at the time of the fault:

State Dump for Thread Id 0x124

  v0=01002930 00000000   t0=00000000 00360000   t1=00000000 00000001
  t2=00000000 00360000   t3=00000000 00000000   t4=00000000 00000000
  t5=00000000 0000011c   t6=000003ff fff8f868   t7=00000000 00303030
  s0=000003ff fff8fac0   s1=01002930 00000000   s2=000003ff fff8fad8
  s3=00000000 00000000   s4=00000000 0106f2a8   s5=00000000 01000000
  fp=00000000 00000010   a0=01002930 00000000   a1=00000000 00000000
  a2=000003ff fff8fad8   a3=00000000 30010000   a4=00000000 69e17610
  a5=00000000 69e0a360   t8=000003ff fff8f868   t9=00000000 00000000
 t10=00000000 00300000  t11=00000000 00000002   ra=00000000 69e9d5c0
 t12=00000000 6a264710   at=ffffffff fffffe10   gp=00000000 00000000
  sp=000003ff fff8fa50 zero=00000000 00000000 fpcr=08000000 00000000
SoftFpcr=00000000 00000000  fir=6a264710
 psr=00000003
mode=1 ie=1 irql=0 

Some disassembly around the faulting instruction:

function: Otsstrlen
FAULT ->00000000'6a264710: 2f700000 ldq_u t12,0(a0)
        00000000'6a264714: 239fffff lda at,-1(zero)
        00000000'6a264718: 4b90065c mskql at,a0,at
        00000000'6a26471c: 4600f000 and a0,#7,v0
        00000000'6a264720: 477c041b bis t12,at,t12
        00000000'6a264724: 43fb01fb cmpbge zero,t12,t12
        00000000'6a264728: 43e00520 subq zero,v0,v0
        00000000'6a26472c: f7600005 bne t12,00000000'6a264744 Otsstrlen+00000034
        00000000'6a264730: 2f700008 ldq_u t12,8(a0)
        00000000'6a264734: 42011410 addq a0,#8,a0
        00000000'6a264738: 40011400 addq v0,#8,v0
        00000000'6a26473c: 43fb01fb cmpbge zero,t12,t12

And a very useful stack backtrace:

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
000003FFFFF8FA50 0000000069E9D5BC 0100293000000000 0000000000000000 000003FFFFF8FAD8 0000000030010000 !Otsstrlen 
000003FFFFF8FA50 0000000069E9DB64 0100293000000000 0000000000000000 000003FFFFF8FAD8 0000000030010000 !PostThreadMessageA 
000003FFFFF8FA90 0000000069E9C000 0100293000000000 0000000000000000 000003FFFFF8FAD8 0000000030010000 !SetClassLongA 
000003FFFFF8FB80 000000000100F914 000003FFFFF8FC58 0000000000000000 000003FFFFF8FAD8 0000000030010000 !RegisterClassA 
000003FFFFF8FBF0 0000000001012A1C 0000000001000000 0000000001002DC8 000003FFFFF8FAD8 0000000030010000 !<nosymbols> 
000003FFFFF8FCA0 0000000001064B0C 0000000001000000 0000000001002DC8 000003FFFFF8FAD8 0000000030010000 !<nosymbols> 
000003FFFFF8FED0 0000000068948C50 0000000001000000 0000000001002DC8 000003FFFFF8FAD8 0000000030010000 !<nosymbols> 
000003FFFFF8FFC0 0000000000000000 0000000001064800 0000000001002DC8 000003FFFFF8FAD8 0000000030010000 !BaseProcessStart 

Ok, so it died inside RegisterClassA, a critical Win32 API function. That API function couldn’t have been the culprit, because if it were bugged, no GUI Win32 program would run at all. This means the only possible source of the error is its sole argument – a pointer to a WNDCLASSA struct. Needless to say, the pointer itself was valid, otherwise the API would’ve detected the invalid argument, or the segfault would’ve happened a lot sooner.

From the stack trace, the return address of RegisterClassA was 0x100F914, inside the function splash_screen. A quick disassembly of the instructions preceding that address shows a WNDCLASSA structure being built with the following layout:

00000000 u32 style         = 0
00000004 u64 lpfnWndProc   = splash_message_handler (0x100FE40)
0000000C u32 cbClsExtra    = 0
00000010 u32 cbWndExtra    = 8
00000014 u64 hInstance     = *0x106AE30
0000001C u64 hIcon         = NULL
00000024 u64 hCursor       = LoadCursorA(NULL, IDC_ARROW)
0000002C u64 hbrBackground = NULL
00000034 u64 lpszMenuName  = "" (0x1002710)
0000003C u64 lpszClassName = "3DPB_SPLASH_CLASS" (0x1002930)

Right off the bat, I noticed something wrong – the field alignment. It is a general requirement that fields be aligned to their size, as in 8-bit fields should be byte-aligned, 16-bit fields should be 16-bit (2-byte) aligned, 32-bit fields should be 32-bit (4-byte) aligned, and 64-bit fields should be 64-bit (8-byte) aligned. If you look at the offsets of the fields above, the 32-bit ones are indeed 4-byte aligned, but the 64-bit ones are not. At the start, we have a 32-bit style field followed by a 64-bit lpfnWndProc, and to satisfy the alignment requirements, a 4-byte padding should be inserted between style and lpfnWndProc to ensure that lpfnWndProc starts on an 8-byte boundary. RegisterClassA was expecting this padding, but Pinball lacked it, so it read data from the wrong offset and crashed.

To fix this, I simply bumped the offset of each field after style up by 4 bytes.

 00000000 u32 style         = 0
-00000004 u64 lpfnWndProc   = splash_message_handler (0x100FE40)
+00000008 u64 lpfnWndProc   = splash_message_handler (0x100FE40)
-0000000C u32 cbClsExtra    = 0
+00000010 u32 cbClsExtra    = 0
-00000010 u32 cbWndExtra    = 8
+00000014 u32 cbWndExtra    = 8
-00000014 u64 hInstance     = *0x106AE30
+00000018 u64 hInstance     = *0x106AE30
-0000001C u64 hIcon         = NULL
+00000020 u64 hIcon         = NULL
-00000024 u64 hCursor       = LoadCursorA(NULL, IDC_ARROW)
+00000028 u64 hCursor       = LoadCursorA(NULL, IDC_ARROW)
-0000002C u64 hbrBackground = NULL
+00000030 u64 hbrBackground = NULL
-00000034 u64 lpszMenuName  = "" (0x1002710)
+00000038 u64 lpszMenuName  = "" (0x1002710)
-0000003C u64 lpszClassName = "3DPB_SPLASH_CLASS" (0x1002930)
+00000040 u64 lpszClassName = "3DPB_SPLASH_CLASS" (0x1002930)

But that was not sufficient – Pinball calls RegisterClassA in 4 different places – Sound_Init, splash_screen, WinMain and WaveMixStartup. I’d already patched the one in splash_screen, so I started going through the rest one by one.

The ones in Sound_Init and WinMain were identical to the one in splash_screen, but for some strange reason the one in WaveMixStartup already had the correct alignment:

00000000 u32 style         = 0
00000004 u32 <unused>      = <undefined>
00000008 u64 lpfnWndProc   = WndProc (0x105CFA0)
00000010 u32 cbClsExtra    = 0
00000014 u32 cbWndExtra    = 0
00000018 u64 hInstance     = *0x106B818
00000020 u64 hIcon         = NULL
00000028 u64 hCursor       = LoadCursorA(NULL, IDC_ARROW)
00000030 u64 hbrBackground = GetStockObject(LTGRAY_BRUSH)
00000038 u64 lpszMenuName  = NULL
00000040 u64 lpszClassName = "WavMix32" (0x10050B0)

I can’t think of why the same struct would be aligned differently within the same binary, unless they came from different objects compiled with different flags or something.

Anyway, with the WNDCLASSA struct alignment fixed in 3 of the 4 places, I ran Pinball again. This time it created the fullscreen window and attempted to draw the splash screen before dying of another segfault:

Crash log shows that the segfault happened deep in the Win32 audio system, while calling auxSetVolume:

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
000003FFFFF8E9C0 0000000050306E84 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8E9E0 00000000503034B8 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8EA10 0000000050304B60 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8EA90 0000000050305B8C 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8EB20 000000000001AF78 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8EB60 0000000000025AFC 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !auxSetVolume 
000003FFFFF8EBD0 0000000000025F98 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !mixerSetControlDetails 
000003FFFFF8EC80 0000000000027214 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !mixerSetControlDetails 
000003FFFFF8ED30 0000000000030644 00000000FFE5D420 0000000000000000 000003FFFFE5D420 0000000000000000 !mciSendCommandW 
[...]
000003FFFFF8FC60 0000000001012AB4 0000000000000000 000003FFFFE5DE00 000003FFFFE5D420 0000000000000000 !CreateWindowExA 
000003FFFFF8FCA0 0000000001064B0C 0000000000000000 000003FFFFE5DE00 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8FED0 0000000068948C50 0000000000000000 000003FFFFE5DE00 000003FFFFE5D420 0000000000000000 !<nosymbols> 
000003FFFFF8FFC0 0000000000000000 0000000001064800 000003FFFFE5DE00 000003FFFFE5D420 0000000000000000 !BaseProcessStart

The fault happened while trying to dereference a pointer in the register a0 (r16):

function: <nosymbols>
        00000000'50305658: 00000000 halt
        00000000'5030565c: 00000000 halt
        00000000'50305660: 23deffe0 lda sp,-20(sp)
        00000000'50305664: b53e0000 stq s0,0(sp)
        00000000'50305668: b55e0008 stq s1,8(sp)
        00000000'5030566c: b57e0010 stq s2,10(sp)
        00000000'50305670: b75e0018 stq ra,18(sp)
        00000000'50305674: 47f00409 bis zero,a0,s0
        00000000'50305678: 47f1040a bis zero,a1,s1
        00000000'5030567c: 47ff040b bis zero,zero,s2
FAULT ->00000000'50305680: a2100128 ldl a0,128(a0)
        00000000'50305684: 20500001 lda t1,1(a0)
        00000000'50305688: e440001b beq t1,00000000'503056f8 00000000'503056f8
        00000000'5030568c: d35ff6f8 bsr ra,00000000'50303270 00000000'50303270
        00000000'50305690: e4000019 beq v0,00000000'503056f8 00000000'503056f8
        00000000'50305694: 47e00411 bis zero,v0,a1
        00000000'50305698: 454b0801 xor s1,s2,t0
        00000000'5030569c: e4200005 beq t0,00000000'503056b4 00000000'503056b4
        00000000'503056a0: a2090128 ldl a0,128(s0)
        00000000'503056a4: d35ff722 bsr ra,00000000'50303330 00000000'50303330
        00000000'503056a8: 4160300b addl s2,#1,s2
        00000000'503056ac: 47e00411 bis zero,v0,a1

The register dump shows the value of a0 at the time of the crash:

State Dump for Thread Id 0x150

  v0=000003ff ffe5de00   t0=00000000 00000000   t1=00000000 00000058
  t2=00000000 50306150   t3=00000000 0000015e   t4=00000000 00000001
  t5=00000000 00000001   t6=00000000 50300000   t7=00000000 00ed39fb
  s0=00000000 ffe5d420   s1=00000000 00000000   s2=00000000 00000000
  s3=00000000 00000000   s4=00000000 00000001   s5=00000000 50305a10
  fp=00000000 000123b8   a0=00000000 ffe5d420   a1=00000000 00000000
  a2=000003ff ffe5d420   a3=00000000 00000000   a4=00000000 00000000
  a5=00000000 cc5a4dbc   t8=00000001 00000000   t9=00000000 00000612
 t10=d1b71758 e219652c  t11=00000000 00000612   ra=00000000 50306e88
 t12=00000000 00000000   at=00000000 00010000   gp=00000000 00000000
  sp=000003ff fff8e9c0 zero=00000000 00000000 fpcr=89000000 00000000
SoftFpcr=00000000 00000000  fir=50305680
 psr=00000003
mode=1 ie=1 irql=0 

Indeed, it was an invalid pointer! As you can see, it’s identical to the pointer in a2, but with the entire top 32 bits zeroed. It must’ve been truncated by a bug somewhere, either in the audio subsystem or in Pinball itself.

I spent some time and pinned down the DLL responsible for the fault – mciseq.dll, and did some tracing. The truncation of a0 happened when a2 was moved into a0:

50306150    ZAPNOT  a2,#15,a0

ZAPNOT is an interesting instruction – it takes a source register, a bitmask and a destination register, and it “zaps” (zeros) the bytes whose corresponding bit in the bitmask is 0. In this case, the bitmask is 15, which is 00001111 in binary. From this we can work out that the ZAPNOT instruction at 0x50306150 zeros the upper 4 bytes of a2, when it is copied into a0. This perfectly explains why, at the time of the fault, a0 contained a truncated version of the pointer in a2.

Of course, 0x50306150 was not the only place where it truncated 64-bit pointers, I found 6 truncations of the exact same type in mciseq.dll. I have not the slightest clue why it decided to truncate pointers. If I had to guess, maybe they had pointer → integer → pointer casts for whatever reason, and that integer type was 32-bit. With all 6 truncations patched out, we have some Pinball for ourselves:

Here’s proof that Pinball is indeed running on a 64-bit build of Alpha NT:

To make Pinball work on your NT build 2210 install, replace %ProgramFiles%\Windows NT\Pinball\pinball.exe and %windir%\system32\mciseq.dll with the following:

• Patched pinball.exe
• Patched mciseq.dll

You could also patch the installation files and burn them to a new CD if you want Pinball to work out of the box on fresh installs – simply copy these files to the AXP64 directory of the install disc:

• Patched PINBALL.EX_
• Patched MCISEQ.DL_

The Bug

Now I’m going to disappoint you with the fact that I did not find the collision detector bug Raymond talked about. With the struct alignment and pointer truncation issues patched, the game now works flawlessly. Ok, I’m not sure if it’s actually flawless, but I never saw any glitches in the few games I played. At the very least, the ball does not fall through the plunger, can be launched and bounces around the table just fine.

Below are the 2 reasons I could think of for not seeing the collision detector bug:

• The bug was introduced after build 2210. Build 2210 has Pinball installed by default and predates Windows XP by almost a year and a half, so it almost certainly predates Raymond removing it. In this build, Pinball doesn’t even run by default, so there’s no way they could’ve tested it and seen the bug. They probably only started testing Pinball later, after they fixed the struct alignment and pointer truncation issues.
• The bug only manifests in free/release builds, not in checked/debug builds. Maybe it only shows up when the code is compiled with the more aggressive optimisation used by release builds – something that happens quite often when code has undefined behaviour or the compiler has bugs. This is less plausible, however, as I’m sure Raymond would’ve used debug builds when he attempted to debug it, and discovered any differences between debug and retail builds.

Of course, only Raymond himself could shed more light on this topic. It was fun (read: painful) debugging Pinball, as well as the NT kernel to fix the emulators – too much fun (read: pain) that I will never do it again.

Some trivia about me and pinball:

I spent a fair chunk of my kindergarten and pre-school days playing the various games my dad installed on our Windows XP home computer, however, there was one game that I never quite figured out how to play – Pinball. It came bundled with the OS, and the splash screen scared me every time I tried to open it up.

The flipper looked like a pistol to my 3-year-old self, and the overall darkness of the splash screen just injected fear into me. I would open the game, close my eyes, count to 20, then open my eyes again, to skip past the splash screen.

The first time I actually played a full game of pinball was on the first day of this year, when a friend of mine took me to an arcade. After playing pinball in real life, the Pinball game finally started to make sense.

First up, you need the ‘v73.iso’ and not much else. VGA is fun to make it all graphical. First look for your CD-ROM drive, the RRD42 in this case, I’ve put mine on SCSI id 6, so it’s the DKA600

So, it’s a simple ‘boot dka600’ to get the process started

It’ll take a few seconds to boot up to the menu

hit control+c and you’ll get the menu

It’ll detect our machine, so you can hit enter to boot the default option

This will take a hot minute as the SRM likes to re-load itself between things

Now I know you think we would just go ahead and hit update, but oddly enough it won’t program the TIG, so we exit from here:

and choose the manual update process

And now we can run the update.

Basically we update them all!

And keep going. For all us Windows NT on Alpha fans, the ABIOS has to be programmed in. It’s a compressed image, so the machine will still boot SRM then we have to load ARC. It’s just the way the ES40 is.

This will take a few minutes, just hang in there.

rmc always fails for me but it’s fine.

at this point we can exit, and we’ve programmed our flash.

The emulator will reboot, and we will be sent back to the SRM prompt.

For those of us who want to run Windows NT we can now edit the NVRAM so it always auto-starts ARC, so it doesn’t require manual intervention.

simply type in:

edit nvram
10 show dev
20 arc

Then you can exit this mode with a Control+Z (some machines/emulators require Alt+Z)

now it’ll show the devices and auto-start arc.

You can test-drive ARC now by simply typing in ‘arc’

And this will load up ARC.

You’ll see the VGA bios re-initialized, and then the boot logo

as of yet, the memory test wipes out the video ram so it’ll blank the screen. this is normal.

Hit the space bar to exit the memory test

Then press F2 to enter setup. This will take a minute or so.

it really does take a few minutes the first time.

Because the nvram is fresh it’ll reboot. so hit space again to skip the memory test and f2 to enter setup

arrow key down to the CMOS setup

and F6 to enter advanced setup

In the advanced menu, hit tab to advance to a selection and arrow keys to change them

And then Press F10 to save the changes.

Now we’ve fully programmed the flash and set ARC to autoboot!

It appears that up until just now we did not have archived copy of MS Word 6.0 for PPC. There were copies floating for Alpha and MIPS, for example https://archive.org/details/ms-word60-nt. However PPC version was nowhere to be found…

Until Term24 pointed me to this eBay auction:

Since it clearly said PowerPC on the box I got it… and here it is:

Now thanks to Rairii you can enjoy it on a PowerMac or WII!

Download ISO or RAR

This is a guest post by CaptainWillStarblazer

Hello, everyone. This is a continuation of my previous blogpost on EmuWoW (formerly win32emu) found here, but to summarize, I’m the 18-year-old developer behind a project that allows running applications compiled for the MIPS/Alpha version of Windows NT on standard x86 PCs through emulation, but without requiring a full system emulator. Since that last post, the project has made some substantial strides.

Since then, I’ve adapted the MIPS emulator from MAME, which is both more accurate and faster than my own (writing my own was a fun exercise but to the end of running applications, borrowing an emulator was a better decision). This alone enabled WinMine to function, which can be seen below.

Around the same time, another VirtuallyFun member named x86matthew entered the scene. His prior credits include a similar project, for Win16. He was inspired by the initial win32emu blog post, created his own similar project called WoWMIPS, which quickly started running a few simple apps, such as WinMine, Solitaire, and Notepad. Be sure to check out WoWMIPS – MIPS Emulator for Windows, Part 1: Introduction, and parts 2,3,4,5,6!

This had actually been what I was hoping for from the beginning; I always saw win32emu as a proof of concept for a smarter person (either myself in the future or someone else altogether) to come back later and do it better, and this is a massive undertaking for a single individual. What makes x86matthew’s WoWMIPS so incredible is its clean design. For one, there’s no thunk DLLs required. When an application tries to import a DLL, the host x86 DLL is first loaded, and then any attempts to get the address of an exported procedure from it are then redirected to an auto-generated stub of MIPS code which invokes the emulator to call the function. In other words, the thunk DLLs are generated at load time. Additionally, there’s no window procedure thunks required either. Instead, MIPS code pages are marked as non-executable, causing an access violation when Windows attempts to call them. Using an exception handler implemented via Windows XP’s Vectored Exception Handling feature, one can detect this and then invoke the emulator to execute the callback. Storing the CPU state in thread-local-storage allowed proper support for multithreading. I duplicated these design choices into EmuWoW, and the results largely speak for themselves. Unlike WoWMIPS (at time of writing), EmuWoW is still capable of loading MIPS DLLs (and will prefer to do so if possible), however.

To aid the process of fixing faults in the emulator, I hacked up a quick, minimal debugger into EmuWoW. First of all, there’s a “crash screen” which will indicate the type of error and dump registers and the current instruction if there’s a fault, and a running disassembly can be printed as you go, but most crucially, there’s a limited degree of interactive debugging functionality.

The main capabilities contained herein are dumping registers and memory to the screen, disassembling regions of memory, listing loaded modules, getting import entry points, setting breakpoints, and single-stepping, along with printing functions. It’s no gdb (especially for the lack of PDB symbol support), but it’s something.

MIPS is all well and good, however, but we can already emulate Windows NT for MIPS. MIPS is a fairly clean, simple architecture, often used for teaching, and short of weirdness like delay slots, is dead simple to emulate. And it fits the bill for what I’m trying to do here – a RISC architecture Microsoft abandoned, fixed-length 32-bit instructions, the works. However, adding support for the DEC Alpha AXP will finally get this project to where it was intended to be from the beginning, and I hope for it to eventually be able to run the Visual C++ compiler toolchain under EmuWoW. Being able to compile (and even test!) Alpha apps on readily available modern PCs will be a game-changer, and I intentionally wrote EmuWoW to be CPU-agnostic, so adding rudimentary support for the Alpha wasn’t difficult. Like with MIPS, I lifted the emulator from MAME. This admittedly did pose some challenges, due to MAME’s use of C++ features such as

• Classes (which I had to substitute for passing pointers to structs)
• Templates (which I had to substitute for macros)
• Function-style casts (which I had to change into C-style casts)

There was a lot of weirdness in how Alpha function calls, but it was my misunderstanding of the calling convention, and when to consider values to be 32-bit vs 64-bit posed a modest issue, but I got it to the point where some very simple DEC Alpha programs started to run, though many of them have various issues.

This is the first time this has ever been possible; emulation of AXP NT programs on standard PCs has just become possible now. I’m hoping to see EmuWoW continue to evolve, and I welcome contributions, whether that be improving support for the CPUs I already have, adding support for another (such as PowerPC) or anything else. To take a look at the code, go to github.com/bhty/emuwow and to download EmuWoW and try it out for yourself, click here.

I like exploring vintage hypervisors and emulators. In the past I did a whole series on Merge, VP/IX and others. This time I wanted to take look at something a little more exotic – SoftWindows on Alpha OpenVMS. I have in fact installed it a while back but I could never get it properly licensed. I looked everywhere, asked everyone and of course no one had a license pack for this. Fortunately there are two license generators for OpenVMS, pakgen and lmfgen. But how do you find out what is the exact product code and vendor? VMS provides a license debug facility:

$ reply/enable=license
$ define/sys/exec lmf$display_opcom_message true

Then, when starting an app, you will get an opcom log message with all the required product name, vendor, etc. The rest is easy. For the lazy, here is a complete license pack for SoftWindows:

$ LICENSE REGISTER SOFTPC -
        /ISSUER=DEC -
        /PRODUCER=DEC -
        /UNITS=0 -
        /OPTIONS=(MOD_UNITS,ALPHA) -
        /CHECKSUM=2-GNHM-DAFO-CPGG-AICI
$ LICENSE LOAD SOFTPC

Here is a screenshot for your viewing pleasure!

The install comes with it’s own version of Windows 3.1 plus some additional tools and apps, typical for Insignia products. You can map drives to folders, ports COM and LPT, etc. There are a variety of video modes – Hercules, CGA, EGA and VGA, even 256 colors. The performance is quite decent, however the CPU is pegged at 100%, as you can see in the system monitor. There is a CPU idle detection tool, however it doesn’t seem to work very well. I suspect that perhaps this may be to do with much never OpenVMS version, than the software has been designed for. The SoftWindows has been released in 1994 and not been updated since.

How do you install and run this thing? There is a full installation guide, however since this is just a PCSI file, you can simply use product install:

$ unzip softwin-v0100.zip
$ product install *

To start it you cast these magic spells:

$ @sys$sysroot:[sysmgr]softwin$startup.com
$ softwin

Since SoftWindows is essentially SoftPC you can run pure DOS mode. I will do a follow up on this and explore some DOS games.

You can find all the files on osarchive.org.

From a hindsight, it’s ironic how roles have reversed in 30 years. Back then MS-DOS / Windows was a toy OS, running on a toy “personal” computer, emulated in a little window on a “real” computer like DEC Alpha. In modern times you run OpenVMS as a guest VM on a Windows PC.

Have fun with virtualization!

As I was preparing the Windows NT RISC exhibit for VCF west, I realized that I’m missing a rather important piece of the history. While I was showing the potentially last DEC Alpha Windows build ever – AXP64 2210, I don’t have anything earlier than NT 3.51. It would be nice to showcase the very first RTM version – NT 3.1 on a RISC platform.

From time perspective, NT didn’t get popular until 3.5 and later. Windows NT 3.1 would be considered rare even on a 386, let alone on a RISC machine! So what hardware does Windows NT 3.1 run on?

Quite a limited list! The HCL published on gunkies has a few more systems, but nothing that I would have. The early MIPS based systems are all but unobtanium as of today. This is probably a good time to mention a little known port of Windows NT 3.1 to the DECstation 5000. However these builds have not surfaced anywhere, so no help.

The Alphas were looking a little more reachable. The DEC 2000 Model 300 and DECpc AXP 150 are one and the same machine, packaged in a server and workstation cases. Code-named Jensen, DEC designed and marketed these specifically around Windows NT. Unlike prior Alphas, this model used a lot of “PC” components for increased compatibility and lower cost. Eventually paved way for the more well known DEC Multia. The Jensen has been seen floating here and there and many people have these.

I was able to get a loaner from Chris Satterfield aka Compgeke and I was set for the VCF. However, having a working specimen at hand, I started looking at part numbers of various components. In an amazing streak of luck, in practically zero time I was able to find, buy and assemble a complete DECpc AXP 150 from spare parts on eBay! Without a case, but nevertheless. Also big thanks to Christopher Rivett for help with some fine details!

BOM

• Motherboard + CPU – DEC 70-29685-01
• GPU – DEC/Compaq Qvision 1024/E (1024×768) – 126654-001
• GPU – (Optional) Number 9 High Res (1280×1024) – 30-41800-01
• HBA – Adaptec AHA-1742A EISA – 467806-00
• NIC – DEC DE422-S EISA – 5021102-01
• RAM – 4x 16MB, FPM, 60ns, 72-Pin, 12-Chip, True Parity SIMM
• PSU – DEC/HP 30-37197-02, however a standard AT PSU may be OK

If you going to build one yourself, beware of overheating. Jensen runs rather hot and needs good cooling. Not only for the CPU. There is a section of the motherboard just under the EISA cards that runs incredibly hot. See the picture, where I have installed a large Noctua fan.

OS Install

There are many Windows NT 3.1 CDROMs floating around. I purchased a DEC branded, shrink-wrapped CD on eBay to use as a prop along with the machine. You can download the iso image here.

Installation of Windows NT 3.1 on DECpc AXP 150 is pretty straightforward and not that much different from the later versions. However as a prerequisite you will need the ECU floppy disk to configure the EISA slot assignments, card and jumper settings. After that you will have to go through various setup screens in ARC BIOS to configure system settings. Then you run arcinst to create a system partition and setupldr to install the OS. The rest of it is pretty uneventful. This is somewhat expected, as this was pretty much the only one and supported hardware combination, so must have been well tested. The only curious part is that the NT OS Kernel does not display any messages in text mode. Later versions of NT will display the build number and MP or UP kernel variant and dots indicating subsystem load progress. This is rather odd because I expected more char mode stuff from earlier NT version, but who knows.

Service Pack Saga

If you are even vaguely familiar with installing Windows NT at all, you will know that the very first thing you have to perform after installation, is to apply a service pack. NT 3.1 did have service packs, up to SP3. The problem was that, as you may expect, RISC editions were nowhere to be found in 2023. The only thing I could come up with was http://www.win31.de/ent31.htm, which at the time had a German AXP and MIPS SP3, but no English! [It since has been updated…]. I had to do some real detective work to track down an US-English AXP SP3 version. I spent a few days going through various random CDs and ftp site mirrors of that era, with little luck. Eventually I stumbled on this README file, stating:

Due to space constraints on the Windows NT Service Packs for
International Versions CD, the USA Service Pack version 3 is located on
the Additional Windows NT Service Packs, Windows 3.11 versions, SDKs,
and DDKs CD in the NTSRVPC3\USA directory.

Bingo! After a few hits and missed I spotted this particular CDROM here: https://archive.org/details/microsoft-developer-network-january-1995-disc-4-of-15 – Now the OS is finally “servicepacked”

Applications!

OS by itself without apps is not much. While overall Alpha NT application outlook is pretty scanty I was able to find a several very interesting gems!

Most importantly, thanks to Chris, a DEC Windows NT Developers CD-ROM!

The disk has an incredible amount of demo, freeware, public domain and shareware applications as well as DEC marketing material.

You can get a lot of DEC proprietary software like C++, Fortran, PATHWORKS, DECtalk, as well as X servers, etc.

However I was particularly interested in some 3rd party commercial apps.

For example there is an early version of DMC Calamus Desktop Publishing.

Also a demo version of a vintage, text-mode SlickEdit, way before it was replaced by the Visual SlickEdit known today.

There also is WinDev editior, which is quite superior to Notepad and has some code editing goodies and shortcuts to SDK tools, making it something of a simple IDE.

Another big source is Windows NT Application Sampler CDROM, (also from Smithsonian).

One of the coolest thing found there is a GUI text editor called WinEdit. It has a ton of features including syntax highlighting! It has since became my default to go editor / IDE on this system!

There of course is a Windows NT SDK with the M (MEP) editor.

There also are quite few public domain apps and games, ports of GNU software, Micro Emacs, Kermit, etc.

Update: CICA NT Shareware Collection has some interesting apps under the /alpha directory.

High Resolution GPU

One of things that was troubling me for some time was rather low resolution of the default QVision graphics card. The maximum being only 1024×768 is just not acceptable. Talking to several Jensen’s owners, no one even heard about anything better. However looking at the Windows setup options, I curiously noticed that the system does support one 1280×1024 video card – Number 9 GXE.

I assumed that such card would simply be unobtanium in 2023. However, digging through some old catalogs and spare part listings, I managed to find a DEC part number, which is 30-41800-01. Armed with this, I was able to find it via DEC spare part reseller that I often use. They had it in stock listed as “HIGH RES EISA 1280 x 1024 GRAPHICS”. The price wasn’t too bad either. A few days later I received this:

After installation of the S3 driver (must be the Service Pack 3 version!) I was finally able to get 1280×1024 from the poor thing!

With this I should have a more cozy environment to compile and port even more apps

In future I want to try the Advanced Server edition as well as some early Betas with Alpha support. To be continued…

I hosted a Porting Party last where where I setup my Dec Alpha as a terminal server allowing people from all over the world to connect in and cross compile software for the 64bit version of Windows for the Dec Alpha. While many problems were overcome, and many more remain, I have to say the most annoying thing was joining a domain hosted by a SAMBA server.

In my mind, I though the easiest way to get files in & out of the Alpha was not to use something like IIS/FTP where it would probably lead to end-less issues with text/binary/active/passive modes, but rather I should rent a VPS, install the OS default SAMBA and just map drives. The benefit of the VPS is that it has a public address, so no NAT is required. The VPS had an option for either CentOS (no) or Debian 10. I went with the Debian, and did an in place upgrade to 11, then 12. Nothing special.

I’d never actually used SAMBA as a domain controller before, but I thought this would be a fun experiment. So the idea is then that the VPS running SAMBA is the Domain Controller, and my Alpha joins it as a member server. Everyone else can use Windows or any SAMBA client and map drives, and then copy files to the VPS, and then copy back and forth from the Alpha to the VPS. This part worked fine.

What didn’t work was SAMBA version 4.

I had come up with this config, based on the fragments of the default config, and and hints from samba.org.

[global]
    netbios name = PDC
    passdb backend = tdbsam
    server max protocol = NT1
    username map = /usr/local/samba/etc/username.map
    workgroup = ALPHAPARTY
    server string = Samba Server
    security = user
    hosts allow = 127.0.0.1, <<<peoples networks...>>>
    load printers = yes
    log file = /usr/local/samba/var/log.%m
    max log size = 50
    passdb backend = tdbsam
    local master = yes
    os level = 33
    domain master = yes
    preferred master = yes
    domain logons = yes
    wins support = yes
    dns proxy = no
    add user script = /usr/sbin/useradd %u
    add group script = /usr/sbin/groupadd %g
    add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/null -s /bin/false %u
    delete user script = /usr/sbin/userdel %u
    delete user from group script = /usr/sbin/deluser %u %g
    delete group script = /usr/sbin/groupdel %g
[homes]
    comment = Home Directories
    browseable = no
    writable = yes
[printers]
    comment = All Printers
    path = /usr/spool/samba
    browseable = no
    guest ok = no
    writable = no
    printable = yes
[public]
    comment = share for everyone
    path = /public
    public = yes
    writable = yes
    printable = no
    creaet mask = 0777

I had endless issues with the machine account not being either created correctly or not being authenticated. I tried manually creating it, to no avail. No matter what I tried it didn’t work.

Working with NT 4.0 must be depreciated or something but no matter what I tried IT JUST DIDN’T WORK.

Feeling outraged, I purged the old Samba, downloaded the source code to 3.6.25, built that, and using the same configuration I had tried to put together, it just worked.

Adding users was somewhat straight forward:

useradd -M -s /bin/bash neozeed
passwd neozeed
/usr/local/samba/bin/smbpasswd -a neozeed
/usr/local/samba/bin/smbpasswd -e neozeed
mkdir /home/neozeed
chown neozeed /home/neozeed/

Creating both a Linux user & directory, and the SAMBA credentials. On the terminal server, all that remains was assigning a local home directory & profile directories, as you really don’t want those over the WAN.

I have no idea if this is a warning to others, or whatever the larger issue is.

Porting Party II

At any rate I’ll be running another porting party this coming weekend. I can host cross compiling fine, but we need people with the 64bit Whistler beta installed to test. The best way to get details is over on discord. Lately the IRC bridge is down more than it’s up, and I can’t effectively send out passwords & get your network block to allow access to the RDP, since I’m not going to open up worldwide access to a Windows NT 4.0 SP5 machine.

So for anyone interested in porting their C/C++ to either the 32bit Alpha Windows, or 64bit Alpha Windows come join us on discord!

I’ll fire up the Alpha on Friday afternoon GMT and expect the event to run all weekend!

Introduction

Unfortunately, during this amazing period, the Dec Alpha I had acquired specifically for this research had died. However, I was able to find an amazing group of people to not only go through with this research but take it upon themselves to provide an amazing working ISO image release! Needless to say, this is beyond my knowledge, and this is obviously a guest post

Background

In ~1997, Microsoft started work on a project dedicated to porting Windows NT to use 64-bit addressing on 64-bit machines. Before this, Windows NT used the 32-bit mode or ABI of 64-bit machines. This effort was internally referred to as “Sundown”, otherwise referred to as “Win64”. The ports consisted of not only to the Itanium/IA-64 architecture (which later shipped as Windows XP 64-Bit Edition) but also to the 64-bit DEC Alpha architecture.

Compaq dropped support for Windows on Alpha in mid-1999, and Microsoft stopped the development of 32-bit Windows NT for Alpha soon afterwards, with Windows 2000 build 2128 (RC2) being the last build. Due to a lack of physical IA-64 hardware and the slowness of the simulator, Microsoft continued to work on the AXP64 port of Windows till mid-2000, to help fix general issues related to 64-bit addressing. You can read more about this project here.

In May 2023, a disk image containing an installation of an AXP64 build of Windows XP (Whistler) build 2210 was discovered by a guest reader of this site, and a team (amarioguy, neozeed, pivotman319, starfrost and Tenox) was later assembled to help make this release possible.

Why Repack To ISO

When I saw the news about this build, I asked my friends why didn’t neozeed or Tenox share the full disk image, they told me that the disk image contained PII (Personally Identifiable Data) and neeozeed would like to have them removed first. I have some experience with cleaning up Windows builds, so I joined their Discord server and offered to help, then I got sent a full sector dump of that disk. I scanned the build 2210 partition with a file recovery tool that I stole from a data recovery shop when I worked there, and to my amazement, quite a few files in the deleted \$WIN_NT.~LS directory (a place for holding temporary setup files) survived (more importantly, setupdd.sys, txtsetup.sif, setupldr and the hiv*.inf files). Since all the files required for a clean install from ISO/CD are there, this build can be repacked into an ISO which is guaranteed to contain no personal information!

Recovery

The first thing I did was I recovered all of the files in the deleted \$WIN_NT.~LS directory, but since the integrity of files recovered from NTFS and FAT partitions cannot be guaranteed, I checked every single one of them. Most of those files were Microsoft Cabinet (CAB) archives, so I wrote a tool called CabChk to verify that 1) they are valid CAB archives, 2) there is only one file per archive, 3) the name of the compressed file is the same as the name of the archive and 4) the compressed file extracts fine. This helped me to verify most of those 4600 files, but I had to verify the remaining 300 or so files by hand because they’re not CAB archives and that task alone took days to complete. After verifying all the recovered files, it turned out that 85% of them survived while the remaining 15% didn’t.

Repacking

A lot of those overwritten files are actually in the Windows directory (NT64) of that 2210 install, so I copied them out and recompressed the appropriate ones. I set my computer to the time zone Microsoft used and compressed them with the Cabinet Tool (CABARC) parameters Microsoft used. Microsoft used UTC-8 and the following CABARC parameters:

CABARC -m LZX:21 N [output_cab] [input_file]

After repacking and copying over the files, the number of missing files went from about 650 all the way down to roughly 30 :).

Missing User Mode Setup Stub

Unfortunately, usetup.exe was one of those 30 or so files. It doesn’t do much as it’s a stub, but nonetheless without it, text mode setup won’t start. My original idea was to decompile I386 build 2211’s usetup.exe (as it has only about 20 functions) and recompile it for AXP64 with the toolchain discovered earlier on, but I had to wait for someone to cross compile it on an Alpha for me. While I was waiting, I searched that partition for substrings in the I386 usetup.exe and I got a match!

It’s compressed, but since LZNT1 is a simple and weak-ish compression algorithm, you can sort of recognise the original data. I cobbled together an LZNT1 decompressor and decompressed that 32 KiB chunk, and indeed it’s the AXP64 usetup.exe!

E:\Projects\LZNTTool>LZNTTool -d "E:\Whistler 2210 AXP64 Recovery\usetup_compressed_0.bin" "E:\Whistler 2210 AXP64 Recovery\usetup_0.bin"
Decompression successful.

E:\Projects\LZNTTool>wsl hexdump -C -v -s 0x600 -n 0x200 "../../Whistler 2210 AXP64 Recovery/usetup_0.bin"

I then searched for strings expected to be in the second 32 KiB chunk and then the third chunk and so on, until I got all of them recovered. After decompressing all of the 5 chunks, I concatenated them together into one single executable and yay, we now have the original AXP64 usetup.exe!

E:\Projects\PEChkSum>PEChkSum "E:\Whistler 2210 AXP64 Recovery\usetup.exe"
Expected checksum is: 0x00035E4E
Actual checksum is: 0x00035E4E

"E:\Whistler 2210 AXP64 Recovery\usetup.exe" is valid.

Broken Driver Cabinet

pivotman319 pointed out to me that some files in driver.cab were dead, and indeed, Setup did not work with that broken cabinet:

There were 2 copies of driver.cab on that disk, sadly the deleted one in $WIN_NT.~LS got overwritten and the one in \NT64\Driver Cache\axp64… well, 68 errors :

Looking at the broken files, I noticed a pattern – all of them came from 3 blocks – 5, 36 and 37. What on Earth are “blocks”? Well, let’s talk about how CAB archives work first.

Files in CAB archives are stored in blocks, where each block stores 1 or more files. When files are added to a CAB archive, they are all concatenated together into one big file. The concatenated big file is then split into multiple sub-blocks (with default size of 0x8000 bytes) and each of them gets compressed and then concatenated together to form the compressed block. So, for small corruptions (bit-rots and etc.), theoretically only 0x8000 bytes are lost and the rest should still be recoverable, but tools like 7-Zip will refuse to extract anything beyond the point of corruption.

Now looking at the corruption in driver.cab, 2 of the 3 blocks can be fully recovered because we have all of those files in uncompressed form. Block 5 contains mostly printer-related files that are arch- and build-independent, so they can all be borrowed from build 2211 i386. Block 37 has only 1 broken file (win32k.sys) which exists on the hard drive (in system32). To fix these blocks, I simply took the uncompressed files, compressed them and replaced the broken blocks with the newly created ones.

And after fixing block 37:

I then ran my CabScan tool on the fixed CAB and as expected, there is only one bad sub-block left:

E:\Projects\CabScan>CabScan "E:\Whistler 2210 AXP64 Recovery\driver (fix).cab"
Offset 0x0253FD75:
    Expected checksum is 0x568C0AC3
    Checksum is 0x1CEBB9DE
    Original size is 0x00008000
    Compressed size is 0x00003862

Detected 1 bad sub-block(s) in 1 bad block(s).

So, what can we say about the corruption?

1. Size: 4 bytes
2. Location: Last 4 bytes of a 0x2000 section
3. Pattern: Starts with 00 F0 (possibly the result of a buggy NTFS driver)

Knowing these, I immediately located the 4 corrupted bytes in block 36:

So how did I recover those 4 bytes, did I brute force them? Nope, I used the checksum to calculate them! Here is the checksum algorithm Microsoft used for CAB archives:

And as you can see, it’s very simple, so it took me almost no time to work out the 4 missing bytes (4A ED 16 71) from the checksum 0x568C0AC3! With block 36 fixed, as expected, all files are now good!

Buggy Setup Loader

I thought I got everything necessary recovered and fixed, so I packaged up the files and sent them to G-Nug85 to test… and it didn’t work:

It failed to find A321064.PAL in the [SourceDisksFiles] section of txtsetup.sif. Well, this is an AXP64 build and A321064.PAL is a 32-bit PALcode image… why would it be there? Needless to say, copying that file to the disc image didn’t help. I have literally spent days on this stupid issue and who would have expected this:

E:\Whistler 2210 AXP64 Recovery>wsl strings -t x SETUPLDR | wsl grep -i '.pal'
  91f68 A321064.PAL

The culprit of the problem was they hard coded the name “A321064.PAL”… in the setup loader executable… how stupid!

We can tell from this that Microsoft has never made ISOs or discs for AXP64 builds, otherwise they would’ve found and fixed this bug. Well, maybe they did eventually try installing AXP64 builds from disc, because it’s fixed by the time of Windows XP SP1, but that’s long after this build:

#if defined(_AXP64_)
        SlGetDisk("a121165.p64");
#else
        SlGetDisk("A321064.PAL");
#endif

Oh well, I replaced the hard coded “A321064.PAL” with “a121165.p64” and what do you know, it’s working!

Finishing Touches

That install went smoothly, but one error did pop up during second stage setup:

A missing driver – big deal, hey? We actually have the build 2209 AXP64 version of this driver, so I injected it to the ISO and Setup happily accepted it.

I’ve also copied the Arc Installation Program (ARCINST) from Windows 2000 build 2128 AXP32 to the AXP64 directory of the ISO, because it is required for disk partitioning if you don’t have AlphaBIOS (and yes, it works because it’s not a Windows executable).

Supported Machines

Microsoft compiled several HALs for this build, but not all of them are listed in txtsetup.sif, the following machines are supported by default:

• Digital Personal Workstation A-Series
• Digital AlphaServer 4×00 5/xxx Family
• Digital AlphaServer/AlphaStation 1200 5/xxx Family
• Digital Alpha 21264/Tsunami Uniprocessor
• Digital Alpha 21264/Tsunami Multiprocessor

The following machines may be supported if you replace textsetup.sif with a modified version:

• Digital Alpha EB164
• Digital Alpha PC164SX
• Digital Alpha XL 300/366 Family
• Digital AlphaPC 164LX
• Digital AlphaServer 1000 5/xxx Family
• Digital AlphaServer 1000a 5/xxx Family
• AlphaServer 800 5/xxx (Corelle)
• AlphaStation 600A 5/500 (Alcor Primo)

We have only tested this build on the Digital Personal Workstation A-Series, AlphaServer DS10 and the AlphaServer 800, so there is no guarantee that the other HALs work (though they should).

Also, since this is a checked build, it does run slower than a retail build, and by default it will expect you to have a kernel debugger attached. Be sure to add the /NODEBUG flag to the bootloader to improve performance. I had noticed the SDL spite test demo going from 60fps to 70fps on my Alpha Personal Workstation 500a before it had died.

For Preservation

As I have said earlier on, Microsoft has never made ISOs/discs for AXP64 builds, so please don’t preserve the ISO file (eg: don’t upload it to BetaArchive). I know BA prefer ISOs over folder dumps, so let me tell you this mrpijey, the ISO is a franken-build with a patched Setup Loader and files from 2128, 2209 and 2211. We have a folder dump of the original files from the \NTDev network share with original high-precision timestamps just for preservation, so please for the sake of preservation, use this. Also don’t even think about creating an ISO out of the folder dump, you’ll end up with a non-existent thing that doesn’t work.

Download

ISO for Installation: https://mega.nz/file/q5AhhDJR#MsLYxxvmAdYDQ101fUHoGyzJ5Pk0EFsc2xdYH1p9qxQ
Whistler 2210 axp64 installable

Folder Dump for Preservation: https://mega.nz/file/r5gE3RxQ#4VfviMdQo44wJZT0df0cw8o4kE30lvSQKBZklma0mtg

Modified TXTSETUP.SIF For Other Machines: https://mega.nz/file/zsBVAJDD#5oQVM6U2AwseTJ54lOmN1E7BHTDFuwOuWdZOykmXP8E

Special Thanks

• to the person who sent us the disk image
• to Microsoft for not wiping that disk before throwing it away
• to pivotman319 for verifying recovered files and finding missing files
• to Tenox for testing
• to G-Nug85 for testing and providing photos used in this post
• to Furball for testing
• to lbdm for testing
• to myself… I guess?

Special Offer – Windows 2000 RC2 AXP32 Full ISO

The ISO on BetaArchive is the same as the ISO on WinWorld, which was originally named usa_2128_axpfre_win2000.pro_beta3_cairo.iso… hmm, that doesn’t sound very ‘Microsoft’!

Yep, definitely not original. Even worse, SETUP.EXE is broken/truncated:

The fact that the AXP32 2128 ISO we’ve had for over a decade is both unoriginal and incomplete is truly shocking! Well, I have something to offer – an at least complete Windows 2000 build 2128 AXP32 ISO from my private collection:

The SETUP.EXE in this ISO is good and complete! The CDIMAGE parameters used to build this image matches what was used to build ISOs of AXP32 builds from the same era and the disc label (W2PAS_EN) is much more sensible than “Cairo_2128”. The only thing that doesn’t make sense is the timestamp – 1999-09-23 12:00:00. Microsoft used 1999-09-10 as the timestamp for all other copies of build 2128, so I’m not sure why this one is different. It’s worth noting that all files from the incomplete ISO also have the strange 1999-09-23 timestamp, so I guess it’s not a coincidence ¯\_(ツ)_/¯.

Download: https://mega.nz/file/qoYyUbLB#oKArX_Qqh_kjnESnT6dQD8NGTg05_CMhKMxW4FKuhjEWindows 2000 build 2128 DEC Alpha

Hinted by friends on Discord, Neozeed recently “re-discovered” a Win64 compiler for AXP64 / ALPHA64. It came as part of Windows Platform SDK from 1999. Microsoft wanted developers to test-compile their code to see if it’s “64bit ready”, well ahead of the 64bit hardware even being available. However, this was just a cross-compiler and there was no way of running any of the binaries. Trying the compiler, just for fun, I built Alpha64 version of Aclock – with zero hopes of ever being able to run it.

Sadly, 64-bit Alpha AXP Windows was never released outside of Redmond. There are some known surviving machines with AXP64 stored at Microsoft Archives. In fact I saw one with my own eyes, last time I visited there some 10 years ago:

The machine in picture above was featured in a blog post by Raymond Chen, which is a must read on this topic. It will give you background info on the whole Alpha 64bit situation.

And that would be the end of the story… if not for one generous reader, who contacted Neozeed after his previous post, and shared a disk image… containing non other but a 64bit build of Windows 2000 for Alpha AXP! The reader got it from a lot of random hard disks, bought from an e-waste and completely forgot about it until they saw the blog post!

The image was previously installed on Digital Personal Workstation. Having a PWS500 with ZuluSCSI at hand, I was able to slap the image on an SD card and boot it up:

The system BSOD shortly after. Turns out, this is a checked (debug) build and requires a permanently attached kernel debugger to even boot up (yes tried /nodebug flag). Initially WinDbg and kd.exe refused to work, as the target CPU did not match the host (the exact error code is: KD Version has unknown processor architecture). After some deliberation and help from friends, I learned that alphakd.exe can be run on x86 machine to cross debug an Alpha target. Most importantly it works with AXP64! We were able to continue the boot!

Another problem was that the system came up with “Found New Hardware” wizard and there was no functioning keyboard and mouse to click through it. Yes, I tried safe mode, VGA mode, etc., but nothing worked. The system was completely stuck on this dialog:

Fortunately, the network card worked. Neozeed and I built a 64bit version of rlogin daemon and hacked it in to the registry. Then we remotely executed a VBScript that clicked through 20+ “found new hardware” and “install unsigned driver” dialogs. Eventually, a PCI to ISA bridge was found and keyboard and mouse came up!

Unfortunately there are no identifying marks that would easily prove that this is a 64bit Alpha AXP build. The only way to tell is because there is no WOW, even for AXP32. You can’t run 32bit Alpha binaries. It will only run executables produced with the ALPHA64 compiler. This also means in practice there is no self hosted, native compiler. You have to cross compile on 32bit NT4 or 2KRC.

For sake of search engines the build number is 2210, the full string: 2210.main.000302-1934.

Update I have copied and ran a x86 `winmsd.exe` from Windows NT 4.0 and this came out:

How is it possible to run x86 binary? Because of Fx!32.

Update: So what else is in the image?

First of all, everyone is asking about Pinball… Yes, it’s there, but it won’t start:

In addition, I can’t open the event details. Maybe one day we can debug it with NTSD.

Other than that, it has some basic stuff, the every other Windows would have. Internet Explorer 5.5, agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0). Sadly msinfo32 doesn’t work, unable to connect to a service.

The image, similar to other private builds, comes with Internal Developer Workstation (IDW). It’s a set of developer tools, that most of (but not all) were released in Platform SDK and/or Windows Resource Kit.

There are a bunch of unix like utilities, cp, mv, ls, kill, etc.:

build.exe version 4.03.2209

It can build for AXP32 and IA64:

There also are two famous text editors, Microsoft Editor aka MEP / Z and Stevie, VI clone:

Lastly, lets explore 64bit Alpha AXP gaming scene! While Pinball doesn’t work, IDW comes with an impressive amount of games. Microsoft engineers must have been busy playing these while waiting for builds to complete…

We have 4 different card games, FreeCell, Solitaire, Gold and Cruel. Also Taipei game, TicTactics, Reversi, Minesweeper and Snake.

AXP64 NT also has fully working OpenGL Screensavers:

If you want to see this live in action. We going to be exhibiting on VCF West 2023 in August, alongside other NT RISC machines. Come and see us!

BetaArchive Wiki Link

Yes OpenBSD 7.3 Alpha boots, and installs! And it’s incredibly slow. But it’s running!

For those impatient just download it here: OpenBSD73_Alpha_es40.7z

The root password is: password

I had es40 built this from gdwnldsKSC but I amputated the pcap based networking code. I just wanted a smooth compile. The install took over an hour, as there is ssh keys to generate, and re-ordering and re-linking involved. All of which I disabled in the above image. The root password is password.

Since people never read this, the password for root is password.

One weird thing is that OpenBSD will crash on an assert if you are using the VGA console, so a serial console is a must. After it boots, as you can see the VGA console works fine.

The games work just fine as well. I didn’t bother installing the compilers as it took forever to decompress the base file, and I figured if you wanted it, you could install it. Also since I amputated the networking, there is no X11.

For those of you who want to play with virtual Dec Alpha stuff this one is pretty simple enough.

At the P00>>> prompt type in

boot dka0

And in no time it’ll boot up (takes about 2-3 minutes)

And for those of you who are into these things:

OpenVMS PALcode V1.98-104, Tru64 UNIX PALcode V1.92-105

starting console on CPU 0
initialized idle PCB
initializing semaphores
initializing heap
initial heap 240c0
memory low limit = 1b0000 heap = 240c0, 17fc0
initializing driver structures
initializing idle process PID
initializing file system
initializing hardware
initializing timer data structures
lowering IPL
CPU 0 speed is 1000 MHz
create dead_eater
create poll
create timer
create powerup
access NVRAM
Memory size 512 MB
testing memory
...
probe I/O subsystem
probing hose 1, PCI
probing hose 0, PCI
probing PCI-to-ISA bridge, bus 1
bus 0, slot 1 -- pka -- NCR 53C810
bus 0, slot 2 -- vga -- Cirrus CL-GD5434
bus 0, slot 4 -- ewa -- DE500-BA Network Controller
starting drivers
entering idle loop
initializing keyboard
*** system serial number not set. use set sys_serial_num command.
Partition 0, Memory base: 000000000, size: 020000000
initializing GCT/FRU at 1c8000
Initializing pka ewa
Memory Testing and Configuration Status
  Array       Size       Base Address    Intlv Mode
---------  ----------  ----------------  ----------
    0        512Mb     0000000000000000    4-Way

     512 MB of System Memory
Testing the System
Testing the Disks (read only)
Testing the Network
AlphaServer ES40 Console V7.2-1, built on Jun  9 2006 at 15:36:48
P00>>>boot dka0
(boot dka0.0.0.1.0 -flags 0)
block 0 of dka0.0.0.1.0 is a valid boot block
reading 15 blocks from dka0.0.0.1.0
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 1e00(7680)
initializing HWRPB at 2000
initializing page table at 1ff56000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code

OpenBSD/Alpha Primary Boot
VMS PAL rev: 0x4006800010162
OSF PAL rev: 0x400690002015c
Switch to OSF PAL code succeeded.
>> OpenBSD/alpha BOOT 2.0
boot>
booting disk:/bsd: 8562592+683208 [326169+106+499752+320686]=0x9e9790
Unrecognized boot flag '0'.
[ using 1147688 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 7.3-current (GENERIC) #133: Wed May  3 12:45:27 MDT 2023
    deraadt@alpha.openbsd.org:/usr/src/sys/arch/alpha/compile/GENERIC
AlphaServer ES40, 1000MHz
8192 byte page size, 1 processor.
real mem = 536870912 (512MB)
rsvd mem = 2801664 (2MB)
avail mem = 514916352 (491MB)
random: good seed from bootblocks
mainbus0 at root
cpu0 at mainbus0: ID 0 (primary), 21264C-6 (pass 4.0)
cpu0: architecture extensions: 305<PAT,MVI,CIX,BWX>
tsc0 at mainbus0: 21272 Chipset, Cchip rev 0
tsc0: 8 Dchips, 2 memory buses of 16 bytes
tsc0: arrays present: 512MB, 0MB, 0MB, 0MB, Dchip 0 rev 1
tsp0 at tsc0 hose 0
pci0 at tsp0 bus 0
siop0 at pci0 dev 1 function 0 "Symbios Logic 53c810" rev 0x01: dec 6600 irq 8
scsibus0 at siop0: 8 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <DEC, RZ58 (C) DEC, 2000> serial.DEC_RZ58_(C)_DECSRL0000
sd0: 2048MB, 512 bytes/sector, 4194304 sectors
vga0 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5434-8" rev 0x02
wsdisplay0 at vga0 mux 1
wsdisplay0: screen 0-5 added (80x25, vt100 emulation)
dc0 at pci0 dev 4 function 0 "DEC 21142/3" rev 0x30: dec 6600 irq 20, address 08:00:2b:e5:40:00
ukphy0 at dc0 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 0x000000, model 0x0000
sio0 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0xc3
isa0 at sio0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0 mux 1
wskbd0: connecting to wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x3bc/4 irq 7
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
tsp1 at tsc0 hose 1
pci1 at tsp1 bus 0
tsciic0 at tsc0
iic0 at tsciic0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
siop0: target 0 now using 8 bit async xfers
root on sd0a (d4f7f3ff7ccee1b1.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
Automatic boot in progress: starting file system checks.
/dev/sd0a (d4f7f3ff7ccee1b1.a): 11877 files, 188223 used, 792736 free (232 frags, 99063 blocks, 0.0% fragmentation)
/dev/sd0a (d4f7f3ff7ccee1b1.a): MARKING FILE SYSTEM CLEAN
pf enabled
starting network
/etc/rc[498]: read: -p: no coprocess

starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: smtpd sndiod.
starting local daemons: cron.
Wed May 10 04:54:32 MDT 2023
reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC/relink.log

OpenBSD/alpha (es40.my.domain) (tty00)

login:

And there we go!

OpenBSD/alpha (es40.my.domain) (tty00)

login: root
Password:
Last login: Tue May  9 12:00:11 on tty00
OpenBSD 7.3-current (GENERIC) #133: Wed May  3 12:45:27 MDT 2023

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

You have new mail.
es40#

Did I mention that the root password is password?