Jump to content

Talk:Cmd.exe/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Syntax error

There was no "Syntax Error" message in command.com (just checked with my MS-DOS 6.22) —Preceding unsigned comment added by Tyomitch (talk • contribs) 12:47, 4 September 2005

Nor in Windows 7; the usual messages are
  • 'snafu' is not recognized as an internal or external command, operable program or batch file.
  • Invalid switch - "foo"
and similar context-relevant messages.
"Syntax Error" has been removed from the main article some time ago. Done D A Patriarche, BSc 00:41, 23 March 2017 (UTC)

Backwards Compatibility

I believe the statement "cmd.exe remains part of Windows Vista, Windows Server 2008, and Windows 7 for backward compatibility." is wrong. It's not for backwards compatibility, it's from running CLI programs like "NET", "telnet", "ping", etc. And in the server core versions of Windows Server cmd.exe is the default UI. I think this statement should be deleted or modified to be a bit more true, but I want to hear what other people think before doing that myself. TheGeekHead (talk) 21:03, 17 June 2010 (UTC)  Done D A Patriarche, BSc 00:46, 23 March 2017 (UTC)

Emulator

I think cmd.exe hardly classifies as Emulator, so I propose to remove the category: DOS Emulators from the page (and also remove the link to cmd.exe from List of emulators, where it recently appeared. Opinions? Darkstar 11:28, 28 August 2006 (UTC)

  • Update: in fact I already removed the link to cmd.exe from List of emulators. Darkstar
  • This is most definitly not a DOS emulator... it dosn't emulate dos at all, infact, it's completely different software... (no dos virtual machine at all)... I'm removing it, if you want, someone can put it back in, but it shouldn't be. Leif902 01:32, 14 February 2007 (UTC)
The confusion with the MS-DOS prompt, is due to Microsoft using the same icon for DOS as CMD.EXE in NT3 and NT4, and calling the thing the DOS prompt. DOS actually launches a NTVDM and runs its console output into the windows console session. In OS/2, the DOS emulation + COMMAND.COM are run as separate desktop applications to native OS/2 command-line applications. You don't hear OS/2 users confusing the two. Wendy.krieger (talk) 09:10, 6 January 2017 (UTC)

x64

Have x64 processors dropped support for cmd.exe, or just authentic versions of DOS? --File:Cvilletrojan.PNG page | contact 13:36, 14 June 2006 (UTC)

Your question is erroneous. cmd.exe is just a Windows program. Are you asking if MS-DOS 6.x runs on a 64-bit AMD64 or IA-64? From the articles it seems it does. --ozzmosis 03:31, 21 June 2006 (UTC)
Win64 does not have the virtual machine to run MS-DOS 5.0 and Win16 apps. Programs like command.com, edit.com, edlin.exe and edit.com are not supplied with these versions. On the other hand, ye can run a third-party VM, like Virtual PC, which will run MS-DOS and Win16. --Wendy.krieger (talk) 10:20, 3 February 2009 (UTC)
I think you are referring to x64 versions of Windows. If you install an x86 version of Windows on an x64 processor cmd.exe will act exactly like it does on x86 processors. In x64 versions of Windows the 16-bit executable compatibility was removed. The 16-bit executables were the most common for DOS. cmd.exe has never been a "version of DOS", but it was able to run the 16-bit executbles associated with DOS. On x64 Windows the 16-bit executables won't run giving the illusion that it's not DOS compatible anymore. I hope I have answered your question. TheGeekHead (talk) 20:53, 17 June 2010 (UTC)
In 64-bit Windows, cmd.exe is a 64-bit Windows application that can run either 64-bit Windows console apps or 32-bit Windows console apps (like FAR 2, which comes in both types). 16-bit DOS apps can't run. This has nothing to do with the user interface, it's a platform compatibility issue. For example, Volkov Commander might look like FAR and perhaps even uses similiar routines, but it's a 16-bit DOS app and unsupported on 64-bit Windows. An emulator like DOSBox is needed to run it. --79.178.202.78 (talk) 15:59, 2 August 2010 (UTC)

Merge with Win32 console

I've suggested a merge between Win32 console and cmd.exe, as I don't really see any difference between them (Win32 console appears to be the API for cmd.exe?). If they really are different, please explain how, and remove the merge tags. If they are the same, say "aye!" here (or just go ahead and merge them, I suppose). --H2g2bob 19:00, 20 June 2006 (UTC)

No, they are different. Console I/O is done by way of the Console Subsystem API [1]. cmd.exe is not required. Additionally, Win9x/ME support the Console API (albeit poorly), where cmd.exe is nowhere to be found. --ozzmosis 03:18, 21 June 2006 (UTC)
No merge. cmd.exe is just an example of a program that uses Win32 console APIs. There are many others, e.g. FAR Manager or Cygwin, which have nothing to do with cmd.exe. — Monedula 08:32, 21 June 2006 (UTC)
No merge. OS/2, on which Windows is modeled, also has cmd.exe. The name comes from some failed IBM attempt to associate file.EXT with EXT.exe, eg mybatch.cmd with cmd.exe. In both OS/2 and Windows, it is possible to replace the default comspec with something more useful, eg 4OS2, 32-bit CMD, or in nt, 4NT. --Wendy.krieger (talk) 07:31, 21 August 2010 (UTC)

Command line length limitations.

There is no reference to the maximum length of the command line, or if the line splitter '\' has any influence upon the length. Also, I think a history or some sort of changelog would be welcomed, since the cmd.exe did changed between NT3.5 and NT4. —The preceding unsigned comment was added by Muttley.meen (talk • contribs) 15:49, 16 January 2007 (UTC).

Shutdown

Does anyone know how to use the shutdown command? Any help would be greatly appreciated.

Thanks,

PulsHrd 02:44, 26 January 2007 (UTC)

See this page: http://www.ss64.com/nt/shutdown.html or type shutdown /? at the command prompt. — EagleOne\Talk 22:19, 13 February 2007 (UTC)
It's "shutdown -s -t 0". Using the /? argument gives you the full list of options and explains what the "-s -t 0" do. TheGeekHead (talk) 20:55, 17 June 2010 (UTC)

Vista

Can someone with Vista fix this:

cmd.exe is scheduled to be replaced with Windows PowerShell during 2007, but is expected to remain as part of Windows Vista for backward compatibility.

Is it part of Vista? --h2g2bob 22:12, 18 March 2007 (UTC)

I use Vista Ultimate at home. Cmd.exe is definitely included with the OS. — EagleOne\Talk 16:20, 18 February 2008 (UTC)
It's 2010 now and as far as I know Windows Powershell is only enabled by default in Windows Server. It's included with Windows Vista and 7, but it needs to be enabled through add/remove Windows components. TheGeekHead (talk) 20:56, 17 June 2010 (UTC)
2017 - Windows 10 officially replaced cmd with PowerShell, but cmd.exe is still available. See Windows Versions below. D A Patriarche, BSc 01:07, 23 March 2017 (UTC) — Preceding unsigned comment added by D A Patriarche (talk • contribs)

Virus?

Suddenly, my computer went to a screech and I opened up my task manager, only to find about 300 tasks for cmd.exe. Is this a virus? Ever since that, our computer's calender has been messed up, internet speed's a craw even if we use DSL, and freezes up regularly. Someone help us. —Preceding unsigned comment added by 69.154.140.125 (talk) 20:16, 8 September 2007 (UTC)

Sounds like a virus or bug that makes cmd open many times. Just use a virus scanner. And Wikipedia isn't the place to post questions like this. Please use something like Yahoo! Answers or a forum. TheGeekHead (talk) 20:58, 17 June 2010 (UTC)
Wikipedia is suitable for questions like this, but only in the proper part of Wikipedia, namely Wikipedia:Reference desk/Computing. --Teratornis (talk) 21:47, 10 June 2014 (UTC)

Requested move

The decision to rename this from cmd.exe to Command Prompt (Windows) was wrong.

See In case anyone cares below (et praec. et sqq.) for final outcome checkYD A Patriarche, BSc 23:42, 22 March 2017 (UTC)

No fullscreen support in Windows Vista and Above

Could someone please explain in the article the reason why Windows Vista and above cannot run any type of command prompt (CMD.EXE, Powershell) full scren (possibly real mode?) --azure talk × contribs 18:21, 19 April 2008 (UTC)

I don't think it's appropriate to be in this article, since it's not specific to cmd.exe, but all console applications. And it's not exactly true, either. It only applies to WDDM video drivers. If you go back to an old WDM driver (losing aero in the process), full screen works. Madlobster (talk) 18:07, 13 August 2008 (UTC)

EXTPROC and REXX

OS/2's cmd.exe supports extproc and rexx commands (ie .cmd files beginning with /* )

EXTPROC allows a different command (including a different cmd file), to take over processing of the batch. You can then write alternate command processors (in rexx, eg), that will process the batch as input.

Running 'mybatch options' beginning 'EXTPROC MYPROC' will run myproc mybatch options.

This replicates the /# functionality of unix shells.

REXX was the IBMSAA glue language, the idea being that eventually, all IBM operating systems (including OS/2 and PC-DOS 7.0 and higher), would recognise rexx scripts as batches, and process these using the rexx processor.

4NT, being a port of 4OS2, replicates these functions, bringing this utility to Windows NT. --Wendy.krieger (talk) 10:11, 3 February 2009 (UTC)

CMD and COMMAND

CMD is a 32-bit command.com, which is differentiated from the 16-bit version for various reasons. Much of the command interface is identical, so if cmd.exe is to be merged with something, it is command.com.

The cmd.exe in reactos is a recompile of freedos command.com. OS/2's cmdref.inf shows the DOS and OS/2 specific bits by using the DOS and OS/2 icons in the manual.

The 4os2.exe cmd-replacement, is a recompile of the 4dos command.com replacement. The first 4os2 manual is an addendum to the 4dos manual. Many of the cmd. fetures were backported to 4DOS, for example. --Wendy.krieger (talk) 10:27, 3 February 2009 (UTC)

Actually, the command.com for MS-DOS 7.0 (Windows 95) and MS-DOS 7.1 (Windows 95 Service Pack 2 and Windoows 98) was a binary that could run in both 16-bit and 32-bit modes. In the 16-bit mode, it was a real-DOS application, and when in the 32-bit mode, it was a DOS-emulator running inside Windows. 189.120.185.126 (talk) 20:14, 7 July 2013 (UTC)
This is not true at all. While there were some changes to the file format of COMMAND.COM with MS-DOS 7.0, it is still a genuine 16-bit DOS application. Further, Windows 95/98/SE/ME do not need a DOS emulator, because these versions are DOS-based. The DOS portion, from which the GUI is launched, integrates with the Windows portion to form the hybrid 16-bit/32-bit OS Windows represents in 386 Enhanced mode when the virtual machine manager (VMM) is loaded (which happens as part of the normal process to start up the GUI). DOS thereby becomes part of the system VM. Despite claims to the contrary, this DOS portion is a vital part of the system, actively used while the GUI is up (even when no DOS programs are executed at all), and the system could not function without it, architecture-wise. When you launch DOS applications under the GUI, each of them is executed in their own virtual machine (VM) context, partially instanced from the system VM and preemptively multitasked under the control of the VMM. --Matthiaspaul (talk) 22:30, 7 July 2013 (UTC)

?

trying inquiry mind of deleter scorching[2]: 

SET variable=toValueX, ECHO %variable% ; for math SET /A Arithmetic v=2+2 ; see more [3]
The existing sources give more detailed (and authoritative) information than that. The addition didn't pass WP:EL TEDickey (talk) 10:10, 7 July 2012 (UTC)

Start with WP:EL, which says "The burden of providing this justification is on the person who wants to include an external link". A quick check of the suggested link shows that it's no better than the content on Wikipedia, having no reliable sources, a mishmash of comments for a variety of components of Windows - and some not. So it adds nothing to the topic. The comments about non-commercial are irrelevant, since low-quality information has no lower-limit on its value. TEDickey (talk) 09:15, 12 February 2014 (UTC)

While the external site http://www.kapcom.com.au/windows-cmd-commands-cmd-network-commands.html offers a lot more information than the Wikipedia page (no surprise there, given that Wikipedia is not a manual), it doesn't seem to offer anything that goes beyond the self-documenting feature of commands when invoked with /?. I agree that it's not a value-adding link for this page. -- Michael Bednarek (talk) 13:43, 12 February 2014 (UTC)

Requested move 14 July 2014

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved. Command Prompt will now redirect to command prompt. Jenks24 (talk) 09:54, 22 July 2014 (UTC)


Command Prompt → CMD.EXE – The article is specifically about the command-line interpreter CMD.EXE in OS/2 and Windows NT, not about command prompts in general. Neither is CMD.EXE called Command Prompt in general, nor is the term command prompt specific to or in primary usage for CMD.EXE, quite to the contrary. The term refers to command-line interpreters in general (of which CMD.EXE is just one out of many others), or specifically to the prompt feature typically found in command-line interpreters. In analogy to similar articles for f.e. COMMAND.COM and per MOS:COMPUTING, the proper title for this article is therefore CMD.EXE, hence the move request. Command Prompt should become a redirect to the already existing disambiguation page at Command prompt. – Matthiaspaul (talk) 12:39, 14 July 2014 (UTC)

This is a contested technical request (permalink). EdJohnston (talk) 14:41, 14 July 2014 (UTC)
MOS:COMPUTING seem to be silent on the capitalization; exiting usage seems mixed. cmd.exe seems to be more natural and in line with the physical name in current and recent Windows versions. -- Michael Bednarek (talk) 07:11, 15 July 2014 (UTC)
Regarding capitalization, MOS:COMPUTING#Platform-specific guidelines distinguishes between various operating systems: Commands and filenames in DOS and OS/2 should always be written in uppercase, whereas for Windows it depends on the context, CMD-related stuff should be written in all-uppercase, whereas PowerShell-related stuff should be written in lowercase. Therefore, the correct capitalization here would be CMD.EXE. Actually, if you check the help (CMD /?, HELP, etc.), Microsoft consistently uses the uppercase form as well. This is also the form used in most books on the subject. --Matthiaspaul (talk) 09:51, 15 July 2014 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

In case anyone cares

Command Prompt has been retargeted to point back to this article, despite the consensus of the above discussion. I've already reverted once, but can't really be bothered entering into a protracted discussion or edit war over an article/redirect that holds no interest to me. But seeing as multiple people above felt strongly enough to to comment that they believed the redirect should point to command prompt I thought I'd leave a note here in case anyone wants follow up on it. Pinging the editors who participated in the above RM: Matthiaspaul, EdJohnston, Michael Bednarek, 65.94.171.126, Red Slash. Also BD2412 as they were involved in turning that dab page into a concept dab. Jenks24 (talk) 16:10, 31 July 2014 (UTC)

User:Jenks24, the list of users you just posted qualifies as WP:CANVASSING, particularly since you did not include myself or User:Codename Lisa in it. (Surely, being an administrator, you are already aware of this guideline?) Dogmaticeclectic (talk) 16:20, 31 July 2014 (UTC)
You and Lisa are already aware of this issue, what would have been the purpose of pinging you two? Admittedly EdJohnston is also aware of it so pinging him was unnecessary, but I was just copy pasting everyone who participated in the above discussion regardless of their views. (Yes, I'm aware of the canvassing guideline.) Jenks24 (talk) 16:27, 31 July 2014 (UTC)
a) It seems unhelpful if readers land at different articles depending on the case of a search term like "command prompt"; in other words, "command prompt" and "Command Prompt" should lead to the same target. b) Unanimous consensus above was clear: "The result of the move request was: moved. Command Prompt will now redirect to command prompt. Jenks24 (talk) 09:54, 22 July 2014 (UTC)" (The original request's wikilinks have now become distorted.) -- Michael Bednarek (talk) 03:52, 1 August 2014 (UTC)
I just want to remind you all that WP:DIFFCAPS is, indeed, policy. Good night. Red Slash 04:35, 1 August 2014 (UTC)
Hi. Please allow me to quote:

Command Prompt should become a redirect to the already existing disambiguation page at Command prompt.

However, command prompt is no longer the approved disambiguation page. (Special:Diff/618031347) Hence, per WP:CCC and WP:NOTBUREAU, that consensus is rendered invalid by the current circumstances. At this time, leading the existing backlinks of Command Prompt to cmd.exe is the most logical choice.
Best regards,
Codename Lisa (talk) 10:26, 1 August 2014 (UTC)
Command prompt is no longer a disambiguation page because it is an unambiguous broad concept. The concept covers all of the topics that were listed on the disambiguation page. No information has been lost from that page, and it remains the optimal target for a capitalized version of itself. I see no distinction here that would invoke WP:DIFFCAPS, and no reason to believe that a reader searching for Command Prompt will not have their query fulfilled by the content at Command prompt. If there are incoming links that are intended to invoke cmd.exe, AWB is this way, and can fix hundreds of these links in a few minutes. bd2412 T 12:56, 1 August 2014 (UTC)
Correct so far, but incomplete. There are inbound links to Command Prompt whose perfect targets are Cmd.exe. Retargetting was the best and the only flawless fix; and most importantly, no one yet has named a caveat besides the so-called deviation from a consensus whose parameters are invalidated by you yourself.
As for the rest, please have a look at the 90-days traffic stats for "Command prompt" and "cmd.exe". As you can hopefully see, there has been a marked change of trend since 22 July 2014, the day of the rename: "Command prompt" traffic has fallen below its average while "Cmd.exe" traffic has soared. Evidently, "cmd.exe" is the primary topic and with the end of ambiguity after the rename, visiting command prompt is now pointless. (Previously, it was just frustrating.) And although I did not invoke WP:DIFFCAPS, it appears it is the case here.
Best regards,
Codename Lisa (talk) 16:33, 1 August 2014 (UTC)
For the records, Lisa has changed the link target of Command Prompt for the forth time now in short succession against the outcome of the discussion and consensus above. Consequently, she has been reverted by various editors. Obviously, there is little support for her wish to point Command Prompt to CMD.EXE. In either case, the edit-warring must stop, because edit-warring is disruptive and never a solution. Using foul language and attacking other editors is not acceptable, either.
Personally, I support the current consensus to point Command Prompt to Command prompt. I do agree with Lisa, that case matters, but disagree with her in regard to what sources are authorative to determine the proper capitalization.
To me, "Command Prompt" is just a capitalization variant (typically used for headlines or in messages) of "Command prompt" or "command prompt", a generic term used in all kinds of contexts and not related to Microsoft or Windows at all, hence the redirect to "Command prompt" (regardless if this would be a disambiguation page or not). To Lisa, it is a proper name used by Microsoft.
But even when narrowing the focus down to the Windows environment only, "Command Prompt" is nothing more than the default window title in the English version of Windows for the default command-line interpreter named CMD.EXE. The display can be changed easily using the TITLE command, and many systems are configured to instead display the path to the currently running program, anyway, f.e. C:\WINDOWS\SYSTEM32\CMD.EXE. If you invoke CMD /?, the program name is CMD and it is described as the "Windows command interpreter", no signs of "Command Prompt" there at all. If you check Microsoft literature, they use all kinds of descriptions ("command-line interpreter", "command interpreter", "command prompt", "Windows prompt", "Windows command line", "Windows command prompt", etc.) in all possible capitalization variants. "Command Prompt" is not even their preferred usage; it is impossible to derive any primary usage from this.
So, while WP:DIFFCAPS could apply in more specific cases (or cases with less ambiguity), I don't see it applying here at all; Command Prompt is just a much too generic term, capitalization notwithstanding.
Per WP:NCDAB our normal procedure in such cases is to make the title more specific, f.e. Microsoft Command Prompt, Windows Command Prompt, Command Prompt (Microsoft), Command Prompt (Windows). All of them already exist as redirects to CMD.EXE (and should continue to exist, of course).
Summing up, I suggest to keep the redirect from Command Prompt to Command prompt and individually fix up the few remaining article backlinks (This was ongoing work-in-progress after the page move, anyway. Most of the remaining incoming links are from project, user or talk pages and don't need to be fixed up.) to Command Prompt to whatever is their optimal link target, Command prompt, CMD.EXE, COMMAND.COM, CCP, PROMPT, Command-line interpreter, whatever. In many cases, the following redirects may be suitable alternative link targets as well in order to simplify piped links (for the little known "pipe trick", see also: Help:Pipe trick#Examples):
--Matthiaspaul (talk) 00:04, 3 August 2014 (UTC)
Hi. I have few comments in response to Matthiaspaul:
  • "...against the outcome of the discussion and consensus above"
The outcome was retargetting to a actual bulleted disambiguation page. No such page exist at this time. Hence the parameters of the consensus are invalid.
  • "To Lisa, it is a proper name used by Microsoft".
Not even once did I say that. My main reasons were existing backlinks, Wikipedia's integrity and page view stats. See above.
  • "I do agree with Lisa, that case matters..."
I don't know where you are going with this discussion – which already smells fishy – but I am not coming: We are talking about the target of a redirect. Redirects can be created because of being typos, wrong, obscure and ugly and in spite of the realities of what matters and what not. The only consideration in creating them is whether they lead the reader to his intended target. Stats show the cmd.exe is a more likely candidate than that poorly written command prompt.
  • "Consequently, she has been reverted by various editors."
And supported by various editors too. I and Dogmatic talked to some opposing editors and they decided not to pursue the matter further. And last time I checked, per WP:REVERT and WP:BRD, I was entitled to be talked to (not talked at) before a counter-revert. There is no second R in BRD. What was the last time you, Matthiaspaul, had a collegial chat with me without resorting to misrepresenting quotations, ignoring the policy, vilifying me or censoring my point of view? Exactly like this discussion, you start your arguments with a comment on person or personal attack.
Concerned,
Codename Lisa (talk) 12:41, 3 August 2014 (UTC)
  • Back in prehistoric times before anyone heard of Windows, many computers and computer terminals only had one case of letters, usually uppercase, and all their filenames and commands were thus in uppercase, and thus were so written in computer instruction books. Anthony Appleyard (talk) 05:02, 4 August 2014 (UTC)
  • We don't live in those ages anymore. We live in the age of WP:COMMONNAME and MOS:CAPS, when the commonly recognizable name is in lowercase. And the subject of this article does not come from those ages. It comes from the age of case-insensitivity. Uppercase was internally chosen for performance. Lowercase was internally given validity. Fleet Command (talk) 05:29, 4 August 2014 (UTC)

CMD.EXE or Cmd.exe?

The caps of the name of this page have gone back and forth. Myself, I think all-caps simply looks ugly and ignorant, and doth harking back to days of yore and ye 6-bit pre-ASCII sets of yon characters. But it doesn't matter what I think, or what other authors think. The Wiki policy at MOS:COMPUTING#Platform-specific guidelines seems to hold sway. To wit "As such, stick to the DOS and OS/2 guidelines [upper-case] for command-line elements and examples of Command Prompt [CMD.EXE]". (Note that the link to Command Prompt was meant to point to this article, but currently suffers from the debris of the ongoing "non-controversial" page moves.) Comments? --A D Monroe III (talk) 21:15, 1 August 2014 (UTC)

Move request – CMD.EXE to Cmd.exe

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page moved by a rough consensus. Arbitrarily0 (talk) 02:20, 13 August 2014 (UTC)

CMD.EXE → Cmd.exe – This is a follow up of a speedy move request by User:Codename Lisa, which is contested by User:Matthiaspaul. Note that this is not an escalation; I am starting this discussion independently of my own volition.

Codename Lisa's reason for moving: [4]

  • WP:ALLCAPS forbids the use of all capitals except in a handful of cases
  • MOS:CLI exceptionally allows command line code examples to be written in all capital but says nothing about the body text and the title. (User:Michael Bednarek seems to have independently confirmed this observation above, if I am not mistaken.) Hence, WP:ALLCAPS must be followed there.

Matthiaspaul's reasons for not moving: [5]

  • "These are DOS file names and" and per MOS:CLI "DOS filenames must be written in all-uppercase". (This claim directly contradicts Codename Lisa, who contends that section only applies to code examples only and Michael Bednarek who contends that MOS:CLI says nothing about title in all capitals.) Hint: Cmd.exe is not a DOS file. Has never been.
    • Note: In a separate discussion in Talk:CHKDSK in October 2013, Matthiaspaul contended that MOS:CLI applied to everything (not just examples) but Codename Lisa subverted the text. I did look at a version of the page that predates the alleged subversion: [6]. Looks the same to me in that certain area.
  • This reflects the established conventions in the majority of books on the subject over the past 35 years.
  • Codename Lisa is already engaged in another discussion
  • Codename Lisa is rude and verbally accosted User:Jenks24 (an admin, no less) Struck out per Jenks24 request below.
  • Codename Lisa is gaming the system

Potentially interested parties: User:A D Monroe III, User:BD2412, User:Anthony Appleyard, User:Red Slash, User:Jenks24, User:EdJohnston.

What do you think? Fleet Command (talk) 08:12, 2 August 2014 (UTC)


  • Support. Wikipedia policies and guidelines have already overruled established practices that are several centuries old, let alone 35 years. MOS:CAPS, and its child section WP:ALLCAPS are no exceptions. But they are our guidelines, and reflect the consensus of the majority in Wikipedia. Fleet Command (talk) 08:12, 2 August 2014 (UTC)
  • Support. I see nothing in WP policies or guidelines that clearly overrides Microsoft's own treatment. See the first item in External links. Surely no one would claim that the primary source is not sufficient in this case.   Mandruss |talk  08:57, 2 August 2014 (UTC)
  • Just dropping by to say I didn't have a problem how Codename Lisa addressed me. She is perhaps blunter than absolutely necessary but I definitely didn't feel "verbally accosted". I know you, Fleet Command, were just trying summarise the arguments but I don't think that bullet point is either correct or actually germane to this RM, so I'd appreciate it if you struck it. Cheers, Jenks24 (talk) 09:01, 2 August 2014 (UTC)
  • Support. As stated above, this is not and in fact cannot be a DOS file name; it is the name of a Win32 executable that first existed in Windows NT 3.1. (Developers' releases in late 1992, product release in 1993, thus any books written more than 22 years ago are completely inapplicable.) I don't have an NT 3.1 system to look at, but I do have a 4.0 system, and it's called "cmd.exe" there. Today, in both Windows 7 and Windows 8, the display in Windows Explorer/File Explorer says "cmd.exe". (btw, NTFS is case-insensitive for file name matching, but is case preserving, meaning that the file system and Explorer are not simply downcasing the name. That's the actual name of the file.) The article name should follow reliable sources, namely the operating system itself. Or, how about the most authoritative book on the OS? Windows Internals (Russinovich, Solomon, and Ionescu) calls it "cmd.exe", both in prose and in code samples. And there is precedent; we already have ntoskrnl.exe (horrible though it is). I don't see how a line in MOS:CLI that concerns DOS filenames is applicable. n.b.: A filename stored in a Windows NT-family system is not a DOS filename any more, even if the file originally came from a DOS system, which this one did not. Jeh (talk) 09:05, 2 August 2014 (UTC)
  • Support as unaffected by MOS:CLI. I didn't respond to Matthiaspaul in an unrelated RM (09:51, 15 July 2014 UTC above) because his argument (DOS) was not on point. I still maintain that Wikipedia:Manual of Style/Computing#Platform-specific guidelines is silent on the question of CLI commands in Windows NT-based systems. (IMO, they should all be in lower case.) -- Michael Bednarek (talk) 10:06, 2 August 2014 (UTC)
  • Oppose: unfortunately sources don't demonstrate consistent preference for any capitalization scheme, so we have to base descisions on Wikipedia style guidance. MOS:CLI definitely applies to all mentions of Windows command-line software, and it explicitly says that it is not limited to code examples. Although CMD.EXE is not exactly DOS software, it is native implementation of DOS command interpreter on Windows, which is what MOS:CLI refers to. — Dmitrij D. Czarkoff (talk•track) 12:19, 2 August 2014 (UTC) (Fixed wikilinks. 23:25, 4 August 2014 (UTC)
    • I think all reasonably current sources do show a consistent preference for non-all-upper-case, as does the operating system itself. I don't know why you would give any weight at all to a source that says the file name is CMD.EXE when the operating system clearly says it is cmd.exe. This does not need any other source. It is a "the sky is blue" level of obviousness.
    • You write: "it explicitly says that it is not limited to code examples" - ah, no, just the opposite. The guidelines in question in WP:CLI are preceded by "The following additional guidelines are for command-line examples". To the extent that it does apply to NT-based systems, I don't see how this can be interpreted as applying to general discussion in prose, let alone article titles. Jeh (talk) 14:35, 2 August 2014 (UTC)
      • I actually don't see dominant lowercase "cmd.exe" outside Microsoft documentation and derived writings. In fact I see no single material with different cases used for COMMAND.COM and cmd.exe, showing that lowercase usage demonstrates typographical neglegence if anything. As for examples: "As such, stick to the DOS and OS/2 guidelines for command-line elements and examples of Command Prompt and Recovery Console" (emphasis added). — Dmitrij D. Czarkoff (talk•track) 23:25, 4 August 2014 (UTC)
  • Support. While some sources do refer to it as CMD.EXE, it appears to me that cmd.exe (or Cmd.exe at the beginning of a sentence) is at least and probably more common. The actual pathname as it appears in a default Windows installation is "C:\Windows\System32\cmd.exe". Finally, I agree that the guidelines discourage all caps titles. Msnicki (talk) 12:44, 2 August 2014 (UTC)
  • Support - For reasons already stated. The lowercase form is more consistent with common practice on enwiki, and would seem to preferable according to WP:TITLE. Personally, I would actually prefer that the first letter be lowercase as in eBay, but I believe that is outside of the norm.- MrX 14:32, 2 August 2014 (UTC)
  • Oppose: What seems to have been ignored by the other participants in this discussion is that this is not a Windows-only topic: "on OS/2 and eComStation, Windows CE and on Windows NT-based operating systems" - that comes right from the lead of this article itself! Wikipedia:Manual of Style/Computing#Platform-specific guidelines is abundantly clear that capitalization is required in this case; furthermore, User:Codename Lisa failed to supply evidence for the assertion (made here) that this guideline "does not apply to the article prose or even title". Finally, even for Windows-only topics of this type, note that the same guideline section states: "As such, stick to the DOS and OS/2 guidelines for command-line elements and examples of Command Prompt and Recovery Console." Dogmaticeclectic (talk) 15:18, 2 August 2014 (UTC)
    • One, cmd.exe never existed in DOS so that claim in this article should be corrected. Two, there is no reason to follow any precedents set by OS/2, eComStation (whatever that is), or Windows CE - they're all obsolete. The evidence that the guideline does not apply to article prose or title is in the phrase "The following additional guidelines are for command-line examples". It is under that heading that the list item "Write the names of commands and programs all upper-case letters." appears. There is no way this can be construed as extending to prose or article titles. Jeh (talk) 15:36, 2 August 2014 (UTC)
  • So if we take the previous word "example" it has even narrower scope. But I don't think that guideline should be applied to Windows NT at all. Windows doesn't name its own files by all upper case. Microsoft does not either. Who is WP to fly in the face of such sources? Jeh (talk) 16:31, 2 August 2014 (UTC)
  • Hello, MrX. I changed the word "example" to "elements" in the title only, because under that title, there are other guidelines that are not related to examples alone. But I kept the word "example" under the §Platform-specific guidelines. I was very careful to keep that word because it was of the CHKDSK fiasco. Best regards, Codename Lisa (talk) 17:31, 2 August 2014 (UTC)
  • User:Jeh, whether the operating systems you just listed are obsolete or not is a strawman argument - this article explicitly refers to them (even in the infobox!) and they are therefore relevant here. (I can note, though, that the eComStation article states that is still being updated - even if you are unfamiliar with it, which of course brings up the question as to whether your opinion in this discussion is entirely fact-based, you could have simply visited the article to find that out.) Your point regarding DOS is even more of a strawman argument since I did not even mention that (except as part of a quotation). I still do not see any evidence for this statement of yours, including the snippets you just posted (which do not preclude anything): "There is no way this can be construed as extending to prose or article titles." Dogmaticeclectic (talk) 16:06, 2 August 2014 (UTC)
  • Sorry, my reference to DOS was simply a mis-read of what you'd written; in the future, please WP:AGF rather than assume that I'm deliberately making stuff up, any more than when I wrote WP:CLI instead of MOS:CLI previously.
  • Why we should kowtow to conventions originating in DOS, when the convention in the Windows NT family is different, and far more widespread, is beyond me. OS/2 is dead and eComStation should be listed in the dictionary as an example under "obscure." As for CE, cmd.exe isn't even a required component. Windows NT calls the file "cmd.exe" and when writing about NT it is simply not within WP's prerogative to say that it is anything different. That other OSs call it CMD.EXE does not change that. The quote I gave from the guideline says "the following applies to such-and-so"; if it was meant to include prose and article titles then it would have said so. As it is it does not preclude the use of all upper case in prose or article titles but it certainly does not require it; in the absence of such a requirement we must go to the sources; the authoritative sources use "cmd.exe". It is factually wrong for WP to use anything else. Jeh (talk) 16:31, 2 August 2014 (UTC)
  • There is at least considerable question whether this guideline says that "cmd.exe" should be written "CMD.EXE" in article prose or titles where Windows NT is concerned. Even if it does, guidelines are not absolutely binding. Heck, not even policies are absolutely binding. When did the standard on WP become, instead of "verifiability, not truth", "guidelines, not verifiability or truth"? Calling it "CMD.EXE" on the NT family is verifiably wrong. As for "then fix the guideline," the best service to readers is to not wait for that, but to fix the article first. Jeh (talk) 17:10, 2 August 2014 (UTC)
  • One, verifiable facts trump both consensus and guidelines. The WP policy on verifiability is policy, and policies do trump guidelines. You seem to not understand that this is about more than a choice of typography. This article claims that the program is named CMD.EXE. But it is not, not in the Windows NT family. (Do I have to include screen snapshots here?) Thus the article is verifiably, factually wrong. There is no guideline anywhere in MOS that can be legitimately construed as requiring WP to include a verifiably, factually wrong claim. Two, I don't think the guideline applies anyway. The guideline says what it says. It says "The following additional guidelines are for command-line examples". It does not say "for examples, prose, or titles." So consensus for the guideline is irrelevant anyway. There is no consensus you can point to that says the guideline requires uppercase here for prose or the article title. Jeh (talk) 17:44, 2 August 2014 (UTC)
  • Your point about Windows NT is largely valid, although it does in fact refer to the file as "CMD.EXE" for compatibility purposes, at least as far as I am aware. However, I now reiterate that this is not a Windows-only application. How do the other operating systems mentioned as including this program refer to it? Dogmaticeclectic (talk) 00:52, 3 August 2014 (UTC)
  • No, NT never "refers to the file as "CMD.EXE"." Rather NTFS, as used by the normal Windows API, is case-preserving but case-insensitive. The actual file name is cmd.exe, period. But you can refer to it as cMD.ExE if you want to. Or just CmD if you're in a context that's expecting an executable name.
  • If you're going to invoke other operating systems, then a number of corrections should be made. For one thing there is the infobox that says "component of Microsoft Windows". I don't think anything in OS/2, eComStation, or Win CE can be correctly called that. For another there is the verbiage "Microsoft-supplied command-line interpreter", but Microsoft never supplied cmd.exe to any shipping version of OS/2. Before the IBM and MS joint effort, OS/2 was an IBM product, so no Microsoft code there; and before the OS/2 NT project resulted in a shipping product, IBM took their OS/2 ball and went home. When later versions of OS/2 shipped, their components came from IBM. Of course MS does not supply any component of eComStation either. So the only hope to support the "Microsoft-supplied" phraseology is CE. this article says: "Windows® CE includes a command processor shell (Cmd.exe) that is similar to Command.com in Windows 95 and Cmd.exe in Microsoft Windows NT®." That blog author seems fond of capitalizing image names, as if they were proper names... I can find out from a friend what CE really names the file, if it matters.
  • But I don't think it matters. In the most widely used desktop/laptop operating system, the file is named cmd.exe. That's what this article should use in the general case. Other OSs with other file name conventions can be named as exceptions, after verification. Or else split off to their own articles (or maybe sections of the articles on those OSs). To do otherwise is to let the tail wag the dog. Jeh (talk) 02:01, 3 August 2014 (UTC)
Your claim that "Microsoft never supplied cmd.exe to any shipping version of OS/2. Before the IBM and MS joint effort, OS/2 was an IBM product, so no Microsoft code there..." is incorrect. There was LOTS of Microsoft code in OS/2, including HPFS (High Performance File System) and the DOS box, both contributed by Gordon Letwin, who was Microsoft's Chief Architect for OS/2. For more, see Letwin's book, Inside OS/2. And, yes, absolutely, there was definitely a cmd.exe in OS/2. If you wanted an SDK so you could develop an application, you had to buy it from Microsoft. I think I paid $2000 for mine in September 1987. The logo in those days was a blue square with Microsoft across the top and "OS|2" (note the vertical bar, not a slash) across the bottom. I don't recall IBM shipping their own OS/2 SDKs until the split with Microsoft in 1990 just after the release of OS/2 1.3. IBM was on their own to support OS/2 2.0. Msnicki (talk) 02:34, 3 August 2014 (UTC)
ok. We could fairly say that the cmd.exe in early versions of OS/2 was MS-supplied. Did OS/2 installed on HPFS name it in all upper case? I don't know, but even if it did, this is still at the "microscopic fringe" level today. Tail, dog. Jeh (talk) 02:46, 3 August 2014 (UTC)
Sorry, I just can't remember after so many years and I couldn't find anything online to answer the question. (I had already looked even before seeing your post above that I replied to.) I think they named everything in 8.3 FAT format because not everyone used HPFS and, in those days, FAT names were all upper case. But of course, most people typed in lower case and many (most?) third party directory list programs automatically translated everything to lower case for better readability on the display. But I agree, this is just so irrelevant to what we should do with the Windows cmd.exe. Apologies for this digression down the rat hole. Msnicki (talk) 03:14, 3 August 2014 (UTC)
Not at all - more information is always good. Jeh (talk) 04:18, 3 August 2014 (UTC)
Found it. It was CMD.EXE in early versions of OS/2, seen here. More on early OS/2 here. Turns out I misremembered the cost of the SDK and the date. It was $3000 and they shipped them in May 1987. I attended their seminar in downtown Manhattan in July. Msnicki (talk) 05:04, 3 August 2014 (UTC)
That doesn't look like an actual file name display. What does OS/2's equivalent of File Manager or File Explorer show? Jeh (talk) 18:31, 8 August 2014 (UTC)
You're looking at it. That is what OS/2 looked like in those very first developer releases. It was just that character-mode "Program Selector" as the whole UI. This was long before any graphical UI. You could add things to the "Start a Program" list by editing config files IIRC. If you started cmd.exe, it ran full-screen, 25 lines x 80 characters. If you wanted to read directory entries from your application, you used the DosFindFirst system call and what you got back would have been in upper case. Msnicki (talk) 18:50, 8 August 2014 (UTC)
Windows is case-insensitive but case-preserving. If you open up C:\Windows\System32 with the explorer, you'll see that cmd.exe is stored in the filesystem in lower case. Msnicki (talk) 02:24, 5 August 2014 (UTC)
Can we conclude this? There is very little support here for all upper case. Jeh (talk) 05:47, 10 August 2014 (UTC)
Hear, hear. Fleet Command (talk) 06:40, 10 August 2014 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Command prompt turned into a redirect now?

The consensus of the move discussion above (Talk:CMD.EXE#Requested_move_14_July_2014) was to rename the article on the Windows default command-line interpreter to CMD.EXE and point "Command Prompt" to the existing disambiguation page "Command prompt", where the different meanings of the term "command prompt" were disambiguated.

There was an edit-war to point "Command Prompt" to CMD.EXE instead of "Command prompt", which appears to have stopped now that Codename Lisa declared ([7]) to leave it alone and disengage from further warring.

However, only moments later she turned "Command prompt" (the link target of "Command Prompt") from its current concept-dab status into a redirect to "Command-line interface#Command prompt" ([8]), thereby once again editing against the previous consensus. Of course, this turns "Command Prompt" into a double-redirect which will have to be fixed up to point to "Command-line interface" as well, thereby undermining the whole follow-up discussion above again. In the face of the previous broad consensus, the various ongoing and already heated discussions and the fact that this aggressive editing style has already caused more than hundred completely unnecessary back-and-forth edits in a whole bunch of related articles and wasted a tremendous amount of other editors' time, I can see such an unsensitive hyper-bold approach to editing only as carelessness or as a provocation and deliberate attempt to fuel a fire, and I simply do not want to become involved in any such activity, although I disagree with the edit and would normally revert it to reestablish the consensus.

Lisa made a good point in regard to redundancy with some of the contents at Command-line interface#Command prompt, though.

Still "Command prompt" and "Command Prompt" redirecting there does not appear to be a particularly good idea to me, as the term "command prompt" has even more meanings than those currently (and potentially) discussed in that article about command-line interpreters.

Therefore I would like to suggest that we restore the contents of "Command prompt", but go back a few days to the stage when it was still a normal disambiguation page only ([9]). This, however, would unfortunately trash Bd2412's efforts.

What do you think?

--Matthiaspaul (talk) 12:55, 4 August 2014 (UTC)

There are currently many links to Command Prompt, all created before the move (Command Prompt to CMD.EXE (which was then moved to cmd.exe (and back (or maybe not)))). This links were intended to point to cmd.exe. On most page moves, the old name is left as a redirect to the new; that didn't happen here. (We decided that Windows' doesn't get to claim this generic name for their specific use, especially since they don't always use it when their documentation gets to details.) That means all these existing links are broken.
We must fix the links ASAP. As I see it, we have two choices.
A) Make Command Prompt redirect to CMD.EXE.
B) Find and replace all links to Command Prompt to be CMD.EXE.
I suggest we do both right now. "A" is a simple, single immediate change. We also do "B", fixing those links per the decision of the move; that takes only a bit longer. When both "A" and "B" are done, then we redirect Command Prompt (upper-"P") to "Command prompt" (lower-"P"), in keeping with the move decision.
Then, after the name of this page settles down, we can discuss some "improved" fix as needed. --A D Monroe III (talk) 15:49, 4 August 2014 (UTC)
Hi. I agree. But I'd like to hear the opinions of Dogmaticeclectic, FleetCommand, EdJohnston, Jenks24 and Michael Bednarek too. I and the first two were in favor of Option A. The next two initially opposed or questioned Option A but ceased to oppose. The latter registered an opposition. Basically, he and Matthiaspaul are the only people who insist on "Command Prompt" being a redirect to "Command prompt" at this time.
Best regards,
Codename Lisa (talk) 16:56, 4 August 2014 (UTC)
I agree actually... Curious thing, how my agreement is being completely ignored to this point. I like to be acknowledged you know; not perhaps in the usual way. Fleet Command (talk) 06:53, 5 August 2014 (UTC)
Hi. I have a hard time imagining what you mean by "not perhaps in the usual way". Is it because you crave an acknowledgement beyond the common ones; one that is worth of the special and the distinguished? Or is it because you are usually acknowledged in some substandard or degrading fashion?
Best regards,
Codename Lisa (talk) 11:21, 5 August 2014 (UTC)
  • For the records, I just counted the incoming links to Command Prompt, which would need to be checked and possibly changed to a better link target (and would already have been fixed up without the discussions above): 37 (astonishing, this is more than two days ago, apparently someone has restored some of the already fixed up links #-| ). All other links are from talk pages etc. which do not normally get fixed up on article moves.
IMHO, 37 is a trivially low number (in the past, I have manually fixed up articles with hundreds of incoming links already), much less work than already spent in this discussion. --Matthiaspaul (talk) 18:45, 4 August 2014 (UTC)
  • Nevertheless, this particular discussion isn't about A) or B) at all, it isn't about Command Prompt or CMD.EXE, it is about:
C) Command prompt remains a concept-DAB page (and with perhaps some of the redundancy removed, and other stuff added) as per BD2412 ([10])
D) Command prompt remains a list-style DAB page as per consensus and before ([11]), with perhaps more meanings added (at least I know of a number more meanings of the term)
E) Command prompt becomes a redirect to Command-line interface#Command prompt as per CL's bold edit. ([12] --Matthiaspaul (talk) 18:45, 4 August 2014 (UTC)
  • There is no figuring out. Options C and D are all out of question. Command prompt cannot remain a stand-alone page per WP:CFORK. It cannot be a list-style dab either because per MOS:DAB and WP:DAB all its entries must consist of items whose titles or alternative titles are "command prompt" (with different capitalization). Basically, BD2412's decision, Codename Lisa's merge decision and your declaration are natural outcomes in Wikipedia. Fleet Command (talk) 06:09, 6 August 2014 (UTC)

