Companion to the porting plan · 27 July 2026

Executor, read twice

The evidence behind A GNUstep Front End for Executor. The plan says what to do; this says what was found and where. Everything here is source reading with file and line citations. Where something could not be verified, it says so.

Method and honesty

Two trees were read in full: Cliff Matthews' 2008 MIT source release, which contains the 1993–97 NeXTSTEP front end, and autc04's modern C++17 fork, which is the build target. Five parallel reviews covered the old front end's architecture, the modern front-end contract, the input and output subsystems, the toolchain and GNUstep API surface, and the bundled HFS_XFer utility.

Contents

1. 01The front-end contract
2. 02Threading and synchronisation
3. 03Pixel formats
4. 04Toolchain and runtime
5. 05The 1993 front end
6. 06Input, sound, printing, scrap
7. 07GNUstep API gaps
8. 08Interface files
9. 09Rootless, in depth
10. 10HFS_XFer
11. 11Salvage register
12. 12Unknowns

Exactly one abstract base class, Executor::VideoDriver vdriver.h:103-174. No required free functions. The global Executor::vdriver vdriver.h:176 is defined by the core at vdriver.cpp:10, not by the front end.

Pure virtual

Also required

• A constructor (IEventListener*, int& argc, char* argv[]) — argc by non-const reference. Required by main.cpp:416.
• A default_vdriver.h supplying using DefaultVDriver = …, found via target_include_directories(… PUBLIC .). Included by main.cpp:62.

Optional — all have working defaults

The true minimum is proven by headless.h — sixteen lines implementing setMode and three empty methods.

The callback interface

IEventListener vdriver.h:62-78, reachable as the protected member callbacks_ vdriver.h:152. The concrete instance is EventSink vdriver.h:80-101. All methods are safe to call from the GUI thread.

mouseButtonEvent(bool down, int h, int v)   // convenience, :65
mouseButtonEvent(bool down)                // :71
mouseMoved(int h, int v)                   // :72
keyboardEvent(bool down, unsigned char mkvkey)  // :73
suspendEvent()                             // :74  focus lost
resumeEvent(bool updateClipboard)          // :75  focus gained
requestQuit()                              // :76
wake()                                     // :77  only Wayland uses it

main.cpp:424-509 is unambiguous about ownership:

auto executorThread = std::thread([&] {
    ROMlib_InitGDevices(...);   // :441 → vdriver->setMode
    executor_main();            // :496
    vdriver->endEventLoop();    // :503
});
vdriver->runEventLoop();        // :506  MAIN THREAD, blocks all session
executorThread.join();          // :507

The toolkit's loop owns the main thread and calls into Executor through callbacks_. Executor never calls the front end to pump events — there is no pumpEvents(). This matches [NSApp run] directly.

GUI thread to emulator

Front-end calls are queued and delivered via a synthetic interrupt eventsink.cpp:90-95:

void EventSink::runOnEmulatorThread(std::function<void()> f) {
    std::lock_guard lk(mutex_);
    todo_.push_back(f);
    eventInterrupt.trigger();
}

where eventInterrupt eventsink.cpp:15-19 is serviced on the emulator thread and drains the queue in pumpEvents() :97-106. The front end never touches Toolbox state.

Emulator thread to GUI — your problem, three existing idioms

Under GNUstep, also enable multithreading early — the runtime must know it is multithreaded before performSelectorOnMainThread: behaves — and wrap every secondary-thread entry point touching Objective-C in an autorelease pool. Executor already had to do this on macOS macosx.mm:83.

What the guest writes

Executor::Framebuffer vdriver.h:43-60, constructed at vdriver.cpp:12-17:

rowBytes = ((width * bpp + 31) & ~31) / 8;   // rows padded to 4-byte multiples

Accepted modes are powers of two up to 32 vdriver.cpp:98-109; minimum size 512×342 vdriver.h:31-32. The framebuffer is big-endian Mac format. It must never be handed to AppKit directly.

What updateBuffer() produces

