Talk:Windows Console

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on the project's importance scale.

Microsoft Windows: Computing High‑importance

	This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows
High	This article has been rated as High-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Listcruft

Is this list of functions really necessary? Can we instead link to some MSDN documentation? Timbatron 21:43, 28 November 2006 (UTC)[reply]

Good point. I've decide to 'Be Bold' and delete it. Banality 04:38, 22 March 2007 (UTC)[reply]

UCS2

Under Windows NT/2000/XP, the screen buffer uses four bytes per character cell: two bytes for character code, two bytes for attributes. The character is then encoded as Unicode (UCS2).

But UCS2 characters can be longer than 2 bytes. --Abdull 09:21, 8 June 2007 (UTC)[reply]

No, UTF-16 characters can be longer than 2 bytes. — 71.147.52.209 (talk) 04:08, 19 November 2007 (UTC)[reply]

see related UTF-16/UCS-2 article. Tedickey (talk) 11:25, 19 November 2007 (UTC)[reply]

The API allows using UTF-16 in many other places, but console isn't one of these. You can't output anything more than UCS-2, and the buffer doesn't have any means to store them even if you could. KiloByte (talk) 03:02, 1 January 2010 (UTC)[reply]

Text mode

At least beginning with Vista, is it still valid to say that a Win32 console window can be put in text mode? --Abdull (talk) 23:00, 7 March 2010 (UTC)[reply]

Apparently not. ☹ Synetech (talk) 03:07, 14 January 2013 (UTC)[reply]

SVGA modes for Win32 console

The edit is phrased to make Windows seem defective. As I recall it, it provides the standard text modes for SVGA. Linux consoles can make use of nonstandard modes (particularly via command-line options to fill in for devices). On the other hand, Linux consoles are not directly accessible in the (X) Windowing environment, while Win32 console is supported in either the Windows environment (as noted) or full-screen. TEDickey (talk) 20:28, 11 May 2012 (UTC)[reply]

What do you mean as an "accessible Linux console"? Actually, an X Window server relies on either Linux console drivers /dev/ttyn or Linux framebuffer. In the former case one of virtual consoles is dedicated to an X server, so this console is perfectly "accessible in the (X) Windowing environment". I assert what I said, no more:

Win32 console can use less modes than Linux console;
Unlike Win32 console, a Linux application cannot be switched between fullscreen and X Window, at least without special non-standard software.

What exactly caused doubts? Incnis Mrsi (talk) 10:05, 12 May 2012 (UTC)[reply]

"Accessible" - you cannot display the console in an X session, you must switch. X is an application which uses a console. Your phrasing "only a limited list of text modes" ignores the issue of whether those are the standard ones, and makes the reader see that you are making Linux console the reference point. By the way, your comments (about available modes) apply to other operating system's consoles (such as FreeBSD, NetBSD, OpenBSD), and without making an attempt to balance the discussion are not neutral TEDickey (talk) 10:18, 12 May 2012 (UTC)[reply]

WP:SOFIXIT. Make all needed attempts to balance. Does somebody object? Incnis Mrsi (talk) 15:45, 12 May 2012 (UTC)[reply]

I'll collect sources, but won't have much time til the end of next week (will pick up the thread at that point) TEDickey (talk) 09:51, 14 May 2012 (UTC)[reply]

Now I need to make a [[WP:SOFIXEDIT]] shortcut. I think I'll point it to WP:PMBR. —Zenexer [talk] 04:37, 15 November 2012 (UTC)[reply]

thanks for the reminder, although your comment is not helpful in any sense TEDickey (talk) 09:32, 15 November 2012 (UTC)[reply]

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

Microsoft Windows 95 Version 4.00.1111 command.com MS-DOS Prompt 492x259.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 11:09, 1 July 2021 (UTC)[reply]

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

Microsoft Windows 95 Version 4.00.1111 command.com MS-DOS Prompt 492x259.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 04:07, 27 February 2022 (UTC)[reply]

Console Host & Windows Terminal

Would this be a place to explain the console host / Terminal ? Or is that to specific for this generic topic? Theking2 (talk) 14:34, 20 June 2022 (UTC)[reply]

Silly claim

"Prior to Windows 95, there is no native support for consoles."

NT 3.1 (https://wiki.riteme.site/wiki/Windows_NT_3.1) had a 32-bit cmd.exe running in a console. With the whole complement of 32-bit Windows standard console programs. NT 3.1 was released July 27, 1993, that's well before 1995. 77.16.35.138 (talk) 20:57, 18 July 2024 (UTC)[reply]

I changed it to, instead, say that "In Windows 3.1 and earlier, there is no native support for consoles." (BTW, you don't need to paste the URL for a Wikipedia page into a talk page; you can just link it, as in "NT 3.1 (Windows NT 3.1) had..." or "NT 3.1 had...".) Guy Harris (talk) 22:32, 18 July 2024 (UTC)[reply]