I was teaching command line interface to my sister and I taught her what are Internal & external commands (also referred to as Resident and transient commands). Her question to me was which of these commands in windows XP and which of the Windows Vista, Windows 7 Commands are internal & which are external?
Well, is there any way to know that?
The distinction between "resident" and "transient" commands comes from a non-virtualized memory management architecture that was in MS-DOS and CP/M. On demand-paged virtual memory operating systems such as Windows NT 6.1, it's meaningless. The system doesn't keep the things built in to the command processor resident, and programs invoked by the command processor are not necessarily transient. Memory simply isn't managed the same way at all.
You're also doing your sister a dis-service by referencing a list of "DOS commands". Your operating system isn't DOS, and never has been DOS in its entire history. What is true of the DOS family of operating systems isn't necessarily the case for your operating system and its command interpreter.
The terminology that you are groping for is "built-in commands", whose program code is built in to the command interpreter executable and runs in the command interpreter process itself, versus "external commands", whose program code is in separate executable program image and is run in a separate process.
JP Software's replacement command interpreter TCC has a built-in command — the ? command — that displays all of the currently enabled built-in commands. Obtaining the list of built-in commands is as simple as running:
?
My command interpreter has the same thing. So too has the cmd from ReactOS. (In all of our command interpreters, it's the same command — ? — in fact.) All other command interpreters on which this is possible will have that or a command with similar function. (Shells for POSIX systems have, variously, built-in commands named type, whence, or which, for examples.) Obtaining the list of built-in commands has to be done via a command built in to the command interpreter, because only something with access to the innards of the command interpreter code knows where to find the list of built-in commands that the command interpreter program contains and maintains.
It's possible for an external command to be written with its own list of built-in commands. I wrote one such myself, some two decades ago. It knew all about the commands variously built-in to command, cmd, 4dos, and 4os2, because I constructed my own table of who had what built-in command and put it into the program. But it had no way to tell whether any built-in commands had been disabled with setdos /i, and it was consistently at the mercy of the authors of those command interpreters adding new built-in commands to their programs or simply not documenting some commands. And it had no way to know what command interpreter (if any) it was invoked from, so it couldn't know when (for example) help was a built-in command (as it is for some of the command interpreters) and when it was an external command (as it is for others).
The only reliable method is a command built in to the command interpreter that you want to check. External commands by other people like various people's where, which, help, and so forth will all suffer from the same problems that my program did.
Unfortunately, Microsoft has never seen fit to provide such functionality in its cmd.
To the best of my knowledge, there's not a complete list of commands that are embedded into the command interpreter... (at least, not that I've found) But a quick & dirty way to tell would be to crack open a command prompt.. and wipe out the PATH variable. Any commands that still work are embedded in the shell (or the working directory if there are any)... the ones that no longer work... are programs located somewhere on the machine.
helpdisplays internal commands. Of course now that I type it and look, I can see that isn't true.