vdriver.cpp:271-405. Output is packed 32-bit 0xAARRGGBB in host byte order, no padding, stride bufferWidth * 4 :332, :341. On a little-endian host the memory order is B, G, R, A. Alpha is 0xFF except where a pixel lies outside the rootless region and equals opaque white, which is written as fully transparent :332. Work is chunked at 100 rows when a rect exceeds 160 rows :303-309.

Qt performs no conversion of its own. QImage::Format_RGB32 is bit-identical, so it passes qimage->bits() straight in qt.cpp:215, :268.

The AppKit equivalent:

NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
    initWithBitmapDataPlanes:&buf
                  pixelsWide:w pixelsHigh:h
               bitsPerSample:8 samplesPerPixel:4
                    hasAlpha:YES isPlanar:NO
              colorSpaceName:NSDeviceRGBColorSpace
                bitmapFormat:(NSAlphaFirstBitmapFormat
                            | NSBitmapFormatThirtyTwoBitLittleEndian)
                 bytesPerRow:w*4 bitsPerPixel:32];

That highlighted constant arrived in gnustep-gui 0.25. Verify before building around it.

Palette

setColors vdriver.cpp:141-153 receives 16-bits-per-channel vdriver_color_t vdriver.h:38-41 from gd_update_colors() qGDevice.cpp:216-234 and stores host-native 0xAARRGGBB into colors_[256]. It then dirties the whole screen and calls requestUpdate() :151-152 — correct, since a CLUT change alters every pixel's meaning. If you do not override it, palette handling is free. Qt does not override it.

Dirty rects

DirtyRects dirtyrect.h:10-31. Maximum five :13, auto-merged into unions when they overlap dirtyrect.cpp:150-196. Half-open, top-left origin. getAndClear() at :199-204.

Framebuffer::rgbSpec vdriver.h:56 is consulted only by qPixMapConv.cpp:265-268. Qt, SDL2, Wayland and headless all leave it null, which selects the correct Mac defaults. Leave it null.

How front ends are selected

• src/CMakeLists.txt:1 — set(FRONT_ENDS qt x sdl sdl2 wayland CACHE STRING …). A cache list; override with -DFRONT_ENDS="qt;gnustep".
• :102-107 — every directory is unconditionally added; each decides for itself whether to create its target, guarded on its dependency being found qt/CMakeLists.txt:4.
• :605-610 — requested list intersected with what actually built.
• :612-637 — one executable per front end, executor-<name>, all from the same main.cpp; front-end-headless links into every one.
• :641-647 — the first surviving entry wins the plain executor name.

Naming contract: library target front-end-<name>, directory src/config/front-ends/<name>/, and PUBLIC . on the include directories. Adding one is three edits plus a new CMakeLists.txt.

Runtime and compiler

Flags emitted by the ng combo, derived from gnustep-make's library-combo.make and common.make:

-fobjc-runtime=gnustep-2.2 -fblocks -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1
-fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS
link: -fexceptions -lobjc -lgnustep-base -lgnustep-gui

Objective-C++ mixing is fully supported: gnustep-make has a dedicated .mm rule, and libobjc2 has ENABLE_OBJCXX on by default. libobjc2 itself needs C++20 to build, but it is a separate shared object, so a C++17 consumer is fine. ARC works on Linux and is per-file, so ARC and manual-retain translation units mix freely — though this codebase is manual throughout.

Precedent

GNUstep's own android-examples compiles a .mm from CMake via gnustep-config with no enable_language. libobjc2 is itself a CMake project with Ubuntu CI. No Gershwin-specific build convention was located.

8,453 lines excluding HFS_XFer. Every file is dual-compiled #ifndef OPENSTEP. The NEXTSTEP branch is finished, shipped code; the OpenStep branch is an abandoned 1997 port.

The framebuffer bridge

Two buffers. The guest one MacViewClass.m:103-105, allocated :470-473; the host one :89-95, page-aligned :465, in 16-bit RGB 4:4:4 declared once at :408-414.

The aliasing trick — the image rep is built around the client-owned buffer, so plain C stores are visible to it with zero copy MacViewClass.m:483-499. There is no shared memory, no framebuffer device, and no Display PostScript pixmap.

The blit :612-712 does not use setNeedsDisplay:. It grabs the drawing context from arbitrary emulator code, sets a multi-rect clip, and redraws the whole bitmap :696-709:

