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?

[kassafari]

Nice to see some progress, awesome keep it up 👌

[pbronez]

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.

Hopefully Ghostty can support a broader set of Windows targets than Windows Terminal does.

Windows Terminal doesn't support Windows Server 2016-2022 or anything newer than Windows 10 version 2004 (build 19041). It's supposed to be included with Windows Server 2025 but I haven't seen it personally.

My primary use case for a Windows-native Ghostty is Windows Server VDI. I frequently use Amazon Workspace with Windows, and the lack of a decent terminal is painful.

[jcollie]

Supporting anything more than Windows 11 and very recent Windows 10 is unlikely. We're a small team and we don't have the developers nor the CI resources to support anything like that.

Ghostty is also unlikely to be suitable for deployment inside a VM since it requires a GPU and software GPUs just don't cut it.

There is a rich ecosystem of terminals based on libghostty-vt developing so that may the path forward for some of the use cases that you want.

[sskras]

@jcollie, that's sad to hear. At least you aren't against contribution to make Ghostty more cross-platform. Am I right?

[jcollie]

Yes, we've been accepting many Windows-related fixes recently.

[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.

[MadSpindel]

@sskras Read https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/ They are moving more stuff to WinUI 3.

[sskras]

Oh, it took only what – two years to make public response?

I guess they were in uncertainty, and later in a hard process of decision. Maybe they still are. Only time will tell for sure.

Now I wonder if there are already any means to interface WinUI3 from Zig.

[marler8997]

Now I wonder if there are already any means to interface WinUI3 from Zig.

I believe WinUI3 publishes their APIs the same way they publish the win32 metadata, in .NET "winmd" files. I recently finished winmd-zig enough to rewrite my win32jsongen project from C# to Zig (this is used in the chain to generate the full zigwin32 bindings).

So, it shouldn't be too hard now to use winmd-zig to write a tool that converts the WinUI3 winmd files to zig bindings. I haven't had a reason to do this myself yet though? So far all my interaction with WinUI3 apps have been so poor it hasn't seemed worth investment, but I'm open to being convinced otherwise :) I'm always having problems with Microsoft's own builtin "Settings" app, are there any good WinUI3 applications out there that have good performance and aren't full of bugs?

[GitMurf]

Just throwing out an idea... would using Microsoft PowerToys as a reference help at all? It is popular and has been around a while so assume it has at least partially tried all the different Windows methodologies of building. And it's open source so potentially good patterns to follow (or not follow)?!

[pbronez]

Here's the best info I could find on WinUI3 supported targets:

microsoft/microsoft-ui-xaml#3370 (comment)

WinUI 3.0 will require a minimum Windows 10 version of 10.0.17134.0. On the desktop client, this is known as 1803, but this build did not ship a corresponding Windows Server version. The next Windows Server release was based on 17763, which was Windows Server 2019 (see a useful decoder ring here: https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Server_versions )

For full transparency - we are only testing WinUI 3 on client. Your scenario of using a server with Terminal Services is reasonable, but not one we have been testing explicitly, so it is possible you could encounter unique bugs with that.

If you require Windows Server 2016 support, then WPF or Windows Forms would be better choices at this time. Or you could write a UWP app using the Windows.UI.Xaml framework using WinUI 2, if the UWP app model is a fit for your app. We have no plans to lower the minimum version for WinUI 3 at this time.

So WinUI 3.0 would give the most contemporary, native feel, but Ghostty would be limited to the same platforms that Windows Terminal supports. An older technology like WPF, Windows Forms or WinUI 2 would support a broader set of platforms.

[i999rri]

I have a working Windows PoC using the embedded apprt pattern.

Working: libghostty DLL, Win32 + WGL OpenGL, ConPTY, keyboard, mouse, clipboard, config loading.

Repos:

• Host: https://github.com/i999rri/GhosttyWin32
• Fork: https://github.com/i999rri/ghostty/tree/windows-port

Next: investigating DirectX/ANGLE.

AI disclosure: Claude Code was used to assist development.

ghostty-windows-opengl-win32-poc.mp4

[i999rri]

Update: Native DirectX 11 Renderer

Built a native DirectX 11 renderer backend for the Windows port, replacing Mesa Zink (OpenGL→Vulkan) to reduce input latency.

DirectX 11 is now the default. OpenGL still available as fallback.

Details: i999rri#6

Try it

scoop bucket add ghostty https://github.com/i999rri/scoop-bucket
scoop install ghosttywin32

Or download from releases.

AI disclosure: Claude Code was used to assist development.

[sgwong]

vim works fine, but nvim breaks. not sure why. cannot run neovim with it.

[00-kat]

Neovim changes a lot about the terminal handling. Anyway, open an issue in their issue tracker or whatever; there's too many people subscribed to this discussion so reducing irrelevant comments is best.

[mattn]

I’ve managed to bring over almost all of Ghostty’s features to Windows. The main things still missing are i18n and a proper tab overview. While this does not guarantee good long-term quality or maintenance, I’d be happy to serve as the maintainer for the Windows port if the project and community are comfortable with that.

https://github.com/mattn/ghostty/tree/win32-apprt

2026-04-10.135155.mp4

2026-04-10.173915.mp4

[mattn]

Added missing OSI 9;4 implementation

2026-04-10.190556.mp4