Skip to content
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

WIP - Windows command prompt support #1

wants to merge 12 commits into from


Copy link

@coreyoconnor coreyoconnor commented Aug 28, 2015

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.
Copy link

@NightRa NightRa commented Feb 2, 2015


Copy link

@simonmichael simonmichael commented Aug 16, 2015

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.

Copy link

@jtdaugherty jtdaugherty commented Aug 16, 2015

@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.

Copy link
Contributor Author

@coreyoconnor coreyoconnor commented Aug 17, 2015

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).

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.


  • 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 coreyoconnor self-assigned this Aug 28, 2015
…cts to platform specific modules. Minor re-arrangements. Add stub implementations for windows constructors: inputForConfig, outputForConfig.

These are only the changes required for the library to compile on windows. Nothing more. The tests, for instance, do not compile.
@coreyoconnor coreyoconnor changed the title Windows command prompt support WIP - Windows command prompt support Aug 28, 2015
The tests fail to compile due to a "No such file or directory" error. This appears to be due to the long paths used for compilation. Pushing the changes as is for investigation.
Copy link
Contributor Author

@coreyoconnor coreyoconnor commented Aug 29, 2015

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:

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-\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-\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
e-opsStub.hs, .stack-work\dist\x86_64-windows\Cabal-\build\verify-attrib
ute-opsStub\verify-attribute-opsStub-tmp\Main.o )
Linking .stack-work\dist\x86_64-windows\Cabal-\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-\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-\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
erify-crop-span-generationStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.
.o )
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:
.10.2\\bin\\runhaskell.exe -package=Cabal- -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-\ 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-\hpc\.hpc\ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1
PS X:\>
Copy link

@simonmichael simonmichael commented Aug 29, 2015

Sounds like nice progress!

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

coreyoconnor added 10 commits Aug 30, 2015
…all test names.

Mapping the repo to a drive letter is also required.

All tests will compile. All but 1 test fails. The failures are all of the form "Test suite _ executable not found for vty". All the tests that fail are using detailed-0.9.
…ing necessary Console functions to Win32. Incomplete, but enough to get started.

TODO: Pull Request forks prior to merging this branch to master.
…ure of equations that produce Write values. The interpretation of the DisplayCommands is left to the platform. On POSIX platforms the DisplayCommands are interpretted to Write values.

No Windows implementation.

According to the terminal test and mock-terminal tests the performance is worse than before. I am
unable to locate the source of the performance issues.
Fixup setting console *output* code page and determining display size.
The output matches the terminfo output except: Double Column Characters are rendered single column; Instead of the default attribute white/black is used.
Correcting the default attribute handling is a straight forward application of Reader. I have not found a way to correct double column character support.
Copy link

@simonmichael simonmichael commented Jul 23, 2016

Ping, how is this looking ?

Copy link

@pavonia pavonia commented Aug 20, 2016

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.

Copy link

@pavonia pavonia commented Sep 14, 2016

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.

Copy link

@jtdaugherty jtdaugherty commented Dec 4, 2016

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

@jtdaugherty jtdaugherty closed this Dec 4, 2016
Copy link

@simonmichael simonmichael commented Dec 4, 2016

@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 ?

Copy link

@jtdaugherty jtdaugherty commented Dec 4, 2016

@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!

Copy link
Contributor Author

@coreyoconnor coreyoconnor commented Dec 4, 2016

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.

Copy link

@jtdaugherty jtdaugherty commented Dec 4, 2016

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

Copy link

@simonmichael simonmichael commented Dec 5, 2016

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. :)

Copy link

@simonmichael simonmichael commented Apr 25, 2017

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: 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."

2016: 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."

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

Copy link

@simonmichael simonmichael commented Apr 25, 2017

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.]

@jtdaugherty jtdaugherty reopened this Apr 25, 2017
Copy link

@simonmichael simonmichael commented Apr 29, 2017

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 for details.

Copy link

@jtdaugherty jtdaugherty commented Oct 1, 2017

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.

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

Successfully merging this pull request may close these issues.

None yet

5 participants