[self_view lockFocus];
NSRectClipList (nxr, num_rects);
[current_screen_bitmap draw];
[self_view unlockFocus];

Two supporting details that matter: [self allocateGState] :168, :243 — "since we will be repeatedly focused on" — without which per-frame lockFocus is ruinous; and the Y-flip per rect :693. drawRect: :340-393 exists only for genuine expose events and does the same twenty-line redraw.

Event loop

AppKit owns it. The emulator is a coroutine on a hand-built second stack, on the same thread. contextswitch() NEXTmain.m:110-168 is inline assembly — m68k at :127-138, i386 at :139-164 — pushing callee-saved registers, 108 bytes of FPU state and segment registers, then swapping stack pointers and returning into the other side.

The pump is - step MacViewClass.m:1059-1112: run guest code continuously until the host has an event waiting, then yield. Driven by a timer — on OpenStep, an NSTimer at .00000001 seconds :135-149, i.e. as fast as the run loop permits.

Re-entrancy is ugly. drawRect: can itself context-switch during printing :376-382. Clipboard services drive the guest synchronously by posting a synthetic Mac event and burning exactly three context switches :2626-2647, :2667-2679 — three, because that empirically worked.

Window model

One window for the entire Mac screen. grep -rni rootless over the whole 2008 tree returns zero hits. The class comments apologise MacViewClass.m:39-45:

/* NOTE: This isn't a very good NEXTSTEP object, because much of its
 * data is stored in static variables, instead of in instance
 * variables.  That means we can only have one instantiation. */

Backed by static MacViewClass *self_view; :77, which every C entry point reaches through. vdriver_init() :431-463 resizes the host window to the whole Mac screen. The nib confirms it: one WindowTemplate containing one CustomView.

Colour and depth

Guest depths 1, 2, 4, 8 only — no direct colour ever :784. Two host classes, detected once: colour, or 2-bit grayscale :170-171, :246-247, which forces vdriver_fixed_clut_p — the Mac is told it has a CLUT it cannot change :173-181. Conversion tables are built lazily :635-660. The entire "conversion" for the native NeXT display is *d++ = ~*s++ :553-608 — polarity inversion, unrolled four times.

Keyboard

The front end's entire job is: produce a Mac virtual key code and call callbacks_->keyboardEvent(down, mkv). KCHR lookup, KeyTranslate, dead keys, autokey and the key map all live in the core eventsink.cpp:42-68.

-[NSEvent keyCode]  →  x_keycode_to_mac_virt[]  →  MKV_*  →  keyboardEvent()

Ignore -[NSEvent characters] entirely. The classic code used charcodes because ROMlib wanted them; the modern core runs the guest's own KCHR, so host-translated characters would double-translate.

Modifiers are keys, not flags. ROMlib_GetModifiers() osevent.cpp:223-239 derives everything by testing the key map — ROMlib_GetKey(MKV_CLOVER) and friends. There is no flags path. The front end must deliver explicit down/up events for MKV_LEFTSHIFT 0x38, MKV_CLOVER 0x37, MKV_LEFTOPTION 0x3a, MKV_LEFTCNTL 0x3b, MKV_CAPS 0x39 and the right-hand variants 0x3c–0x3e. Constants at rsys/keyboard.h:94-211.

Tables available across the tree, should you need another space:

Mouse

Trivially thin in the modern tree qt.cpp:84-103: forward view coordinates to mouseButtonEvent / mouseMoved. No Y-flip, no clamping — the core expects top-left origin. Override -isFlipped to return YES and all of the 1993 code's vdriver_height - y arithmetic NEXT.c:576, :597 disappears.

Required: [window setAcceptsMouseMovedEvents:YES], -acceptsFirstMouse: → YES, and folding right-button into left for one-button Mac semantics NEXT.c:635-636, :644-645. GNUstep's X11 backend generates NSMouseMoved unconditionally when no button is down and has full scroll-wheel support; classic Mac has no wheel, and IEventListener has no scroll callback, so drop those.

Sound

Interface is SoundDriver sound/sounddriver.h:20-34 — a pull/hunger model where HungerStart() returns a buffer plus a time window, the core fills it, the driver plays it. Default is SoundFake sounddriver.cpp:18-24.

