New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Support #28

Closed
jwilm opened this Issue Dec 17, 2016 · 105 comments

Comments

Projects
None yet
@jwilm
Owner

jwilm commented Dec 17, 2016

Support Windows via the Linux subsystem

@jwilm jwilm added this to the Version 1.0 milestone Dec 17, 2016

@berwyn

This comment has been minimized.

berwyn commented Jan 5, 2017

When you say "via WSL", do you mean the end user would install alacritty inside of Ubuntu and use it from there?

@ehartford

This comment has been minimized.

ehartford commented Jan 6, 2017

I want it for cmd.exe and powershell too please not just linux subsystem

@ehartford

This comment has been minimized.

ehartford commented Jan 6, 2017

I'd think it'd be like ConEmu right and be able to run any shell you want (cygwin, mingw, cmd.exe, powershell, wsl)

@voltagex

This comment has been minimized.

voltagex commented Jan 7, 2017

Getting graphics rendering out of the WSL would be pretty tricky. Microsoft will not support anything X11 based, you need to run an X11 server and forward out of WSL.

@voltagex

This comment has been minimized.

voltagex commented Jan 7, 2017

At the moment building on Windows bails out at servo-fontconfig-sys - should I open an issue for this?

@martinlindhe

This comment has been minimized.

Contributor

martinlindhe commented Jan 7, 2017

@voltagex I opened #177 about building on Windows

@flaki

This comment has been minimized.

flaki commented Jan 8, 2017

I managed to build this on WSL (Ubuntu 16.04.1 LTS), fully updated (sudo apt-get update && sudo apt-get upgrade) yesterday evening.

I'm on Insider Slow Ring (build rs_prerelease 14986).

But as unsurprisingly it bails on exec:

alacritty$ ./target/release/alacritty
Alacritty encountered an unrecoverable error:

        Error creating glutin::Window; No backend is available