I repeat: the existing links in current pages to Command Prompt are broken. They originally linked to this page. At this moment, they link to a paragraph about generic text command-line interface. That means, for example, someone reading the current COMMAND.COM sees "COMMAND.COM's successor is Command Prompt"; they click on the link, and it goes to the wrong page. It used to be a good link, and we broke it, in COMMAND.COM, CP/M, FreeDOS, CHKDSK, and many other pages. We need clean up the mess we've made by moving Command Prompt to CMD.EXE yet not making Command Prompt redirect to CMD.EXE.

So, yes, we need to resolve the what Command Prompt should point to, but before we work to figure this out, we need to fix the current links ASAP. I'd do it myself, but this talk section is claiming this all needs to be discussed, and it's considered rude to make changes that are under discussion.

Again, I propose we work on short-term and long-term solutions. This discussion is fine to continue to debate what the long-term solution is, but right now, we must do something. I've suggested A and B (above). After that is done, we can discuss at length the merits of C, D, or E, and replace A/B with a "better" long term decision. Agreed? --A D Monroe III (talk) 17:28, 8 August 2014 (UTC)

Agreed here. Codename Lisa (talk) 17:47, 8 August 2014 (UTC)
@A D Monroe III: It might have been rude if the discussion was active and progress, but it really isn't. Some discussion are just abandoned. As such, I implemented your suggestion ... at least temporarily if not permanently. Fleet Command (talk) 06:53, 9 August 2014 (UTC)

