Potato Bread (or, how I got Windows 10 on a PowerBook for some reason)

Not too long ago, with distance dependent on your current location...

I had an idea. It wasn't a very good idea, but it sure was an idea. And like many of my ideas, it was something that I couldn't ignore. No, I couldn't just let this one slide. That's because the idea... was Windows 11 on my PowerBook G4.

No, that wasn't a typo. I know what I said. And I know what the title of the post says. For the time being, please just assume that title says "11" instead of "10", and let's continue.

The beginning

From the outset, one thing was abundantly clear. There was NO POSSIBLE WAY this was going to work on Mac OS X. And don't even mention OS9.

The main reason for this was going to be just one of the reasons this was a bad idea (but, surprisingly, not a major sticking point). That reason is, of course, RAM usage. Let's take a look at Windows 11's minimum requirements:

Processor - 1 gigahertz (GHz) or faster with 2 or more cores on a compatible 64-bit processor or System on a Chip (SoC).
RAM - 4 gigabyte (GB).
Storage - 64 GB or larger storage device Note: See below under “More information on storage space to keep Windows 11 up-to-date” for more details.
System firmware - UEFI, Secure Boot capable. Check here for information on how your PC might be able to meet this requirement.
TPM - Trusted Platform Module (TPM) version 2.0. Check here for instructions on how your PC might be enabled to meet this requirement.
Graphics card - Compatible with DirectX 12 or later with WDDM 2.0 driver.
Display - High definition (720p) display that is greater than 9” diagonally, 8 bits per color channel.

Now, things I can get past:

But there are some sticking points. UEFI is probably not an issue with OVMF, so RAM is the biggest (for now). This PowerBook has 2GB of memory, and that's already the maximum. So we need a system that has as little RAM usage as physically possible on this machine.

Wrong answers first.

Enter OpenBSD

My first thought was to try OpenBSD. Great PowerMac support, has a QEMU port, I'm (relatively) familiar with it, and (I thought) it's fairly lightweight. Ignore the parentheses for now.

So, one short OpenBSD install later, I'm ready to build QEMU. No, I'm not sure why I USED THE PORTS SYSTEM FOR THIS either, but that's what happened. And 18 HOURS later, I've got a working QEMU. Yes, 18 hours. No, I didn't forget to disable GTK support in QEMU, what makes you say that?

And so I run my new QEMU. I figure I've probably installed Windows 10 with 1.5GB of RAM before, so Windows 11 should be perfectly fine. But then I see the dreaded message:

qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory

Wait, that can't be right. There's NO WAY OpenBSD is using that much memory at idle. But then I ran htop.

Exit OpenBSD

htop confirmed my expectations. OpenBSD (particularly the X server for some reason) is surprisingly heavy at idle with the base system. Why? Who knows! All I know is that there was ~250MB of RAM used, and that I didn't care to investigate further.

Okay, I did do some more investigation. Mainly with vNVDIMM, but that doesn't appear to work on PowerPC at all.

In addition, it occurred to me that if I encountered any weird edge cases caused by running QEMU on OpenBSD, those would get multiplied with the whole PowerPC thing and my shit would end up entirely fuckered. So onward to Linux.

Void Linux