NSSound cannot serve this. GNUstep's implementation loads only complete files (-initWithContentsOfFile:, -initWithData:) and streams them through GSSoundSource→GSSoundSink plugin bundles with a fixed 4096-byte buffer. There is no application-supplied PCM callback and no streaming API — no equivalent of SDL_AudioCallback or HungerStart. Only two sinks exist, libao and OSS. The code carries a FIXME admitting it grabs "the first available sink/device for now," and gnustep-dev described it in 2012 as "a bit of a mess" they'd like to revisit but which "doesn't seem likely in the foreseeable future." The architecture is unchanged on master.

NSBeep is fine for beepAtUser() — compare the X front end using XBell x.cpp:792-797.

Printing

Do nothing. print/prPrinting.cpp:452-516 already generates PostScript and popens it to a program read from the INI file's [Printer] section :461-467, falling back to a spool file. print/PSprint.cpp is 1,200+ lines of QuickDraw-to-PostScript, entirely independent of any front end. Printing is not part of the VideoDriver interface at all.

NEXTprint.m's ROMlib_availableFonts exists only in the NEXTSTEP branch and its only modern call site is guarded by a macOS macro PSprint.cpp:1169. On Linux these are dead declarations. MacPrintClass.h declares a class with no .m anywhere in the tree and zero references.

Clipboard

This is where the 1990s code exceeds the modern tree. PutScrapX MacViewClass.m:1874-2038 handles five Mac types — TEXT, EPS , RTF , TIFF, PICT — each cached with its own generation counter so a multi-flavour copy declares all flavours atomically :1906-1970. Text and RTF get CR↔LF conversion and charset transcoding :1915-1916, :1942-1943. RTF additionally gets a synthesised \fonttbl spliced in by insertfonttbl() NEXT.c:720-760, walking the guest's own FONT/FOND resources.

GetScrapX :2042-2193 reads only if [pasteboard changeCount] > ROMlib_ourchangecount :2105-2106 — the guard that stops it clobbering the guest's own scrap.

NSPasteboard maps onto the old code almost line for line. Two risks: it is a client of the external gpbs daemon, auto-launched via NSTask NSPasteboard.m:1985-2036 but a packaging concern; and cross-application interop is documented as weak — gnustep-dev in 2011: "Copy/paste from X11 apps to GNUstep doesn't work well (only plain text was working)," with the root cause being exactly the type-list update that getScrap's probe depends on. Keep the raw X11 path as a fallback.

Bitmap drawing — the performance landmines

NSDrawBitmap() is real Functions.m:346 but allocates and releases a temporary NSBitmapImageRep on every call, then enters the same path as -[NSBitmapImageRep draw]. Strictly worse. Keep the aliasing-rep approach.

Indexed/CLUT bitmaps are genuinely absent — NSCustomColorSpace and NSNamedColorSpace are declared NSGraphics.h:56, 60 with zero branches in NSBitmapImageRep.m. Irrelevant here, because Executor converts indexed to RGB before AppKit ever sees it.

CoreGraphics is not available. -[NSImage CGImageForProposedRect:context:hints:] is declared in a category NSImage.h:489-494 with no implementation anywhere — calling it raises "does not recognize selector."

Drawing performance

Invalidation is real dirty-rect accumulation: NSView maintains _invalidRect and propagates up the superview chain. All three backing-store types are genuinely distinguished by X11 — buffered and retained get an offscreen pixmap XGServerWindow.m:~1732.

Escape hatch. -[NSWindow windowRef] is implemented NSWindow.m:5955 and on X11 returns a gswindow_device_t * exposing Display *display; Window ident; Drawable buffer; x11/XGServerWindow.h:83-104, from which XShmPutImage is mechanically reachable. Two caveats: it is unverified whether distribution -dev packages install that internal header, and no evidence was found that anyone has ever done this — no blog post, list thread or issue. The one demonstrated GPU path is NSOpenGLView with a real GLX backend.

Window level and style — the constraint on rootless

