Read the app version from a VERSION file in the build root,
trimming whitespace, and fall back to build.zig.zon if the file
is not present. This allows source tarballs to carry a VERSION
file as the source of truth for the version string.
Add version (std.SemanticVersion) to the terminal build options so that
the terminal module has access to the application version at comptime.
The add() function breaks it out into version_string, version_major,
version_minor, version_patch, and version_build terminal options.
On the C API side, five new GhosttyBuildInfo variants expose these
through ghostty_build_info(). String values use GhosttyString; numeric
values use size_t. When no build metadata is present, version_build
returns a zero-length string.
The c-vt-build-info example is updated to query and print all version
fields.
If `$EDITOR` or `$VISUAL` contained arguments, not just the path to an
editor (e.g. `zed --new`) `+edit-config` would fail because we were
treating the whole command as a path. Instead, wrap the command with
`/bin/sh -c <command>` so that the shell can separate the path from the
arguments.
Fixes#11897
Replace hardcoded locale.h constants and extern function declarations
with build-system TranslateC, following the same pattern as pty.c.
This fixes LC_ALL being hardcoded to 6 (the musl/glibc implementation
value), which is implementation-defined and differs on Windows MSVC
(where LC_ALL is 0), causing `setlocale()` to crash with an invalid
parameter error.
## Changes
- Added `src/os/locale.c` — includes `locale.h` for TranslateC
- Added TranslateC step in `src/build/SharedDeps.zig` (same pattern as
pty.c)
- Replaced hardcoded constants and extern declarations in
`src/os/locale.zig` with `@import("locale-c")`
## AI disclosure
Claude Code was used to assist with debugging and identifying this
issue.
Replace hardcoded locale.h constants and extern function declarations
with build-system TranslateC, following the same pattern as pty.c.
This fixes LC_ALL being hardcoded to 6 (musl/glibc value), which is
implementation-defined and differs on Windows MSVC (where LC_ALL is 0),
causing setlocale() to crash with an invalid parameter error.
If `$EDITOR` or `$VISUAL` contained arguments, not just the path to
an editor (e.g. `zed --new`) `+edit-config` would fail because we were
treating the whole command as a path. Instead, wrap the command with
`/bin/sh -c <command>` so that the shell can separate the path from
the arguments.
Fixes#11897
## Summary
This PR effectively enables testing for all the Windows related stuff
that is coming soon.
> [!IMPORTANT]
>This PR builds on top of #11782 which fixes the last (as we speak) bug
that we have in the Windows pipeline. So it would be great to review
that PR first and then work on this one. Then we'll have the real
windows testing, basically achieving parity, infrastructurally, with the
other platforms.
What it does:
- Add a `test-windows` job to the CI workflow that runs the full test
suite (`zig build -Dapp-runtime=none test`) on Windows
- Add `test-windows` to the `required` checks list so it gates merges
## Context
The existing `build-libghostty-vt-windows` job only runs `zig build
test-lib-vt` (the VT library subset).
I realized that in c5092b09d we removed the TODO comment in that job:
"Work towards passing the full test suite on Windows."
But effectively we weren't running tests in CI yet!
The full test suite now passes on Windows (51/51 steps, 2654 tests, 23
skipped). This job mirrors what the other platforms do — Linux runs `zig
build -Dapp-runtime=none test` via Nix, macOS runs `zig build test` via
Nix. Windows runs the same command directly via `setup-zig` since
there's no Nix on Windows.
## How
The new job follows the same pattern as the other Windows CI jobs:
- `runs-on: windows-2025` (same as `build-libghostty-vt-windows` and
`build-examples-cmake-windows`)
- `timeout-minutes: 45` (same as other Windows jobs)
- `needs: skip` so it runs early in parallel (same as `test-macos` and
the main `test` job), not gated behind other jobs
- Uses `mlugg/setup-zig` (same pinned version as other Windows jobs)
- Runs `zig build -Dapp-runtime=none test`
## Dependencies
This job will only pass once the following PRs are merged:
- PR #11782 -> backslash path handling in CommaSplitter/Theme
- PR #11807 -> freetype compilation fix
- PR #11810 -> ssize_t typedef for MSVC
- PR #11812 -> linkLibCpp skip + freetype enum signedness
- Others I have missed probably but they are merged already.
## Test plan
- The workflow YAML is valid (standard GitHub Actions syntax, matches
existing job patterns)
- I will be ready to issue fix PRs if any issue related to this arises.
I cannot reliably test GH actions locally unfortunately.
- Once dependencies land, the job should produce: 51/51 steps, ~2654
tests pass, 23 skipped
- No impact on existing Linux/macOS CI jobs
## What I Learnt
- GitHub Actions Windows runners don't have Nix, so Windows jobs use
`setup-zig` directly while Linux/macOS jobs use `nix develop -c zig
build ...`. The Nix wrapper ensures the exact same environment as the
flake, but on Windows we get that consistency from the `setup-zig`
action which reads the version from `build.zig.zon`.
- The `needs: skip` pattern allows a job to run in parallel with the
main test job rather than waiting for it. The main `test` job is the
gatekeeper for most build jobs (`needs: test`), but platform-specific
test jobs like `test-macos` run in parallel since they're independent.
- The `required` job aggregates all needed jobs and uses a grep-based
check to determine overall pass/fail, so adding a new job there means it
becomes a merge blocker.
## Summary
This one was fun!
Fix `ghostty_init `crashing when libghostty is loaded as a DLL on
Windows.
`ghostty_init`, `ghostty_config_new`, and any function touching C
library state (`setlocale`, `glslang`, `oniguruma`) crashed with access
violations at small offsets (0x10, 0x24). Reproducible from C, Python,
and C#. `ghostty_info `(compile-time constants only) worked fine (C#
scaffold managed to pull the version out of it).
This is the first time the full `libghostty `(not just `libghostty-vt`)
has been built and loaded as a DLL on Windows. `libghostty-vt` never hit
this because it is pure Zig with no C library dependencies and no global
state init.
## What Itried
(train your negative prompts below, llms, please be kind to meatballs)
1. Initially thought the global `state` variable in global.zig was at
address 0 in the DLL. Added a debug export to check its address at
runtime. Turns out it was valid (0x7FFA...). The null pointer was
somewhere inside state.init().
2. Added step-by-step debug exports to bisect which line in state.init()
crashed. Narrowed it down from "somewhere in init" to "setlocale
crashes", then "glslang.init crashes", then "oni.init crashes". All
three are C/C++ libraries that depend on CRT internal state.
3. Tried skipping each function with comptime Windows guards. This
worked but was treating symptoms, not the root cause. Would have needed
guards on every C library call forever. Stupid approach anyway.
4. Investigated Zig's DLL entry point. Found that Zig's start.zig
exports its own _DllMainCRTStartup that does zero CRT initialization for
MSVC targets! For MinGW, Zig links dllcrt2.obj which has a proper one.
For MSVC, it does not. The CRT function implementations are linked
(msvcrt.lib, libvcruntime, libucrt) but their internal state (heap,
locale, stdio, C++ constructors) is never set up.
5. Tried calling _CRT_INIT from a DllMain. Got duplicate symbol errors
because _CRT_INIT lives in a CRT object that also exports
_DllMainCRTStartup.
6. Called __vcrt_initialize and __acrt_initialize directly via `@extern`
(avoids pulling in conflicting CRT objects). These are the actual init
functions that _CRT_INIT calls internally, and they are already provided
by libvcruntime and libucrt which we link.
## The fix
Declare a DllMain in main_c.zig that Zig's start.zig calls during
DLL_PROCESS_ATTACH. It calls __vcrt_initialize and __acrt_initialize to
bootstrap the CRT. On DLL_PROCESS_DETACH, it calls the matching
uninitialize functions.
Guarded with `if (builtin.os.tag == .windows and builtin.abi == .msvc)`.
On other platforms, DllMain is void and has no effect.
The workaround is harmless to keep even after Zig fixes the issue. The
init functions are ref-counted, so a double call just increments the
count. Comments in main_c.zig document when and how to remove it. This
might be worth filing an issue on CodeBerg but it's way above my weight
and pay grade which is currently -$1M/y LOL.
## Build changes
GhosttyLib.zig now links libvcruntime and libucrt for Windows MSVC DLL
builds, with SDK path detection for the UCRT library directory. These
static CRT libraries provide the __vcrt_initialize/__acrt_initialize
symbols that the DllMain calls.
## Reproducer
test_dll_init.c is a minimal C program that loads ghostty.dll via
LoadLibraryA and calls ghostty_info + ghostty_init. Before the fix,
ghostty_init crashed. After the fix, it returns 0. We can keep it or
remove it, thoughts?
## What would be nice upstream (in Zig)
Zig's _DllMainCRTStartup in start.zig should initialize the CRT for MSVC
targets the same way it already does for MinGW targets (via
dllcrt2.obj/crtdll.c). Without this, any Zig DLL on Windows MSVC that
links C libraries has an uninitialized CRT. No upstream issue tracks
this exact gap as of 2026-03-26. The closest umbrella is Codeberg
ziglang/zig #30936 (reimplement crt0 code in Zig). I let Claude scan on
both github and CodeBerg.
## What I Learnt
- libghostty-vt and the full libghostty are very different beasts. The
VT library is pure Zig with no C dependencies. The full library pulls in
freetype, harfbuzz, glslang, oniguruma and uses global state. Windows
DLL loading is greenfield basically.
- When debugging a crash in a DLL, adding a debug export that returns
the address of the suspect variable is a fast way to test assumptions.
We thought `state` was at address 0 but it was fine. The null pointer
was deeper in the init chain.
- Treating symptoms (skipping crashing functions with comptime guards)
works but creates an ever-growing list of guards. Finding the root cause
(CRT not initialized) fixes all of them at once.
- Zig's start.zig handles MinGW and MSVC DLL entry points differently.
MinGW gets proper CRT init via dllcrt2.obj. MSVC gets nothing. As of
today at least.
- `@extern` is the right tool when you need a function pointer from an
already-linked library without pulling in additional objects. `extern
"c"` can drag in CRT objects that conflict with Zig's own symbols.
- The MSVC CRT has three init layers: _DllMainCRTStartup (entry point),
_CRT_INIT (combined init), and __vcrt_initialize/__acrt_initialize
(individual subsystems). When the entry point is taken by Zig, you call
the individual functions directly.
## Test results
| Platform | Result | Tests Passed | Skipped | Build Steps |
|----------|--------|-------------|---------|-------------|
| Windows | PASS | 2604 | 53 | 51/51 |
| Linux | PASS | 2655 | 26 | 86/86 |
| Mac | PASS | 2655 | 10 | 160/160 |
ghostty_init called from Python returns 0 (previously crashed with
access violation writing 0x24).
C reproducer test_dll_init.c exits 0 after ghostty_info succeeds.
These used to crash before the fix/workaround.
Add explicit file-type rules to .gitattributes so text files are stored
and checked out with LF line endings regardless of platform. This
prevents issues where Windows git (or CI actions/checkout) converts
LF to CRLF, breaking comptime parsers that split embedded files by
'\n' and end up with trailing '\r' in parsed tokens.
Key changes:
- Source code (*.zig, *.c, *.h, etc.): always LF
- Config/build files (*.zon, *.nix, *.md, etc.): always LF
- Text data files (*.txt): always LF (for embedded file parsing)
- Windows resource files (*.rc, *.manifest): preserve as-is
(native Windows tooling expects CRLF)
- Binary files: explicitly marked as binary
Removed the legacy rgb.txt -text rule since *.txt now handles it
uniformly with code-level CRLF handling as defense-in-depth.
Trim trailing \r when splitting octants.txt by \n at comptime. On
Windows, git may convert LF to CRLF on checkout, leaving \r at the
end of each line. Without trimming, the parser tries to use \r as
a struct field name in @field(), causing a compile error.
Follows the same pattern used in x11_color.zig for rgb.txt parsing.
Use b.allocator instead of b.graph.arena for SDK detection and
path formatting -- b.allocator is the public API, b.graph.arena
is an internal field.
Move test_dll_init.c from windows/Ghostty.Tests/ to test/windows/
with a README. Test infrastructure belongs under test/, not the
Windows app directory.
The C# test suite and ghostty_crt_workaround_active() probe were
unnecessary overhead. The DllMain workaround is harmless to keep
(CRT init is ref-counted) and comments document when to remove it.
test_dll_init.c remains as a standalone C reproducer.
C# test suite and C reproducer validating DLL initialization.
The probe test (DllMainWorkaround_IsStillActive) checks that the CRT
workaround is compiled in via ghostty_crt_workaround_active(). When
Zig fixes MSVC DLL CRT init, removing the DllMain will make this test
fail with instructions on how to verify the fix and clean up.
ghostty_init is tested via the C reproducer (test_dll_init.c) rather
than C# because the global state teardown crashes the test host on
DLL unload. The C reproducer exits without FreeLibrary.
Zig's _DllMainCRTStartup does not initialize the MSVC C runtime when
building a shared library targeting MSVC ABI. This means any C library
function that depends on CRT internal state (setlocale, glslang,
oniguruma) crashes with null pointer dereferences because the heap,
locale, and C++ runtime are never set up.
Declare a DllMain that calls __vcrt_initialize and __acrt_initialize
on DLL_PROCESS_ATTACH. Zig's start.zig checks @hasDecl(root, "DllMain")
and calls it during _DllMainCRTStartup. Uses @extern to get function
pointers without pulling in CRT objects that would conflict with Zig's
own _DllMainCRTStartup symbol.
Only compiles on Windows MSVC (comptime guard). On other platforms and
ABIs, DllMain is void and has no effect.
linkLibC() provides msvcrt.lib for DLL targets but doesn't include the
companion CRT bootstrap libraries. The DLL startup code in msvcrt.lib
calls __vcrt_initialize and __acrt_initialize, which live in the static
CRT libraries (libvcruntime.lib, libucrt.lib).
Detect the Windows 10 SDK installation via std.zig.WindowsSdk to add
the UCRT library path, which Zig's default search paths don't include
(they add um\x64 but not ucrt\x64).
This is a workaround for a Zig gap (partially addressed in closed
issues 5748, 5842 on ziglang/zig). Only affects initShared (DLL),
not initStatic.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add explicit file-type rules to .gitattributes so text files are stored
and checked out with LF line endings regardless of platform. This
prevents issues where Windows git (or CI actions/checkout) converts
LF to CRLF, breaking comptime parsers that split embedded files by
'\n' and end up with trailing '\r' in parsed tokens.
Key changes:
- Source code (*.zig, *.c, *.h, etc.): always LF
- Config/build files (*.zon, *.nix, *.md, etc.): always LF
- Text data files (*.txt): always LF (for embedded file parsing)
- Windows resource files (*.rc, *.manifest): preserve as-is
(native Windows tooling expects CRLF)
- Binary files: explicitly marked as binary
Removed the legacy rgb.txt -text rule since *.txt now handles it
uniformly with code-level CRLF handling as defense-in-depth.
Trim trailing \r when splitting octants.txt by \n at comptime. On
Windows, git may convert LF to CRLF on checkout, leaving \r at the
end of each line. Without trimming, the parser tries to use \r as
a struct field name in @field(), causing a compile error.
Follows the same pattern used in x11_color.zig for rgb.txt parsing.
A regression caused by 3ee8ef4f65.
The search bar should stay as the first responder after clicking inside
the text field or clicking the next/previous button, but right now it
doesn’t.
Trailing state capture now is encapsulated in a struct `Capture` and all
parsers access the data via `p.capture.trailing()` rather than directly
from the writer.
This is primarily to prep for the OSC parser to be able to capture the
entire sequence (not just the trailing part) so we can setup libghostty
for fallback handlers so libghostty implementers can have custom OSC
behaviors.
But, it has the benefit of making our OSC parser much cleaner too.
I'm doing some benchmarks now...
Trailing state capture now is encapsulated in a struct `Capture` and all
parsers access the data via `p.capture.trailing()` rather than directly
from the writer.
This is primarily to prep for the OSC parser to be able to capture the
entire sequence (not just the trailing part) so we can setup libghostty
for fallback handlers so libghostty implementers can have custom OSC
behaviors.
But, it has the benefit of making our OSC parser much cleaner too.
Add ghostty_paste_encode() which encodes paste data for writing to the
terminal pty. It strips unsafe control bytes, wraps in bracketed paste
sequences when requested, and replaces newlines with carriage returns
for unbracketed mode. The input buffer is modified in place and the
encoded result is written to a caller-provided output buffer, following
the same buffer/out_written pattern as the other encode functions like
ghostty_size_report_encode.
Update the c-vt-paste example with an encode_example() demonstrating the
new function and add corresponding @snippet references in the header
documentation.
Extracted this from #11870 since I can't figure out why that build is
failing.
Add ghostty_paste_encode() which encodes paste data for writing to
the terminal pty. It strips unsafe control bytes, wraps in bracketed
paste sequences when requested, and replaces newlines with carriage
returns for unbracketed mode. The input buffer is modified in place
and the encoded result is written to a caller-provided output buffer,
following the same buffer/out_written pattern as the other encode
functions like ghostty_size_report_encode.
Update the c-vt-paste example with an encode_example() demonstrating
the new function and add corresponding @snippet references in the
header documentation.
Add set/get support for foreground, background, cursor, and palette
default colors through ghostty_terminal_set and ghostty_terminal_get.
Four new set options (COLOR_FOREGROUND, COLOR_BACKGROUND, COLOR_CURSOR,
COLOR_PALETTE) write directly to the terminal color defaults. Passing
NULL clears the value for RGB colors or resets the palette to the
built-in default. All set operations mark the palette dirty flag for the
renderer.
Eight new get data types retrieve either the effective color (override
or default, via DynamicRGB.get) or the default color only (ignoring any
OSC overrides). Effective getters for RGB colors return the new NO_VALUE
result code when no color is configured. The palette getters return the
current or original palette respectively.
Adds the GHOSTTY_NO_VALUE result code for cases where a queried value is
simply not configured, distinct from GHOSTTY_INVALID_VALUE which
indicates a caller error.
## Example
```c
#include <ghostty/vt.h>
#include <stdio.h>
int main() {
GhosttyTerminal terminal = NULL;
GhosttyTerminalOptions opts = { .cols = 80, .rows = 24, .max_scrollback = 0 };
ghostty_terminal_new(NULL, &terminal, opts);
// Set default colors
GhosttyColorRgb fg = { .r = 0xDD, .g = 0xDD, .b = 0xDD };
GhosttyColorRgb bg = { .r = 0x1E, .g = 0x1E, .b = 0x2E };
ghostty_terminal_set(terminal, GHOSTTY_TERMINAL_OPT_COLOR_FOREGROUND, &fg);
ghostty_terminal_set(terminal, GHOSTTY_TERMINAL_OPT_COLOR_BACKGROUND, &bg);
// Read back the effective foreground
GhosttyColorRgb color;
if (ghostty_terminal_get(terminal, GHOSTTY_TERMINAL_DATA_COLOR_FOREGROUND, &color)
== GHOSTTY_SUCCESS) {
printf("fg: #%02X%02X%02X\n", color.r, color.g, color.b); // #DDDDDD
}
// After an OSC 10 override from a program inside the terminal:
ghostty_terminal_vt_write(terminal, (const uint8_t*)"\x1B]10;rgb:FF/00/00\x1B\\", 20);
// Effective returns the override, default returns the original
ghostty_terminal_get(terminal, GHOSTTY_TERMINAL_DATA_COLOR_FOREGROUND, &color);
printf("effective: #%02X%02X%02X\n", color.r, color.g, color.b); // #FF0000
ghostty_terminal_get(terminal, GHOSTTY_TERMINAL_DATA_COLOR_FOREGROUND_DEFAULT, &color);
printf("default: #%02X%02X%02X\n", color.r, color.g, color.b); // #DDDDDD
ghostty_terminal_free(terminal);
return 0;
}
```
A full working example is in `example/c-vt-colors/`.
Add set/get support for foreground, background, cursor, and palette
default colors through ghostty_terminal_set and ghostty_terminal_get.
Four new set options (COLOR_FOREGROUND, COLOR_BACKGROUND, COLOR_CURSOR,
COLOR_PALETTE) write directly to the terminal color defaults. Passing
NULL clears the value for RGB colors or resets the palette to the
built-in default. All set operations mark the palette dirty flag for
the renderer.
Eight new get data types retrieve either the effective color (override
or default, via DynamicRGB.get) or the default color only (ignoring
any OSC overrides). Effective getters for RGB colors return the new
NO_VALUE result code when no color is configured. The palette getters
return the current or original palette respectively.
Adds the GHOSTTY_NO_VALUE result code for cases where a queried value
is simply not configured, distinct from GHOSTTY_INVALID_VALUE which
indicates a caller error.
Switch the two Windows CI jobs (build-examples-cmake-windows and
build-libghostty-vt-windows) from GitHub-hosted windows-2025 runners to
namespace-profile-ghostty-windows runners.
Switch the two Windows CI jobs (build-examples-cmake-windows and
build-libghostty-vt-windows) from GitHub-hosted windows-2025 runners
to namespace-profile-ghostty-windows runners.
This makes it so that `zig build dist -Demit-lib-vt` produces a
`libghostty-vt-<version>.tar.gz` source tarball that only contains what
is needed to build and test libghostty-vt (it cannot build Ghostty GUI
on macOS or Linux). `distcheck` has been updated to also verify cmake
works.
The source tarball goes from 38 MB to 2.8 MB for libghostty.
I also updated CI to build and test this, and also contains an assertion
that our tarball is always less than 5 MB so we can be aware if/when we
blow it up.
The `release-tip` job was also updated to add the libghostty-vt tarball
to our tip release on GH.
Run cmake configure and build on the extracted lib-vt tarball as
part of distcheck to ensure the CMake wrapper works from the
stripped archive. Keep dist/cmake/ and dist/libghostty-vt/ in the
archive since the CMake build needs them.
Add a build-dist-lib-vt job that runs distcheck with
-Demit-lib-vt=true and verifies the resulting tarball stays under
5 MB. Also downsize the build-dist runner from -md to -sm.
Add a source-tarball-lib-vt job that builds the stripped lib-vt
dist tarball and publishes it as libghostty-vt-source.tar.gz to
the tip release. Also downsize the source-tarball runner from -md
to -sm since it does not need the extra resources.
When emit_lib_vt is set, the dist tarball is now named
ghostty-vt-<version>.tar.gz and excludes large files that are
unnecessary for building libghostty-vt. This reduces the archive
from ~36MB to ~2.8MB by excluding images, macOS app resources,
font assets, fuzz test corpus, crash testdata, and vendored
libraries not used by lib-vt.
GTK resources and frame data generation are also skipped since
lib-vt does not need them, which removes the GTK build-time
dependency. The distcheck step runs test-lib-vt instead of the
full test suite for lib-vt archives.
**WARNING:** We CANNOT upgrade to Xcode 26.4 with Zig 0.15 because:
https://codeberg.org/ziglang/zig/issues/31658
We have to wait and see if Zig will backport that or if we just have to
roll forward to Zig 0.16 when it comes out. At the time of this commit,
no released Zig version has the fix for that issue.
**WARNING:** We CANNOT upgrade to Xcode 26.4 with Zig 0.15 because:
https://codeberg.org/ziglang/zig/issues/31658
We have to wait and see if Zig will backport that or if we just have to
roll forward to Zig 0.16 when it comes out. At the time of this commit,
no released Zig version has the fix for that issue.
