WIP - Windows command prompt support

[coreyoconnor]

From jpbernardy:

For the next major release of vty windows support is a reasonable goal. The current plan is as follows:

• Use ansi-terminal package to add an instance of Terminal and DisplayTerminal? that does not depend on terminfo.
• Use unix-compat
• Use the backend of haskeline for input. Haskeline has already solved a number of the input issues that are open on vty and has windows support. However the currently exported modules for haskeline do not expose the backend modules. Either that would need to be exposed in the current haskeline package or a new package that is a shared input backend created.

[NightRa]

+1

[simonmichael]

Is this still reasonable ? hledger would use it.

As an alternate route, I wondered how feasible it would be to build a fake terminal on top of OpenGL, which seems to be pretty well supported on all platforms. In my dream world, such a terminal could also render as quickly as the memory mapped displays of early home computers.

[jtdaugherty]

@coreyoconnor - can you provide an estimate of how much work you think this might be? Since this ticket is four years old, is it realistic to keep this ticket open? (This sounds like a ton of work to me and I know I don't have enough time for it.)

On OpenGL: I could see there being a package vty-opengl that provided an alternative rendering backend, provided vty exported enough of the Image, Picture, and event loop internals to do it.

[coreyoconnor]

This is a bit of an essay so.....

Still a Good Idea

This is still reasonable and definitely a goal. I investigated Win32 support this weekend and am confident nice support is doable. However, there are an annoying build aspects to this.

On a high level, vty is set up to be abstract from the particular terminal's interface. This was to support the Win32 console functions (in addition to other frontends).

• https://msdn.microsoft.com/en-us/library/ms682073.aspx

However, I haven't been able to get GHC to link against these functions. I'm missing some critical information on how GHC works on windows. I'll see if I can get some sample programs up somewhere. Hopefully somebody can figure out what I'm doing wrong... Something silly I'm sure!

The terminal abstraction might need some work, but nothing I wasn't planning on doing anyways because... Alternate front ends! Let's make some!

OpenGL+??? / HTML+WebSocket

I'm more interested in building a HTML/HTTP/WebSocket frontend for Vty than an OpenGL one. OpenGL itself only covers: once an output context is acquired how to display the content. OpenGL does not cover: How to acquire a context; How to acquire input events; How to display text. Doable, but not something I want to invest in over HTML/WebSockets.

EG: With HTML I can easily say: "Display this text with these exact dimensions using whatever font that supports the characters requested. Prefer typefaces according to the following priority...." An OpenGL frontend would be faster, but I'd be duplicated a lot of the stuff I get "for free" with HTML.

That said, creating a new OpenGL based terminal optimized for VTY would be awesome as well! :-)

Alternate Front End Usage

Regardless: I'm interested in how would multiple frontends would work from a development/user perspective.

Ideal Scenario: Full Auto

An application using vty would, hopefully, only need to care about depending on vty. No consideration of what front end the user has configured.

For an Application Dev

1. Depend on "vty"

For a User

1. install application
   • dependency on "vty" induces a "vty" install
   • "vty" configure determines supportable front ends and depends on/configures those.
2. Run application
   • "vty" figures out most appropriate front end.

Wouldn't that be nice?

For a VTY Dev

For a vty developer, how would the vty development be set up to support multiple front ends?

Common core, one lib per frontend

Something like:

• front end agnostic code: "vty-core"
• terminfo specific code: "vty-terminfo"
• Win32 specific code: "vty-win32"
• OpenGL+SDL: "vty-opengl-sdl"

"vty" would then contain only:

• build time logic to determine what frontend libraries should be added to dependencies.
• run time logic to determine what frontend to initialize and use.

Monolith

• all code in "vty". Enable/disable modules based on build time logic.

In Conclusion / TL;DR

1. Supporting Win32 console is my top priority. (Gotta use that new Win10 machine somehow!)
2. This will smooth the terminal abstractions and the build process.
3. That will ease adding alternate front ends
4. ???

[coreyoconnor]

Darn. I hit a speed bump. The distro of GHC for windows I'm using (ghc 7.10.2 mingw) appears to have a path length limit. Compiling the tests happens to use paths > 260 characters. Which are resulting in false "file not found" error.

Filed a ticket with minghc team:

• "No such file or directory" error with long paths fpco/minghc#84

I've reduced the length of the test names. Which works around the issue.

PS X:\> stack build --test
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
vty-5.5.0: build (test)
Preprocessing library vty-5.5.0...
In-place registering vty-5.5.0...
Preprocessing test suite 'verify-attribute-ops' for vty-5.5.0...
[1 of 3] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[2 of 3] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-attribute-ops-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-attribute-opsStub\verify-attribute-opsStub-tmp\verify-attribut
e-opsStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attrib
ute-opsStub\verify-attribute-opsStub-tmp\Main.o )
Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attribute-op
sStub\verify-attribute-opsStub.exe ...
Preprocessing test suite 'verify-config' for vty-5.5.0...
Preprocessing test suite 'verify-crop-span-generation' for vty-5.5.0...
[1 of 7] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[3 of 7] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-crop-span-generation-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\v
erify-crop-span-generationStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.
0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\Main
.o )
.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-crop-span-generation
Stub\verify-crop-span-generationStub-tmp\.stack-work\dist\x86_64-windows\Cabal-1
.22.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tm
p\verify-crop-span-generationStub.dump-hi: openFile: does not exist (No such fil
e or directory)
ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset

--  While building package vty-5.5.0 using:
      C:\\Users\\coconnor\\AppData\\Local\\Programs\\minghc-7.10.2-x86_64\\ghc-7
.10.2\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-pac
kage-db -package-db=C:\Users\coconnor\AppData\Roaming\stack\snapshots\x86_64-win
dows\nightly-2015-08-17\7.10.2\pkgdb\ C:\Users\coconnor\AppData\Local\Temp\stack
9836\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build t
est:verify-attribute-ops test:verify-config test:verify-crop-span-generation tes
t:verify-display-attributes test:verify-empty-image-props test:verify-eval-termi
nfo-caps test:verify-image-ops test:verify-image-trans test:verify-inline test:v
erify-layers-span-generation test:verify-parse-terminfo-caps test:verify-simple-
span-generation test:verify-terminal test:verify-using-mock-input test:verify-us
ing-mock-terminal test:verify-utf8-width --ghc-options -hpcdir .stack-work\dist\
x86_64-windows\Cabal-1.22.4.0\hpc\.hpc\ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1
PS X:\>

[simonmichael]

Sounds like nice progress!

The stack devs have been talking about windows issues recently, maybe there's some work you can use/share.

[simonmichael]

Ping, how is this looking ?

[pavonia]

Not sure how much of the functionality you've already got working for the Windows backend, but I'm currently working on a binding to the Windows console API for one of my projects, too. Maybe I could extend the binding part a bit and make it an extra package if it would be of help for vty. I'm not in a big hurry with my project, though, so it could take several weeks til it would be finished.

[pavonia]

The low-level binding is up now (repo here and on Hackage). It's only tested on an old 32-bit WinXP, so feedback on how it works on more recent Windows versions is much appreciated.

[jtdaugherty]

Since this has been inactive for quite a while, I'm closing it - but feel free to re-open if this gets revived!

[simonmichael]

@jtdaugherty that seems odd, I think I am missing some context. Have you taken over the vty project from @coreyoconnor ? Are you saying windows support is a non-goal, and the work so far should be abandoned ?

[jtdaugherty]

@simonmichael Yeah, I've been maintaining Vty in Corey's place for several months now. This pull request has been open for a long time without any activity, and it's my opinion that these things should be closed and later reopened rather than languishing open forever. The same goes for tickets.

By closing this I'm not making a statement about Windows support. Although it is not something I personally plan to pursue myself, I would certainly be happy if these patches were finished up and deemed ready to merge!

[coreyoconnor]

I agree with closing this for now. Unfortunately, my current employer severely restricts any and all opensource contributions. I can't participate at this time and will not able to for the foreseeable future.

[jtdaugherty]

@coreyoconnor - okay, thanks - that's very good to know. I had no idea your ability to contribute was so limited.

[simonmichael]

I see, thanks for the clarifications. Also I notice this is a PR not an issue. I would still love to have vty & brick on all the major platforms, as would the Windows users I hear from periodically. Hopefully someone will help move @coreyoconnor and @pavonia's work forward soon. :)

[simonmichael]

Gathering some notes for anyone working on this:

vty is a nice full-screen curses-style API, and the basis for the nice higher-level brick TUI (text UI) framework, that builds on POSIX platforms only. All agree that it would be nice to make it work on Windows too. This would allow building cross-platform TUIs with haskell. Also there are things in vty, such as Graphics.Vty.Attributes, that would be useful for CLIs too.

2015: https://github.com/jtdaugherty/vty/tree/issue-1-windows-console is @coreyoconnor's work towards windows support. "I investigated Win32 support this weekend and am confident nice support is doable." "will not able to [participate] for the foreseeable future."
more

2016: https://hackage.haskell.org/package/Win32-console is @pavonia's windows console api which might be a useful building block. "It's only tested on an old 32-bit WinXP, so feedback on how it works on more recent Windows versions is much appreciated."
more

2019: #169 WIP: Start on Windows support is @Supernerd11's start on using the windows console API.
discussion

[simonmichael]

PS I pledge $50 to get a bounty started for a windows-compatible vty release. [edit: Please add your pledges to this issue to attract devs.]

[simonmichael]

From haskell-cafe today:

Possibly related are the console changes introduced with Windows 10 Creators Update. A lot of compat issues are said to be resolved. See https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ for details.

[jtdaugherty]

Since our efforts to revive this didn't get any takers, I'm closing this again. I don't like to have open PRs linger and this one isn't getting any attention. In addition, I suspect that at this point the best approach to move forward on Windows support would be to start over anyway.