Windows Command Processor in Windows 8.1

After executing "cmd", I have realized that Windows 8.1 Task Manager lists it as "Windows Command Processor".

Would you add this name in the article, too, please?

I had to take longer to find this article because this name is not listed here.

Thanks in advance! — Preceding unsigned comment added by George Rodney Maruri Game (talk • contribs) 22:44, 14 May 2015 (UTC)

In Task Manager, running Windows 8.1, the name listed for the process is what appears in the description property of the process. The executable is still called cmd.exe. I agree with you, this information should be added to the article. Stefán Örvar Sigmundsson (talk) 23:58, 14 May 2015 (UTC)
The term "Windows Command Processor" is also used in Windows 7 as "File description". I'm not sure what will be gained by adding this imprecise "description" to this article. -- Michael Bednarek (talk) 02:34, 16 May 2015 (UTC)
Adding a note about it may clear up some confusion people may have about it. Stefán Örvar Sigmundsson (talk) 02:51, 16 May 2015 (UTC)

 Done D A Patriarche, BSc 00:13, 23 March 2017 (UTC)

CMD.EXE <> Command Prompt.

There are a number of different programs that respond to commands at the command-prompt. CMD is one of these.

The windows cmd.exe is a port of the OS/2 one, includes a number of disabled and semi-disabled commands that work in the OS/2 one. (eg KEYS, DPATH) Windows cmd.exe still supports both, even in Win8.

