In my previous post, I described how Cursor and I ported a suite of OpenWindows DeskSet tools to modern RHEL. That work gave us a functional desktop — file manager, console tool, CD player, mail reader, system monitors — all running on top of XView and olvwm. But one piece was still missing: the tool that created all those applications in the first place.

What Was DevGuide?

Sun's OpenWindows Developer's Guide — known internally as guide — was a visual interface builder for XView applications. It shipped as part of the OpenWindows SDK on Solaris 2.x and allowed developers to drag and drop OPEN LOOK widgets onto a canvas, set their properties through editors, wire up event connections between objects, and generate compilable C code and .G (GIL) interface files.

Think of it as the Solaris equivalent of Visual Basic's form designer or Glade for GTK — except it was built on XView, spoke ToolTalk, and predated all of them. It was the tool that professionals at Sun and in the industry used to build OPEN LOOK applications throughout the early 1990s.

DevGuide was never open-sourced. When Sun released the XView libraries under a free license, they included the runtime libraries (libguidexv, libguide) and the header files, but the guide binary itself remained proprietary. The source code, as far as anyone knows, was lost when Sun was acquired by Oracle. All that survives is a Solaris x86 binary from the SDK.

A Previous Attempt: DeafGuide (1995)

We were not the first to try. In late 1995, two students at the Haagse Hogeschool in the Netherlands — Pascal Van Dam and Jasper v.d. Horst — started a project called DeafGuide, described as a "Rapid Prototyper à la Sun's devguide for XView 3.2." It was a school project, built from scratch rather than from the Solaris binary, aiming to be "as much DevGuide compatible as is (legally) possible." They planned to generate C++ code for the UIT libraries and support the SlingShot extensions, with a GIL-3 compatible grammar and a first subset by late February 1996.

DeafGuide reached version 0.03 and could display interface browsers with object hierarchies, but the project appears to have ended with the school term. It was an ambitious effort for two students working without access to the original source, and it deserves to be remembered.

A Binary and a Decompiler

The starting point was a single file: guide, a 32-bit Solaris x86 ELF binary, roughly 400 KB. It was not stripped — it retained its symbol table, which meant function names, global variable names, and string literals were all intact. This was extraordinarily fortunate.

Cursor drove Ghidra, the NSA's open-source reverse engineering framework, in headless mode to decompile the binary. Ghidra's decompiler turned the x86 machine code back into approximate C, function by function. The output was not pretty — variables named iVar3, casts everywhere, control flow reconstructed from jump tables — but the structure was there. Each function's purpose could be understood by reading the decompiled output alongside the surviving symbol names and string constants.

The binary contained approximately 900 functions across roughly 30 source files, organized into subsystems: one file per widget type's property editor (gca.c for control areas, gbt.c for buttons, gse.c for settings, and so on), plus core infrastructure for selection, events, object management, code generation, project files, and the connection editor.

The Reconstruction Process

This was not a weekend project. The reconstruction has spanned several weeks of evening sessions, each one following the same pattern:

1. Pick a subsystem or function that was blocking progress (a crash, a missing feature, a property editor that did nothing when opened).
2. Find the function in Ghidra's decompiled output. Read the pseudocode, correlate it with XView API calls and the surviving header files.
3. Rewrite the function in clean C89, matching the original behavior but using modern conventions (bounds-checked snprintf instead of sprintf, NULL guards on xv_get return values).
4. Build on the RHEL 8 build host, test on the actual X11 display, iterate.

The collaboration with Cursor was essential here. I would paste Ghidra's decompiled output of a function — often 50 to 200 lines of mangled C with cryptic variable names — and describe what it was supposed to do based on the symbol name and context. Cursor would reconstruct the function in idiomatic C, inferring the struct layouts from how fields were accessed, matching XView API patterns it had seen in the surrounding codebase, and preserving the exact calling conventions required for ABI compatibility.

Some functions were straightforward — a property editor's activate callback that reads an object's fields and populates a panel. Others were deeply entangled with XView internals — the custom panel repaint procedure that draws selection handles over controls, the connection editor's property-mapping infrastructure, the project file serialization format.

What We Rebuilt

As of today, the reconstructed guide binary can:

• Load and display .G interface files with full visual fidelity — base windows, popup windows, control areas, and all widget types render correctly.
• Select, deselect, move, and resize objects on the canvas with blue grab handles and rubber-band outlines, matching the original Solaris UX.
• Open property editors for all 17 widget types (buttons, text fields, settings, sliders, gauges, scrolling lists, drop targets, messages, menus, and more), with color palette selection working through the editors.
• Manage projects — open, save, and navigate multi-interface projects through the project browser window.
• Edit connections between objects through the connection editor.
• Generate C code from interface definitions.

The reconstructed guide codebase now totals over 66,000 lines of C across 29 source files in the main program alone (120,000 lines including the support libraries). We went from 262 stub functions down to about 29 remaining stubs (mostly code-generation settings dialog callbacks and config plumbing that don't affect the core editing workflow).

Debugging Without Source: A Case Study

One example illustrates the nature of this work. After implementing the selection UX — blue rectangles around selected controls, grab handles on panes — we hit a regression where the blue squares would persist on control areas after deselecting them. Every time you clicked a new object, the old handles stayed behind, accumulating on screen.

My first instinct was that the X11 drawing mode was wrong — GXcopy vs. GXxor, the classic toggle-drawing technique. I spent time switching drawing modes and tweaking the repaint cycle. Nothing worked.

The breakthrough came from stepping back and reading the git history. Using git log and git show on the handful of commits that touched the selection code, I found that a working deselection mechanism — XClearWindow followed by a full panel repaint — had been deliberately removed in a later commit to fix a segfault on canvas panes. The fix had over-generalized: it replaced the deselect logic for all pane types with a simpler call that didn't properly erase the handles.

The solution was to split the behavior by object type: control areas (which are XView panels) got the full clear-and-repaint path restored, while canvas panes kept the simpler path that avoided the crash. Two different pane types, two different deselection strategies. The kind of distinction that only becomes obvious when you understand both the XView internals and the specific crash that motivated the original change.

A Tribute to Sun Microsystems

This project exists because Sun Microsystems believed in open systems. They released XView, OLIT, ToolTalk, and the OpenWindows runtime libraries under open licenses. They published comprehensive programmer's guides and reference manuals. They designed an internally consistent UI specification — OPEN LOOK — that was thoughtful, coherent, and ahead of its time in many ways.

DevGuide was the crown jewel of their developer experience. It embodied the idea that building a GUI application should be visual, interactive, and fast. You drew your interface, you set properties, you wired up connections, you hit "Generate" and got compilable code. In 1992.

The fact that we can reconstruct this tool thirty years later — from a binary, using a decompiler, on an operating system the original authors never targeted — is a testament to how well it was engineered. The code was clean enough that Ghidra could produce readable decompiled output. The symbol table was preserved. The API boundaries between the tool and the XView library were crisp enough that the reconstructed functions could be tested incrementally. Good engineering survives, even when the source code doesn't.

To the engineers at Sun who built DevGuide, the XView toolkit, and the OPEN LOOK specification: thank you. Your work deserved better than to be forgotten in an acquisition. We're keeping it alive.

What's Next

The remaining work is mostly polish: the code generation settings dialog, the resource/config file plumbing, and wiring up the Color Chooser popup (the palette grid already works). The core editing workflow — load, select, edit properties, save, generate code — is functional today.