Window-manager dependency is generic rather than WindowMaker-specific — _checkWindowManager XGServerWindow.m:1186-1234 probes three different supporting-WM properties. But per-WM workarounds persist, e.g. :2421: "Without this, iceWM does not let you move the window!"

Wayland: do not plan on it. stylewindow:, setalpha:, setShadow:, restrictWindow:toImage: and shaped windows are all empty stubs WaylandServer.m:602-605, :917-924, :319-322. Levels are consulted once at surface creation via zwlr_layer_shell — wlroots only, unsupported by Mutter and KWin. Only click-through is real.

Backends

libs-back/Source/: art, cairo, fontconfig, gsc, headless, opal, wayland, win32, winlib, x11, xdps. Server ∈ {x11, win32, wayland}; graphics ∈ {cairo (default), art, xlib, opal, headless}. art is not removed — still the fallback when cairo or freetype are missing, still CI-tested, and still being fixed: issue #176, "read back flipped views in the art backend," merged 2026-07-26/27. NSDPSContext exists only under xdps, which requires the dead X11 DPS extension and is unbuildable today — so MacViewClass.m:920 will not compile as written.

libs-opal has OPColorSpaceIndexed.m but it was last touched in 2010, and Opal's backend was non-functional for years until libs-back PR #77 landed 2026-04-30.

NX* to NS* C functions

Mostly clean: NXBeep, NXRunAlertPanel, NXRectFill, NXRectClip, NXRectClipList, NXHighlightRect, NXEraseRect, NXIntersectionRect and NXCopyBits all have direct equivalents. Gone: NXSetRect (use NSMakeRect), and NXConvertRGBToColor/ColorToRGB, since the packed NXColor integer died at the OpenStep transition.

One behavioural gap worth knowing: NXPing has no equivalent. flushGraphics pushes buffered operations but does not block for a server round-trip, and PSWait() is an explicit no-op. Anything depending on NXPing's synchronous semantics is an architectural rewrite, not a substitution.

Gorm cannot open these. Not "with effort" — at all.

All fourteen nib entries are NeXT typedstream version 4, the pre-keyed-archiving format, verified with file(1). English.lproj/Executor.nib/data.nib is typedstream, big endian, v4, system 930; the OpenStep variant's objects.nib is typedstream, little endian, v4, system 1000. The data.classes files are readable ASCII property lists; the archives are not.

The GNUstep wiki is explicit: NIB compatibility covers 10.2 and later; older typed-stream nibs must be converted first. Newer nibs contain keyedobjects.nib; ours contain data.nib and objects.nib. Runtime loading is equally blocked — GSModelLoaderFactory.m dispatches by signature to Gorm, keyed-nib, XIB and gmodel loaders, and there is no typedstream path anywhere. So [NSBundle loadNibFile:] MacAppClass.m:264 fails at runtime, and [NXApp loadNibSection:] Executor_main.m:65 does not compile.

The only import path is: stand up OPENSTEP 4.2 on real hardware or the Previous emulator, run experimental nib2xib, then Gorm. Multi-day archaeology, approximate fidelity, untested against big-endian archives.

How little is actually in them

Extracted via strings plus the readable data.classes. The historical high-water mark (26 KB) held a main menu and eight windows: the game window, splash screen, preferences, a "Death Certificate" crash panel, a bug-report mailer, two registration windows and a serial-number window. The shipped nib is 7 KB and the preferences and splash strings are already absent from it.

The code has rotted away from the nibs badly:

• MacViewClass declares no instance variables at all — @interface MacViewClass:NSView { } MacViewClass.h:326, empty braces. All seven outlets its metadata declares are stale.
• Four of seventeen declared actions are implemented — pause: :2526, abort: :2573, printGame: MacAppClass.m:243, showInfo: :257. The other thirteen are dead.
• SoundGenerator declares eight actions and ten outlets and has no source file anywhere in the tree.
• Executor.project.nib is untouched Project Builder boilerplate — its strings are "My Window" and "UNTITLED". One data.nib is a 76-byte broken build artifact with a 0-byte data.classes.

There is zero menu construction in code — no NSMenu, addItem: or setMainMenu: anywhere. Structure is 100% nib-driven, and MacAppClass.m:118-150 does nothing but copy roughly 25 outlets into global_* C variables so the plain-C core can reach them.

