Ironically in a twist of fate, I found this article, “AltaVista Search Engine History Lesson For Internet Nerds“, with a nice overview of the amazing rise, and tragic neglectful decline of AltaVista. Then what struck me was this line:
Digital was the original owner of the domain that you’re reading now; www.digital.com.
Wait!? What?!
Did digital.com just purge DIGITAL’s history?
Now I feel like an idiot for not having archived the archive. Always in motion is the past, it’s a shame that DEC’s pages had to be destroyed. History in digital form, especially Digital’s is always in motion and subject to $CURRENT_YEAR.
From the article here, on August 3rd, (aka yesterday) the purge will be complete. Instead of introducing an update to verify SHA-2 into legacy systems, and re-signing old updates, instead MS has taken the path of obsolesce and pulled the downloads instead.
And we’ve been here before.
Microsoft movie maker was a popular download for Windows XP, and MS removed the download, as hosting it was apparently encouraging people to keep on using XP. Naturally this wasn’t taken as a message that people wanted this kind of product, and why fill a void when you can remove a product? So now the majority of downloads that you will find are infected, corrupted and just going to cause further problems.
And here we go again.
A quick search on BING for MS Office 2003 updates still shows links, but they are simply no more. The purge is in full force, and search pages haven’t caught up. And as you can see cnet is already in the top downloads, and will become the authoritative download by fiat.
Also the early .NET’s deployment packages are no longer for download, while .NET 1.1 SP1 is still online surprisingly. For reference:
$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exeÂ
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a NDP1.1sp1-KB867460-X86.exe
For what it’s worth.
Calculating with shasum offers a few algorighims as this isn’t a simple one shot deal.
Naturally to add further confusion. Like everything with crypto, it’s so easy to mess it up.
$ shasum -a 1 NDP1.1sp1-KB867460-X86.exeÂ
74a5b25d65a70b8ecd6a9c301a0aea10d8483a23Â NDP1.1sp1-KB867460-X86.exe
$ shasum -a 224 NDP1.1sp1-KB867460-X86.exeÂ
18507f80722780ca477d7f10528ae28dd176f8d36cbce05a50cc7be0Â NDP1.1sp1-KB867460-X86.exe
$ shasum -a 256 NDP1.1sp1-KB867460-X86.exeÂ
2c0a35409ff0873cfa28b70b8224e9aca2362241c1f0ed6f622fef8d4722fd9a NDP1.1sp1-KB867460-X86.exe
$ shasum -a 384 NDP1.1sp1-KB867460-X86.exeÂ
c2372c71f93b5dc2a1c21c804bc74e27d82bfa45ee50fbc9037e713c156f1c591ffbe5e87f94022157906098916403b4Â NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512 NDP1.1sp1-KB867460-X86.exeÂ
bbe643f447f49636732b12d23a052d02681ad41f6920dc1038b073fa600f7589b378ed8e7de97e811543d93ae89ce52871a85ee58aa3b6aeaddc01bc1617ad85Â NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512224 NDP1.1sp1-KB867460-X86.exeÂ
63b2ffb0c5f1cd68abafba23997482b2087d486dcf60bec6fef7446d NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exeÂ
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a NDP1.1sp1-KB867460-X86.exe
Oddly enough a quick search for these checksums isn’t coming up with anything so I guess I’m first. Which of course is a further problem, is that there is no authoritative source from MS. I get the contract obsolescence thing, after-all the strongest competition to NEW MS products is OLD MS products. I still use Excel 3 & MS Word 2, despite having an Office 365 subscription, and various newer versions retail.
The sad thing is that many people will get screwed over from this action, and the only “solution” is of course move to Windows 10, embrace the new, and hope that you don’t have applications that actually require .NET 1.1 (or 1.0!).
The following is a guest post by PA8600/PA-RISC! Thanks for doing another great writeup on that PowerPC that was going to transform the industry!.. but didn’t.
The history of the PReP platform from IBM is quite interesting, not only because of its place in the history of Windows NT but also the history of the PowerPC architecture in general. When the PowerPC platform was new, IBM (just like a few other vendors, notably DEC) had grand plans to replace the x86 PC clone market (they helped create) with PowerPC. Of course thanks to various factors such as Apple’s refusal to play along, the launch of the Pentium Pro CPU (and the later Itanium disaster), and high cost, this plan never ended up panning out. Later IBM PReP machines were designed for AIX and Linux use only, and they were sold as regular old RS/6000 computers.
Still, Microsoft being Microsoft and willing to port their OS to literally anything hedged their bets and made MIPS, PowerPC, and Alpha ports of Windows NT (along with a PC98 release for Japan only). In the guest post about Solaris for PowerPC I made, I talked about the history of IBM’s PReP platform some more so you should go read that post if you want an initial rundown on PReP’s flaws and history. But I have learned a bit about the Windows NT port for PowerPC, and I discovered a rare version of it as well. By now everyone with a PReP machine (or PPC Thinkpad) has run Windows NT 4.0 on it, and if PReP machines are emulated it’s guaranteed this will be the second most run OS on it aside from AIX of course.
IBM also made a half-baked OS/2 port for PowerPC as well, and then there’s the previously mentioned Solaris port. All of these are rarities and it’s worth documenting. With how rare PReP machines are and their high prices on eBay when they do turn up for sale (or their tendency to be snapped up fast), I think it’s fitting to write perhaps the most in depth look at PReP hardware that anyone has seen.
Windows NT 3.51: “The PowerPC Release”
It’s commonly accepted that Windows NT 3.51 was the first release for PowerPC hardware and it was even called this within Microsoft. Featuring HALs for most of the early PReP machines including the Moto Powerstack, the rare FirePower machines built for NT (which used Open Firmware), the Power Series 6050/70 (and maybe 7248), and the unobtanium IBM 6030, it’s pretty much what you’d expect for a first release for PPC. It’s a polished, solid OS that’s arguably faster than NT4 on the same machine. Aside from the red boot screen (on my Weitek GPU), it’s pretty much Windows NT 3.51 but on the PowerPC. It’s like running NT 3.51 on MIPS or Alpha, it’s interesting but more software will likely run on 4 anyhow (especially on Alpha).
One interesting quirk of Windows NT for PowerPC is it does not report the CPU type of your machine. It simply reports “PowerPC” and what machine you’re running it on. It does not tell you that you’re running it on a 601, it tells you that it’s running on an IBM-6015.
Unsurprisingly Visual C++ 4 works on PowerPC Windows NT 3.51 as well. This is no shock, Visual C++ 4 was designed to work on 3.51 as well as NT 4.0. The same goes with many of the pre compiled programs. One advantage Windows NT 3.51 offers over 4.0 is that it is simply faster than 4.0 on the PowerPC 601.
There’s not much else about Windows NT 3.51 for PowerPC quirk wise that hasn’t been said elsewhere about NT 4. It runs in little-endian mode (one of the few PPC OSes to), it has 16 bit Windows emulation that’s slow, and it needs specific PReP machines to run. One interesting series of articles about the “behind the scenes” of the port worth reading is the Raymond Chen article series, and this discusses the quirks of programming a PowerPC 60x CPU in little-endian mode as well. It can be installed with the same ARC disks NT4 uses, and of course the same SMS and firmware disks will work. In fact QEMU at one time was capable of booting the IBM firmware image from these disks.
Here’s something I’ve found out from research however. There was actually a limited release of Windows NT 3.5, it’s been dumped, and it is a real operating system. It also requires a very specific model of RS/6000 to work, and one with a interesting history giving it a unique place among the PReP machines. While I was unable to make it work in the end, I did discover and document a lot of interesting features of PReP machines.
Enter Sandalfoot: The IBM 7020/6015 (and demystifying PReP machines)
To understand the HCL and weirdness of Windows NT for PowerPC (and why it won’t run on Macs), we need to take a look at one such machine it runs on. This is my RS/6000 40p, a machine that was given several brand names by IBM and used as a development platform for PReP software and operating system ports. This is also perhaps the most historically significant RS/6000 model from the era. While it wasn’t the first PowerPC RS/6000 (that honor goes to the 250), it was the first to use the PCI and ISA busses and it was a few months ahead of both the initial PCI PowerMacs and other PReP boxes. It’s also one of the few true bi-endian machines as just like other PReP machines, the MIPS Magnum, HP’s Integrity, and modern Power8+ machines it has OSes for both endians available.
In 1994 (presumably October 28, if the planned availability date is correct), IBM released the RS/6000 40p (announcement letter here, codenamed Sandalbow) and the Power Series 440 (codenamed Sandalfoot). Both are near-identical machines with different faceplates and boot screens. The RS/6000 ranged in price from around $4,000-6,000 and was designed to be an entry-level AIX workstation, bundling a copy of AIX with each machine. As an AIX machine it’s relatively slow and fits the entry-level badge quite well, but thanks to the 601’s POWER instructions it served as a transition machine over to the later 604 AIX machines. Unlike the later PowerPC 603 and 604 machines, it featured POWER instructions allowing it to run both legacy AIX POWER software and later PowerPC software. The Power Series was presumably sold to those wanting a PReP box for Windows instead.
Since IBM PReP hardware is so obscure and undocumented, I’m going to document this as best as I can being the owner of an IBM Model 6015/7020. The machine features a 66mhz PowerPC 601 (similar to that of the Power Mac 6100 and RS6K 250), PCI and ISA slots, and IBM’s “Dakota” PReP firmware (more on the boot process here). It uses an off the shelf NCR 53c810 SCSI controller, Crystal CS4321 sound chip, an Intel 82378 PCI bridge, and a NIC can be inserted into the ISA slots (mine has the famous 3com Etherlink III). The Super-IO chip is also off the shelf, and is a National PC87312VF. The clock IC is a Dallas DS1385S, a close relative of the Dallas DS1387 (with internal battery). At least some of the IBM custom ICs are the chipset ICs and those are also documented. A Linux 2.4 dmesg can be found here.
Mine is also maxed out at 192mb of RAM, however there are some solder pads for more and the chipset is limited at 256mb. This makes me wonder if the system was based on a reference design of some sort. There was an ultra-rare 604 upgrade as well, but considering how there are more 7248 and 7043 machines in the wild I can assume many customers just waited for that instead due to its superior AIX performance.
If the idea sounds familiar (off the shelf chips + RISC CPU) it’s because it was the very same idea used to create the two other non-x86 Windows NT platforms. The Microsoft Jazz MIPS platform most MIPS NT boxes were influenced by was infamously based on the same idea of a “PC with a MIPS CPU”. To a lesser extent, this was also seen on the DECpc AXP 150 and other EISA/ISA/PCI based Alpha machines designed to both run Windows NT and DEC’s own OSes. Crazy undocumented custom hardware and expansion busses were thrown out the window in favor of industry standards. In fact when I posted a photo of the motherboard to a chat full of PC nerds, they stated it looked remarkably like a normal PC motherboard. The whole industry would later adopt PCI and sometimes ISA on non-x86 machines to cut costs and reuse the same expansion cards.
The main difference between the RS/6000 40p and the Power Series variant is the boot ROM logo and chime. The RS/6000 and “OEM” systems used a boot ROM that featured the PowerPC logo and just a beep, while the Power Series machines featured a logo more closely resembling the PowerPC Thinkpads complete with the chime. One can boot firmware from a floppy as well by typing in the name of the ROM image in the prompt and pressing enter, and watching as it reboots once the firmware is loaded into RAM. Here’s a video I filmed demonstrating this, along with some other quirks including there being two SMS keys: F1 for a nice flashy GUI SMS and F4 for a text based SMS, along with F2 for netbooting (with the right NIC of course).
The Sandalfoot machines were LPX form factor machines, featuring a riser card and generic sheet-metal case popular with prebuilt machines from this era. The LPX form factor was wildly popular in the mid 90s due to its versatility, seeing use by both IBM and DEC for their RISC machines, various PC builders, and even Apple for the clone program and clone based Power Macintosh 4400. The Sandalfoot machines also drove home one of the core goals of the PReP project, which was to build a PowerPC platform using as many off the shelf and PC style components as possible instead of using lots of custom ICs like Apple did. I dug out one of my cameras to take a few high-res photos of the motherboard of this computer to illustrate this. Compare this to the motherboard of the Power Macintosh 6100 or even the 601 based 7200 and notice the bigger heatsink and use of fewer custom ICs (Apple loved those).
There were three main GPU options: the famous S3 Vision864, the Weitek Power 9100 (or P9100 for short) as a higher end option, and IBM’s own GXT150P. The S3 was the entry level GPU and the Weitek was a higher-end and faster GPU. The GXT150P is beyond the scope of this because it is unsupported on the other PReP OSes, only AIX. The other two video cards are essentially unmodified Diamond PC cards with the BIOS chips missing.
The Sandalfoot machines are perhaps the most important PReP machines due to their role in PReP OS development. Both OS/2 Beta 1 and Windows NT 3.5 were written for this machine in particular as it was one of the first PowerPC machines to support PReP and feature PCI/ISA slots, unlike the NuBus Macs released a few months earlier or the first PPC box: the MCA based RS/6000 Model 250. They also often shipped with the well documented and emulated S3 Vision 864 video card, a common GPU family in PCs of the time to the point where it was even included on some motherboards and emulated in too many PC emulators/virtualization programs to count (notably 86box/PCem). In fact it’s successor (the 7248) featured one soldered to the motherboard.
Windows NT 3.51 was dubbed the Power PC release, because it was designed around the Power PC version of NT, which was originally supposed to ship in version 3.5. But IBM constantly delayed the Power PC chips, necessitating a separate NT release. “NT 3.51 was a very unrewarding release,” Thompson said, contrasting it with Daytona. “After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it.” NT 3.51 eventually shipped in May 1995.
I think a more accurate thing to write is that there simply weren’t many PReP boxes out in late 1994. Windows NT 3.51 supported the Motorola PowerStack series, the IBM 6050/6070 (and maybe the 7248, which came out in July 1995), and rare FirePower machines. Windows NT only features HALs for the 6015 (Sandalfoot/Power 440/RS6K 40P), 6020 (Thinkpad 800), and the 6030 (a rare IBM machine that likely was only sent to a few developers). By 1995, there were more PReP machines on the market and this made the NT 3.51 release logical. NT4 even supported a few servers, mainly the RS6K E20, E30, and F30.
Windows NT 3.5 was most likely a limited release for testing purposes on the Sandalfoot machine as it’s HCL file declares it as “Build 807” with a date of October 18, 1994. The date seems to be around a week or two before the first 40p machines at least shipped. Some more files were modified later on and the folders were created on November 9th, 1994. Hardware support is very barren, and the readme file even has a section dedicated to quirks of the 40p along with a list of supported software for the x86 emulator. This might have been considered a beta as well, as an announcement letter for the Thinkpad 800 (6020) explicitly mentions Windows NT and that this version might be a beta for developers. It also talks about a Windows SDK for it and a Motorola compiler used to build 3.5 software.
However the real problem for me has to do with getting a video card. Windows NT 3.5 for PowerPC does not support the Weitek P9100 GPU that came with many RS/6000 branded machines, and neither does OS/2 for PowerPC. It only supports the S3 Vision 864 and 928 video cards. It’s listed in the setup options, but choosing it causes a txtsetup.sif error. I’m going to assume that the development units came with the S3 video card instead. My box contained a Weitek card which works for AIX, Solaris, and Windows NT 3.51/4. I bought a card from eBay to use with NT 3.5 and the OS/2 port.
The readme also features an ominous warning with the S3 video cards, that only revision B3 is supported and that 928 cards need 2MB of VRAM for anything above 256 colors. My revision of the card I ordered was B4, so I took the risk of seeing if it worked with my system. I also removed the ROM chip as the system initializes the video card itself and that having a ROM chip can cause the system to not complete the self-test or display video. As the IBM Weitek card lacks a BIOS, I did this.
Despite the scratches on the card from possibly coming out of an ewaste pile, the card worked fine in both a PC I inserted it in for testing purposes and the IBM system. I now had a 40p with a GPU much more well supported among non-AIX or Windows NT operating systems.
Anyhow, let’s talk about the install process in closer detail here. Windows NT for PowerPC installs in a similar manner to Solaris for PowerPC on the IBM PReP machines. First the floppy disk boots ARC, then when you choose to install it the machine copies the ARC bootloader/firmware to the hard disk so it can load it from there at each boot. The floppy disk can also be used to load ARC if the loader is damaged on the hard disk. Keep in mind, on IBM machines ARC is not stored in the ROM unlike on many other ARC capable machines so this has to be done. The Firepower machines do something very similar by using an Open Firmware shim, and unsuccessful attempts at emulating PPC NT have exploited VENEER.EXE to attempt booting instead of using the IBM firmware. It fails because they’re not emulating the hardware, just trying to find a quick way to just boot NT.
Once this is done, the installer loads up and installs just like every other NT install. It checks the HAL by reading the machine ID, what video hardware the machine has, and whatnot to prepare the installer. You need a IBM 6015, 6020, or 6030 according to the HALs it has and only the S3 video cards are on the HCL.
Or that’s what should happen. I first tried using ARC 1.51 as it worked for 3.51 and was greeted with a HAL error BSOD:
I first attempted to use older ARC boot floppies and I got somewhere, the BSOD changed to the classic 07b, and then I got nothing else. Using ARC 1.48 and 1.49 gave me this, I got some i/o error with ARC 1.46 (the first 3.51 ARC floppy), and any previous ARC floppy is most likely undumped. I’m assuming either the error is due to an ARC mismatch, a weird firmware mismatch/hardware revision mismatch, or some incorrect SCSI ID Solaris style. There might very well be some weird forgotten trick to making it work (maybe a Windows expert could dig through the files and find some weirdness), but I’m going to move onto another obscure PPC rarity:
OS/2 PowerPC Boot Attempts: Beta 1 and the Final
Recently the OS/2 Museum site dumped Beta 1 for PowerPC. It’s an earlier version of OS/2 for PowerPC that insists on a Sandalfoot machine with an S3 GPU. Unlike the other OS/2 PowerPC disc, it features a verbose boot featuring the kernel it uses. If you want to really see OS/2 for PPC working, try it on a 7248 or read this post about it.
This failed to boot, throwing up an error about mounting the disk or something. I did record it doing something at least however, an improvement over the Weitek which just does nothing at the PowerPC screen. I tried several things including removing the external SCSI CD drive and that didn’t fix much. It also declares 88c05333 an unknown PCI device.
So I decided to try the “final” build. The final build requires a 6050/70, and some people did get it working on the PPC Thinkpads. I decided to see what it’d do on my machine. Unsurprisingly it did absolutely nothing but give me a blank white screen and sometimes a 00016000 error (for a trashed CMOS). If anything the 6015 loves to trash it’s CMOS contents for absolutely no reason, especially when OS/2 is involved.
Anyhow this was very anti-climatic, as the OSes I threw at it found reasons to not work on it whatsoever. I weeded out the GPU being at fault by testing Windows NT 4.0 and finding out that it works just fine with the GPU, however I seem to have fewer resolutions available than what the Weitek card allows. It did change the boot screen font, making me wonder if the red boot screen is a GPU driver quirk.
However changing the device IDs with OS/2 PowerPC Beta 1 got me somewhere, as I now got a screen about the HDD failing to write. I formatted the HDD to FAT using the ARC diskette, then I nuked all the partitions, but not much else changed. I’m not sure what the error means, but it was a letdown.
Unless these OSes require some long lost firmware, I’m wondering if there’s else that’s causing issues with installation. Either way, it was a letdown. Nothing I tried worked and I spent hours messing with everything from SCSI IDs to using different drives.
So I wanted to dive back into old BSD, and I wanted to use the new native Qemu on OS X. That means having to “learn” the new crazy syntax that has drifted a LOT over the last 10+ years.
I want to run NetBSD 1.0 and tear into the GCC 2.x patches required back in the day
In the old days, I was using Qemu 0.13 and had it working using the following:
Thankfully I was using VMDK containers, probably as I’m sure I installed it under VMware, with it’s better floppy support, but pulled it back to Qemu to have NE2000 support. Now let’s look at the dmesg to where the source of the problem is, the network card:
NetBSD 1.0 (QEMU) #0: Thu Sep 22 06:45:37 PDT 2016
  [email protected]:/usr/src/sys/arch/i386/compile/QEMU
