Put fold chevrons in the gutter, fading in while the pointer is over
it, a guide down each open scope, and a placeholder after a folded one.
Number lines past folded ones, and put a swatch before each colour the
server reports.
Outline decoded fields over the hex view, list them in a tree beside
it, and place types from its context menu. Read more of an insight's
memory when a decode runs out.
Draw the bytes once, a glyph run per colour per row, and show the
selection as themed bands beneath them, so a drag repaints only what
changed. Lay the rows out on a character grid, as the SwiftUI view
does.
SwiftPM re-reads every manifest when the environment changes, and
both it and Xcode key link and plugin tasks on PATH. An agent's shell
has a different PATH than the terminal's, so a build that was a no-op
in one relinks everything and regenerates the GTK bindings in the
other.
Run swift and xcodebuild from an allowlisted environment, with PATH
reduced to the directories that exist, each named once.
On CI the inherited Path runs past cmd's 8191 characters, so vcvars
loaded nothing and said nothing.
Load it on the system directories and put the caller's Path back
after. What it keeps as __VSCMD_PREINIT_PATH is then the same each
time, so the build no longer drops it.
SwiftPM rebuilds everything when the environment changes. Each run
grew LIB in the caller's shell, and each terminal brings its own
variables, so no build was ever a no-op.
Build from an allowlisted environment and hand the caller's back
afterwards.
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.
Sync-Checkout deleted subprojects/<name> for every wrap whenever the
checkout moved, which also took frida-gum, a wrap rather than a
submodule. capstone.wrap redirects into that tree, and meson resolves
every redirect while parsing, before it downloads anything, so the
next `subprojects update` failed outright:
ERROR: wrap-redirect subprojects\frida-gum\subprojects\capstone.wrap
filename does not exist
Bumping FRIDA_CORE_REF could therefore never work on Windows. The
deletion was redundant anyway -- `update --reset` already brings each
subproject to the revision its wrap names -- so only the build
directory goes now.
Observe the shared connection activity in the target picker and show
the current stage under the process and application spinners, animating
the bar toward the next stage over its expected duration with a timed
animation. Show the stage on an attaching session's row too.
Snap and Flatpak name a radare2 of their own, and both were left
behind when the ref moved -- so SwiftyR2, which follows the newer
RIOPlugin layout, met a struct without the field it sets.
Ubuntu and Fedora were spared: they read the ref of record.
Bootstrap provisions QEMU into a prefix of its own, and nothing told
the app about it -- the search goes by PATH, which named every other
prefix but that one.
Only git's own submodules were being updated, and a wrap subproject
is invisible to git -- so radare2 kept an sdb from whatever ref was
built before, and the build failed on symbols the pinned one has.
The check ran the emulator without vcpkg on the path, so it could not
load GLib and answered nothing -- and the build failed saying the
dbus display was missing from a QEMU that has it.
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 sweep that picks them out of ntldd's output asked for a literal
bracket after the drive letter, so it matched nothing and not one
library travelled. The emulator then found vcpkg's zlib beside the
app instead of the one it was built against, and died on a missing
entry point before it could say anything.
contrib/plugins is a C++ sample that GCC 15's libstdc++ cannot
compile against the win32 thread model, and nothing here loads a TCG
plugin -- the backend drives QEMU over QMP and the gdbstub.
vcpkg keeps it in tools/glib, beside glib-mkenums, and only bin was
on the path -- so the dbus display the app draws from could not be
configured at all.
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.
The webview shims went with the native editors; the libraries and
packages they pulled in stayed. Let go of the WebView2 loader and
its COM and WinRT companions, the vcpkg port, and webkitgtk in the
AppImage.
Open through the r2 command so what it opens is mapped: the
disassembler skips whatever falls outside a map, and reading is not
enough. Drop the bin load, which only sniffed formats at address zero.
Let a failed read say so instead of returning null, remember the pages
that have none, and resolve an anchor live or not at all -- a stale
address lands on whatever occupies it now.
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.