Other command processors exist. JPSoftware's popular 4os2/4nt/tcc all replace cmd.exe, and https://jdebp.eu/Softwares/cmd.html is a 32-bit replacement of the OS/2 command processor. CMD.EXE is a 32-bit replacement for COMMAND, the command name comes from the IBM desire to create the exe-file in the same name as the extention it is intended to run: so BMP.EXE would load bitmaps, etc. CMD has a lot of bug compatibility with COMMAND.

On the other hand, the command prompt, is simply a prompt that answers commands. Even gui programs, like JPSoftware 'take command' (before v 9), and 'praxim', provide command-prompts, where you type a command, and the program reacts. This is different to a 'command processor', which can run batch files, but does not display a prompt. I've written many a command processor, but no command prompts. Wendy.krieger (talk) 09:04, 6 January 2017 (UTC)

@Wendy.krieger: Hi. You have clearly confused "command prompt" with "Command Prompt" despite the fact that a hatnote tells you not to! CMD.EXE's official title is "Command Prompt". If you don't like it, take it up to Microsoft.
Fun fact: In the Tales from the Dragon Mountain 2: The Lair video game, there is a village whose title is "The Village".
Best regards,
Codename Lisa (talk) 09:18, 6 January 2017 (UTC)
In NT 3 and NT 4, it was called the 'MS-DOS Prompt', and it had the MSDOS 5 iccon. 4NT was called '4DOS for Windows NT'. Wendy.krieger (talk) 22:49, 6 January 2017 (UTC)
"Was" dear! Past tense. In Windows 2000, XP, Vista, 7, 8, 8.1, 10, Server 2003, Server 2008, Server 2008 R2, Server 2012, Server 2012 R2, Server 2016, MultiPoint Server, and PE, it is called "Command Prompt".
Best regards,
Codename Lisa (talk) 07:35, 7 January 2017 (UTC)
"In NT 3 and NT 4, it was called the 'MS-DOS Prompt'"
Don't believe Wendy just yet. See these: NT 4.0, NT 4.0, NT 3.5, NT 3.1
FleetCommand (Speak your mind!) 08:15, 7 January 2017 (UTC)
At least they have DOS icons. But it has certainly taken Microsoft a while to realize the icons are not appropriate. —Codename Lisa (talk) 09:22, 7 January 2017 (UTC)

