Ho discusso con il mio amico che il prompt dei comandi è solo una versione GUI di MS-DOS che funziona in ambiente Windows Form. Non è assolutamente d'accordo con me.

Chi ha ragione?

Questo era vero una volta, ma non lo è più.

Dall'interfaccia della riga di comando di Windows MS-DOS # : Wikipedia :

Tutte le versioni di Microsoft Windows hanno avuto un'interfaccia a riga di comando (CLI) simile a MS-DOS. Ciò potrebbe eseguire molte utilità della riga di comando DOS e vari Win32, OS / 2 1.x Posix nella stessa sessione della riga di comando, consentendo il piping tra i comandi. L'interfaccia utente e l'icona fino a Windows 2000 hanno seguito l'interfaccia nativa MS-DOS.

Le finestre consumer (fino a 3.11, Win9x, WinME) funzionavano come GUI (Graphical User Interface) in esecuzione su MS-DOS. Con Windows 95, 98 e ME è stata integrata la parte MS-DOS, trattando entrambi i sistemi operativi come un pacchetto completo. La riga di comando ha avuto accesso alla riga di comando DOS (di solito command.com), tramite un modulo di Windows (winoldap.mod).

Una nuova linea di Windows, (Windows NT), si avvia attraverso un kernel il cui unico scopo è caricare Windows. Non è possibile eseguire le applicazioni Win32 nel sistema di caricamento in modo che OS / 2, UNIX o Windows consumer possano avviare sessioni in modalità carattere.

Quindi no, in ogni Windows della famiglia NT (ad es. XP, Vista, 7, 8), il prompt dei comandi e MS-DOS sono visivamente simili, ma abbastanza diversi.

Sono cose diverse - Il prompt dei comandi non è MS-DOS - ma per quanto riguarda l'utente potrebbero essere le stesse cose che fanno le stesse cose.

Quindi dipende dal tuo punto di vista. Da un punto di vista tecnico il tuo amico ha ragione, ma dal punto di vista dell'utente sei corretto (un po 'perché ci sono differenze che un esperto potrebbe individuare).

No.

