Support older Windows versions anyway :-P

[eyalroz]

I know the README says Windows < 10 is not supported because of lack of proper ANSI support.

But - people have been writing and using Windows terminal/command-prompt apps for years before Windows 10 came around. Sure, maybe they used something broken that's not ANSI. But - would it be that unrealistic to support that as well?

[certik]

If it is maintainable, we'll accept PRs to support older Windows. One approach might be to emulate the ANSI support, so we can just keep using ANSI in the rest of the library.

[staxfur]

Hi! I have actually tested windows compatibility with windows 8.1 and below and while it still compiles with MSVC, the constructor of the Terminal class (which is the core of the library, as it sets the terminal into "raw mode" so we can control the terminal manually) fails. The reason for the failing is that one function that we call of the Win32 API throws a runtime error on those versions of windows. I guess that they haven't implemented the functionality in the Win32 API at all.

Windows 8.1 and below use other parts of the win32 API than we do. Also i'm not sure if the "raw mode" is supported at all. I'll investigate this. Managing colors in the old CMD works by using special Win32 functions, they only support 3bit or 4bit colors though, so we would need to

• find a way to check the windows version on runtime properly
• on windows 8.1 and below we need to switch over to a method of entering the "raw mode" that works on older versions (if it's possible at all)
• the color() function would need to switch over to the old way of printing colors in the CMD on those versions
• the Window class needs to force 4bit or 3bit colors on those windows versions

So supporting windows 8 and below would mean much work and research. Currently the best would be to compile your program using MSYS2 or MinGW / Cygwin as they are using a ported version of Glibc (wich uses the linux version of the Terminal class constructor).
When you want to run the program outside of the chroot environment without packing the runtime along, you can compile using -Static when you call GCC or set the CMAKE_CXX_FLAGS cmake variable in cmake when compiling to compile glibc etc into the binary to make it stand-alone.

Compiling statically produces bigger binaries, but it makes packaging and installing the program a lot easier.

I'll add this to the roadmap to look into it later. When you would like to have this added quicker, feel free to contribute by researching ways on possible solutions! I'm currently working on the new window class, you can see the current development in the roadmap:
https://github.com/jupyter-xeus/cpp-terminal/projects/1

If you need help with the work around, feel free to ask!

[staxfur]

moved the documentation update to #174.

[flagarde]

Hi,

I found back this : https://gist.github.com/mlocati/21a9233ac83f7d3d7837535bc109b3b7
to check version of windows and apply color. It should solve one or two point of @MCWertGaming post

https://github.com/adoxa/ansicon seems to do what you are looking for... Maybe a merging of the two code could be done (it seems the LICENSE is quite open but i'm not lawyer so it must be cross-checked)

[staxfur]

The gist contains pretty cool checks to be honest. We can definitely use that. The other project would need a bit fixing and refactoring as far as I saw, should be pretty simple though. We should definitely look into that. The License is a custom one, but it reads like MIT, so I guess that adding the copyright to our license would be enough to comply. Much testing is needed, maybe we can simply use another part of the Win32 API that works on all windows versions. I'll look into that after i'm finished with the window class re-working. So it might take a bit for now.

@flagarde if you want to look into this, I can help you. But the Window class is more important right now for me as it's needed for some of my projects.

[flagarde]

I don't know if I will have time but I could try if I can. Indeed the 'ansicon' needs to be refactored and included but it gives a hints on what could be done.

For the gist if I understood correctly, the actual code, before Win10 crashes because it doesn't recognize some new features. Addind the version check and using it to avoid the crash could be the first step

[staxfur]

No problem, we have time. The first thing we should look into, would probably be the Terminal class. We should modify it so the runtime error that happens on windows if fixed, or (if possible) make a small re-write of it using a method that works across windows versions. Does ansicon include code to put the terminal into "raw mode"? That would be the most important thing for now as it's the core of the library that allows us to have full control over the terminal and things like input.

When we updated the Terminal class, we can move to updating the color function and the Window class (which is hopefully merged until then).

[staxfur]

This seems to be suitable for converting the 8bit colors (that are coming with the next Window class update) into windows XP / later versions of windows. I have created a "Auto color" function that does auto fallback to 8bit colors when 24bit are not supported (because MacOS terminal and the VGA console on linux are not supporting them, but 8bit it pretty widely supported).
https://github.com/adoxa/ansicon/blob/master/palette.h

So I could Imagine that we just create a function that determines the windows version, and if it's windows 8.1 to XP / 2000, we are just returning the string of the legacy windows terminal instead of the ANSI version.

[staxfur]

I don't see any code for changing the terminal mode though in ansicon, I think it's just for terminal colors.

I have looked through the Microsoft docs and they note:

Checking whether SetConsoleMode returns 0 and GetLastError returns ERROR_INVALID_PARAMETER is the current mechanism to determine when running on a down-level system. An application receiving ERROR_INVALID_PARAMETER with one of the newer console mode flags in the bit field should gracefully degrade behavior and try again.

So we would have to change https://github.com/jupyter-xeus/cpp-terminal/blob/master/cpp-terminal/private/platform.cpp#L166 to check the return value, it it's 0 and the error is invalid parameter as described here:
https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
When the error happens, we would have to try again with less flags enabled so we would have to find out which flag is causing the error.

[flagarde]

Yes is what I was thinking. Determine the windows version then depending on this turn the raw mode with ANSI handling or not. If windows is too old we need to parse the input to see if there is ANSI and fallback to the legacy windows terminal function for each

[flagarde]

Seems ansicon has to do a lot of hacks we don't need to do as we don't need to injects a DLL into a process, hooking its functions. . I think the easiest solution could be to let windows 10 deal himself with ANSI and if windows is older parse the ANSI by ourselft and trigger the good Windows functions base on the ANSI value. Mainly take the InterpretEscSeq() in https://github.com/adoxa/ansicon/blob/master/ANSI.c and plug it on input.cpp

[staxfur]

Well for the raw mode, we just have to find out which console modes are supported on the oldest windows version we want to support and then, when setting them fails, just try again with less flags turned on. The ansi fallback would be something to look into after that. parsing then ansi codes is pretty complicated, also microsoft writes that the virtual terminal modes (which we are using) provides a unified interface for all windows versions, so I assume that they have added the ansi patches for the cmd and powershell 2 already for later versions. If so we can simply skip the changes to the ansi functions.