Windows Versions

The opening section, para 1, is out-of-date and needs to be brought up to Windows 10, in which I understand "PowerShell" finally officially replaced cmd.exe. I made the change but my change was challenged & reverted by a Senior Editor, so perhaps there needs to be some further comment on the issue. D A Patriarche, BSc 01:18, 23 March 2017 (UTC) — Preceding unsigned comment added by D A Patriarche (talk • contribs)

The senior editor also objected to my use of the The Register as a ref source. The Register has been used extensively as a reference throughout Wikipedia (100+cites) and hardly seems to deserve the epithet "evil". I respectfully recommend reference to the policy pages Help:Reverting & Wikipedia:Revert only when necessary. I propose to reinstate my change but will wait 24 hr. for responses. D A Patriarche, BSc 01:37, 23 March 2017 (UTC)

Hello, D A Patriarche
Thanks for bringing the matter here. Also, thanks for calling me a senior editor, but I do hope my seniority isn't a factor all by itself. I prefer the merit of my actions to defend the act, not my identity as the performer.
Here is a link to a diff of the disputed edit: Revisions 771693296→771700177 I will address issues from the bottom. You wrote:

In Windows 10, Windows PowerShell officially replaced cmd, although cmd.exe is still accessible.

Problems:
  1. Meaning: You are effectively saying CMD is no longer included with Windows 10 but can be download for it! I doubt you even meant to say that! But when people say "X replaced Y", they mean X is no longer available; instead Y is available instead. For example, in macOS, Safari replaced Internet Explorer for Mac. What you perhaps meant to say is: "Starting with Windows 10 Creator Update (Redstone 2), shortcuts to Command Prompt in the Quick Links menu and File Explorer's hidden context menu are replaced by shortcuts to PowerShell, although the former can be restored."
  2. Unreliable source: The Register is a tabloid and fails to comply with Wikipedia's reliable source guideline. It is even named in Wikipedia:Potentially unreliable sources. Articles that use this source usually fail to become Featured Articles. One of the reasons for its unreliability is sensationalism. In this instance, simply two shortcuts in two rather obscure places in Windows are changed and this source writes: "Microsoft's cmd.exe deposed by PowerShell in Windows 10 preview"! While this is hardly compliant with WP:NPOV, the sensationalism makes it inaccurate.
  3. Novel info: The lead section must summarize the article and must not have novel info of its own. This is novel info and should be moved to the body.
  4. Minor problems: "cmd" and "Windows PowerShell" mustn't be writen in boldface. Also, the subject of the article is once called "cmd" and once again "cmd.exe".
