Its detection wants MINGW64's gcc on x86_64, which went missing when
MSYS2 moved to UCRT64 for QEMU. A cached frida-core hid this until
the 17.19.0 bump.
The emulator's control channel was the only thing pulling grpc-swift
in, and with it swift-nio-ssl, which does not build on Windows at all
-- it has no branch for the platform and its PosixPort reaches for
mlock, lstat and readlink. Nothing here wants TLS: the endpoint is
plaintext on the loopback, and only seven calls are ever made.
So the wire is spoken directly. GRPCConnection opens one HTTP/2
stream per call over swift-nio-http2 and frames length-prefixed
protobuf into it; EmulatorControlClient names the seven. That drops
grpc-swift-2, grpc-swift-nio-transport, grpc-swift-protobuf and
swift-nio-ssl from the graph, along with 7840 lines of generated
service stubs. The generated messages stay.
The rest is what running it on Windows turned up:
- AVD discovery split on "\n" and trimmed only .whitespaces, so
every name kept a trailing \r and every AVD was dropped.
- An AVD config spells its paths with backslashes, which URL keeps
as ordinary characters rather than separators.
- emulator and adb want .exe, and the SDK sits under LOCALAPPDATA.
- Port reservation and process lookup move into HostPort and
HostProcessLookup, which QemuMachine's two copies also wanted.
- The launcher re-execs into QEMU there, so the discovery ini is
named after that process; the one naming this launch's debug port
is taken when the launcher's own is absent.
Frames still arrive through a mapping rather than the socket:
CreateFileMapping backs the same file:// handle the emulator is
handed elsewhere.
A guest without vsock is refused outright on Windows, where the
virtio-serial fallback would ask QEMU for a QMP UNIX socket and be
told "unix sockets are not available on windows".
LUMA_EMULATOR_DISPLAY_ONLY drives launch, control and streaming
without a guest agent. Against a Pixel_2 AVD it reports a 1080x1920
first frame and nine more in three seconds.
Nothing packages libfdt, which the arm targets cannot be built
without, so QEMU falls back to the dtc of its own -- and fetching that
wants a git the shell was never given.
MSYS2's profile exports a PKG_CONFIG_PATH of its own, which is read
before PKG_CONFIG_LIBDIR, so zlib, bzip2 and zstd came from the
compiler's own prefix while glib and pixman came from vcpkg. A second
zlib then travelled beside the emulators under the same name as the
app's, and won by sitting closer.
Let go of that path, and point the linker at vcpkg for bzip2, which
asks the compiler rather than pkg-config. Bring zstd along so nothing
is given up for it, say outright that both are wanted so a build
stops rather than quietly dropping them, and leave behind only what
vcpkg has no answer for.
The emulators were downloaded from a qemu-<build> release built in
MSYS2 against MinGW's GLib and pixman, so the installer carried
those beside the vcpkg ones the app links: two copies of GLib and
friends.
Build them in the Windows job instead, against the vcpkg prefix,
cached like the other dependencies on the QEMU version and the
build script. QEMU builds under MinGW and nowhere else on Windows,
but UCRT64 and CLANGARM64 sit on the same C runtime as the MSVC
DLLs they now link, so a descriptor means the same on both sides.
The x86_64 environment moves from MINGW64 for that reason.
The emulators live a directory below the app, where nothing looks
for its GLib on its own, so they are started with the installation
root on PATH.
Windows drops out of the QEMU workflow, which macOS still uses.
Off Apple the xz container was unpacked by running /usr/bin/env xz,
which Windows has no answer for: Process reports that the file does
not exist, and the message reaches the user as it stands.
Decode in-process instead, the way Compression already does on
Apple, and ask for the library the platforms package.
Nothing in the list needs it, but it arrives as a weak dependency, and
Iceberg then loads it into the Pharo VM: the system one brings OpenSSL
3 where the VM already has 1.1, and the handshake to GitHub corrupts
the heap.
frida-core wants Go 1.26 for its compiler backend and Node for the
barebone runtime, and frida-swift now reaches for the GIO headers.
Swift needs ncurses in the snap.
Extract with shortcuts, since the tarball's dangling symlinks defeat
MSYS2's habit of copying what one points at, and install base-devel
for the make and diff that meson and the build itself want.
Build the arm64 flavour on an arm64 runner under CLANGARM64, name the
archive after the arch -- the MSYS2 runtime is x86_64 whatever it
builds for -- and stage it into that installer too.
Unpack the published archive beside the LumaCore bundle, where the
app already looks, and sign every emulator for the hardened runtime;
TCG needs the JIT entitlements.
Name the build once now that more than Windows uses it, and keep a
checksum per platform.
frida-swift to 141d200c, which carries FridaCore 17.18.0. frida-core
to 0602e5dc and radare2 to 84e28a44 for the Windows and Linux builds.
GRDB 7.11.1, swift-asn1 1.7.2, Sparkle 2.9.6.
Drop the Monaco webview. Edit in a GtkSourceView on GTK and in a
native text view on Apple, both speaking to Frida.Compiler's
in-process language server for completions, signature help,
hovers and diagnostics.
Color, complete and indent code natively, matching the GitHub
theme in light and dark.
frida-swift resolves the main context off a worker thread, a halted
guest can be let go, and a script that errors or overflows its stack
no longer takes the guest down. Fetch the matching barebone agents
from the 17.17.1-barebone lineage.
Same slim build as the Windows one, published to the same qemu-<build>
release as qemu-<build>-macos-arm64.zip -- arm64 only, which is what
the runners are. The binaries link Homebrew dylibs, so the closure is
copied into lib/, every load command rewritten to
@executable_path-relative names, and the touched Mach-Os re-signed
ad hoc. iOS is left out: nothing spawns subprocesses there.
Fetch the qemu-<build> archive our workflow publishes instead of
unpacking the upstream installer, dropping the 7-Zip requirement and
the list of graphics libraries that only existed to leave that
installer's cruft behind. The checksum pin moves to the new archive;
fill it in from the release notes once qemu-11.1.0-luma.1 has built.
The upstream Windows build carries the GTK, SDL, VNC and curses
frontends, none of which the app drives, and with them a second copy
of GTK in the installer. Build the four emulators and qemu-img from
the unmodified source in MSYS2 with those frontends disabled, keeping
the dbus display, QMP and the gdb stub, and publish the archive
against a qemu-<build> tag the way the shader toolchain is published.
The release notes carry the checksum and name the corresponding
source, which is what GPLv2 asks of a distributor.
Nothing packages a QEMU to build against, so the official build is
taken as it comes, pinned by date and by hash. Upstream publishes no
checksum, so the hash is of the bytes this was verified with.
Its installer wants administrator rights, which this script does not
ask for, so 7-Zip unpacks it instead. A QEMU built without the D-Bus
display cannot draw a guest, and is refused here rather than at boot.
Bootstrap provisions Frida, radare2 and the Pharo VM at their pinned
revisions and skips what is present, so a re-run resumes. The Windows
CI job drives it a component at a time. Build from a plain shell via
vcvars, and order the prefixes so a stale Frida cannot win the load.
The app links GtkSourceView for the Pharo editors and librsvg for the
symbolic icons, and neither package said so: on a machine without the
development packages installed, both fail at the first line the loader
reads. The AppImage found this the hard way, having nothing installed
at all.
Repack the Ubuntu 26.04 .deb through sharun, which maps the interpreter
itself and jumps to a stack of its own making. The auxiliary vector it
builds says the program has no interpreter at all, and gum reads that
vector to find the program and the modules beside it, so a library
preloaded ahead of it puts the vector back.
Based on the scripts pkgforge-dev publishes as TEMPLATE-AppImage.
Xcode enumerates a package target's sources when it loads the package
graph, before any build phase or scheme pre-action runs, so generated
Swift that appears during a build is missing from that build.
Move generation into scripts/generate-sources.sh, run it from the
Makefile, CI and the Luma scheme's pre-action, and drop the
AgentBundle target. Say what to run when the files are not there yet.
It came from the CMake build, which downloaded one. The Meson build
links whatever the distro provides, so the prefix holds the VM and
its plugins and nothing else.
No distribution packages a Pharo VM, so what a package leaves out is
what the app goes without: the .rpm and the .deb both installed a
binary whose libPharoVMCore.so nothing on the system provides, and
the flatpak, the snap and the MSI were each short of it in their own
way.
The VM's prefix now ships whole in each of them -- plugins included,
since the image asks for a plugin by name and the VM answers by
looking beside libPharoVMCore, so half a directory is no better than
none.
Nothing on that path ever built one, so the bridge compiled against a
header no pkg-config could point at. Building it there took a VM that
speaks MSVC rather than pthreads, a generation VM for ARM64, and a
prefix named in every dialect of path the toolchain reads -- one
pinned bridge at the end of it, rather than the dozen the search took.
Point frida-swift at the devkit this build made, the way every other
platform does, and drop the xcframework that stood between them.
Leave V8 out of it, sign the dylibs inside the frameworks before the
frameworks themselves, and add the GtkSourceView port Windows needs.
No distribution packages one, so SwiftyPharo asks pkg-config and
the Makefile builds a VM into .build when nothing answers. CI keeps
it in a prefix of its own and finds it again at run time.
The Meson-built VM replaces the CMake one, which brings the plugin
and boot fixes with it.
The playground, the notebook cells, the source editor with its
marks, the inspector columns and the canvas are written once for
both Apple platforms, with a file naming what the two frameworks
call differently. The editor is where they really part company.
The engine owns the image and its start-up, so a mission reaches
the whole of Pharo.
The example catalogue is Smalltalk inside Swift string literals,
which no compiler reads: parse each one in the image and report the
syntax errors, the names nothing defines and the selectors nothing
implements. Play every patch offline. Draw the effects and a
lettered scene offscreen and write a PNG of each, since what goes
wrong in drawing is blank frames and mirrored glyphs.
Play a snippet in a canvas for a while and report what the process
holds as it goes, and let go of what the image lets go of.
glslang and SPIRV-Cross build under neither SwiftPM nor Xcode, so
CI makes them into an xcframework and publishes it against a tag.
The manifest names that artifact; a build downloads it and needs
nothing local.
Write each effect body-only against a preamble the host supplies,
and let the build systems generate what each renderer needs -- a
Swift catalog for OpenGL, a Metal fragment function through glslang
and spirv-cross. Effects react to arriving events.
Call scripts/windows/build.ps1 from the workflow instead of a
duplicated inline recipe. The subst drive-letter mapping is
gone -- setup-env.ps1 strips the redundant -L so the link fits
-- and the separate PKG_CONFIG_PATH step folds into
setup-env.ps1. Keep the vcpkg-environment step; the frida-core
and radare2 meson builds run before it and need pkgconf on
PATH.
