grumpy

At 23 you're getting old????? Heck, I'm older than 23 in HEX

In the early 90's I used an IBM compatible PC for the first time (before that I used a VAX 11/780, a Sun 3/60, and a couple of other machines) and there was no such thing as windows. windows 3.1 came later. As I recall, it was described as an "upgrade", but early versions were actually a step backward for those who had used DOS: I spent a lot of my time flicking back to the dos prompt (or, even, not starting windows) because windows was less productive. Fortunately, things have improved a lot since then.

A .cmd file was originally a batch file used by a third-party command line interpreter called DR-DOS, if memory serves (DR = Digital Research). That command line interpreter supported some extensions not supported (then) by MS-DOS. Although DR-DOS was able to work with .BAT files (understood by MS-DOS), .CMD files were introduced so people could write batch files using DR-DOS specific features. MS-DOS evolved a fair bit in response to DR-DOS (probably one of the earliest instances of Microsoft attempting to beat an opponent). The CMD command line interpreter under windows came later.

DBZ

I got a question. How does CMD program work. I mean I used those commands and stuff. So what does it suppose to do? I know it open files so what is the point they have this function?

grumpy

Historically, command line processors like CMD existed before GUI based environments like windows. Their purpose is to allow execution of other programs (eg compilers, text editors, etc) and basic maintenance tasks such as listing files, deleting them, etc. Command line options were the means that a user could use to control behaviour of the programs (eg options settings, making a text editor open a particular file).

Some reasons that command line processor continues to exist under environments like windows are;

1) Some tasks are easier for the user via a command processor than by using a GUI program. For example, it is easier to type "fc /b file1 file2" to do a binary comparison of two files than it is to open both files using a GUI and then search through an options page to do the comparison in binary rather than text mode. Objective measurements of users have shown that the time to do such tasks is more for the GUI program (and also, interestingly, that most GUI users report incorrectly that they completed the task faster with the GUI). The only exceptions are for very specific GUI designs for which there is no direct equivalent via a command line (eg some instances of drag and drop functionality, programs that require a user to interact with a graphical display)

2) It takes more effort to add new features to a GUI based program than it does to add them to a console program. Let's say we have defined some new feature for a program that processes one or more text files. If we are adding it to a console mode program, all we need to do is an (often minor) adjustment of code for parsing the command line and calling the necessary function with required arguments. Adding a similar option to a GUI program involves setting up one of more places in the GUI to access that function (eg redesign of the GUI to add a menu item, setting in a configuration page, etc) and the effort to do that can be significant depending on the design of the GUI. There are a lot of cases where a developer provides both a GUI-based and console mode (i.e. command line) variants of the same program (eg an IDE and a compiler). In most such cases, the console mode program has more features than the GUI program because it is easier to implement. The exceptions to that statement only happen because a larger effort is directed to development of the GUI variant or, in some cases, the working of the GUI program calls up the command line version (as is the case with IDEs such as devcpp).

3) It is easier to write a command file (eg a .BAT or .CMD file) to automate a few repetitive tasks than it is to configure a set of GUI programs to do the same things. GUI programs are better for one-offs, but command line programs are better for doing repetitive actions (to do the task again on a different file it is just necessary to run the program again with different options). Most command processors provide basic programming capabilities (eg looping, etc) so can be programmed to invoke a command line program repeatedly to work on (say) a set of files. There is some blurring of that boundary with GUI programs that include a macro capability (eg spreadsheets and word processors), but not every GUI program includes such capability.