Now as for the other part of the contribution:

Command Prompt, also known as Windows Command Processor, cmd.exe or cmd (after its executable file name), is the command-line interpreter on Windows NT, Windows CE, Windows Vista, Windows 7, Windows 8, OS/2 and eComStation operating systems.

  1. "Windows Vista, Windows 7, Windows 8" are redundant; "Windows NT" is already in the list and covers those.
  2. "also known as Windows Command Processor" needs a source. The emphasis here is more on "also known as", not on "Windows Command Processor" because you are claiming that it is a well-known name; as well-known as "cmd". In fact, if it is an obscure name, please mention it in the body and keep it off the lead.
Best regards,
Codename Lisa (talk) 14:19, 23 March 2017 (UTC)
Thank you very much, Lisa, especially for taking the trouble to go into so much detail. I have also posted on your User Talk page. For this page, suffice it to say that your points are well taken, and I will not change the article (if at all) until I have considered them more fully. I believe we can consider this issue closed for now unless other editors wish to comment.
Best regards, Tony - D A Patriarche, BSc 21:50, 23 March 2017 (UTC) — Preceding unsigned comment added by D A Patriarche (talk • contribs)

Requested move 10 April 2020

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: No consensus to move buidhe 05:51, 26 April 2020 (UTC)


Cmd.exe -> Command Prompt - Per WP:COMMONNAME. cmd.exe is searched for a lot less than Command Prompt. Aasim 01:45, 10 April 2020 (UTC) —Relisting. buidhe 05:36, 18 April 2020 (UTC)

  • Support. When a typical reader searches for this article, they will be searching for "command prompt" not "cmd.exe". Rreagan007 (talk) 03:35, 10 April 2020 (UTC)
  • Support I would tend to agree jamacfarlane (talk) 08:28, 10 April 2020 (UTC)
  • Oppose -- Then we would confusingly have two articles named "Command Prompt" and "Command prompt" whose titles only differ in the capitalization of the second word... AnonMoos (talk) 10:43, 10 April 2020 (UTC)
  • Strong Oppose We already had this discussion before (e.g. in 2014; see above) and nothing in support for this name has really changed since then, so it is a long standing consensus. Counting google searches for Command Prompt will of course bring up more results since it is also a very generic term that may refer to cmd.exe but also other command prompts such as COMMAND.COM or PowerShell when searching. If you use quotes to specifically search for the "Windows Command Prompt" the results are much different (see). Therefore, I don't think it is a very strong argument. Also, consider that this move will require a rewrite of this article and also changes to many other articles linking here. For example, the closely related and in many ways almost identical cmd.exe of OS/2 is also covered here, but the window title and icon name is not "Command Prompt" as in Windows, but actually "OS/2 Window". In OS/2, "Command Prompt" is a generic term that refers to both, cmd.exe and COMMAND.COM (OS/2 includes both shells). So renaming this article would probably also cause even more confusion. Ghettoblaster (talk) 10:48, 10 April 2020 (UTC)
  • Oppose. There are lots of command prompts, including all the various Unix/Linux shells. There is only one cmd.exe. Msnicki (talk) 12:10, 10 April 2020 (UTC) Added: The other thing that bothers me about this proposal is that it's not even technically correct. Yes, people do commonly refer to command processors as command prompts (I do it, too), but the correct term is command processor, command-line interpreter, or shell. The command prompt is merely the string the command processor prints, prompting the user for a command, which the user can set to anything they like in cmd.exe and most other command processors. Finally, for anyone not yet convinced there are lots of command prompts, we have a list. Msnicki (talk) 13:56, 11 April 2020 (UTC)
  • Oppose The terms are both used pretty much interchangeably. I can't see what benefit there is to moving the article. With the added confusion of the article needing to be re-written as Ghettoblaster mentioned above if it is moved. And the added confusion of there then being an article and a redirect with identical names except for the case of one letter. AlistairMcMillan (talk) 15:36, 10 April 2020 (UTC)
  • Oppose per Msnicki's reasoning. Cabayi (talk) 09:01, 11 April 2020 (UTC)
  • Support move to Windows Command Prompt or Command Prompt (Windows) and redirect Command Prompt to command-line interpreter with hatnote. Oppose move to Command Prompt. Sceptre (talk) 22:37, 16 April 2020 (UTC)
  • Oppose – This has been discussed before, and I don't see why it should be moved now. "Command [P|p]rompt" is a concept not limited, by far, to cmd.exe. -- Michael Bednarek (talk) 09:54, 18 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