Live UI surface today: one menu, one window plus framebuffer view, one info panel, four actions.

windRootless.cpp:14-46 unions every visible window's structure region, plus the menu bar, plus any open menus, into one region and makes one call:

RgnHandle rgn = NewRgn();
SetRectRgn(rgn, 0,0, qdGlobals().screenBits.bounds.right, LM(MBarHeight));
for(WindowPeek wp = LM(WindowList); wp; wp = WINDOW_NEXT_WINDOW(wp))
    if(WINDOW_VISIBLE(wp))
        UnionRgn(rgn, WINDOW_STRUCT_REGION(wp), rgn);
vdriver->setRootlessRegion(rgn);

Qt consumes it as a shape mask on a single fullscreen window qt.cpp:244-256 — window->setMask(qtRgn) on the one window created at :216 and maximised at :217. Wayland does the same via set_input_region wayland.cpp:452. Windows are still drawn into the framebuffer; updateBuffer reads it in both modes and the region only selects which spans are copied versus left transparent vdriver.cpp:332.

The four load-bearing levels

1 · Every port shares one bitmap

qGrafport.cpp:91 — every port opened, including each window's:

PORT_BITS(p) = qdGlobals().screenBits;

and screenBits.baseAddr is the main GDevice's PixMap base :33, which is the vdriver framebuffer qGDevice.cpp:77. Windows draw at absolute screen coordinates, clipped by visRgn. No independent backing surface. This is faithful — the real Macintosh worked this way.

2 · The framebuffer is in the guest's address space

qGDevice.cpp:76 calls SetupVideoMemoryMapping(...); mman.cpp:383-390 installs it in the guest offset table; qGrafport.cpp:59, 72 publish LM(ScrnBase) and LM(ScreenRow). Guest 68k code can and does write directly to screen memory.

Not theoretical — autorefresh.cpp:12-19 exists solely to cope with it:

"This file provides a mechanism to detect when applications are bypassing QuickDraw and writing directly to screen memory. It works by partitioning the screen into NUM_AUTOREFRESH_STRIPS horizontal strips… Each strip is periodically checksummed."

Per-window surfaces are fundamentally incompatible with this. An app poking ScrnBase writes to screen coordinates, not to any window's surface.

3 · Window chrome can be guest code

Frames come from the Window Definition Procedure, invoked as WINDCALL(w, wDraw, 0) windDisplay.cpp:127. Built-in WDEFs blit embedded bitmaps windDocdef.cpp:21-25. But ROMlib_windcall windMisc.cpp:511-533 does LoadResource(defproc) — the WDEF is a resource, which can come from the application's own resource fork and execute as guest 68k code. No host titlebar can reproduce arbitrary custom chrome.

4 · The guest manages its own windows

C_FindWindow windMouse.cpp:27-60 walks Executor's LM(WindowList) in Z-order and hit-tests in global coordinates. DragTheRgn windMisc.cpp:120-215 implements dragging by XOR-ing a grey outline into the shared framebuffer and polling to mouse-up. Occlusion is computed by Executor via CalcVis/CalcVisBehind/PaintBehind windMisc.cpp:369-434, called from about ten sites. Hand stacking to the host WM and its z-order can disagree with visRgn — which is what QuickDraw clips against.

What per-window would actually require

• Redirect every window's PORT_BITS to a per-window offscreen buffer — the GWorld machinery exists qGWorld.cpp.
• Rewrite CalcVis/PaintBehind to stop computing occlusion.
• Suppress or reimplement the WDEF, synthesising Mac part-codes from host events.
• Intercept DragWindow/GrowWindow/ZoomWindow, defer to the host WM, and reflect results back into WindowList.
• Accept that any app writing to ScrnBase breaks — precisely the population autorefresh.cpp exists to serve.
• Plus the five missing GNUstep window features from §7.

Multi-month change to the most compatibility-sensitive subsystem, with a guaranteed tail of app-specific breakage. Not a front-end feature, and emphatically not free.

9,194 lines that look like exactly what a Mac-oriented desktop needs, and are not.

