Console limitations

by Michael S. Kaplan, published on 2012/06/13 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/06/13/10318676.aspx


In response to chcp can't do everything from March 2006, PierreMic asked over six years later:

Is it true that one can't add SimSun as a TrueType command box font on a Windows 7 Ultimate box unless the OS default locale is already Chinese!?

What is a *good* reason for this limitation?

Yes, it is true that the console limits its font selection based on the default system locale.

Since the console is based on the default OEM system codepage, it wouldn't make much sense to let another font outside the system codepage be selected.

This actually is a limitation that no one seems terribly interested in fixing, since changing the way the console works in such a huge way is an implicit promise that the console is still supported.

Which is something no one wants, since the backcompat bar is so high!

In the end, it is better left as legacy. PowerShell is the future for the console (note that the PowerShell ISE doesn't limit font selection this way!).


skSdnW on 13 Jun 2012 7:13 AM:

PowerShell ISE does not support interactive applications ( blogs.msdn.com/.../console-application-non-support-in-the-ise.aspx ) so I don't understand how you can call it the future. FTP? VIM? etc

"...that the console is still supported" why does MS hate the console so much? 20 years later and we are still stuck with stupid block selection, no tabs, incomplete font&unicode support etc.

Joshua on 13 Jun 2012 8:37 AM:

WndSks has a point. There is fundamentally no way to build a roguelike on top of PowerShell ISE _or any other pipe driven console replacement_ without re-linking the binary.

Since developers won't forgo a working console, you're in a pretty bad bind if you don't improve the existing one. Since forcing 65002 to OEMCP almost works (published hack), maybe finishing it is the way to go.

Random832 on 18 Jun 2012 12:09 PM:

CJK characters also (in addition to being boxes, that is) only take up a single character cell on non-CJK locales - I assume as fullwidth characters they take up two character cells in the appropriate locales.

Random832 on 18 Jun 2012 12:16 PM:

@Joshua

Roguelikes are a bit much to ask for... If you're going to build a roguelike, and specifically targeting windows (if you're not specifically targeting windows, it'd be best to use either pdcurses, or something like cygterm or cygwin rxvt), why wouldn't you use... well, windows? as in, the GUI?

A more serious problem is that if the console is unsupported, and powershell ISE can't support interactive input, then there is no support for ANSI/ISO C or C++ with stdin or cin for ordinary "ask a question, user types the answer" type interactive programs.

Anyway, I don't think Powershell ISE supports Unicode from console applications (as opposed to from powershell scriptlets). The earlier blog blogs.msdn.com/.../10072032.aspx says how to detect running in powershell ISE, but doesn't actually say how to accomplish unicode output if that is the case - WriteFile inherently doesn't support Unicode, and WriteConsole doesn't work in ISE.)

Joshua on 18 Jun 2012 2:24 PM:

@Random832: "...powershell ISE can't support interactive input..."

Turns out that fixing this is the problem that blocks roguelikes anyway.

Yuhong Bao on 30 Jul 2012 11:20 PM:

Someone proposed on the Old New Thing that replacement conhosts be supported.


go to newer or older post, or back to index or month or day