64bit computing on a budget

Posted on by
10

With all that Dec Alpha talk, and how hard it is to get hardware, and how seemingly exclusionary it is, I thought I would try to touch on a more available 64bit ‘risc’ platform, for the masses!

While a couple years ago I had touched on running Windows 10 on the Raspberry Pi 4, in the brave new world of 2023 getting ahold of a pi4 is expensive, hard to find, and kind of depressive, which lead me to this (old) but exciting project, the Renegade Project!

Long story short, there exists enough drivers & information to facilitate a port to the Snapdragon 845, a 64bit System On a Chip( SOAC!), meaning that if you have a device with this chip it *can* be slightly possible to install Windows 10 onto it.

system compatibility matrix, for ants.

Glancing at the system matrix, to me the glaring hole is Charging. 3 systems outright support it, all of them from Xiaomi, the Xiaomi Mix 2s, Xiaomi Mix 3 & the Xiaomi PocoPhone F1. Looking around eBay to start this adventure I found a PocoPhone F1!

Getting the Phone

This seemed like a good start, 29.99, 128GB of flash storage, and I’d later learn 6GB of RAM. The first problem came from Xiaomi. Turns out that the phone was still locked, the seller had neglected to logout from his Xiaomi account. Even worse though he had forgotten his login and password. Calling Xiaomi support was basically worthless. Without unlocking the phone on a reset to root the phone lead me to this:

Locked!

I got lucky however after talking to the seller, he agreed to go above and beyond and we were able to unlock the phone together. So everything went well. If you do buy one of these phones used, MAKE SURE TO CHECK THE XIOAMI login id! It has to be unlocked and blank so you can register it and get the unlock. It will require a valid email & phone number + sim for it to send/receive SMS codes.

Access to the site is very up & down, so I archived what I had downloaded to unlock the phone here. miflash_unlock_en_7.6.602.42.7z

I should add that we’ve cleared the first few hurdles of precuring the device and unlocking it. And I’m glossing over stuff. Getting to this point was not easy and took a week. The unlock process is not intuitive, and I’m sure many phones are sold out there that have their google access wiped, but have not been logged out all the way, or the flash erased. I can’t show you mine as I ended up erasing Android but be aware of this!

Getting ready for Windows

Basically on the Android side there is three main modes, the boot, the recovery and the ‘fastboot’ mode. Holding power & down brings you to fastboot, where using the fastboot tool you can load an image from your PC into ram and execute it. EDK2 UEFI firmware, is the first part or the renegade project you’ll encouter. It’s really powerful, allowing you to not only boot into Windows, but it also supports a linux disk target mode, allowing you to partition and access the flash directly from a PC. Naturally this is SUPER dangerous, and backup your modem files!

With the phone unlocked softbooting E2DK you can put it into a target disk mode, connect it to a pc and partition away!

disk mode… for ants!

The guide (section 1.2) advices pushing the disk tools to the phone booted up in twrp-3.7.0_9-0-beryllium.img. Honestly its easier to just partition it on your computer. HOWEVER if you were to use Windows, there is a slight issue:

The device may no longer be able to boot into fastboot mode

