THE WRITER MUST EAT -> patreon.com/trn1ty <-

blah!

ideas with no tangibility;
ideas with irrelevant supports;
ideas without value;
ideas' witlessness;
ideas' witnesses;
ideas-

<^>

2023-10-22

: more adventures trying to run a .exe file

So long as you can get QEMU.
qEMU?
qEmu?
QEMU according to its website.

I grabbed the RAR file of this Windows game and now I desperately want to run
it because it looks really cool. Now that I figured out unRARing it's time to
play it. However WINE (an API conversion layer from Win32 to Linux+other OSes)
won't work on the Raspberry Pi because this is an ARM processor which can't
execute x86 code, even if the API calls are translated. So I've decided this
game warrants mucking around in a lot of complicated compatibility shims.

The stack will look something like this:

 __ Raspberry Pi 4B+ 8GB _______________________________
|                                                       |
|  __ Linux __________________________________________  |   ; I'm including the
| |                                                   | |   ; kernel as its own
| | Chimera                                           | |   ; layer-maker
| |  __ X11 server _________________________________  | |   ; because QEMU will
| | |                                               | | |   ; be booting the
| | | WINE display<---------------------------------------. ; kernel image
| | |  __ urxvt __________________________________  | | | | ; itself without a
| | | |                                           | | | | | ; bootloader and
| | | |  __ QEMU amd64 _________________________  | | | | | ; from the kernel
| | | | |                                       | | | | | | ; init etc will be
| | | | |  __ Linux __________________________  | | | | | | ; spawned. The
| | | | | |                                   | | | | | | | ; Raspberry Pi also
| | | | | | Alpine                            | | | | | | | ; basically just
| | | | | |  __ WINE _______________________  | | | | | | | ; boots the kernel
| | | | | | |     ^-(X11 client)--------------------------' ; image sans loader
| | | | | | |                               | | | | | | |   ; because U-Boot.
| | | | | | | The Coffin of Andy and Leyley | | | | | | |   ; The details
| | | | | | |                               | | | | | | |   ; mentioned are the
| | | | | | |_______________________________| | | | | | |   ; ones I expect to
| | | | | |                                   | | | | | |   ; add non-trivial
| | | | | |___________________________________| | | | | |   ; overhead to
| | | | |                                       | | | | |   ; processor load,
| | | | |_______________________________________| | | | |   ; which might be a
| | | |                                           | | | |   ; problem in
| | | |___________________________________________| | | |   ; practice.
| | |                                               | | |
| | |_______________________________________________| | |
| |                                                   | |
| |___________________________________________________| |
|                                                       |
|_______________________________________________________|

This seems fine!

I had sex four times tonight and this is what I'm doing with the clarity.

So the first order of business is QEMU. This is packaged for Chimera in
multiple variants. I don't know what I'm doing so I looked it up and I think I
need qemu-system-* because I'm emulating the processor as well as the software.
# apk add qemu-system-x86_64

Now I need Alpine. I think it comes in really small images for containers.
$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/\
alpine-virt-3.18.4-x86_64.iso

Let's try booting.
$ qemu-system-x86_64 -cdrom alpine-virt-3.18.4-x86_64.iso
Error relocating /lib/libspice-server.so.1: __aarch64_ldadd4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_ldset4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_ldclr4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_cas4_acq_rel: symbol not 

Hm. Same thing as root. Maybe I need a kernel image outside of the ISO? Let me
try something:
$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/\
alpine-minirootfs-3.18.4-x86_64.tar.gz
$ tar tf alpine-minirootfs-3.18.4-x86_64.tar.gz | head
./
./sys/
./srv/
./run/
./root/
./opt/
./mnt/
./media/
./media/usb/
./media/floppy/
$ mkdir amd64
$ <alpine-minirootfs-3.18.4-x86_64.tar.gz gzip -cd | tar x -C amd64
$ man -k qemu
qemu(1) - QEMU User Documentation
qemu-img(1) - QEMU disk image utility
qemu-storage-daemon(1) - QEMU storage daemon
virtfs-proxy-helper(1) - QEMU 9p virtfs proxy filesystem helper
qemu-block-drivers(7) - QEMU block drivers reference
qemu-cpu-models(7) - QEMU CPU Models
qemu-ga-ref(7) - QEMU Guest Agent Protocol Reference Contents 0.0 • 2 QEMU Gu
qemu-qmp-ref(7) - QEMU QMP Reference Manual Contents 0.0 • 2 QEMU QMP Referen
qemu-storage-daemon-qmp-ref(7) - QEMU Storage Daemon QMP Reference Manual Con
qemu-ga(8) - QEMU Guest Agent
qemu-nbd(8) - QEMU Disk Network Block Device Server
$ man qemu # brb...
$ ls amd64 | grep linux
$ # fuck... I'm just gonna look up a tutorial

The good news is I don't think X forwarding will be necessary so that saves a
lot of trouble. The bad news is I don't know what I'm doing and am tired so
this will wait for tomorrow.

https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/alpine/genimg
How does Drew do it?

It was at this point the file got corrupted so here's my reconstruction of this
section based on the nvim swapfile:

I return well rested, ten hours later.
# apk add qemu-img

[ 1:20 AM] trinity: trying to figure out qemu
[ 1:20 AM] trinity: not going well
[ 1:21 AM] trinity: trying again with the sun up
[ 1:21 AM] [...]:   I remember I used that for the class where we
                    re-implemented a lobotomized risc-v operating system