HFS_XFer v2.2, © 1991–92 ARDI. It is not a NeXTSTEP application. It is a classic Mac Toolbox program written in C against ROMlib and linked as a NeXTSTEP binary. The only Objective-C is HFS_XFer_main.m — fourteen lines of boilerplate instantiating Executor's own NSApplication subclass. The UI is MenuMgr, DialogMgr, StandardFile and TextEdit.

Operations, from file_funcs[] HFS_XFer.c:20: Copy Disk, Move Files, Copy Files, Rename, Delete, New Folder, Quit. The transfer is HFS to HFS, using Mac File Manager calls on both sides — no host-filesystem path, no AppleDouble, MacBinary or BinHex conversion. Host access happens only because ROMlib maps a Unix directory into a fake Mac volume. The Info panel concedes: "No System 7 floppies / No fancy file conversions."

The HFS engine

Limits, even setting endianness aside: 512-byte physical blocks hardcoded; allocation block numbers are unsigned short throughout, giving the classic 65,535-block ceiling; byte offsets are signed long, so 2 GB on 32-bit. And in practice far tighter — helper.c backs the entire volume with static char buf[NBIGBLOCKS * BIGBLOCK], 144 × 20 KB = 2.88 MB, with TransPhysBlk doing memcpy into it. It only ever worked on floppies.

Defects found in passing

1. Inverted bounds check — helper.c:238 reads if (firstbigblock >= 0 || lastbigblock < NBIGBLOCKS). That must be &&. As written, an out-of-range block passes the guard and the following memcpy runs past the static array.
2. Uninitialised reads — transferer.c:397-400 reads hpb and vrn on a path where neither is populated.
3. Unbounded sprintf — HFS_XFer.util.c:135, 168 formats from argv into fixed 50- and 100-byte buffers.

The %-prefixed files

Not backups and not editor artifacts — AppleDouble sidecars, the convention A/UX and ARDI's tools used to store Mac forks on a Unix filesystem. file(1) confirms every one. Most are the 198-byte no-resource-fork case carrying only type and creator. Two carry real payload: %HFS_XFer.%B9 is 8,910 bytes, type PROJ creator KAHL — a THINK C project file, where %B9 is hex-escaped 0xB9, which is π in MacRoman, so the file is HFS_XFer.π. And %HFS_XFer_DA is 23,387 bytes, type DFIL creator DMOV — a Font/DA Mover suitcase holding the compiled Desk Accessory. Their paired data forks are 0 bytes.

The Desk Accessory

A genuine 68k DRVR code resource, not a NeXTSTEP component. Entry point is int main(cntrlParam *pb, DCtlPtr dctlp, int n) dispatching on open/control/status/close HFS_XFer_DA/HFS_XFer.c:670, with SetUpA4.h and RememberA4()/SetUpA4() bracketing every callback — the THINK C idiom for a code resource with no A5 world. Its context in practice is Executor itself: as a DA it appears under the Apple menu of whatever Mac application is running, so files could be moved without quitting. Functionally identical to the main app — xbar2.h is seventeen one-line macros hard-wiring every call to the real trap.

Read closely

Archaeology

Stated plainly, because a review that hides its gaps is worse than one that names them.

• Nothing was compiled or executed. No GNUstep toolchain, no clang, no Gorm on the review machine.
• The literal output of gnustep-config --objc-flags and --gui-libs on a current install. All flags given are derived from gnustep-make's own makefiles, not observed.
• Whether distribution -dev packages install libs-back/Headers/x11/XGServerWindow.h, which gates the raw-Xlib blit escape hatch.
• Any GNUstep drawing benchmark newer than 2015.
• Whether recent binutils fixed the GNU ld / v2-ABI problem, or whether lld remains strictly necessary. gnustep-make's own check admits it has no accurate test and only warns.
• Current first-hand bug reports for window levels under KWin, Mutter or i3 — the _NET_WM_STATE_ABOVE gap is inferred from source only.
• Whether [NSGraphicsContext graphicsPort] is populated with a live cairo context on the on-screen path.
• Gershwin's own build conventions — the project was not located from the review environment.
• CMake's issue tracker for prior OBJCXX-on-Linux reports; automated fetching is blocked, so "not checked" rather than "nothing there."