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/

[perrylets]

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.

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

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