Luckily, I still had a really, REALLY old VoidLinux-PPC install DVD sitting in my big ol' spool of disks. I figured that was probably as up-to-date as I was gonna get (which was correct, VoidPPC is fucking sick), and I'd used it on this machine before (to... some success). So, after installing Void... NO. I'm not glossing over this. Here's the experience I had installing and booting Void:

  1. I don't blame Void for this
    • Well, like I said, my install media is a couple years old at this point. So SSL certs are a total no-go. No netinstall for me.
  2. I do blame Void for this
    • void-installer is... not great. It's fast, sure, but it's incredibly fragile. Why do I have to manually unmount the root partition if the installer fails? Why does it think my network is unconfigurable (It's right there! And working!)? Why do I even have to "configure" the network if my network is already configured? Why...
  3. OpenFirmware can be strange
    • void-installer setting the boot-device automatically doesn't work (yes it does. give me a sec)
    • Well, that's what I thought
    • On reboot, I got the good ol' missing folder. So I boot into OpenFirmware.
    • None of these drives have GRUB!? WHAT!?
    • Fine, I'll reboot again into my Debian disk so I can try that.
    • It's... Booting Void? Why? How? Where did that come from?
    • And it's worked ever since.

So, finally, after booting Void, and updating about 38 million packages (hey, one for every Canadian!), I have another working QEMU. And this time it might even work!

It didn't work.

Finally! Time for some Windows!

The first thing I checked was -- of course -- the free memory. According to htop, the RAM usage of my Void+IceWM system was only about 150MB (almost half as much as what OpenBSD was using).

At last, it was time for the first test. I run QEMU. I wait. (A long-ass time. SEVERAL ass-minutes.) And then it hits. The first BSOD of the day.

(Black) Screen of Death

By which I mean BLACK Screen of Death, of course. I'm not sure why either. UPDATE: I've been informed that that's just... how they are on Windows 11. Thanks Waterpear!

Now, I was fairly certain I knew what this was. I'm not actually sure I did (or do), but I did sorta fix it.

CPU struggles

There's one major problem with using QEMU as an actual emulator (without KVM, using TCG). And that's CPU support. Normal people don't try to run a modern Windows VM on a G4, so it's likely you haven't really encountered this issue. Under KVM, you can easily pass your host CPU through to the guest, and everything "just works". This isn't the case with unaccelerated QEMU. So, we need to find a compatible CPU to emulate for modern Windows. Piece of cake, right?

(it's not)

QEMU can emulate a lot of CPUs. And most of those CPUs will run modern Windows. The problem lies in CPU features. Emulating x86 is already SLOW on PowerPC. Emulating SSE? AVX? INFINITELY worse.

So, of course, my first test was the most baller, feature-filled CPU in the list. An EPYC-Rome (but single core, lol). After at LEAST 30 ass-minutes of waiting for the machine to boot, I did get past that BSOD, and I instead got a black screen (but not of death).

My next choice of CPU was phenom-v1 (which is a Phenom 9550). Why did I choose a Phenom 9550? I'm unsure. I didn't know at the time. I don't know now. This will forever be a mystery (and a mistake).

Anyway, with my trusty 9550, I did get a little farther! Finally, I was able to see the little spinny circle guys.

little spinny circle guys

But then I waited. (another 30 ass-minutes or so).

(there was supposed to be a picture here. I didn't take a picture of this error. Whoops. Imagine there's a picture here. Of a DRIVERIRQLNOTLESSOR_EQUAL in tcpip.sys)

This would prove to be the most difficult problem I had to solve during this day.

TCP/IP?

I'm gonna spoil it for you because it makes the following section much more fun to read. It wasn't TCP/IP.

Alright, so the first thing I thought to try was a different NIC. That was really the only thing on my end that made sense. First attempt, an rtl8139. 30 ass-minutes later, I get a BSOD. Same error, same driver.

Fine. I'll try another NIC. How about e1000? One ass-hour later, I get a BSOD. Same error, same driver.

Fuck off. I'll try another NIC. virtio-net-pci? That's not gonna work. I'm getting desperate. Ten ass-minutes later, another BSOD. Same error, same driver.

I had a feeling at the time that it wasn't TCP/IP.

It wasn't TCP/IP.

Oh, what do you know? It wasn't TCP/IP.

At this point, I was running out of things to try. So I turned to one of my actually modern computers. I tried to boot my Windows 11 iso in QEMU. Barely 1 ass-minute later, the moment of truth.

The BSOD appeared.

What!? Then what happened!?

When did the headings gain a personality?

The next step was to try it again, but with KVM. Different crash. I'll spare you the grittiest of details, but several different command lines later, I had made no progress. KVM or no, different NICs, different CPUs, nothing.

So then I decided to try Windows 10. I've definitely run Windows 10 in QEMU without KVM before, and it definitely worked. So, several different command lines later, I discovered... that I apparently hadn't?

To verify exactly how crazy I was, I decided to try 10 on my PowerBook. At this point I had also found a GitHub issue from May 2019 where somebody said TCG runs Windows 10 better with -cpu core2duo. This combination... didn't work. At all. We've got past the TCP/IP thing, but it's a page fault now? What?

Windows Builds Matter

Yes, they do. Thanks for telling past me now of all times.

Something hit me at that moment. The GitHub issue was from May 2019... May 2019... It's almost as if that's when 1903 was current.

OH FUCK OFF

Yeah, that's right. Microsoft broke something about this setup some time after 1903 was current. Which means most versions of Windows 10 (or 11) will absolutely page fault on you the moment you attempt to run them on TCG. Nobody has noticed this for YEARS because nobody is NEARLY insane enough to not use KVM. I literally found a bug in either QEMU or Windows. What the fuck.

Another thing I decided to try was running 32-bit Windows. At this point, there's no hope at all of running Windows 11 on this thing, so I might as well (I'm only allocating 2GB of RAM anyway).

Success?

Yes, it worked, if you can call this "working". This is THE SLOWEST Windows system I have ever used. Windows draw before their contents. I can move my mouse (slowly) into the position where a control will be -- before it has any chance of showing itself.

BUT, as I write this, Windows 10 is installing. The system is working, and although I didn't end up reaching my goal of running Windows 11 on a PowerBook G4, Windows 10 is still pretty damn cool. I suppose I even learned something.

beautiful, aint it?

Appendix: My QEMU options (if you're also insane)

I really, REALLY don't recommend you do this. I wouldn't even call it fun. If there was a fun part, it was the journey. And that's done. Please don't do this.

Anyway, my QEMU command was as follows:

qemu-system-i386 -drive file=win11.img,format=qcow2 \
    -cdrom win10-32.iso \
    -m 2047 \
    -cpu core2duo \
    -vga cirrus \
    -nic user,model=rtl8139

Note that this setup would probably work on any system/architecture that can run QEMU. But if it's x86, and there's KVM support, there are better ways.

I don't know how I feel about spending nearly 10 working hours on this. I guess it was technically productive. Anyway, that's it. Later.

Mastodon