support 256 color

[melspectrum]

please have 256 color support. thanks!

[zadjii-msft]

Thanks for the suggestion! This is actually pretty high on my personal list of requests for the future, however, we weren't able to fit it into the Anniversary Update, though I'd keep my eye out in the future for it.

A coming insider update should have support to at least take the 256-color ANSI sequences and the full RGB ANSI sequences and find the nearest color that's in our 16-color table, and use that to render, which should at least enable applications which use those sequences to not be totally broken.

I'm gonna close this as a dupe of #76, which has more discussion on the subject.

[musm]

Could we get this reopened as #76 was closed since it was decided that the scope there was not 256 color support but just properly mapping 8-bit colors to the 256-bit range.

[benhillis]

Good suggestion!

[be5invis]

It is hard, almost impossible.
Conhost uses a fixed 32-bit-per-cell layout (16 bits for properties and 16 bits for character code), which is a derivative of VGA text mode (yes, the DOS-era video memory layout, 8 bits for properties and 8 bits for color). Modifying it will definitely break compatibility, unless MS want to implement a completely different console API set (and provide a compatibility layer for existing console apps).

[musm]

Thanks @be5invis. It's 2016, breaking compatibility with DOS I don't think will in anyway affect anyone using windows 10, maybe a dozen people. It seems more logical to introduce a new fresh and modern console API that can be used for the next decade and retain the old conhost for legacy purposes.

Certainly, this wouldn't be the first time compatibility has been broken and trying to maintain backwards compatibility for something that old is impressive. I like what they did with IE; tons of stuff depended on IE, but they figured a way around it and introduced Edge, by keeping IE installed but for legacy support.

Considering the large number of devs that use the terminal on a daily basis (esp. linux devs to are married to the terminal), i think this would benefit more people than it would affect. Bash on windows is wonderful, but it's missing some polish and I think this would go a long way.

[be5invis]

@musm However, I am talking about NT console API, which is the basis of almost all Windows console applications and many of them are important basic industrial infrastructure, controlling important things like nuclear power plants...
The only possible solution is to create a new console API interface and a bug-to-bug compatibility layer.

[musm]

I'm going to ref #417 as @Maximus5 suggested the fix
"@zadjii-msft This issue is not actually forces msft to implement truecolor in conhost. In fact, and instead, topic starter asked you to bypass ANSI to ConEmu, which already supports true-color in console.
Current implementation of console output in WSL prohibits ConEmu from processing any ANSI written by linux applications. That tight integration with kernel(?) is rather bad.
I believe, the issue have to be reopened, ConEmu doesn't limit user to 16-colors palette. And proposed approximation would look awful."

[be5invis]

@musm @benhillis @zadjii-msft
What if users do not have installed ConEmu?
The true problem is that CONHOST already used all bits of the console buffer. And programs can directly modify it via C/C++ code.
A solution may be to provide another completely different console API (stream-based) and provide a compatibility layer to the existing one (blitting the buffer at 60fps?). Maybe you MS guys should have a serious talk with OSG.

[musm]

The suggestions is a hacky one I agree, but something hopefully sufficient for the group using conemu in the interim while MS cooks up (hopefully) a longer term fix for the future.
+1 for your idea of a new console API with a compatibility layer is far preferable of course

[be5invis]

@musm
Hacky is necessary, because breaking existing console behavior may break important things like nuclear power plants. You definitely do not want that thing to happen.
If you want to connect your terminal to WSL, why do not just use SSH?

[musm]

Could you clarify on how I would "If you want to connect your terminal to WSL, why do not just use SSH?"