This is mostly (as stated below) connected to WSL not exposing any GPU support (Microsoft/WSL#829), which in the end leads to the inability to support modern Linux graphics subsystem architectures (like Wayland or Mir, see Microsoft/WSL#938).

@voltagex

This comment has been minimized.

voltagex commented Jan 8, 2017

@rigtorp

This comment has been minimized.

rigtorp commented Jan 8, 2017

Relevant resources on Windows font rendering in Rust:
servo/servo#14153
https://github.com/vvuk/dwrote-rs

@Celti

This comment has been minimized.

Contributor

Celti commented Jan 14, 2017

The easiest solution I see is Alacritty built as a Windows-native application and using wslbridge for WSL support, allowing for any of WSL, Cygwin, PowerShell, or plain ol' cmd.exe in Alacritty.

@rayman22201

This comment has been minimized.

rayman22201 commented Jan 18, 2017

Hey guys. I'm attempting to implement a working windows build in my spare time. I'm a Rust n00b, so excuse the roughness...
rayman22201@dab775a

Using the links @rigtorp posted, and a bit of digging, I think that I have font rendering working for windows. (A very rough pass of something that I think might work if I'm lucky... The module compiles at least)
But I have other problems that prevent me from testing it:

You seem to be pegged to a particular commit of @jwilm's fork of Glutin. This fork does not compile on windows. the Glutin Windows implementation does not implement the clear_current function of the glContext trait. (A function that doesn't even exist in later commits, btw)

Why are you pegged to an old commit of your Glutin fork @jwilm ?

Bumping up to the latest commit of the Glutin fork successfully compiles on windows, but then the config.rs goes looking for a glutin::{mods, Mods} and fails to find them.

It looks like the Glutin event system has totally changed in later commits.

Any thoughts on getting Glutin to work on the windows build?
Is the correct action to implement clear_window for this pegged commit?
Or is the correct action to bump up to the latest Glutin and fix the issues with the event handling?

There is also a whole bunch of unix specific stuff that the code goes looking for, which obviously fail to compile, but that seems more straightforward to fix, or at least I consider that to be a battle for another day lol.

Here is a Gist with the Rust Compiler Outputs for reference:
(Shows the output for both the old and the new revisions of Glutin)
https://gist.github.com/rayman22201/6672e595277c8077472d2ac66a065099

@dten

This comment has been minimized.

dten commented Jan 18, 2017

If you check the branch some changes have been added in his fork.
Modifier keys have been added to key events and some function added to the graphics part such as clear_current which clears the current context.

Implementing clear_current isn't hard but i got stuck getting the modifier keys on Windows

You can just put None for now but modifiers won't work

Wish I hadn't rage deleted my commits now :(

@rigtorp

This comment has been minimized.

rigtorp commented Jan 18, 2017

@rayman22201 @dten I'm working on upstreaming the necessary changes to glutin/winit: tomaka/winit#112. Unfortunately upstream seems hesitant making these changes.

@0rvar

This comment has been minimized.

0rvar commented Feb 15, 2017

This should definitely not be solved via the Linux Subsystem.

  • As pointed out earlier in the thread, WSL has no graphics backend
  • WSL terminals cannot interact with the Windows host, so you cannot launch Windows programs from it. You are basically locked out of your normal workflow. For example, you cannot launch any Windows-based text editor from a WSL terminal.
@colemickens

This comment has been minimized.

colemickens commented Feb 15, 2017

(I think the second point is no longer strictly true, as of a recent Insiders build which can launch PE Exes from WSL, but I couldn't agree with the sentiment of the @awestroke more strongly. The first point alone should put the Native vs WSL question to rest.)

@pierrebeaucamp

This comment has been minimized.

pierrebeaucamp commented Feb 15, 2017

You can definitely get graphics working in WSL (via a custom X Server), but that's not the point. You'd need a terminal in the first place to be able to launch any WSL app. A native Windows binary is the way to go here.

@slumos

This comment has been minimized.

slumos commented Mar 7, 2017

tomaka/winit#112 is merged!

@samnardoni

This comment has been minimized.

samnardoni commented May 7, 2017

Any movement on this? I'd love to try Alacritty on Windows.

@dparnell

This comment has been minimized.

dparnell commented Jul 17, 2017

I'm also having a go at getting things working under Windows. Also a rust noob. Have a look here to see how far I've gotten. https://github.com/dparnell/alacritty/tree/windows-patches
I've taken the work done by @rayman22201 as my starting point. It still doesn't quite compile, but I think it is getting close.

@rayman22201

This comment has been minimized.

rayman22201 commented Jul 26, 2017

@dparnell Glad you are having a go. As is so common these days, I got sidetracked with other projects and never found the time to get back to this one. 👍

@dparnell

This comment has been minimized.

dparnell commented Jul 26, 2017

@rayman22201 I know what that's like! I've got so many little side projects going on at the moment. I really want a fast terminal for Windows. I'm running iTerm2 on my Macs and something like that on WIndows would make working there a lot less painful.

@dparnell

This comment has been minimized.

dparnell commented Jun 14, 2018

I've put a preview build up here: https://github.com/dparnell/alacritty/releases/tag/preview-build

@gurpreetshanky

This comment has been minimized.

gurpreetshanky commented Jun 14, 2018

Yes it was on the windows.Thanks for the build.

@zacps

This comment has been minimized.

Collaborator

zacps commented Jun 14, 2018

Pull request is up #1374

@nixpulvis

This comment has been minimized.

Contributor

nixpulvis commented Jun 15, 2018

I've been assuming that this will work on a Windows system with only https://rustup.rs/ installed, is that correct?

(edit)

@dparnell

This comment has been minimized.

dparnell commented Jun 15, 2018

You'll also need a C/C++ compiler of some sort. I 'm using Microsoft Visual Studio 2017 as described above

@parkovski

This comment has been minimized.

parkovski commented Jun 15, 2018

Has anyone tested the DPI support? I have two different DPI monitors, and the window and fonts get lots smaller when dragging it to the higher DPI monitor. winit handles this so I'm not sure where the message is getting lost.

@zacps

This comment has been minimized.

Collaborator

zacps commented Jun 15, 2018

@parkovski @dparnell Did some related work here. I don't have multiple monitors so I can't test it myself.

If you create an issue on my repository it'll be moved into the main one if it's unresolved when it gets merged.

@parkovski

This comment has been minimized.

parkovski commented Jun 15, 2018

Yeah, that part tells windows to do its part of per monitor v2, which works. The problem seems to be that the underlying window library, either glutin or winit isn't handling WM_DPICHANGED (except I linked to where it does...) or the scaling factor isn't getting passed on to alacritty. I'll open a more detailed issue in your repo though.

@parkovski

This comment has been minimized.

parkovski commented Jun 15, 2018

Oh, um, nevermind. I see winit implemented HiDPI support 17 hours ago, so I'm guessing it'll work fine in future builds.

@nixpulvis

This comment has been minimized.

Contributor

nixpulvis commented Jun 15, 2018

@parkovski that's the dream. DPI implementation has been thrashing a little bit, partly due to attempts at fixing things in multiple places. I'm thinking things will stabilize once those updates make it in, and once #1346 and #1362 land.

@chrisduerr and @francesca64 probably know best how that's all coming together.

@francesca64

This comment has been minimized.

Contributor

francesca64 commented Jun 15, 2018

The manifest entry actually has no impact on functionality, though it's quite important for anyone using something like DPI Awareness Enabler, as otherwise the application will be erroneously detected as DPI unaware (I had to disable it for winit testing, and now my legacy applications have blurry text...)

Also, @zacps, you don't need multiple monitors to test that. You can just change the display scale factor, assuming you're on 8.1 or newer.

Once HiDPI support makes its way downstream, everything should work automagically (assuming the new types are properly integrated and any necessary HiDpiFactorChanged handling is done). There's very little I have to do before releasing winit 0.16.0, and then I can cut a glutin release right afterwards.

Anyway, Windows support is pretty exciting. I'll admit I don't actually use Alacritty, but the ability to use the same terminal across all platforms might just sell me on it.

@parkovski

This comment has been minimized.

parkovski commented Jun 15, 2018

It is pretty exciting. I've been using wsl tmux on insider builds when it's not broken. Win32-WSL PTY interop is getting there. Console team is doing an awesome job, but they also have to support business apps from the 90s so progress is slow. A terminal with modern rendering will be a great addition to Windows dev land. Now if we could just get a sudo without UAC popups...

@jasonparekh

This comment has been minimized.

jasonparekh commented Jun 15, 2018

Great to see the progress. Should mouse be working? I've tried vim and tmux with each one's mouse support enabled but alacritty seems to use its native text selection instead of passing the events onward.

@zacps

This comment has been minimized.

Collaborator

zacps commented Jun 19, 2018

@jasonparekh Does it work in cmd/powershell? If so please create an issue on my fork.

@sandric

This comment has been minimized.

sandric commented Jun 22, 2018

I know its not very polite to write such to open pr, but guys, is there any build link or description how to build on windows so I can try out? Know very little about rust, please dont judje)

@zacps

This comment has been minimized.

Collaborator

zacps commented Jun 22, 2018

@sandric Builds are linked above: #28 (comment)

@sandric

This comment has been minimized.

sandric commented Jun 23, 2018

@zacps thanks a lot, it indeed works, and alacritty.exe is show up, the problem is all letters in it rendered as white rectangles for some reason. If I select them and copy paste to say notepad - its valid symbols, like that one string "(c) 2018 Microsoft Corporation. All rights reserved.". Anyone knows what that might be?

@zacps

This comment has been minimized.

Collaborator

zacps commented Jun 23, 2018

@sandric As I have said previously in this issue please create an issue on my fork rather than notifying all 33 participants on this issue.

https://github.com/zacps/alacritty/issues

@sandric

This comment has been minimized.

sandric commented Jun 23, 2018

Sure, you right.

@matttproud

This comment has been minimized.

Contributor

matttproud commented Jul 21, 2018

To anyone implementing native integration with Windows, you may find this article interesting (I’m not sure if it would be helpful):

https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-command-line-inside-the-windows-console/

@zacps

This comment has been minimized.

Collaborator

zacps commented Jul 21, 2018

@matttproud I'm definitely interested in adding support for this. It won't happen immediately though, partly because the API is currently undocumented and in alpha state. And secondly because I run business channel on my desktop, so I won't have access to the APIs for a while.

If anyone else is interested in trying to add support you should just need to create another implementation of the EventedRW trait in src/tty/mod.rs.

The issue for the API is here: Microsoft/console#57

@nathanchere

This comment has been minimized.

nathanchere commented Aug 1, 2018

I would much rather see this targetting cygwin than WSL. WSL will reach a much smaller audience as it doesn't support Windows 8 or 7 (still a majority user base) or the only remotely user-controllable and privacy-respecting versions of Windows 10 like LTSB 2016 or anyone who has no interest in using Windows Store where WSL platforms are exclusively distributed.

@parkovski

This comment has been minimized.

parkovski commented Aug 1, 2018

It’s not targeting either, the current implementation is a regular windows console using winpty which is about as good as it gets before the current in progress win10 release.

The new PTY stuff isn’t documented yet, but you can see how it’s done here.

@chrisduerr

This comment has been minimized.

Collaborator

chrisduerr commented Aug 15, 2018

It looks like the first versions of the API are going out now in Windows 10. An announcement can be found here:
https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/

@jwilm

This comment has been minimized.

Owner

jwilm commented Aug 15, 2018

@chrisduerr I just came here to post that same thing. Exciting stuff! I glanced through the doc pretty quickly, but it looks like they've got something like winpty internally now. Using the new ConPTY interface, it's possible to write code like this:

// Input "echo Hello, World!", press enter to have cmd process the command,
//  input an up arrow (to get the previous command), and enter again to execute.
std::string helloWorld = "echo Hello, World!\n\x1b[A\n";
DWORD dwWritten;
WriteFile(hIn, helloWorld.c_str(), (DWORD)helloWorld.length(), &dwWritten, nullptr);

The part that jumps out to me here is the \x1b[A which is 100% VT protocol 😄. This is a nice path going forward, but we'll still need winpty support if we care at all about older versions.

@zacps

This comment has been minimized.

Collaborator

zacps commented Aug 17, 2018

Issue tracking ConPTY support on my repo: zacps#25

@Congee

This comment has been minimized.

Congee commented Oct 4, 2018

I would like a replacement for putty. It's being maintained the old school way. The authors don't like common features of modern terminal emulators. But, plink + alacritty should be a great match! We don't even have to implement terminal protocols for cmd.exe or powershell. The only thing needed is a gui.

@jwilm jwilm closed this in 15e0dea Oct 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment