Need for support for pre-Windows 10 version 1511 re 'ANSI' codes

May I canvas views here on the following topic? Windows 10 version 1511 was issued in December 2015. The native terminal software on earlier versions of Windows did not support ‘ANSI’ control sequences (the codes that produce colour etc in terminal output). This is my question:

If future versions of a library on Hackage that you use stopped supporting users of Windows before Windows 10 version 1511 - by assuming ‘ANSI capability’ of the terminal - would you, or intended users of your software, be ‘put out’?

I am particularly interested in practical examples of where people would be inconvenienced.

What will be the effect of the change on remaining Win 7 users? It’s probably fine to downgrade to black-and-white, but garbled output would be quite unfortunate.

In part, I am seeking to understand whether there are people (globally) who are (a) compiling Haskell on Windows 7 or (b) using executables built with current libraries on Windows 7. Microsoft itself stopped mainstream support of Windows 7 in January 2020 and has said it will cease all support (even for a fee) from 14 January 2023.

2 Likes

I’m both (a) and (b) at the moment, and globally 12% of Windows users are on Win 7. Obviously, unpaid maintainers like you cannot be hold responsible for my choice to use a legacy technology, but it would be nice if ansi-terminal degraded gracefully to black-and-white on old machines. E. g., isANSITerminal can check getVersionEx and just return False for versions earlier than Win10 1511.

2 Likes

Unfortunately here you will get some kind of reliable answer for the former question but not for the latter, as we are mainly programmers here (or programmers/users, not just users). I wrote some terminal programs and games, I received feedback from people running them on Windows, I cannot say which specific Windows version.

I “MS will cease all support” implies “will cease security fixes too”, I think there is a strong point in dropping Win7 from that date. A possible solution that does not saddle maintainers is a good changelog entry plus adding a isLegacyWin :: IO Bool function so library users could decide to work around Win7 quirks if they so wish.