WIP - Windows command prompt support #1

wants to merge 12 commits into


None yet

5 participants


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 commented Feb 2, 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.


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


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
@coreyoconnor coreyoconnor Add compilation options for windows. Partition platform specific aspe…
…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 from Windows command prompt support to WIP - Windows command prompt support Aug 28, 2015
@coreyoconnor coreyoconnor Update compile options for tests for windows.
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.

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:\>

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 some commits Aug 30, 2015
@coreyoconnor coreyoconnor Work around path length issues on windows by removing "verify-" from …
…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.
@coreyoconnor coreyoconnor Push missing changes to vty.cabal. 15c2b0f
@coreyoconnor coreyoconnor Depend on forks of Win32 and ansi-terminal. These contain changes add…
…ing necessary Console functions to Win32. Incomplete, but enough to get started.

TODO: Pull Request forks prior to merging this branch to master.
@coreyoconnor coreyoconnor Use valid-wanted to prevent Win32 being built unless vty is on windows. 975b2a9
@coreyoconnor coreyoconnor Fixup Posix/Terminfo compile. 7409347
@coreyoconnor coreyoconnor Change the DisplayContext to an Operational monad instead of a struct…
…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.
@coreyoconnor coreyoconnor Stub implementation of output interface for Win32. 2b67f14
@coreyoconnor coreyoconnor Add MoveCursor and DisplayRowEnd implementations for Win32.
Fixup setting console *output* code page and determining display size.
@coreyoconnor coreyoconnor Add Win32 text attribute handling except for "keep current attribute".
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.
@coreyoconnor coreyoconnor Update win32 submodule 8161696

Ping, how is this looking ?

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.

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.


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

@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 commented Dec 4, 2016 edited

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


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.


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


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

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