-
Notifications
You must be signed in to change notification settings - Fork 57
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 #219
Comments
Hi @Shayan-To, there is currently no effort underway to support Windows. There have been a few attempts over the years, but nothing has stuck. If you or someone you know would like to work on Windows support, please let me know! |
I've done a bit of investigation into what would be necessary, here are my findings: All the relevant documentation is here: https://docs.microsoft.com/en-us/windows/console/ I collected this data by commenting out the Terminfo is available via mingw-w64-x86_64-ncurses on msys2. This only needs small changes to the way the terminfo package is built. Although I don't know how compatible this is.
Switch to use Handle as much as possible. This should retain the same behavior, but it is more portable.
I want to see if I can implement some of these steps over the next few weeks. |
Thank you for investigating this! I want to think about some of what is listed here and get back to you before you do any implementation. I’ll do that in the next couple of days.
… On May 27, 2022, at 11:57 AM, Jaro Reinders ***@***.***> wrote:
I've done a bit of investigation into what would be necessary, here are my findings:
All the relevant documentation is here: https://docs.microsoft.com/en-us/windows/console/
Terminfo is available via mingw-w64-x86_64-ncurses on msys2. This only needs small changes to the way the terminfo package is built. Although I don't know how compatible this is.
Preparation:
Switch to use Handle as much as possible. This should retain the same behavior, but it is more portable.
FD -> Use System.IO.Handle directly
stdInput -> System.IO.stdin
stdOut -> System.IO.stdout
fdReadBuf -> hGetBuf(NonBlocking)
fdWriteBuf -> hPutBuf(NonBlocking)
openFd -> openFile
closeFd -> hClose
EnableEcho (ECHO) -> hSetEcho
Basic useable implementation:
handleToFd -> handleToHANDLE
setFdOption NonBlockingRead -> ? ReadConsoleInput & GetNumberOfConsoleInputEvents or PeekConsoleInput & FlushConsoleInputBuffer
(hGetBufNonBlocking doesn't work correctly on windows)
set_term_timing
ProcessInput (ICANON), KeyboardInterrupts (ISIG), ExtendedFunction (IEXTEN) -> ENABLE_PROCESSED_INPUT
get_window_size
windowChange event
Full feature parity:
set_window_size
continueProcess -> possibly unnecessary?
MapCRToLF (ICRNL) -> possibly unnecessary?
StartStopOutput (IXON) -> possibly unnecessary?
get_tty_erase -> possibly unnecessary?
openPseudoTerminal
I want to see if I can implement some of these steps over the next few weeks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.
|
I took a look over this and I have a few questions/thoughts.
Why is
Reading over the list, it looks like this section is about moving away from the From an implementation approach perspective, to me it would be extremely helpful if the move to Another reason I'd like to see the |
As for the post- |
I haven't looked too long at terminfo because it was pretty easy to use the mingw package. I agree that it would be nicer to use the native API. I should look at that in more detail. I'm a bit conflicted about the Handle situation. I know that simply using Haskell's handles will not be enough to cover all those configuration options, but you can use functions like If the high level Handle is good enough for most of the uses and only the initialization and deinitialization needs access to the low-level interface, then I think it would be worth it to switch to Handles. Otherwise, the alternative is to make an abstract One thing that I am wondering about is if vty has a good enough test suite. If we change it to use Handle then we have to be very sure that everything still works correctly. I'm especially worried that something like timing or the handling of special control characters will change slightly. I expect those things are pretty hard to notice. |
This strikes me as worthwhile no matter what, because it then makes it much easier to tell what kind of abstract interface we need for
Vty has a pretty large set of test programs, but 1) I did not write any of them and 2) frankly I don't know what they test or how much test coverage they provide. I have largely ignored the test suite over the years that I've maintained With that said, I share your concern about tiny details being easy to miss. We'll just have to put it through its paces, and perhaps figure out what additional tests need to be written. |
OK, then I think the best course of action is to first consolidate all the unix dependent code behind such an abstract While doing that first step we should take into account the similarities and differences between windows and unix. We shouldn't make an abstraction that turns out to be unimplementable on windows. I think this approach should also have the advantage that the existing unix implementation will stay completely the same, just moved behind an interface. So there should be no regressions at least. Whether the applications work correctly on windows can be dealt with in future issue reports. |
Thanks, @noughtmare - that sounds like a great approach to me. I'm happy to review incrementally or wait until the
|
I also had another thought about this, which is that as we think about these changes, I'd love to keep an eye on whether we could split up the package into a core (e.g. |
Hello, I want to let you know I would be very interested in working on the Windows port of vty with you and/or @noughtmare. I would very much like to discuss how to proceed with you when you have time. Or if you like, I could submit a PR with the NativeHandle change as a first step. Then perhaps you could look at the work I've done and we can decide the next step. |
@chhackett thanks for your offer! I don't know whether @noughtmare still has plans to pick this back up so I'd like to hear from them first. Looking back at the comment history, I am increasingly in favor of abstraction changes to support a core package and platform-specific packages. I strongly suspect that that means we don't need |
I'm not working on anything at the moment. My thought was that the platform independent part would use |
@jtdaugherty is this something possible for GSoC? Or is the effort too much? |
@hasufell Unfortunately I don't think I'll have the time to devote to it, and I also would prefer to use a different mechanism to find a contributor. In particular, it isn't enough even to write the code; I strongly believe that the most important thing is to find a maintainer for the Windows support in vty (as a package) who will have a vested interest in maintaining it longer-term. |
I'm not sure we'll find a contributor if there's no one to mentor them. |
Yes, that's true in the student case and for GSOC. I think that Windows support in Vty will be a big undertaking and will best be undertaken by someone with a lot of industrial software engineering experience. I'm not saying I can't be available to help and collaborate; I would definitely want to do so, but I don't have the resources to do it in a mentoring capacity for this project. |
For those interested in following along, #260 captures the state of preparing for a release of Vty with support for Windows. |
Windows support went live today via the releases for Vty 6 and |
Is Windows is going to be supported?
The text was updated successfully, but these errors were encountered: