This is the FOSBIC1 compiler developed at the University of Gießen, Germany
in the late 70s for the CDC 3300 batch system.
It is a BASIC compiler and runtime system which is written in FORTRAN IV.
The text book from which the source code was copied implies that it is
a modified version of a BASIC compiler named UWBIC from the University of Washington, developed by William Sharp in 1967, for their IBM 7094.
So, without going into it much further I went ahead and made a few minor changes to get it running on Microsoft Fortran
Compiled!
Instead of some boring example, I thought I’d try some Mandelbrot, so going through this collection on rosettacode, I thought the OS/8 version looked simple enough to work with.
Sadly it doesn’t seem to be very ASCII so it doesn’t understand numerical characters. Maybe I’m doing it wrong I didn’t see anything. Just as my attempt to set a string variable to itself + a new letter then print that string strangely failed. Also it does weird stuff with strings, again it maybe me, but I’m impatient. This is terrible, and yeah I know.
TESTCOMPILER -- BASIC BWL 5 GIESSEN -- VERSION 6/76-04
10 X1=59
11 Y1=21
20 I1=-1.0
21 I2=1.0
22 R1=-2.0
23 R2=1.0
30 S1=(R2-R1)/X1
31 S2=(I2-I1)/Y1
40 FOR Y=0 TO Y1
50 I3=I1+S2*Y
60 FOR X=0 TO X1
70 R3=R1+S1*X
71 Z1=R3
72 Z2=I3
80 FOR N=0 TO 30
90 A=Z1*Z1
91 B=Z2*Z2
100 IF A+B>4.0 GOTO 130
110 Z2=2*Z1*Z2+I3
111 Z1=A-B+R3
120 NEXT N
130 REM PRINT CHR$(0062-N);
131 IF N=0 THEN 200
132 IF N=1 THEN 202
133 IF N=10 THEN 204
134 IF N=11 THEN 206
135 IF N=12 THEN 208
136 IF N=14 THEN 210
137 IF N=15 THEN 212
138 IF N=16 THEN 214
139 IF N=17 THEN 216
140 IF N=19 THEN 218
141 IF N=2 THEN 230
142 IF N=20 THEN 232
143 IF N=22 THEN 234
144 IF N=23 THEN 236
145 IF N=24 THEN 238
146 IF N=25 THEN 240
147 IF N=3 THEN 242
148 IF N=30 THEN 244
149 IF N=31 THEN 246
150 IF N=4 THEN 248
151 IF N=5 THEN 250
152 IF N=6 THEN 252
153 IF N=7 THEN 254
154 IF N=8 THEN 256
155 IF N=9 THEN 258
200 PRINT 'A';
201 GOTO 439
202 PRINT 'B';
203 GOTO 439
204 PRINT 'C';
205 GOTO 439
206 PRINT 'D';
207 GOTO 439
208 PRINT 'E';
209 GOTO 439
210 PRINT 'F';
211 GOTO 439
212 PRINT 'G';
213 GOTO 439
214 PRINT 'H';
215 GOTO 439
216 PRINT 'I';
217 GOTO 439
218 PRINT 'J';
219 GOTO 439
230 PRINT 'K';
231 GOTO 439
232 PRINT 'L';
233 GOTO 439
234 PRINT 'M';
235 GOTO 439
236 PRINT 'N';
237 GOTO 439
238 PRINT 'O';
239 GOTO 439
240 PRINT 'P';
241 GOTO 439
242 PRINT 'Q';
243 GOTO 439
244 PRINT 'R';
245 GOTO 439
246 PRINT '-';
247 GOTO 439
248 PRINT 'T';
249 GOTO 439
250 PRINT 'U';
251 GOTO 439
252 PRINT 'V';
253 GOTO 439
254 PRINT 'W';
255 GOTO 439
256 PRINT 'X';
257 GOTO 439
258 PRINT 'Y';
259 GOTO 439
439 REM
440 NEXT X
450 PRINT '-EOL'
460 NEXT Y
461 PRINT 'END'
470 END
It runs in batches, so it’s not interactive. Very mainframe/1960’s minicomputer like. I guess it’s fitting again being in FORTRAN.
******************* EVERYTHING SEEMS OK -- LET'S GO AHEAD
PERCENT OF AVAILABLE STORAGE USED 31.081
PERCENT OF AVAILABLE DATA STORAGE USED .000
PERCENT OF AVAILABLE NUMBERED STATEMENTS USED 30.294
AA A A A A B B B B B K K K K K
K K K K K K K K K K Q Q Q Q Q
Q T T T U X F D E T Q Q Q Q K
K K K B B B B B B B B B B B -EOL
I’m not sure what is up with the AA and after that, it’s all tabulated. I ended up running it through sed to remove the spaces, and using notepad to stitch the lines together. I guess I could have bash’d it some more but.. I’m impatient.
So yeah, it looks like it worked! Very amazing. And of course it’s crazy fast but that should be expected I suppose. I don’t like the hard coded table, but I just wanted to get it to generate an image.
Sadly, the author of the compiler, Weber seems to have disappeared, and the publisher Paul Haupt died in 1978, a year after this being published.
So, a while back I had found this up on eBay. As much as I’m trying not to buy old stuff I just couldn’t resist. And the price was just too good, I’d just have to forego going out to dinner for a week.
I had been using it to mess around with a poorly ported Hack 1.03, although I haven’t done much with that in a while.
One thing is for sure, that the old MS-DOS memory limits were becoming more and more of an issue. Sadly, they didn’t include the QuickC for Windows product which had the benefit of building in protected mode for access to far more memory, nor did they include any DOS Extender to even allow larger runtime access. Obviously you were expected to run this under MSOS/2 1.2 in this era. Although targeting OS/2 protected mode allowed easier integration with PharLap’s 286 based DOS Extender.
Since this was the OS/2 era, the Windows 3.0 SDK was a separate product.
There was another release, the 6.00ax version which included a DOS Extender, allowing the compiler to access 16MB of ram, as reported in this leaflet in a combined Microsoft C & Windows 3.0 SDK package.
The followup Microsoft C/C++ 7.0 addressed many of these shortcomings, but of course famously removed targeting OS/2. There was a later update that at least provided OS/2 compiled version of the binaries allowing you to run it under OS/2. I never tried to see if it could be paired with the OS/2 SDK, and manually made to generate OS/2 executables. I suspect not.
The larger thing is that Microsoft C 386 remained a ‘hidden’ product on Xenix, and the 32bit OS/2 and NTOS/2 betas.
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.
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.
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.
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.
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.
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.
Obviously, this is breaking news! Sure you could like read the official press release, or any of the dozens (hundreds?) of ‘reputable news’ sites, along with thousands of vloggers, but naturally I of course check out 65scribe, and yep there indeed is a new video!
Kind of disappointed there is no planned Mac version, despite what apple says about ARM gaming.
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!
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?
Size: 4 bytes
Location: Last 4 bytes of a 0x2000 section
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:
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:
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.
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 ¯\_(ツ)_/¯.
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:
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.
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.
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
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.
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.
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!
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.