cmd.exe on Windows NT

Msnicki says Windows NT should be called Windows instead because Windows NT is the only active product on the Windows production line, this is true; but consider Windows CE series is also a part of Windows production line, and it is now disconnected, should we remove it as well?

Since a later section specifically mentioned the differences between COMMAND.COM (in DOS and Windows 9x) and cmd.exe, shouldn't it be made clear that cmd.exe does not available in Windows 9x?

-- PC GO (talk) 06:43, 21 April 2020 (UTC)

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:

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 08:05, 11 December 2020 (UTC)

Is Windows CE CMD implementation native or not

The illustration to the "cmd.exe" in question, which I am convinced is third party. Notice the "Pocket CMD v 3.0" printout

I invite Low Power and Ghettoblaster to participate in the discussion.

I am highly convinced that the Pocket CMD implementation for Windows CE is not native. In fact, I can reproduce the steps to show that Pocket CMD is third party, if necessary

PocketCMD developer's page Reads, 

    PocketCMD is an open source command prompt based on the ReactOS command line interpreter "CMD version 0.1.1". It is currently in an alpha development state.

The official download link is dead, but Here are the console installation instructions on XDA, and here is the surviving download link on the third party website

Notice that the third party website contains exactly the same looking console. Same font, same background, same everything. Except maybe it's Windows Mobile, not Windows CE

