Tag Archives: windows

Windows 2000 64-bit for Alpha AXP

Posted on by
44

(this is a guest post by Antoni Sawicki aka tenox)

Hinted by friends on Discord, Neozeed recently “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. That is until Itanium eventually came out, after infamously long delays. The Win64 project for AXP64 and IA64 was code name “Sundown”.

Trying the compiler, just for fun, I built Alpha64 version of Aclock – with zero hopes of ever being able to run it. 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:

DEC Alpha with AXP64 Windows at Microsoft Archives.
DEC Alpha with AXP64 Windows codename “Sundown”, at Microsoft Archives, 2014

The machine in picture above was featured in a blog post by Raymond Chen, which is a must read. It will give you background info on the whole Alpha 64bit situation. Sadly, 64-bit Alpha AXP Windows was never released outside of Redmond.

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, years ago 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 handy, I was able to slap the image on an SD card and boot it up:

Windows 2000 Alpha64 Splash Screen

The system BSOD shortly after. Turns out, this is a checked (debug) build and requires a permanently attached kernel debugger to even boot up. 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!

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 and hacked in to the registry an rlogin daemon. Finally solved the PNP fuckup by remotely executing 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!

Aclock running on 64bit Windows on Alpha AXP

Unfortunately there are no identifying marks that would definitely 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…

64-bit gaming on Alpha AXP

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!

Windows scp to remote machines with spaces in the directories

Posted on by
1

Well one nice thing about Windows 10 is that it has a built in ssh/scp client! Although telnet is optional, I get that it’s insecure but jeez what is a retro user to do?

Anyways the subject at hand is copying files from somewhere that has spaces in the path. In this case I need a copy of OS X Snow Leopard from my Mac Pro cylinder to this junk Fujitsu Celsius. I’m still having USB issues, but I’d like to get my data off of an external disk formatted in HFS+. And for ‘reasons’ I wanted to use something “native” but I don’t feel like building a Hackintosh. While not a strict tutorial on getting Snow Leopard running, I did upload my old download of Empire EFI on archive.org as this kind of stuff is damned near impossible to find.

So back to the matter at hand, I have this VM setup on my Mac Pro, and I want it on this Windows machine. You’d think it would be something like this:

scp -C [email protected]:"/Users/neozeed/Virtual Machines.localized/OSX 10.6/*" .
Password:
scp: /Users/neozeed/Virtual: No such file or directory
scp: Machines.localized/OSX: No such file or directory
scp: 10.6/*: No such file or directory

Okay so double quotes didn’t work. How about a Unix style escape for spaces? I mean it *is* scp after all, maybe it doesn’t know it’s on Windows.

C:\osx>scp -C [email protected]:"/Users/neozeed/Virtual\ Machines.localized/OSX\ 10.6/*" .
Password:
scp: /Users/neozeed/Virtual: No such file or directory
scp: Machines.localized/OSX: No such file or directory
scp: 10.6/*: No such file or directory

Well maybe it parses it like C, so you need double backslash? NO that doesn’t work either. Talk about frustrating. So, in an act of insanity, I tried single quoting the interior spaces around double quotes, something idiotic like a bash variable:

C:\osx>scp -C [email protected]:"/Users/neozeed/Virtual' 'Machines.localized/OSX' '10.6/*" .
Password:
Mac OS Snow Leopard.vmdk                                                               69%   11GB  16.0MB/s   05:16 ETA

And yes, now it’s transferring. I’m just using a cheap 50zt 5 port 100Mbit dumb switch. It’s good enough and it’ll probably take some 30 minutes to transfer all the bits, but it’s working.

So there you go. You may not need it now, or tomorrow but it’ll save you the 20 minutes of frustration!

Revisiting Windows NT 4.0 MIPS on QEMU

Posted on by
9

(This is a guest post by Antoni Sawicki aka Tenox)

This was previously well covered by Gunkies and Neozeed, however as almost a decade passed, some improvements could be made and annoyances fixed.

Firstly NT MIPS now works in 1280×1024 resolution under QEMU. It previously had issues with mouse tracking, but this is now fixed. So the new image has a higher resolution.

Secondly the old images were made with FAT filesystem which I didn’t like too much. The reason for that is the infamous RISC NT osloader needs to be placed on a FAT partition. Then, if NT is installed on a second NTFS partition the default drive will be D:\, C:\ being the just the osloader drive. This was super annoying in practice. So a common procedure was to just have one FAT partition for both osloader and winnt. I have fixed it by supplying a pre-partitioned disk and specified the second partition for osloader and the first for NT.

Also I only had just a bare/vanilla image with no additional software installed. The new image includes most of the available apps, including IE3, some editors, Reskit and Visual Studio.

Lastly I wanted to figure out all the right settings and flags for qemu as they were discrepancies between different sources and nothing seem to work smoothly. The correct flags seem to be:

qemu-system-mips64el -hda nt4.qcow2 -M magnum -global ds1225y.filename=nvram -L . -rtc "base=1995-07-08T11:12:13,clock=vm" -nic user,model=dp83932

The -rtc flag is not really needed if you are ok with having the current date in the guest.

Thanks to Neozeed for figuring out the network settings! Unfortunately the old/legacy -net nic -net user is no longer working while the new -device doesn’t like dp83932. The documentation was quite helpful.

Thanks to reader Mark for pointing out the correct NVRAM settings! See comments below.

The new image with all the apps preinstalled is here and a plain “vanilla” here.

Curiously this now works right out of the box on QEMU 6.1 and is pretty smooth and stable compared to what it was before. Good job QEMU team and thank you! Just in case I still keep the old binaries for Windows made by Neozeed here.

Update: I built Yori for NT MIPS! You can download here!