CPU: Pentium (GenuineIntel 586-class CPU)
real mem = 67764224
avail mem = 62312448
using 852 buffers containing 3489792 bytes of memory
pc0 at isa0 port 0x60-0x6f irq 1: color
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
lpt0 at isa0 port 0x378-0x37f irq 7
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0: 1023MB 2080 cyl, 16 head, 63 sec <QEMU HARDDISK>
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
pci0 at isa0 port 0x0-0x665: configuration mode 1
pci0 bus 0 device 0: identifier 12378086 class 06000002 not configured
pci0 bus 0 device 1: identifier 70008086 class 06010000 not configured
pci0 bus 0 device 2: identifier 11111234 class 03000002 not configured
ed0 at isa0 port 0x320-0x33f irq 10: address 52:54:00:12:34:56, type NE2000 (16-bit)
npx0 at isa0 port 0xf0-0xff: using exception 16
biomask 4040 netmask 412 ttymask 12
changing root device to wd0a
So the important thing here is that the NE2000 is the ed0 device using an IO of 0x320 and IRQ 10. I’m pretty sure back then I cheated, and just recompiled Qemu to remove the default definition that doesn’t work properly with trying to share IRQ 9.
Keeping this in mind, let’s build this for the new Qemu:
So the first important thing is to disable any/all defualt NIC’s with the ‘net none’ flag. Next to add in the NE2K_ISA type device manually so I can specify the iobase & irq manually. Note the netdev as this is used to tie in the emulated device, to the backend that will process the packets. The next part is the redirect to have the host listen on port 42323 and redirect them into port 23 of the VM. Again the syntax to redirect ports has drifted significantly. The hostfwd now is bound directly to the netdev user, in this new syntax it allows for multiple NIC’s to be bound to multiple user NAT’s if needed.
The next ting is the hard disk, before ‘hda’ worked fine, although like everything else that is subject to change in the future, so dealing with it now, use the drive flag:
It could be my personal opinion but the drive syntax, although much longer is easier to work with. The key parts being what interface to use (IDE), and what port/index to plug the device in (0), along with the media type, the cache strategy, along with the encoded format, which is more so important when dealign with RAW devices, as unidentified media will be tagged as raw, however it’ll be mounted read-only unless it is directly specified as above.
For additional fun, the serial port can be set to a MS Mouse port, although I haven’t tested it as of yet.
tickets had to be opened, vendors called, tickets escalated, and all that jazz. I’ve had to tighten some things with cloudflare, so FEED stuff is broken at the moment. I’ll try to turn it on later today.
So yeah, I know I need to move. again…. I’m just not in the mood to do so at the moment. I’m in the middle of a bunch of IRL shit, and just don’t have time at the moment.
As far as computers go, Raspberry Pi’s are cheap. The latest (and vastly incompatible) Pi4 is no real exception. Now you’d think Microsoft would want to get WoA (Windows on ARM) into as many hands as possible to get people to port apps to the new cpu architecture. But that is not the case.
As of this moment there is no real desktop machines, the only route to go is with the laptops, which are the few models from Lenovo, HP, Acer and Microsoft themselves. Brand new these things are not cheap, and of course people find out quickly enough that the emulation just isn’t quite there (not all that surprising) and of course the lack of native apps doesn’t help. It’s that chicken/egg problem that can only be solved by getting hardware into people’s hands.
Developers!
So getting back to to the Pi, on ETA Prime’s channel I saw this video, which quickly went over how to get Windows 10 up and running in no time flat.
Pi4 (4GB/8GB it doesn’t matter thanks to a DMA bug you can only use 3GB)
On the Discord look for the #download-links and look for build 0.2.1 After you extract it, the image should be about 10GB
10,100,932,608 build 0.2.1.img
With a MD5 checksum of: aad51a0e02ba947d24d543ff8ed612b0
Use etcher to write the image to the SD. It took me about 5 minutes to do so. No bigge. I unplugged the SD/IDE/USB adapter thing I’m using, plugged it back in, and used Windows disk manager to expand the partition to take up the rest of the disk. It’s not terribly complicated to setup.
After that slap in the SD to your Pi4 and away you go. Or so I first thought.
Realistically you also need:
A USB Hub
A USB Ethernet adapter (I have some cheapo no name realtek)
A USB audio card
A mini HDMI to regular human sized HDMI cables/adapters
a 5Amp USB charger for extra power!
As I found out rather quickly that the only peripherals that are working is the USB ports. However the USB controller has some DMA bug where it can’t xfer higher than 3GB which caps the current memory ceiling to 3GB.
Otherwise the Pi will think and reboot a few times, and about 15-30 minutes later (I didn’t time it, I walked out) you’ll be up and running Windows 10 on ARM!
It’s heavily customized in that when Windows boots up it is only consuming about 1GB of RAM. So that gives us just under 2GB for user programs. GREAT! Included is the setup program for the latest beta of Microsoft Edge (with the chromium engine) so at least you can actually hit web sites. However Google doesn’t like it, so if you are going to try to watch anything with DRM it will not work.
While many people complain about STEAM, game compatibility, really what on earth were you expecting? Naturally people will want to know how fast it is, and well… It’s not. Although it does have 4 cores, running at 1.5Ghz, there is barely any cache (well compared to an i7/Xeon), and it’s clearly not a power house of a box. The only real test of a machine like this is going to be native stuff. And speaking of, it’s nice that my previous builds for ARM still work! The sales guy that borrwed the ASUS should be back soon so I can do some side by side comparisons of how slow they are.
In addition to DOSBox, Neko98, and frontvm, I managed to get MAME 0.36 cross compiled and I had to disable the DirectX input and output, as although they do compile they have issues on the Pi4. So it’s GDI all the way. That said, it does run:
This isn’t the port you want, or the platform to play it on. I’m using the command line Visual C++ tools to build this, and MAME 0.37 drifted to being more of a MinGW thing, and I just don’t feel like fighting the build process.
Another point of fun, is that this processor & OS does have x86 compatibility you can take things to the extreme with OTVDM, and run Win16 based programs on Windows 10 for ARM! Not that I would know why you want Excel 3.0, but rest assured, it works fine.
The platform supports WSL, so I went ahead and installed Ubuntu 18 & 20… and both have one apparently known catastrophic failure on the Pi’s. When trying to update packages the updater crashes. The fault is apparently in dirmngr, or the usual Linux bandaid of switching distros. There doesn’t appear to be any ‘fix’ to this, so if anyone knows what to do, I’m all ears. Also don’t enable WSL2, it’ll hang at the bootloader. I ended up having to reflash the disk.
In my quick conclusion, is this the RISC Windows workstation of the future? No, not really. It’s more the $50(+peripherals) tyre kicker edition. It’s a cheap way into the platform, to see what the fuss is all about. This machine feels like a low end i3, the CPU just isn’t there, it’s only a BCM2711 Cortex-A72, so there isn’t all that much to be expected. On the other hand it’s FAR FAR FAR cheaper than something like the Surface X. If you have the hardware it’s worth checking out if you are interested in non x86 Windows. Otherwise you aren’t going to miss much.
Since WSL2 runs an actual Linux kernel that means you can run 32bit binaries! And that now means you can run stuff like ancient unmodified UML kernels on Windows! Isn’t that great!
I followed my old posts here & here, to get running or the short version being:
Details don’t seem to be anywhere near as complete as I’d like them for now, but the long speculated move to ARM has finally begun. Interestingly enough, it’s the end of OS X 10.x as now we have version 11, currently named macOS Big Sur:
I guess the more interesting thing will be the emulation in the new Rosetta2, if this is actual emulation or is this going to be relying on LLVM’s intermediary byte-code, allowing a user experience more akin to Java.
With the move to ARM, this will spell the end of the Hackintoshes. Which is a shame, as the best way to experience OS X, most certainly has been on non Apple hardware. I guess time will tell regarding the adoption of the desktops, but as always since the introduction of the Apple Store & Apps, computers have accounted for a negligible fraction of Apple’s sales. Even sales of iPads surpass those of all the computers combined.
The upcoming transition kit will be a Mac mini sporting the A12Z SoC, 16GB of memory and a 512GB SSD. This is the same processor in the current iPad Pro.
The Transition Kit is $500 USD, however it’s invite only. You can try your luck here at:
Naturally I was denied the opportunity to give them $500.
I suppose as time goes on more and more details will become available. I’m sure there will be a race to get Qemu to run Big Sur, although Im sure the retail product will be signed and encrypted, and Apple will consolify their ecosystem.
On the gaming side, however being able to run iOS apps on the desktop means that the Mac is now a serious gaming contender for the casual market. Can apple bridge the Candy Crush gap where Microsoft failed with RT?
I finally got the update to version 2004 of Windows 10 (OS Build 19041.329) which now includes support for running a Linux kernel inside a VM, using paravirtual drivers letting it hook into Windows 10. It reminds me of WinOS/2 where, OS/2 would run Windows 3.1 in a virtual machine, but using special drivers it could redirect it on the native filesystem, and paint the windows on the OS/2 desktop.
So the first thing is make sure you have 2004, winver should look like this:
You will need to go to the old control panel, and enable the Virtual Machine Platform. For those of you using VMware, you’ll need at least version 15.5.5 (15.5.6 is current as of the time of me writing this). I’d suggest you do that before turning on this, but some people like to live dangerously. Also fully shut down all your VM’s otherwise things will end up giving you errors (as you’ll see later).
After the Virtual Machine Platform is installed, your machine will need to reboot. After a reboot, you’ll need to download the Linux Update to the system, available at:
It’s a simple install, and only takes a few seconds. I didn’t have to reboot.
now for the fun parts, you’ll need to list and shut down (terminate) your running WSL’s if you have any running.
C:\Users\neozeed>wsl --list --verbose
NAME STATE VERSION
Debian Running 1
As you can see I only have one, and it’s called Debian, and it is currently running something. Let’s kill it!
C:\Users\neozeed>wsl -t Debian
C:\Users\neozeed>wsl --list --verbose
NAME STATE VERSION
Debian Stopped 1
And now it’s stopped. The command to upgrade is pretty simple:
C:\Users\neozeed>wsl --set-version Debian 2
Conversion in progress, this may take a few minutes…
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
And yes, you can also stop the WSL instance, and move it back to version 1, if you find 2 not doing what you want. However on first impressions, WSL2 is significantly faster.
If you are running VMware, and you didn’t shut down your VM’s you’ll get this lovely message when you try to resume:
The save state will be deleted, but rest assured it’ll launch okay (at least mine did!)
One sad consequence of using the Microsoft Virtual Machine framework is that nesting is no longer available.
which is kind of a bummer, as that was the killer feature.
I’ve been using Sandboxie for a long while to run all those questionable downloads on Windows. It’s a great light weight sandbox (as the name implies) for running random downloads, or even going to questionable websites as Sandboxie does a great job of isolating processes, and their filesystem access.
It’s not been all that cheap, but I felt it was worth it. I went to check to see how much it is as the conversation had come up on discord, and it turns out that Sophos had bought Sandboxie, and opened up the source code!
The downside is that there will be no further official development of the product. So I guess at some point I’ll have to break down and get a signing cert and re-build it if I want to keep using it.
Last version is locally mirrored here, as I understand it’ll be deleted soon enough.