I would like to get this issue resolved, so we can be sure Wikipedia tells the accurate information

Tabdiukov (talk) 07:56, 23 June 2021 (UTC)


As the information I already provided in Clarify Windows CE cmd.exe and console.dll, the offical cmd.exe code can be found from Windows CE Platform Builder; it is not source code, but relocatable object code for many architectures. The user is expected to link it into executable before it can be run.

For example the Windows CE 5.0 ARMv4i debug object code archive is PUBLIC/COMMON/OAK/LIB/ARMV4I/DEBUG/cmd.lib.

By using iconv(1), some internal UTF-16 strings of this program can be viewed:

$ iconv -f utf-16 -t utf-8 -c PUBLIC/COMMON/OAK/LIB/ARMV4I/DEBUG/cmd.lib | less


This archive contains 5 relocatable COFF objects: 

$ ar -t PUBLIC/COMMON/OAK/LIB/ARMV4I/DEBUG/cmd.lib
obj/ARMV4I/debug/cmdpipe.obj
obj/ARMV4I/debug/cmdexec.obj
obj/ARMV4I/debug/cmdutil.obj
obj/ARMV4I/debug/cmd.obj
obj/ARMV4I/debug/cmdrsc.res

Low power (talk) 13:25, 23 June 2021 (UTC)

Additional information for this specific cmd.exe version that titled Pocket CMD v 3.0

Previously I said that there are 2 sources to get cmd.exe for Windows CE from Microsoft; one is the Platform Builder that I already explained above, while the another one is Windows Mobile Developer Power Toys[1] (My original posting mistakenly referred it as Windows CE Power Toys).

This Power Toys package contains many small tools that help developing and testing applications on a Pocket PC / Windows Mobile variant of Windows CE. One tool being the PPC Command Shell— Command shell for the Pocket PC 2003 device, which provides a cmd.exe for Pocket PC, but also working on the standard Windows CE systems.

Different from the Platform Builder version, the cmd.exe provided by this Power Toys package has a startup title saying Pocket CMD v 3.0; I guess this indicates that the version is designed for Pocket PC, rather the standand Windows CE variant. However this version can work on standand Windows CE systems perfectly, one can simply copy this cmd.exe into \Windows\ of a Windows CE device that leaks cmd.exe from factory.

One of the links you provided points to an archived version of SymbolicTools website; the page PocketCMD, however, is not describing the original cmd.exe that made by Microsoft. As it shown, PocketCMD is a fork of ReactOS command interpreter, which in turn, is a fork of FreeDOS command interpreter; I can confirm this because I has personally used this command interpreter on a Pocket PC 2003 Second Edition system back on 2012, it is very different from Windows cmd.exe in many aspects, such as colorized directory listing. SymbolicTools also provides download of the original cmd.exe in another page, I think this one is a repackaged version of the Windows Mobile Developer Power Toys cmd.exe.

Although this topic should stay with cmd.exe, the command interpreter only, I would also like to point out that the console driver implementation shown in that screenshot, is part of the standard, semi-Source-available Windows CE system (thus excluding Pocket PC and Smartphone variants). This console driver has very few features, comparing to Windows NT console (before Windows 10) or PocketConsole from SymbolicTools; for example it doesn't support changing background and text color, neither staticly nor programmatically; the color set is always black text on white background. On another hand, PocketConsole is designed for Pocket PC, rather than standard Windows CE. A typical sign of Pocket PC GUI programs is the menu bar will be shown at bottom, even it is running on a standard Windows CE system; so if someone (like me) installing PocketConsole on such Windows CE system, the menu bar will go to bottom as well.

Low power (talk) 16:35, 23 June 2021 (UTC)

Since I made the screenshot you are referring to, I can confirm that it was in fact made on "Windows CE Version 3.0 (Build 126)" running in an emulator. If you select "Help\About Console..." in the main menu, a dialog box will pop-up with the following text "Windows CE Console Copyright (C) 1997-2000 Microsoft Corp.". The application is installed in the start menu as "Command Prompt" with the old MS-DOS icon that was used at the time. The executable is stored in "\Windows\". Ghettoblaster (talk) 18:40, 23 June 2021 (UTC)
Archive.org has an emulator image available: [13] Ghettoblaster (talk) 18:48, 23 June 2021 (UTC)
I'm pretty sure that this console driver is the original Windows CE part, made by Microsoft; since this page is about cmd.exe, we may need more evidences to prove that the command interpreter (the one titled Pocket CMD v 3.0) is an original part too. I can only confirm that this cmd.exe looks exactly same as the Windows Mobile Developer Power Toys cmd.exe, because I never actually built entire Windows CE OS from source, with Platform Builder, to see what's they looks like. I have only Windows CE 5.0 Platform Builder installed at this time, and I can't find strings like Pocket CMD from that source tree; but the cmd code does appears to contain all interesting strings that a cmd.exe should have. It is possible that the Pocket CMD title exists in Windows CE 3.0 source code, but removed in later versions; if would be great if anyone having an earlier Platform Builder version to provide more sources for this.
Low power (talk) 01:22, 24 June 2021 (UTC)
The Pocket CMD v 3.0 is also referenced in this manual of a Windows CE based industrial computer made by Rockwell Automation. I think it is unlikely to use a 3rd party component. Ghettoblaster (talk) 09:23, 25 June 2021 (UTC)

References

  1. ^ "Download details: Windows Mobile Developer Power Toys". Microsoft Download Center. Microsoft. 2009-02-02. Archived from the original on 2010-01-17. Retrieved 2021-06-23.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Cmd.exe/Archive_1&oldid=1180529311"