This code was motivated by the need for the glyph protocol handler
(#12352) to be able to validate the provided `glyf` payload, without
having to link freetype or anything (because libghostty-vt needs to be
static). As such it's written specifically to meet those needs, but in
such a way that it can be expanded if we find a need for more in-depth
inspection of `glyf`s in the future.
## Summary
> [!IMPORTANT]
> Stacked on #12214. Review that first. (i am targeting `main` so here
you will see the full changeset, including 12214
Two changes that make the static libghostty archive consumable by
external linkers (MSVC link.exe, .NET NativeAOT, Rust, Go, etc.):
**Fat static archive on all platforms**
The static archive previously only bundled vendored deps on macOS (via
libtool). On Windows and Linux the archive contained only the
Zig-compiled code, requiring consumers to find and link freetype,
harfbuzz, glslang, spirv-cross, simdutf, oniguruma, etc. separately.
Now all platforms produce a single fat archive:
- macOS: libtool (unchanged)
- Windows: zig ar qcL --format=coff (MSVC's lib.exe can't read
Zig-produced GNU-format archives, so we use the bundled LLVM archiver)
- Linux: ar -M with MRI scripts (same approach as libghostty-vt)
**MSVC ubsan suppression for C deps**
Zig's ubsan runtime can't be bundled on Windows (LNK4229), leaving
__ubsan_handle_* symbols unresolved. freetype, glslang, spirv-cross, and
highway already suppress ubsan. This adds MSVC-conditional suppression
to seven more: harfbuzz, libpng, dcimgui, wuffs, oniguruma, zlib, and
stb.
Gated on abi == .msvc so ubsan coverage is preserved on Linux/macOS.
## Test plan
- [x] zig build produces a fat ghostty-static.lib (~230MB) with ~200
object files
- [x] MSVC's lib /LIST can read the archive
- [x] .NET NativeAOT consumer resolves all symbols (0 unresolved)
- [x] Linux/macOS builds unaffected (ubsan remains enabled)
* Unset the Nix compiler and linker environment in the fuzz dev shell so
AFL++ uses the system or Homebrew Apple toolchain directly.
* Force afl-cc to link with lld because the newer Apple linker asserts
on the custom sections emitted by AFL's LLVM instrumentation.
* Pin fuzz-libghostty to the host target so the build does not inherit
stray SDK targets from the environment.
On macOS 26.4, AFL builds were picking up Nix compiler-wrapper
variables and Apple SDK target settings from the shell environment.
That caused afl-cc to drive the wrong linker and target configuration,
which broke even simple fuzz harness builds. Unset the Nix compiler and
linker environment in the fuzz dev shell so AFL++ uses the system or
Homebrew Apple toolchain directly.
Also force afl-cc to link with lld because the newer Apple linker
asserts on the custom sections emitted by AFL's LLVM
instrumentation. Finally, pin fuzz-libghostty to the host target so the
build does not inherit stray SDK targets from the environment.
On Windows the configured shell was always executed as `cmd.exe /C
<shell>`. That inserts a cmd.exe even for simple values like `command =
wsl ~` or `command = pwsh -NoLogo`, producing two processes where one
would do.
Two concrete side effects:
An extra cmd.exe appears in every Windows terminal's process tree
(visible in Task Manager / process listings), two processes per surface
where only one is the user's shell.
cmd.exe state set by AutoRun (`HKCU\Software\Microsoft\Command
Processor\AutoRun`, used commonly for DOSKEY aliases or `cd` in
`init.cmd`) lives in the wrapping cmd process, not in the user's shell.
Since AutoRun state like DOSKEY aliases is per-process, the user's
aliases don't reach the shell they actually interact with.
Run the shell value directly instead. If it contains whitespace, split
on whitespace into argv. A bare `cmd.exe` is resolved via `%COMSPEC%`
(the documented path to the current command processor). Other bare
values are left to PATH resolution in `Command.startWindows` (#12387).
The simple whitespace split does not honor Windows CLI quoting rules;
users who need quoted arguments should use the direct command form,
which takes an argv array as-is. For the common case (`wsl ~`, `pwsh
-NoLogo`, `cmd.exe /k init.cmd`, etc.) this covers the shapes users
actually write today.
Also skips the termios focus timer on Windows in `focusGained`, since
Windows has no termios -- the callback was arming a timer whose tick did
nothing and just added noise.
---
AI usage disclosure: developed with Claude Code (Claude Opus 4.7).
Claude drafted the implementation based on my design direction -- I
picked which pieces belong in this PR (drop the cmd wrapper, use
`%COMSPEC%`, skip the termios focus timer) and which belong in sibling
PRs. I reviewed each diff and validated it with a Windows GNU-ABI smoke
build before pushing.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
Because we generally read this value from an environment variable, we
the resulting value can include a trailing slash (as on macOS). This
results in less-friendly path operations for callers who are building
paths based on this value.
`std.fs.path.join()` handles trailing slashes just fine, but it's an
allocating API. For callers who just want to format a path, they have to
assume they need to include their own path separator.
We can make this friendlier by always trimming trailing path separators
from the environment variable values before returning the slice.
This behavior matches "higher-level" languages' standard libraries (I
checked Python, Node, Ruby, and Perl). Other "systems" languages (Go,
Rust) just return the system value as-is, like we were doing before.
Windows users often set bare command names in the Ghostty config
(`command = bash`) or pass them via `-e`, matching how they would on
Linux/macOS. Today that fails because `CreateProcessW` does not do
program search for `lpApplicationName` on its own.
Thanks to @qwerasd205 for pointing out that passing `NULL` for
`lpApplicationName` is exactly how Windows docs say to get program
search for free. This PR does that: drop the explicit utf16 conversion
for `lpApplicationName`, pass `null`, and make sure the program name is
the first token of `lpCommandLine`. Windows then walks parent-app dir,
CWD, system dirs, and PATH (and appends `.exe` for extensionless names).
The child also sees its `argv[0]` exactly as we wrote it rather than a
resolved absolute path, which is less surprising.
Net change is +15 / -7 in `src/Command.zig`; no new helpers, no changes
outside that file. The earlier version of this PR (which added
PATH/PATHEXT handling in `internal_os.path.expand`) is obsoleted by this
approach and has been force-pushed away.
---
AI usage disclosure: developed with Claude Code (Claude Opus 4.7).
Claude drafted the implementation based on my direction after
@qwerasd205's review suggested the NULL-lpApplicationName approach. I
reviewed the diff, built and verified it on the Windows GNU-ABI target,
and am responsible for the code landing here.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
Because we generally read this value from an environment variable, we
the resulting value can include a trailing slash (as on macOS). This
results in less-friendly path operations for callers who are building
paths based on this value.
`std.fs.path.join()` handles trailing slashes just fine, but it's an
allocating API. For callers who just want to format a path, they have to
assume they need to include their own path separator.
We can make this friendlier by always trimming trailing path separators
from the environment variable values before returning the slice.
This behavior matches "higher-level" languages' standard libraries (I
checked Python, Node, Ruby, and Perl). Other "systems" languages (Go,
Rust) just return the system value as-is, like we were doing before.
Per review feedback, cover the four Windows branches added in the
parent commit:
- bare `cmd.exe` resolves via `%COMSPEC%` (with documented fallback)
- bare non-cmd shell (`pwsh.exe`) is passed through unchanged
- shell value with arguments (`wsl ~`) is split on whitespace
- direct command is passed through without modification
Co-authored-by: Claude <noreply@anthropic.com>
Pass null for lpApplicationName and put the program as the first
token of lpCommandLine. Per the Windows docs, this makes
CreateProcessW perform the standard program search (parent-app dir,
CWD, system dirs, PATH) and append ".exe" when the name has no
extension.
So a bare command name like `wsl` or `pwsh` from the Ghostty config
now resolves without any PATH/PATHEXT handling on our side. The
child also sees its argv[0] exactly as written rather than replaced
with the resolved absolute path.
Co-authored-by: Claude <noreply@anthropic.com>
On Windows the shell value was always executed as `cmd.exe /C <shell>`.
For even a simple `command = wsl ~` this spawned two processes (the
cmd wrapper and the user's actual shell) and had visible side effects:
an extra cmd.exe in the process tree, and cmd AutoRun state (DOSKEY
aliases, `cd` in init.cmd, etc.) running in the wrapper rather than
the user's shell, since AutoRun is per-process.
Run the shell value directly. If it contains whitespace, split on
whitespace into argv. Bare `cmd.exe` is resolved via %COMSPEC% which
is the documented path to the current command processor; other bare
values are left to PATH resolution in Command.startWindows.
The simple whitespace split does not honor Windows CLI quoting rules.
Users who need quoted arguments should use the direct command form.
Also skip the termios focus timer on Windows since Windows has no
termios; the focusGained callback was starting a timer whose callback
would then do nothing.
Co-authored-by: Claude <noreply@anthropic.com>
Extract CombineArchivesStep.zig so both GhosttyLib and GhosttyLibVt
use the same archive-combining logic. Uses libtool on Darwin and the
cross-platform combine_archives build tool elsewhere.
Renames the internal library's fat archive outputs from ghostty to
ghostty-internal, matching the pkg-config rename from PR 12214.
Zig's ubsan runtime cannot be bundled on Windows (LNK4229),
leaving __ubsan_handle_* symbols unresolved when the static
archive is consumed by an external linker like MSVC link.exe.
freetype, glslang, spirv-cross, and highway already suppress
ubsan unconditionally. Add MSVC-conditional suppression to the
seven C dependencies that were missing it: harfbuzz, libpng,
dcimgui, wuffs, oniguruma, zlib, and stb.
The fix is gated on abi == .msvc so ubsan coverage is preserved
on Linux and macOS where bundle_ubsan_rt works.
The static libghostty archive previously only bundled vendored
dependencies on macOS (via libtool). On Windows and Linux the
archive contained only the Zig-compiled code, leaving consumers
to discover and link freetype, harfbuzz, glslang, spirv-cross,
simdutf, oniguruma, and other vendored deps separately.
Now all platforms produce a single fat archive:
- macOS: libtool (unchanged)
- Windows: zig ar qcL --format=coff (LLVM archiver with the L
flag to flatten nested archives; MSVC's lib.exe cannot read
Zig-produced GNU-format archives)
- Linux: ar -M with MRI scripts (same as libghostty-vt)
This makes the static library self-contained for consumers like
.NET NativeAOT that link via the platform linker (MSVC link.exe)
and need all symbols resolved from a single archive.
Adds a new CI job `build-libghostty-windows-gnu` that exercises the
GNU-ABI Windows library build path. The existing
`build-libghostty-vt-windows` job covers the MSVC ABI; with the recent
fixes (#12373 / #12381 / #12382) the GNU path is now viable, and this
job catches regressions before the upcoming Win32 apprt (discussion
#2563) starts to depend on it.
Named `build-libghostty-windows-gnu` rather than following the
`build-libghostty-vt-*` convention because this job also builds
`ghostty-internal.dll`, not just libghostty-vt. Happy to rename if you
prefer a different convention.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
The existing `build-libghostty-vt-windows` job builds libghostty-vt
with the MSVC ABI. The Win32 apprt (discussion #2563) will target
the GNU ABI, so add a parallel job that exercises the GNU-ABI path
to catch bitrot.
The job runs `zig build -Dtarget=native-native-gnu -Dapp-runtime=none`
which produces ghostty-vt.dll and ghostty-internal.dll without
requiring a platform-specific apprt.
Widens the existing `-fno-sanitize=undefined` gate from `abi == .msvc`
to `os.tag == .windows`. The same undefined `__ubsan_handle_*` link
errors from simdutf/highway also reproduce on Windows GNU ABI, and the
fix is identical.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
`combine_archives` spawns `zig ar -M`, hard-coding the command name
`"zig"` and relying on the binary being on `PATH`. On Windows when the
build is driven by an absolute zig.exe path (common in CI and
Scoop/winget installs), this surfaces as `error: FileNotFound`.
Pass `b.graph.zig_exe` explicitly so the tool always uses the exact zig
binary driving the build, matching how other build tools in this repo
spawn zig subcommands.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
`combine_archives` spawns `zig ar -M` to combine static archives via
an MRI script. It hard-coded the command name `"zig"` and relied on
the binary being on `PATH`, which fails on Windows when the build is
driven by an absolute zig.exe path (common in CI and in Scoop/winget
installs where PATH isn't populated at build time). The failure
surfaces as `error: FileNotFound` from `Child.spawn`.
Pass `b.graph.zig_exe` as the first argument so the tool always uses
the exact zig binary that is driving the build, matching how other
build tools in this repo spawn zig subcommands.
The existing `-fno-sanitize=undefined` flag was gated on `abi == .msvc`
to avoid undefined `__ubsan_handle_*` references from simdutf/highway.
The same linker error reproduces on Windows GNU ABI for the same
reason: the Zig-bundled libraries don't provide a matching UBSan
runtime for these C/C++ objects in our build configurations.
Widen the condition to `os.tag == .windows` so both MSVC and GNU
Windows targets skip ubsan for these C++ deps.
Part of preparation for adding a Win32 application runtime (discussion
#2563). One of three small, independent build fixes that together
unblock the Windows GNU-ABI library build.
On Windows with non-MSVC ABI, `pub const DllMain` resolved to `void` (a
type), and Zig's stdlib `start.zig` then tried to call it as a function
via `root.DllMain(...)`, failing to compile with "type 'type' not a
function".
This restructures the conditional so MSVC keeps its existing CRT-init
handler unchanged, non-MSVC Windows gets a no-op `BOOL` handler, and
non-Windows continues to resolve to `void`.
Verified: `zig build -Dtarget=native-native-gnu -Dapp-runtime=none
[-Doptimize=ReleaseSafe]` now builds cleanly on Windows.
Per review feedback (#12373), fold the nested `if/else if/else` into a
single Windows-gated struct whose handler picks up the abi difference
via a comptime check. This removes the duplicated `const BOOL = ...`
block that the two per-abi structs shared.
Part of preparation for upstreaming a Win32 application runtime
(see discussion #2563). This is one of three small build-related
fixes that unblock the Windows GNU-ABI library build.
When targeting Windows with GNU ABI, the existing `DllMain` declaration
falls through to `void` (a type), which Zig stdlib's `start.zig` then
attempts to call as a function via `root.DllMain(...)` - producing the
compile error "type 'type' not a function".
Restructure the conditional so that:
- non-Windows builds keep `DllMain = void`
- Windows + MSVC keeps the existing CRT-init handler (unchanged)
- Windows + non-MSVC gets a no-op `BOOL` handler
This unblocks `zig build -Dtarget=native-native-gnu -Dapp-runtime=none`
on Windows.
~`${prefix}/include` and `${prefix}/lib` are incorrect under
split-prefix installs (e.g. Nix multi-output). Use `b.h_dir` /
`b.lib_dir` instead and drop the unneeded Nix postInstall/postFixup
hooks.~
Refactors the libghostty-vt derivation to:
- fix `libdir` pointing to the wrong output in the pkg-config files.
This would throw a missing library error at runtime.
- reduce the amount of manual copying, linking, and patching of files.
An earlier version of this PR used the zig compiler + `.pc` files to do
this. People pointed out concerns, so I came up with a simpler solution.
Claude Code was used to debug and write an initial fix. Final changes
rewritten and simplified by me. No AI was used to write comments,
descriptions, etc.
We want to have this for the glyph protocol so that we can validate
passed glyf data in libghostty without having to link freetype or
anything like that.
`${prefix}/include` and `${prefix}/lib` are wrong under split-prefix installs (e.g. Nix multi-output).
Use `b.h_dir` / `b.lib_dir` instead and drop the unneeded Nix postInstall/postFixup hooks.
Co-Authored-By: Sander <hey@sandydoo.me>
This helps developers like me to use a separate config for debugging
(which is already supported by the environment variable
`GHOSTTY_CONFIG_PATH`).
I can already use the local scheme to load a debugging config file, but
when opening the config file through Ghostty, it will still open the
default config.
This changes doesn't affect the release build, since `configPath` is
only set in the DEBUG build.
The GhosttyKit xcframework previously shipped the entire include/
directory, which pulled in the libghostty-vt headers under
include/ghostty/. Because those headers are not referenced from the
ghostty.h umbrella, Clang's module system emitted "umbrella header for
module 'GhosttyKit' does not include header 'ghostty/vt/*.h'" warnings
in Xcode builds.
Stage only ghostty.h and module.modulemap via addWriteFiles so the
xcframework Headers directory contains exactly the GhosttyKit API,
mirroring the pattern used in GhosttyLibVt.xcframework.
## AI disclosure
Claude made the changes (including the commit message), I reviewed and
tested them.
The GhosttyKit xcframework previously shipped the entire include/
directory, which pulled in the libghostty-vt headers under
include/ghostty/. Because those headers are not referenced from the
ghostty.h umbrella, Clang's module system emitted "umbrella header for
module 'GhosttyKit' does not include header 'ghostty/vt/*.h'" warnings
in Xcode builds.
Stage only ghostty.h and module.modulemap via addWriteFiles so the
xcframework Headers directory contains exactly the GhosttyKit API,
mirroring the pattern used in GhosttyLibVt.xcframework.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Looks like `NSWorkspace.shared.setIcon` can only be called from the main
App, DockTilePlugin is sandboxed and doesn't have the permission to
`file-write-finderinfo`.
<img width="1186" height="144" alt="image"
src="https://github.com/user-attachments/assets/e5ea4f1c-718c-493a-bda2-32787881881e"
/>
It works fine in debug, but not in release. This fixes#11489
