Windows Support

[mitchellh]

This is a tracking issue for windows support. I'm not yet committed on Windows working for Ghostty 1.0 but I wanted to make this issue in case anyone wants to help, as well as to provide some guidance on the order of operations I've taken before to support new platforms. We can make incremental progress towards Windows without it completely working at any time as long as we can keep those pieces tested in CI.

The recommended approach I take with new platforms is to get the GLFW, OpenGL, Freetype build working first. This doesn't provide a super native experience but it forces you to get dependencies compiling and gets you a window + renderable surface very quickly. This isn't something we'd want to ship, but it moves the needle forward and is satisfying to see. From there... you can dive into the weeds incrementally.

Tasks

The tasks below are in the order I would take, for reasons stated in "notes". I think each checkbox is individually PR-able.

• zig build test working. Testing doesn't bring in a lot of dependencies like apprt, font rendering, pty creation, so this should be a priority and will make all the following steps easier. (windows: add support for the glfw backend #773)
• CI, GitHub Actions for zig build test (Inital windows CI support #581)
• Get shared dependencies building for Windows (build.zig updates)
  • Freetype
  • Harfbuzz
  • GLFW
  • libpng
  • zlib
  • utf8proc
  • pixman
• MVP: GLFW, OpenGL, Freetype zig build -Dapp-runtime=glfw run working (windows: add support for the glfw backend #773)
  • This will likely require getting individual libraries building successfully with Windows, too. i.e. pkg/freetype. You can PR those separately.
  • This will also force us to figure out the termio implementation, i.e. how to open a pty.
• CI, GitHub Actions for Windows build
• Font Discovery for Windows (DirectWrite? Unsure) -- can still use Freetype for rasterization
• Font Face for Windows (DirectWrite)
• Use the GLFW native API to get access to Window to use DirectX
• New apprt implementation for dedicated Windows GUI, native widgets
• Installers, packages, whatever is necessary for a platform-native run experience (i.e. the macOS codesign + notarization step)
• GitHub Actions for release (release-tip.yml changes)
• Alternate "terminal" support, maybe: Console, PowerShell, WSL integration

Notes

The ordering above is purposeful. It incrementally goes from a feature-poor not-super-native cross-platform experience to a fully native, dedicated experience. The "GLFW+OpenGL+Freetype" combo is a fully cross-platform stack that will let you get a basic terminal working. Its not something we want to ship but its the lowest lines of code, forces you to get the build system to work, the CI, etc.

I then move on to "font discovery" because it lets users type font names and integrates a really simple, small C API for a dedicated platform. I still use Freetype usually at this point for rasterization. See coretext_freetype as an example for macOS which uses CoreText for discovery but Freetype for rasterization.

I then do the dedicated font rasterization using the platform-native solution. This is important for the fonts to feel right. Each OS does subtly different font rasterization so this is important.

Next, I use the GLFW native API to grab a window handle so I can swap OpenGL for a platform-native solution. This lets me keep using GLFW for window creation and input events while iterating on the renderer.

Finally, I start building a custom windowing layer in apprt.

[barvirm]

Hello, I today tried to build all listed dependencies on Windows:

• Freetype
• Harfbuzz
• GLFW
• libpng
• zlib
• utf8proc
• pixman

It went without problems, only Harfbuzz needs "Developer mode" enabled for Windows or user has to have permission to create symlinks.

[raggi]

@barvirm they're all in vcpkg & mingw too, but so far we're able to build the test target without looking up any externals.

[matu3ba]

Extracted from #871 (win support not a goal until 1.0):
Looks like as of a8e82b1 the config path is incorrectly applied and lang info is not found:

warning(os): setlocale failed with LANG and system default. Falling back to en_US.UTF-8
error(os): setlocale failed even with the fallback, uncertain results
info: homedir config not found, not loading path=C:\Users\hafer\AppData\Local\ghostty/config

Further, I had no debug output when starting from another terminal, only for directly starting via clicking.

Further, I noticed that for example nvim-qt is heavily penalized by the scheduler and freezes, when my system is under heavy load (ie compiling). So I believe that the "native frontend" might require some experimentation of what things Microsoft chooses to penalize under heavy loads, since the terminal should be always repsonsive.

[mitchellh]

Looks like as of a8e82b1 the config path is incorrectly applied and lang info is not found:

In general, the config path should be completely unrelated to LANG settings, unless Windows in particular behaves very strangely. I imagine these are two separate issues, though.

[der-teufel-programming]

setlocale warnings appeared for me before any changes to config file loading

[matu3ba]

For context of DirectWrite https://en.delphipraxis.net/topic/6054-choice-of-windows-text-rendering-engines/.
https://www.ghacks.net/2022/09/15/windows-terminal-preview-1-16-theming-text-rendering-engine/
https://visualstudiomagazine.com/articles/2022/02/07/windows-terminal-1-13.aspx

Relevant PR: microsoft/terminal#11623
AtlasEngine should be used now or in future in Windows Terminal. Afaiu, the engine can simplify alot things and improve shader performance by assuming monospace fonts. See also microsoft/terminal#13936 for their transition planning.
Afaiu, their main reasoning were performance and complexity problems.

DirectWrite example here https://stackoverflow.com/questions/37572961/c-directwrite-load-font-from-file-at-runtime, but I found no documented API for AtlasEngine and this one https://github.com/tippesi/Atlas-Engine is described as "toy engine".
I'll search the windows terminal code to look for hints what exactly they are using https://github.com/microsoft/terminal.

Getting font file from commandline: https://superuser.com/questions/1432800/get-actual-font-name-of-ttf-file-from-command-line (probably there are more standard paths and a db or something though).
Getting current font in powershell: https://stackoverflow.com/questions/62458016/detect-which-font-is-in-use-by-powershell-session
Customization https://devblogs.microsoft.com/powershell/windows-powershell-font-customization/

Old gnarly things we hopefully dont have to deal with https://www-user.tu-chemnitz.de/~heha/petzold/ch17c.htm
gdi fns https://learn.microsoft.com/en-us/windows/win32/gdi/font-and-text-functions
font selection in general https://learn.microsoft.com/en-us/windows/win32/directwrite/font-selection

I'll clean this brain + link dump up eventually.

[matu3ba]

@mitchellh The README of Windows shell has a nice design motivation and overview, which is visualized in the browser https://github.com/microsoft/terminal/tree/be9fc200c7b22c544103ec3304ca31c3b984031e/src/renderer/atlas:

As you can see, breaking the text buffer down into GDI-style primitives just to
rebuild them into DirectWrite ones, is pretty wasteful. It's also incredibly
bug prone. It would be beneficial if the TextBuffer and rendering settings were
given directly to AtlasEngine so it can do its own bidding.

Would you mind taking a look how you'd like to proceed? TextAtlas restricts support to monospace fonts, see microsoft/terminal#10461 (comment), so I'm not sure what your plans would be related to that.

To other interested folks: Do you know, if all "Windows native fonts" are all monospace? Afaiu, Monospace fonts can be also have Cleartype enabled, but not necessarily all. Do you happen to know from knowledge or trying, if that "just works" with "TextAtlas" renderer in Windows Terminal?

[donaldguy]

Just a thought:

[It is probably out of scope for the project per se but ]

given that Windows world probably has a fairly clear answer already for "best native terminal" (in Windows Terminal),

I imagine it would probably (in the near term with less effort) get a lot of what (needy, not-so-zeroconf-y) people wanted from windows support if there was only a mapped across ghostty config → Windows Terminal settings.json translator (ranging from an adhoc run on demand cli filter to, more ambitiously, something like an injecting App Extension ? )

obviously not every action would map, but it seems doable.

[no promises but I might give it a shot if I feel like playing with zig]

[pidgeon777]

Will the Windows release support graphical features such for example the one used in the Kitty's Graphics Protocol?

I mean for example being able to render images "in the terminal".

See for example this Neovim plugin:

https://www.reddit.com/r/neovim/comments/1et23ag/diagramnvim_diagrams_as_code_mermaid_markdown_to/

[perryhq]

Why wouldn't it?

[mitchellh]

Yes it would

[Eplisium]

Do sure hope that this becomes a release. Just came upon this and was going to make another post. I appreciate the tool yous are building here.

[itpropro]

Please include a Windows on ARM build. It's already hard enough to get terminal based workflows like nvim to work on Windows on ARM, as not all of the plugin system has ARM builds, yet.
So when you release it for Windows (in the near future hopefully 😄), please include Windows for ARM artifacts from the start on.

[Daydreamer-riri]

I still can't successfully build Neovim on my ARM machine. So at present my development is placed in wsl2.

[itpropro]

It took me 2 days but you can actually get it to run if you build like 95% of the plugins etc. on your own with Visual Studio (MVC pipeline was the only one that worked for me). Got Lazy vim including all plugins to work this way.

[cheater]

Please include MSYS support (+ possibly work to get this as the default MSYS terminal, or have instructions to easily set it up). The current terminal in MSYS is absolutely horrendous garbage.

[pirafrank]

you can use Windows Terminal with MSYS

[atomlin]

Just a comment. Personally, WSL support is more important than CMD or PS.

[spenserlee]

I think they probably meant the ability to use WSL from a native build of Ghostty for Windows, similar to how Windows Terminal offers the ability to open new tabs for either CMD, Powershell, or WSL.

[atomlin]

You are actually both right.

I did not know if it worked properly in WSL, and was looking for that, I'll give it a try.

It would still be nice if it worked directly in Windows, which is the main thrust of this issue.

[pidgeon777]

With Windows support, I mean I would love ghosty.exe to run as a Windows .exe executable, not running it on a WSL instance (I suppose no issues should occur in that case).

[daf-code]

Is window resizing supposed to be working under WSL? It isn't for me, whether I launch Ghostty directly from the Start menu, or from an Ubuntu terminal. I can switch between maximized and whatever I've hardcoded in the config, and that's all. (The terminal inspector is resizable, using default X or WLSg or whatever widgets.) I also can't reload the config on the fly to change the window size, I have to change the config, exit, and relaunch Ghostty.

[00-kat]

@daf-code Possibly microsoft/wslg#1244 (comment).

[ManiProjs]

What do you mean "CI, GitHub Actions for Windows build"? You mean adding an Actions workflow to release Windows builds?

[00-kat]

Not "how to use", but rather "adding one".

[ManiProjs]

@00-kat Thanks for pointing out. I fixed it.

[MadSpindel]

Is there a timeline for Windows support on the roadmap?

[pluiedev]

There's only a somewhat informal one, but perhaps Ghostty 1.4 or 1.5. Right now we have other much bigger ticket items that need fixing (e.g. #111, #189)

[pidgeon777]

Those have been closed now. Let's hope a Windows version is not too far away 🙏.

[pluiedev]

It's literally in the description.

[eamonburns]

I see the current step is "CI, GitHub Actions for Windows build", but there are already some Windows steps in .github/workflows/test.yml.

What needs to be done next, and is this contributor friendly?

[HO-COOH]

@cheater By using Direct2D and Direct3D directly, you can go as high fps as you want, there is no limit. UWP and WinUI3 will try to render the xaml content and animations with vsync (so you don't get tearing). But you are able to use a SwapChainPanel and rendering it without vsync, so unlimited fps as the raw apis. Also the classic GDI I know of will not impose a frame rate limit, you can redraw the window as fast as you want.

@marler8997 You are correct that UWP can use WinUI 2 (which is basically a style library and some extra controls), but it is still in a UWP app model. Your app is sandboxed and there is no way around that.

WinUI 3 is completely different as it's a standalone GUI framework. Your app is a normal win32 program like the majority of the existing exe.

[tom-huntington]

@cheater The FPS of WinUI3/UWP isn't relevant for most use cases (I don't even know what it is). This is because the compositor does animations of UI components and presenting of a IDXGISwapChain (i.e. your TTY window) and essentially has unlimited FPS

[Tamnac]

You might want to look at Avalonia UI (https://avaloniaui.net/). I have used it briefly in the past. Though technically a crossplatform framework, from my understanding it is about about as native as WPF (they have a service that lets you swap out WPFs backend with theirs), comes with a fluent theme, should offer a lot more flexibility, and most importantly, frees you of whatever Microsoft is doing.

[jasonwun]

Realistically speaking, we should not bring UWP into the conversation because it is officially deprecated by Microsoft and is under maintenance mode. (source) unless we can tolerance the risk of potential migration in the future

If you are starting to develop Windows apps, we recommend you consider using the Windows App SDK, and WinUI rather than UWP. Although still supported, UWP is not under active development. Please see Start developing Windows apps for more information.

[MadSpindel]

In [Our Commitment to Windows Quality](https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/, Microsoft mentions WinUI3 several times. I would say WinUI3 is the only option that makes any sense if Ghostty wants to have a native feel on Windows.

[Lololegeek]

I run ghostty on windows ! It's not the same interface

[Lololegeek]

Personally, I don't mind the framework it is built in, as long as I can hide the title bar. I do want a link to this version though!

The app is good, it’s just that the latency is REALLY HUGEbasically unusable. I can’t manage to build in release mode.

[Lololegeek]

Personally, I don't mind the framework it is built in, as long as I can hide the title bar. I do want a link to this version though!

And the code is very bad

[codebymiles]

Personally, I don't mind the framework it is built in, as long as I can hide the title bar. I do want a link to this version though!

And the code is very bad

Bad code is better than no code

[codegod100]

wen files

[edbordin]

wen files

Maybe I should've just joined this thread #2563 (comment)

[hvent90]

If someone wouldn't mind helping me list out a test/verification suite for a windows build, I could try throwing a ralph loop at it. Probably will be hot garbage that won't see the light of day, but would be a fun experiment.

A bit off topic but a few days ago I wanted to make a stateful mock AWS terraform provider. I was able to scaffold the verifications from both terraform and aws cli, then did the ralph loop. The result wasn't the worst thing in the world.

[eamonburns]

Should probably create a separate discussion for that.

[edbordin]

Hey @mitchellh, I've just been hacking on this a little and found the glfw apprt was cleaned up. Would you recommend (a) Resurrecting it on a branch as a stopgap; or (b) Setting up a bare bones windows apprt before proceeding with the other steps in your original plan?

[edbordin]

I got a couple of explorations going in parallel for fun. With a fair bit of AI slop added to the build process, I now have the GTK version building in release mode under UCRT64 in MSYS2 (similar to another post but I don't have the issue of it crashing in release builds). I don't think this would ever need to be an official build config but perhaps this branch could be useful for someone working on font discovery etc. I've pushed it here, it's actually pretty responsive on my laptop's fairly ancient intel graphics:

Recording.2026-03-21.191541.mp4

Just for the heck of it, I started playing with https://github.com/microsoft/terminal as a reference point for a WinUI app hosted inside a win32 application. I figure if this is how MS chose to do it, it's worth considering. I actually don't know if anyone could have built this outside of a team at Microsoft with access to the Windows source though😅 Not too much worth sharing yet on this front - I didn't work out an easy way to use the opengl renderer on top of a directx swapchain so I started focusing on plumbing the input events in instead.

[edbordin]

Just to put it out there in the spirit of collaboration: I'm making some progress on a renderer using Direct3D + WinUI (just freetype font rendering to start with). It looks like WPF also has a SwapChainPanel so this approach would likely work there too. I started with the renderer rather than the native fonts piece just because it seemed like truly integrating OpenGL on top of a directx render target was going to be more trouble than it was worth (ANGLE exists but it targets OpenGL ES).

Still a long way to go - I fully own making heavy use of AI here but I've been trying to steer it towards something roughly the right shape. It helps that https://github.com/neurocyte/flow and https://github.com/microsoft/terminal are MIT licensed too, so I will be sure to credit those sources appropriately but it seems like they should be fair game to copy/modify. I'll definitely need to clean up a lot of details later e.g. manual bindings vs using zwindows, setting up a callback/action pattern so the libghostty swapchain can be attached to any windows host app supporting this kind of direct rendering, general code quality/style passes.

Recording.2026-03-22.163138.mp4

[edbordin]

Still huge amounts of cleanup to do, but I'm getting close to having the major renderer features roughly covered, including GLSL->HLSL conversion for the shader effects!

Recording.2026-03-24.130627.mp4

[sskras]

I guess there are two conflicting definitions of the native look/feel/experience on Windows:

I always fancy the first one, since it's available across a lot wider range of Windows versions.

[00-kat]

Not that I would know what the consensus is, but I feel like it would be best to gravitate toward using the one Microsoft promotes, which I believe is neither of the UIs you've shown. Paint also looks very different on Windows 11 than it did on Vista through 10 (and XP and before had an entirely different paint too).

I always fancy the first one, since it's available across a lot wider range of Windows versions.

While it's available for a wider range of Windows versions, it isn't a native look & feel for the same wide range.

[eamonburns]

I would say that a better analogy for the "new native look and feel" would be the new look of Paint, rather than Paint 3D.

There is also Notepad:

And File Explorer: