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?