I ran into this issue and thought I had bricked my phone. I was actually in the middle of researching how to do a physical hard reset, and place it into EDL mode (taking it apart and finding which pads to short, when I found this section of the troubleshooting guide, where it’s the partition names. So instead, I ended up doing the partitioning on a Virtual Machine using VMware and Ubuntu.

(parted) print
print
Model: SAMSUNG KLUDG4U1EA-B0C1 (scsi)
Disk /dev/block/sda: 123GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name        Flags
 1      24.6kB  41.0kB  16.4kB               switch
 2      41.0kB  73.7kB  32.8kB               ssd
 3      73.7kB  524kB   451kB                bk01
 4      524kB   786kB   262kB                bk02
 5      786kB   1049kB  262kB                bk03
 6      1049kB  1573kB  524kB                keystore
 7      1573kB  2097kB  524kB                frp
 8      2097kB  4194kB  2097kB               bk04
 9      4194kB  8389kB  4194kB               misc
10      8389kB  16.8MB  8389kB               logfs
11      16.8MB  33.6MB  16.8MB               oops
12      33.6MB  50.3MB  16.8MB               devinfo
13      50.3MB  67.1MB  16.8MB               bk05
14      67.1MB  134MB   67.1MB  ext4         persist
15      134MB   201MB   67.1MB  ext4         persistbak
16      201MB   268MB   67.1MB               logdump
17      268MB   403MB   134MB                minidump
18      403MB   1275MB  872MB   ext4         cust
19      1275MB  1342MB  67.1MB               recovery
20      1342MB  1611MB  268MB   ext4         cache
21      1611MB  123GB   121GB                userdata

Before I did anything, this is what the phone partition table looked like. It’s an exceptional amount. The new parted v 3.0 that is recommended to use, doesn’t support the resize command so I had to manually do the numbers after destroying partition 21.

Originally, I had made a 32Gb partition to keep some Android functionality but somewhere it just stopped booting. But I didn’t care.

rm 21
mkpart userdata ext4 1611MB 32G
mkpart esp fat32 32G 32.5G
set 22 esp on
mkpart win ntfs 32.5GB 123G

21      1611MB  32.0GB  30.4GB  ext4         userdata
22      32.0GB  32.5GB  499MB   fat32        esp         boot, esp
23      32.5GB  123GB   90.5GB  ntfs         win         msftdata

Obviously dont follow this. I’m only providing output as an example.

If I were more patient, I guess I would have dd’d the entire phone to get a full entire backup. But I didn’t get this phone to run Android, so I really don’t care.

There is a LOT of disks being presented to Windows, in case you ever wondered how those 128GB flash devices get sold with only 114GB of user space.

So many partitions!

And even that 112GB is actually usable!

Remember the system partition needs the boot,esp flags, and the windows partition is msftdata. Also make sure the partition names are either single words, or NO words. Spaces will kill the fastboot mode.

I put all the disks that are presented in offline mode, so I don’t get confused. Make sure you are going to mess with the right volumes when formatting after the partitioning. This is NOT for the novice, it would be easy to not only brick the phone but screw up your existing install. If you have physical disks attached you don’t absolutely need, remove them or put them offline to make sure you don’t screw up.

I used diskpart to select the appropriate volumes and format them.

select disk 8
select volume 5
format quick fs=fat32 label="System"
assign letter="S"
select volume 6
format quick fs=ntfs label="Windows"
assign letter="W"

This isn’t a guide, just a reflection of what I went through.

With the disk now formatted, it’s a matter of selecting an OS to install.

I had really bad luck picking random versions of Windows, so I looked until I could find a confirmed working version in this video, Rodando o Windows 10 ARM nativamente em um Dispositivo Android (Pocophone F1 + UEFI). Long story short, it’s Windows build 210521-1658 with version 0.4 of the bootloader. Long story short I messed with LOTS of Windows on ARM driver sets, before I finally had the brave idea to just load it with no drivers:

booted

But that image is far too stale, and expires out very quickly, reducing any useful functionality once it’s connected to the internet. So it’s something that probably could be fixed, but it’s far easier to just grab an image that’s newer.

The x86_64 image I’m using now is 19045.3031, so I guessed to pick something comparable on ARM64. I used something called 19045.3031_arm64_en-us_professional, although it too was out of date, but Windows update brought it up to 22H2 19045.3086 . I had tried the downloader tool and apply all the updates offline, but I had issues. I suspect now in retrospect it was drivers.

Another thing I learned the hard way is that some of these images have multiple OS images installed. I guess it’s de-duplication, along with compression, but be sure to index the image first! I accidentally installed a Home version. Yuck.

dism /Get-ImageInfo /imagefile:install.wim

Index : 1
Name : Windows 10 Home
Description : Windows 10 Home
Size : 17,706,743,995 bytes

Index : 4
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 17,836,320,420 bytes

So just don’t go wildly apply image #1. I wasted too much time on that one.

But in the release I’m using it’s image #1. I checked. Trust me.

dism /apply-image /ImageFile:10.0.21390.1.co_release.210521-1658_arm64fre\install.wim /index:4 /ApplyDir:W:\

The S volume needs to be populated with the UEFI boot files. I had foolishly thought the boot.wim file would include the boot files, but instead bcdboot can set it up based on the location of a Windows install.

bcdboot W:\Windows /s S: /f UEFI

The next thing to do is install the drivers.

I was lucky enough to get some insight into some driver combination to work, and I came up with this much:

minimal 2210.1-fix
USB beryllium v2.0rc2
FG beryllium v2.0rc2

The key of course is that there is a minimal set in 2210.1-fix that will bring the system up with working USB. The FG package brings in enough of the power management to know the battery status.

dism /Image:W: /Add-Driver /Driver:drivers /Recurse

The drivers are not signed, so that means we need to change a bunch of boot flags. I also turned on debugging so have Windows dump core files, so you can run analysts on them with Windgb.

S:
cd S:\EFI\Microsoft\Boot
bcdedit /store BCD /set "{default}" testsigning on
bcdedit /store BCD /set "{default}" nointegritychecks on
bcdedit /store BCD /set "{default}" recoveryenabled no
bcdedit /store BCD /set "{default}" debug on

Of course the catch being that with no drivers loaded it’s in a super basic mode, with no USB, no touch screen, no power management, no wifi no nothing. So it’s a brick. But at least we’ve reproduced enough to show that you can boot Windows.

Sadly, loading all the drives from 2210.1-fix or beryllium v2.0rc2 lead to this:

the cracked glass adds to the feeling.

Add in a much needed OTG adapter and a mouse or keyboard, and you can complete the installation.

However, since I left off the majority of the device drivers as I didn’t want to spend forever trying to track it down, I used a random USB to Ethernet adapter and thankfully It just worked!

Accessing the phone over RDP.

I added a fancy USB 3.0 ‘dock’ with USB-C connector that you can plug a charger into, so that not only can the phone stay connected to power, but there is room for the Ethernet. It also has HDMI, perhaps is the drivers were more stable, it could be a viable desktop? And I have what I wanted, which was a non Intel/AMD 64bit platform that is hopefully more reliable than the Alpha64 platform, and maybe something to do some kind of contrast of the past vs future

This was NOT a simple thing to go through. I would be extremely hesitant to advise other people to follow suit. But in the off chance anyone who wants to do it, might have a better idea of what is involved.

Read the Troubleshooting guide & the Installation guide. Keep notes! I would have absolutely given up, without keeping notes.

Even simple tracking of disasters like this at least helped me along:

210521-1658
10.0.21390.1.co_release.210521-1658_arm64fre
boot-beryllium Version 0.4.1.img
boot-beryllium-ebbg Release - 2210.1.img
boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img

boot-beryllium-ebbg Release - 2210.1.img
no drivers

no drivers

v1.1.1


v1.1


FocalTechTouch v2.0rc1


v2.0rc1
INTERNAL_POWER_ERROR

installer


SYSTEM THREAD EXCEPTION NOT HANDLED


SYSTEM THREAD EXCEPTION NOT HANDLED

installer


SYSTEM THREAD EXCEPTION NOT HANDLED

Sorry the table doesn’t format well.

TL;DR don’t do it, unless you don’t mind spending too much time on this. Get a used Surface X instead.

AXP64 2210 Installation Media Reconstruction

Posted on by
19
Yes, Neko is ALPHA64 Powered!

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:

Crash to the NT firmware Monitor

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:

CAB checksum algorithm

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

CDE on WSLv1

Posted on by
4

AKA CDE on Windows 10!

This is about as weird as it sounds. While many disregard WSLv1 as being borderline useless, it can still quickly bridge the gap when you need something in user-space, and quickly. And for those of us on Windows 10 (I could upgrade this machine, but I haven’t bothered as I don’t have a real GPU for it), there is no real UI. But how to solve this?

Well, the first thing is xrdp. Xrdp is an RDP server that will allow any halfway good Unix machine become a terminal server, very ‘Citrix like’. Combine that with the Xorg virtual frame buffer, and now you have a display surface that is basically exported over RDP. I did modify it to listen on a different port so I could retain RDP to Windows 10 by modifying xrdp.ini:

port=4389
port=ask4389

Now the real fun comes from CDE.

I built 2.5.1 from source, following the guide, with 2 important notes: Make sure you install and activate the UTF!!!. The other thing that was trashing my build was that WSLv1 picks up the Windows path, and it has spaces in it, which confuse the build process. Be sure to export something like:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

before beginning the process.

With all the bits in place, the next issue is the RPC. I couldn’t figure out how to start the ‘safe mode’ version, so it will absolutely need RPC. But it turns out that you just have to start the rpcbind manually, since WSLv1 doesn’t have a real ‘startup’. I also saw a lot of errors trying to talk to dbus, so may as well start that up as well.

mkdir -p /run/sendsigs.omit.d/
/usr/sbin/xrdp
/usr/sbin/xrdp-sesman
/usr/sbin/rpcbind
/usr/bin/dbus-daemon --system

And finally link the Xsession to the default user .xsession so CDE will be the default environment.

ln -s /usr/dt/bin/Xsession $HOME/.xsession

Now you should have everything in place, to login and get the Xrdp login

xrdp login

And with any luck, you’ll be greeted with CDE!

CDE on WSLv1!

And there we go! Neat!

Citrix 2 on Qemu!

Posted on by
Reply

Something weird happened when I was stress testing a build platform, I scripted out a build of all the old Qemu I could with GCC 3.4.5, and I had pointed them to a random disk. Turns out it was a Citrix Multiuser 2 disk. And something weird happened, a few of them actually booted!

I setup a simple script to have it listen on both serial ports, one for the ICA Citrix client, the other accepting a more generic serial terminal.

qemu -L pc-bios -m 64 -M isapc ^
-fda dummy.vfd ^
-hda citrix2-1b.vmdk ^
-serial telnet:127.0.0.1:5523,server,nowait ^
-serial telnet:127.0.0.1:5524,server,nowait ^
-net nic,model=ne2k_isa ^
-net user

Just very simple stuff.

I can then just boot a simple PC qemu and attach it to the other side of the serial port

qemu.exe -L pc-bios -m 8 ^
-serial telnet:127.0.0.1:5523 ^
-fda "i:\Citrix Multiuser Link 1.0 (3.5-720k)\Images\disk01.img" ^
-hda msdos5.vmdk

Sadly it’s only text mode, and at 9600 baud, which you can really feel. Sadly OS/2 PC Serial port drivers sucked.

this kind of setup for me was a bit easier to mess around with linkers as I have multiple screens to view stuff, along with a terrible modem option to transfer files. Only the console can run graphical programs, so this isn’t the one to build a Windows 3.0 farm on

If anyone was crazy enough to try this, I’d suggest the 1.0 manuals. Sorry I didn’t get a chance to scan the 2.0 stuff.

The serial ports lock & jam a lot so I made some scripts to try to deal with it, just rserial1/2 to reset the port, and logouts1/2 to logout the serial connection. Yes it’s that fragile. Being a pre-release version of OS/2 I had zero luck getting any lan client going. If I had it’d make dealing with this thing, even with NetBEUI a lot more tollerable.

I did load up Windows 3.0 by the directions so it does work, albeit standard mode only. Looking back at OS/2 6.123, while it has the OS/2 1.2 interface, it’s MS-DOS was restricted to real mode only. So this was also a nice step up.

One thing to point out is that it’ll hang at the logo screen for literally a minute. I’m not anywhere near as smart enough to debug the loop and ‘fix’ it. Sometimes it just won’t make it, so close it down, and try again. It may seem hopeless sometimes but it does work. Although this unpredictability is why there is no public Citrix 2.0 on demand. I haven’t bothered tryng to build Qemu 0.8.2 on Linux, but if it were more reliable booting and networking, combining it with xinetd having a LAN backing store of homes & apps would make for a neat Citrix on Deman farm thing.

I can’t imagine anyone wanting to play but I did upload it to archive.org.

Windows NT demo on the DECstation 5000

Posted on by
2

Well this was unexpected find! Thanks to hyenasky over on discord.

While the platform had a few mentions here and there but it’s great to have found a talk about the product with video of it running.

Interestingly enough Compaq was apparently in charge of the ARC specifications? Also kind of funny how the do touch on that maybe one day it could be available for the Dec Alpha, but as we know DEC pivoted away from the MIPS entirely to focus on the Alpha.

The other part being how the Pentium/Pentium Pro was entirely unexpected from the wider RISC market that thought they had the migration point out of 386/486 based machines.

Unfortunately, like the platform, Alexandre Bronstein exited DEC to go onto other ventures, oddly enough at Veritas being pulled back into dealing with Microsoft with the disk manager.

Re-visiting VM/386

Posted on by
8

So years ago I had won an eBay auction for 3 disks:

VM/386

But pretty much everything I threw at it emulation wise came up with NOTHING but green bars when trying to enter a virtual machine. I’d always thought it was a video ROM thing but VGA type ROM I put in Qemu it’s always the same thing, green jail bars.

VM/386 in action

However, I tried it again on 86box, and YES it runs!

VM/386 VM status

You can see VMs running, where they are in memory and all that other fun stuff.

And even better you can run graphical PC programs on your advanced 80386, and seamlessly multitask them all, using the hotkey ALT+PRINTSCREEN to toggle between them all. Surprisingly creating and terminating VMs didn’t really mess with overall system stability. I have to imagine that had this program had a 32bit API, it would have killed OS/2 before it ever got a chance. Considering that version 1.2 is from 1988 there very well could have been a larger possibility.

It does have the ability for individual profiles to specify RAM or even where or how to boot, it has disk drivers for sharing of files (think file locking). It also has the ability to boot from floppy, or even ROM!

MS-DOS 3.30A booted under VM/386

Indeed there is a rather good review from PC Magazine: January 1988, that goes into many features, and compares it to other contemporary multitaskers of the era.

The one big drawback is there is no data exchange facilities. The one thing that Windows/386 had bridging the gap between MS-DOS & Windows applications.

So many products like VM/386 ended up finding their niche’s in attaching dumb terminals, and turning 386 classed machines into ‘micro mini’s’ witthout the power of Unix. It’s even out of this environment Citrix was born.

But there was so much potential here to be something so much larger, but sadly that was not to come. Perhaps 1988 was just a little too early in the sense of GNU GCC/GAS/LD and some Xenix COFF help. The world would have been a lot more stranger had Microsoft lost that second vital platform war.

Anyone crazy enough to want to try it in 86box, I uploaded my images on archive.org.

Microsoft’s Netware emulators

Posted on by
6

First thing to take care of, is if you have the old pcap on Windows running around. If you have it, you’ll know as you’ll get spammed with “FATAL Bad Memory Block.”, although things will continue to operate just fine.

Win10Pcap!
C:\dynamips\netware\qemu-0.90-pcap-client>qemu -m 16 -L pc-bios -M isapc -hda client.disk -soundhw sb16,adlib -net nic,macaddr=52:24:00:22:00:01 -net pcap,devicename={BFA868ED-E508-4436-B085-EC815C4C544C}
Eth: opened {BFA868ED-E508-4436-B085-EC815C4C544C}
Could not open '\\.\kqemu' - QEMU acceleration layer not activated
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.

So be sure to dump that for the one over on npcap!

The old times, actually running Netware 3.12

There was a time when Windows NT didn’t dominate the 1990’s data centre. Instead as a carryover from the 1980’s the majority of corporate LANS were instead based on Netware. And the only way Windows NT was going to make space in this environment was to dress up in sheep’s clothes and mingle among them unnoticed. That brings us to this GEM:

Services for NetWare

This fun CD will let our NT 4.0 server emulate a NetWare server! The first thing in one of these stealth migrations was to just join the existing network.

The existing network is 0C0FFCAB

In order to do this, the two bits of information we need is the frame type, since NetWare supports so many, and the network address. In this case its 0C0FFCAB.

default IPX is no good

By default the NT server will just listen to the network, and participate on what it sees. This is fine if you are just playing along as a dynamic node, but being a NetWare node requires you to step it up, and have these values set, as it is very possible that you could be the first one (or only one) live on the network, and you don’t want clients trying to think on their own.

I also gave mine an internal network number of 1381, because you know, it’s NT 4.0.

To add the FPNW, you need to add it as a new service. Just tell it you have a disk

You’ll then have to point it to the path of the install. This is honestly the hardest part.

Selecting the first option will install the NetWare Server emulation on the NT server.

I went ahead and named my NetWare emulation as SHEEP, as I NT to blend into the existing NetWare network, with nobody being the wiser.

indeed, on our client that was already connected to the Qemu server before I built WOLF, I ran an slist command to show all the servers on the network, and there is my Wolf in Sheep’s clothes.

Creating NetWare compatible volumes is done in the Server Manager, under the FPNW option. It’s pretty self explanatory, nothing too exciting there.

The truth is during the period where this was important the NT 3.51-40 timeframe, NetWare was still a dominant force. But once Windows 95 had launched, and the explosion of people wanting MORE, the natural interest of people going to NT was just amazing to see in corporate space. While there was an early beta of the newshell for NT 3.51, when NT 4.0 shipped it was just amazing as all the reservations for running NT had just evaporated. We’d gone from hiding among the sheep to full on eating them all. It was staggering how fast we were backing up NetWare volumes to only re-format the servers to NT, and get people converted to using them. Before NT 4, the consensus was that rolling out the client config was going to be a nightmare, and that being able to emulate NetWare was the way to go, as it would just work (see the MS-DOS VM talking to NT with an unmodified NetWare client). Instead we saw a massive drive to Windows 95, which ended up changing the client landscape and upending NetWare completly.

About the most difficult thing was user mappings, there was tools to do this kind of thing, and I believe we had something to even proxy passwords, but it was easier to make people just login to the NT side.

Of course this is ONE of the emulators, you might be asking, okay, what is the other?

Why, it’s WINDOWS 95.

YES.

I’m joining the NT domain for the full experence, but the NetWare emulation relies on NetWare servers for authentication. You could use an actual NetWare server, or of course a FPNW server.

Adding file and printer sharing for NetWare workgroups under Windows 95 is done by adding a Service to the network stack. It’s even on the floppy version.

To maximize the functionality and the pain, be sure to turn on SAP Advertising. This way it’ll appear in server lists.

SAP on!

So with all of this in place, yes you can map drives from the MS-DOS client to the Windows 95 workstation acting as a server.

Mapping a drive on 95, authenticated by the WOLF hiding as a SHEEP

And there we go, I can now see the Windows 95 workstation on the SLIST, and connect and map drives. My user account of course exists on the NT side.

While professionally I didn’t rely too much on this feature, but it was nice in that era where you still had MS-DOS/MacOS/OS2 desktops with NetWare clients to quickly share stuff. But in a large organisation this would lead to major issues.

The fundamental flaw in NetWare is that there is no directory service. Instead, all the servers have to broadcast that they exist, along with what services they provide.

On my tiny demo network this isn’t that much traffic. But on a larger network that spans continents this becomes a problem. With thousands of servers there can be an incredible amount of this SAP announcement traffic. Since there is no directory service, the other problem is that when a new client is booted up, it’ll do what is known as a GNS or Get Nearest Server request in order to find the closest server to attach to, in order to facilitate a login. And EVERY server will reply.

And as you can see some servers even will reply more than once. And this can have other effects where people reboot servers during the day, something that is very natural for a Windows 95 user, which could create issues for other users, even forcing them to reboot! And yes, anecdotally I ran into this so many times where people with laptops with this feature turned on, and they would screw up the local office building (impacting hundreds of people). Even when they weren’t winning the GNS elections.they are still generating extra traffic, and occasionally they will win. This was another problem we had with all these wolves hiding in sheep’s clothing.

In the end, NetWare was utterly removed from the data center’s by the end of 1997. Windows NT just scaled too well for SMP and large disks (I had one server with 1TB! It was using 4GB disks it was massive!), along with being able to easily install stuff like SQL Server & SNA Server, unlike NetWare where any NLM conflict will bring the entire thing down. Not having a name lookup server was a giant pain, but the final nail was also in 1997 with the rise of the internet, and normal people now getting involved the entire LAN/WAN was going TCP/IP, where it had only been a fringe protocol used for managing cisco routers, and tftp/ftp some files around, Windows NT’s ability to encapsulate named pipes, and NETBIOS over TCP/IP let them embrace this new world where the TCP/IP stack on NetWare 3.12/4.11 was only good for sending SNMP alerts.

But don’t cry for NetWare, they made so much money they were able to coast for decades before being bought out in 2010 by a Mainframe Terminal Emulation company of all things, The Attachmate Group, who was later in turn bought out by Micro Focus, a COBOL language company. I guess in the end, the Mainframes won?

Building a 100% virtual SNA network on your desk!

Posted on by
4

So I have been fighting the Mainframe thing for a while (see part1/part2) and getting nowhere. I couldn’t shake the feeling that it was working, but something on the mainframe side was broken. I just don’t know enough about MVS/VTAM on the host side. Although I have setup and deployed quite a few cisco routers in production doing remote ring groups, translational bridges, and the like, a DLSw connection to SDLC was something I’d never done as I’d always had direct token-ring access to the FrontEndProcessor.

On suspicion that I’ve been talking to the mainframe the whole time is that in the packet trace from Microsoft SNA server I’d see the string UNSUPPORTED FUNCTION in the capture.

Microsoft SNA Server

The LU goes online, but there just isn’t anything to be displayed. Traffic is constantly flowing but it’s always the same, a blank dead screen.

On a fluke I had spotted a copy of Attachmate Extra! 4.20 on eBay for $10. I was able to get someone to get it for me, and fence me a copy of the disks. Configuring Extra isn’t too involved, just set the terminal to type 4, and using the same block/destination address as all the others:

LU #3, and Model 4!

With the usual restricted I-Frame (MTU), and I turned everything on feature wise (it didn’t matter)

I had fired up both OS/2 & NT and with the same empty screen showing nothing. Next I loaded up Extra on Windows 95, and got this:

Unsupported Function
Unsupported Function

Well that was unexpected!

The 3705’s on Hercules can be connected to direclty, so I try c3270 and get this:

Wait, so my suspicion was right?!

I reset the mainframe, and then was greeted with the cat!

Finally!

So what was wrong?!? I’m still not so sure, but turning off the debug on DLSw, let me see that both OS/2 AND Windows NT crash out SNASOL with an abend code of U0020.

ABEND

I’m sure it means something to someone, but not to me. So this is one of those ‘dont do that if it hurts’ type things.

Since I had used Windows 95, as I figured it had more robust networking support than Windows 3.1

Setting up Windows 95 was a minor challenge as Extra! 4 is a Win16 application, and it’s DLC/802.2 support requires you to knock down the 32bit networking support to instead use the 16bit networking drivers. This is what let Extra! attach to it. Of course the following updates/files are needed for Windows 95 on Qemu:

the AMD PCnet driver is built in, so it works the best. Again, I have Dynamips & Qemu using the Microsoft Loopback as their common network, so I can do packet captures, and they both can communicate on the network.

So, of course the other question is, does it work with physical hardware?!

And YES it does!

If anything, using a terminal emulator that doesn’t crash out the host makes it seem all too easy. While I’ve seen SDLC PCI cards on ebay they are rather expensive, and does the ISA card really add anything that you could get over the LAN? Honestly no. Back in the day it really was just what you could get a hold of, and of course logically (virtually) setting stuff up made the 802.2 stuff all the easier to do, instead of leased lines, physical v35 cables, and all that other fun stuff.

With everything said & done, if you want to experience some pseudo fake SNA, go virtual. It’s far more portable, less cables involved, plus it’s self-contained making it more of a conversation piece.

All the hard work is being done by IOS, and it’s functionality like this is why cisco had established itself as king of the multiprotocol networking world. But everything is TCP/IP these days, and Cisco doesn’t commend the same enterprise place as it had once before, making this whole thing a middle point relic of the past. It’s far too new for real FEP/DLC networking, but everything now is TN32720 (telnet 3270).

I guess as a tip for people who buy physical routers is that those super expensive PCMCIA flash cards aren’t needed as long as you have enough RAM. One cool feature of the cisco routers is that the power on bootrom loads up a ‘boot’ version of IOS that is either also burned on ROM, or it’s also in FLASH. You have to remember it was super expensive back then so it may be only a few megabytes of space. The boot IOS can’t route or do anything too useful but it can load the proper IOS from various network sources into memory. My 7200 has one that supports FTP, so I could just drop IOS onto an anonymous ftp server at home.

I guess my ‘old man yells at the clouds’ is that I’ve had to deal with some bug in a remote site where the router didn’t have enough flash to store the image, and the Ethernet cards were too new for the boot IOS to drive, but we had an async card that did work, so I rebooted it to load production IOS over a T1. This one didn’t support FTP, rather it was TFTP, and it took about an hour to load. During that much time I didn’t have console access so I was getting ready to drive the 5 hours to the site, when I barely got onto the highway when I got the call that my ‘fix’ had worked and that the site was online. YAY.

I hope this has helped someone.