^{(A meno che la tua definizione di uguaglianza non si estenda oltre » È un'interfaccia di testo e non posso eseguire programmi da essa. « )}

Ciò che viene eseguito quando si fa clic su Prompt dei comandi nel menu Start è il processore dei comandi di Windows, aka cmd.exe. I suoi comandi e la sintassi degli script incorporati (incluse molte stranezze) si basano sull'antico command.comCP / M e successivamente su MS-DOS, ma a parte ciò sono cose completamente separate. Inoltre, command.comè un programma a 16 bit mentre cmd.exeè un'applicazione console nativa di Windows.

Le cose erano diverse in Windows 95, 98 e ME dove command.com sarebbero state eseguite in una VM MS-DOS con Windows che fungeva da hypervisor (sì, avevano già quel genere di cose al momento). Lì avevi un'intera macchina virtuale con DOS. Ma su Windows NT, 2000, XP, Vista e 7 - no. DOS vive solo là ntvdm.exedove c'è la macchina virtuale virtuale NT che è solo un sottile livello di emulazione che cattura le chiamate che la CPU non può eseguire direttamente (motivo per cui funziona più velocemente ma peggio di DOSBox).

In ogni caso, persino command.comera solo una shell per DOS. Non era il sistema operativo.

All'interno, in realtà rabbrividisco ogni volta che vedo persone che si riferiscono a una finestra con testo grigio-nero come MS-DOS. Nella stragrande maggioranza dei casi, in realtà non sanno a cosa si riferiscono.

Da quello che ho capito, MS-DOS è il sistema operativo del disco che Microsoft ha rilasciato. Il prompt dei comandi è un'interfaccia non grafica che ti consente di interagire con il tuo sistema operativo.

Prompt dei comandi è un'applicazione di interpretazione della riga di comando disponibile nella maggior parte dei sistemi operativi Windows, ufficialmente denominata Processore di comando di Windows ma a volte chiamata shell dei comandi. Il prompt dei comandi è un programma Windows che emula molte delle capacità della riga di comando disponibili in MS-DOS ma in realtà non è MS-DOS.

Il prompt dei comandi è una versione GUI di command.com in MS-DOS. cmd.exe è un'applicazione Windows nativa in genere in esecuzione in una console Win32. Ciò consente di sfruttare le funzionalità disponibili per i programmi nativi sulla piattaforma che non sarebbero altrimenti disponibili per i programmi DOS.

Ad esempio, poiché cmd.exe è un'applicazione nativa in modalità testo su OS / 2, può utilizzare pipe reali nelle pipeline di comando, consentendo l'esecuzione simultanea di entrambi i lati della pipeline. Di conseguenza, è possibile reindirizzare l'errore standard in cmd.exe, diversamente da COMMAND.COM. (COMMAND.COM utilizza file temporanei e esegue le due parti in serie, una dopo l'altra.)

In realtà, cmd.exe è un programma Windows che funge da interprete da riga di comando simile a DOS. È generalmente compatibile, ma fornisce estensioni che affrontano alcune delle limitazioni di COMMAND.COM (le spiegazioni sopra riportate sono riferite da Wikipedia).

Il tuo amico ha ragione. MS-DOS è / era un sistema operativo (il sistema operativo disco Microsoft è l'acronimo di.) L'interfaccia utente per DOS è chiamata prompt dei comandi ( the ).

Le prime versioni di Windows funzionavano su DOS (rendendole ambienti tecnicamente operativi, anche se non sono più sicuro che qualcuno faccia più questa distinzione), ma i sistemi operativi successivi, a partire dal kernel NT, non lo fecero - DOS non c'era più.

Tuttavia, la gente aveva ancora bisogno della funzionalità fornita dal prompt dei comandi e invece di command.com abbiamo command.exe (e in questi giorni cmd.exe), che quando eseguito ci fornisce un prompt dei comandi.

Ma questo non è l'unico (né vicino al primo) prompt dei comandi che le persone hanno usato. I prompt dei comandi sono anche chiamati conchiglie e Unix ne ha molti e i comandi sono diversi e spesso molto potenti. A proposito di potere, Microsoft ha creato un nuovo prompt dei comandi per Windows chiamato PowerShell che è incredibilmente potente e interessante. Vedi Wikipedia per ulteriori informazioni: http://en.wikipedia.org/wiki/Command-line_interface#Operating_System_Command-Line_Interfaces

Non sono gli stessi!

Apparentemente molte persone non si rendono conto che il prompt del DOS e il prompt dei comandi di Windows non sono la stessa cosa. In realtà sono due programmi diversi, rispettivamente COMMAND.COM e CMD.EXE.

Conosci i tuoi comandi

In primo luogo a causa delle differenze nella piattaforma (DOS vs Windows) e nell'interprete (command.com vs cmd.exe), ci saranno ovvie differenze come

• DOS viene eseguito a schermo intero senza una finestra, quindi nessun mode con:cols=COL lines=ROWcomando per ridimensionare la console e nessun titlecomando
• DOS non supporta multitasking, multiutente, registro, autorizzazioni, nomi di file lunghi, collegamenti simbolici / hardlink, rete, Unicode, dischi dinamici e supporto di volumi avanzati ... quindi nessuno strumento per gestirli

Ma ci sono anche grandi differenze nelle capacità e nella sintassi dei comandi interni tra command.com e cmd.exe, così come alcuni strumenti esterni nei due ambienti. In MS-DOS ci sono

• Nessuna funzione, blocchi di codice ()e ambiti locali che significano

  • for, if... deve essere seguito da un singolo comando sulla stessa riga
  • no exit /bogoto :eof
  • no setlocaleendlocal
  • gotopuò solo passare a un'etichetta, callpuò solo avviare un altro file batch

  • i comandi non possono essere raggruppati insieme come

    (
    command1
    command2
    ) >output.txt
    

• Nessun personaggio in fuga ^. Stampare caratteri speciali sarebbe una seccatura e nessuna possibilità di eseguire comandi multilinea

• Nessun formato speciale di if
  • no if cmdextversioneif defined
  • nessun confronto tra stringhe numeriche e senza distinzione tra maiuscole e minuscole if [/i] string1 compare-op string2
• Nessuna cronologia dei comandi e completamento dell'argomento comando
• Nessuna espansione indiretta (ad es. call set %%var%suffix%=string) Di variabili e nessuna espansione ritardata (ad es. echo !var%suffix%!)
• Nessuna manipolazione avanzata delle stringhe
  • nessun ~xxxVsupporto variabile
  • nessun %variable:~num1,num2%supporto per la sostituzione di sottostringa o stringa%variable:str=newstr%
• Nessun nome di variabile parziale corrispondente per set, e
  • no, set /aquindi non puoi fare l'aritmetica
  • no, il set /pche significa che leggere l'input dell'utente è una seccatura
  • nessuna set "var=value"sintassi
• No %*per l'intera riga di comando
• No for /d, for /ro for /l. No, for /fquindi anche leggere l'input dai file è difficile. L'unica forma di forin DOS èFOR %variable IN (set) DO command [command-parameters]
• No findstr, e findnon supporta Unicode
• Nessuna variabile d'ambiente speciale come%CD% %DATE% %TIME% %RANDOM% %ERRORLEVEL% %CMDEXTVERSION% %CMDCMDLINE% %HIGHESTNUMANODENUMBER%
• Abilità di cambio directory limitata
  • No pushd/popd
  • No cd /d. Inoltre no cd path with spacese a cd "path with spaces"causa della mancanza di supporto per nomi di file lunghi
• No color
• No forfiles
• No assoc(perché non ci sono GUI e i file devono essere aperti manualmente dalla riga di comando, quindi non è necessaria alcuna associazione di file)

Molti utili comandi esterni in Windows come dove, ordina, altro (in alcune versioni DOS), scelta ... mancano anche in DOS

E questo è ciò che ha detto Rich Turner di MS

Inoltre, Cmd! = MS-DOS!

Voglio anche sottolineare un malinteso comune perpetuato da articoli come quelli sopra: Cmd <> MS-DOS!

Infatti:

• L'ultima volta che Microsoft ha spedito una "nuova" versione di MS-DOS (v8.0 in Windows ME), il 16 settembre 2000 - 16 anni fa (al momento della stesura di questo documento) !!
• MS-DOS era un sistema operativo (anche se un sistema operativo relativamente semplice per gli standard odierni) la cui interfaccia utente principale era una shell della riga di comando, fino a quando Windows 3.xe 9.x arrivavano e funzionavano su / intorno a MS-DOS
• Il linguaggio di scripting della shell della riga di comando di MS-DOS era relativamente conciso e moderatamente potente, ma mancava di molte delle funzionalità più ricche e più avanzate di cui godiamo nei moderni PowerShell, Bash, ecc.
• Mentre le versioni successive di MS-DOS sono cresciute in raffinatezza e hanno aggiunto / sostituito alcuni vecchi assembly con un nuovo codice scritto in 'C', gran parte di MS-DOS è rimasta scritta in assembly x86 per motivi di efficienza, e poiché al momento era l'unico modo per ottenere l'accesso a molti dispositivi hardware e periferiche. Ciò ha reso la CPU da MS-DOS non portabile a quella non x86. Se sei così incline, puoi effettivamente scaricare il codice sorgente per MS-DOS v1.1 e v2.0 per vedere quante delle versioni precedenti di MS-DOS sono state scritte nell'assembly x86 (suggerimento: praticamente tutte esso)!

https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/

Ulteriori letture

• Limitazioni di MS-DOS 6.22
• Comandi e loro disponibilità Da MS-DOS 6.22 a Windows 8
• Comandi nuovi (e rimossi) in Windows 8
• In che modo i .batfile moderni differiscono dai vecchi .batfile MS DOS ?
• File batch di Windows: .bat vs .cmd?
• cmd.exe: confronto con il prompt di MS-DOS

In conclusione, dal punto di vista della funzionalità possono essere un po 'simili, ma altrimenti enormemente diversi