[ 1:22 AM] trinity: i just wanna play this rpgmaker game
[ 1:24 AM] [...]:   which one?
[ 1:29 AM] trinity: coffin of andy and leyley
[ 1:29 AM] trinity: i think i can figure this out tomorrow
[ 1:29 AM] trinity: \/when i wake up
[ 1:29 AM] [...]:   why do you need qemu to run a rpgmaker game?
[ 1:30 AM] [...]:   they run in wine
[ 1:30 AM] [...]:   someone must have built some wrapper for them if
                    wine/proton does not work
[ 1:30 AM] [...]:   you just need the fonts
[ 1:31 AM] [...]:   also I remember running touhou mother in easyrpg on my
                    steam deck
[ 1:31 AM] trinity: not on arm64
[ 1:31 AM] [...]:   oh i see
[ 1:32 AM] [...]:   WHYYYYYYYY
[ 1:32 AM] [...]:   WHY HAS THIS SPREAD SO FAR
[ 1:32 AM] [...]:   is that the incest canibalism one?
[ 1:33 AM] [...]:   no comment
[ 1:33 AM] [...]:   :3

Drew bootstraps an extremely minimal Alpine x86_64 image with just enough
packages to self-host. However in the genimg script there is this one line:
30	dd if=/usr/share/syslinux/mbr.bin of=/dev/nbd0 bs=1 count=440
which relies on there being an existing SYSLINUX installation on the host. This
won't work on ARM64 for which there is no SYSLINUX and Chimera doesn't have a
GCC x86_64 cross compiler packaged and I don't wanna have to compile gcc for
this so I'm just gonna find a way that's different from Drew's way.

I'm gonna try using the standard ISO now because that should have a kernel and
means to boot on x86_64 already. I wonder if I can boot it as a live system and
no shit it has no X server. Maybe it wouldn't be too bad to install?

Fuck this shit. I'm just gonna figure out Box86.

Actually Box64 because I don't wanna figure out armhf stuff today.

; doas gmake 
[  1%] Building C object CMakeFiles/interpreter.dir/src/emu/x64run.c.o
/usr/local/src/box64/src/emu/x64run.c:1351:47: error: expected expression
                emu->segs[_ES] = *(__uint16_t*)(((char*)ED)+4);
                                              ^
/usr/local/src/box64/src/emu/x64run.c:1351:36: error: use of undeclared identif
ier '__uint16_t'
                emu->segs[_ES] = *(__uint16_t*)(((char*)ED)+4);
                                   ^
/usr/local/src/box64/src/emu/x64run.c:1364:47: error: expected expression
                emu->segs[_DS] = *(__uint16_t*)(((char*)ED)+4);
                                              ^
/usr/local/src/box64/src/emu/x64run.c:1364:36: error: use of undeclared identif
ier '__uint16_t'
                emu->segs[_DS] = *(__uint16_t*)(((char*)ED)+4);
                                   ^
4 errors generated.
gmake[2]: *** [CMakeFiles/interpreter.dir/build.make:76: CMakeFiles/interpreter
.dir/src/emu/x64run.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/interpreter.dir/all] Error 
2
gmake: *** [Makefile:166: all] Error 2

it is all so tiresome. This also matters less because I'm gonna need Box86
anyway. Maybe I should make a QEMU virtual machine for Raspberry Pi OS, install
Box86 and Box86's packages on that, and then have it all nice and dandy?
# apk add qemu-system-arm
# apk del qemu-system-x86_64

End recovered segment.

I'm gonna use the armhf image because I don't think this EXE is 64-bit and
it'll cut out all of the compat stuff.
$ curl https://downloads.raspberrypi.com/raspios_armhf/images/\
raspios_armhf-2023-10-10/2023-10-10-raspios-bookworm-armhf.img.xz \
	| xz -cd \
	>2023-10-10-raspios-bookworm-armhf.img
1238MB... jeez... time to plug in the laptop fan
The tutorial I'm following provided a link to a GitHub repo with a Raspberry Pi
QEMU Linux kernel image which is awesome. Except there's no Linux 6.1 so I'm
gonna have to go a version behind. This is all to play one video game so we can
move fast and break things without risking all hell breaking loose.
$ rm 2023-10-10-raspios-bookworm-armhf.img
Except where are the old OS versions? I can't find them on the Raspberry Pi
website.
Found by looking up, good old no-TLS HTTP: http://downloads.raspberrypi.org/
The newest kernel provided by the GitHub repo is 5.10.63, which corresponds
according to the Raspberry Pi OS Full armhf release notes (raspios_full_armhf
/release_notes.txt) to the 2021-10-30 release. But that download isn't in this
HTTP source. I think 5.4.51, which is provided in the repo, will work with
2020-08-24, though that version isn't mentioned in the release notes, because
the release notes' mentioned 2020-08-20 does have that version. The issue is
the release notes' dates don't line up with the actual downloads provided.
Strange. Whatever. Let's just try this and hope it works.
Oh, what the fuck? The dates in the folders are different? fucking hell
look at this fucking URL:

http://downloads.raspberrypi.org/raspios_full_armhf/images/
raspios_full_armhf-2020-08-24/ <- 2020-08-24
2020-08-20-raspios-buster-armhf-full.info <- WTF?????

I'm so tired and just want to read about hot cartoon characters butchering
people. Kernel 5.10.63! 2021-10-30! Of course, in the 2021-11-08 folder! I
should have known!
$ curl -O http://downloads.raspberrypi.org/raspios_full_armhf/images/\
raspios_full_armhf-2021-11-08/2021-10-30-raspios-bullseye-armhf-full.zip
$ # .zip? are you kidding me? 3.0GB??? This is gonna be an hour download...

Fucking hell. See you tomorrow.

<^>

No rights reserved, all rights exercised, rights turned to lefts, left in this
corner of the web.