Windows Support #2563
Replies: 24 comments 85 replies
-
|
Hello, I today tried to build all listed dependencies on Windows:
It went without problems, only |
Beta Was this translation helpful? Give feedback.
-
|
@barvirm they're all in vcpkg & mingw too, but so far we're able to build the test target without looking up any externals. |
Beta Was this translation helpful? Give feedback.
-
|
Extracted from #871 (win support not a goal until 1.0): 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@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: 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? |
Beta Was this translation helpful? Give feedback.
-
|
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 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] |
Beta Was this translation helpful? Give feedback.
-
|
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/ |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Just a comment. Personally, WSL support is more important than CMD or PS. |
Beta Was this translation helpful? Give feedback.
-
|
What do you mean "CI, GitHub Actions for Windows build"? You mean adding an Actions workflow to release Windows builds? |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
Is there a timeline for Windows support on the roadmap? |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
-
|
I see the current step is "CI, GitHub Actions for Windows build", but there are already some Windows steps in What needs to be done next, and is this contributor friendly? |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
I run ghostty on windows !
It's not the same interface
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.






Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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 testworking. 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)zig build test(Inital windows CI support #581)build.zigupdates)zig build -Dapp-runtime=glfw runworking (windows: add support for the glfw backend #773)pkg/freetype. You can PR those separately.termioimplementation, i.e. how to open a pty.release-tip.ymlchanges)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_freetypeas 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.
Beta Was this translation helpful? Give feedback.
All reactions