Add Win 10 native ANSI cmd support
Not sure why on_windows check didn't prevent check_win_10_ansi_support from running..
Well, it seems that the checks assume that Windows needs strip and convert. Not sure what I should do here. @wiggin15
I mentioned this in the review comments, but, just in case it got skipped over:
sys.getwindowsversion()[2] can be used to retrieve the Windows build number on Python versions as far back as 2.3. So check_windows_ansi_support can just be:
def check_windows_ansi_support():
return sys.getwindowsversion()[2] >= 1511
On Windows 7 this returns True. The check should include the major and minor, not just the build. A tuple comparison should work.
This would be wonderful to have! Powershell (on Windows 10) now supports 24 bit color, but when colorama is initialized, we get dropped back to 16 color mode.
Below is the same script, the first run without colorama, the second with colorama initialized.

Adding to the complexity, this new functionality only works on Powershell, and not on CMD...
@kirbyfan64
The build number is not the same as the ReleaseID, but they correspond:
- https://en.wikipedia.org/wiki/Windows_10_version_history
So the code should look like this:
def check_windows_ansi_support():
return sys.getwindowsversion()[2] >= 10586
Hey. FYI, yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it!
I think this PR is a different way of implementing the same feature as is done by https://github.com/tartley/colorama/pull/139, is that right?
I have no idea how to decide which is the best way of doing it. I'll have a closer look soon, but if anyone has any insight, please tell.
Apologies for ignoring this (and all other PRs) for years. :-D
Also, we'd need corresponding test changes before this could merge.
#139 uses a more direct/reliable strategy to handle the ANSI stuff, so closing this in favor of it