Was waren die Gründe, warum Windows nie eine anständige Shell hatte? [geschlossen]

Ich habe ein Thema über SO gelesen: Warum sind Skriptsprachen (zB ...) nicht als Shell-Sprachen geeignet? . Besonders gut hat mir die Antwort von Jörg W Mittag gefallen , aus der ich Wissenswertes erfahren habe Windows PowerShell. Nach mehr als 20 Jahren verfügt Windows nun über eine gut gestaltete Shell (Windows 1.0 - 1985, stabile PowerShell-Version - 2009). Auf der anderen Seite hat Unix-Systeme seit 1978 eine Reihe von verschiedenen Shells Bourne Shell. Ich habe einige Artikel über Vorstellungsgespräche mit MS gelesen und habe den Eindruck eines sehr "geekischen" Unternehmens. Ich frage mich, warum sie im Vergleich zu Unix-Leuten, die all ihre Arbeit mit diesen Tools machen, keine Befehlszeilen-Tools benötigten.

Der gleiche Grund, den iPod, das iPhone (egal welches Telefon) und das iPad nicht haben: Die Befehlszeile ist nicht der primäre Kanal für die Benutzerinteraktion mit dem Computer in Windows. Es ist in UNIX oder GNU / Linux - deshalb sind sie ausgereifter. Dasselbe Argument, warum die Linux-GUI-Desktops im Vergleich zu Windows so lange Quatsch waren (Mac OS-Cheats, da sie die Unix-Befehlszeile ein bisschen kostenlos erhielten).

Vielleicht bin ich zu stark vereinfacht, aber ich halte es für eine kulturelle Sache:

1. In der Microsoft-Kultur konzentrieren sich Entwickler darauf, Programme für ihre Benutzer zu schreiben . Die Programme sind alle GUI-basiert.
2. In der Unix-Kultur konzentrieren sich Entwickler darauf, Programme für andere Entwickler zu schreiben . Die Programme sind klein und darauf ausgerichtet, eine bestimmte Sache gut zu machen.

Beachten Sie, dass Microsoft nicht der einzige sein kann, der eine Shell für Windows schreibt. Die Leute, die Bash schreiben, unterscheiden sich von den Leuten, die * nix-Kernel schreiben. Sie benötigen nicht einmal Root-Rechte. Ich habe meine eigenen Shells kompiliert, um sie zu verwenden, wenn mir die vom Sysadmin installierte nicht gefallen hat. Wenn es eine echte Nachfrage nach einer besseren Windows-Shell gäbe, hätte jemand eine geschrieben.

Weil es nie genug Anrufe für einen gegeben hat, denke ich.

Windows Scripting Host ist seit Windows 98 standardmäßig installiert (ich nehme an, dass es vorher schon so war); VBScript war sehr fähig; Oder Sie könnten einfach ein Befehlszeilentool schreiben, das Zugriff auf die gesamte Windows-API hatte.

Powershell ist einfach nur ein weiterer Schritt in die gleiche Richtung. COM ist nicht mehr populär, deshalb ist WSH ein ziemlicher Lernprozess geworden. Aber .NET ist die aktuelle Big Thing in der Windows-Welt und Powershell aus einem .NET-Hintergrund zu lernen ist relativ einfach.

Ein Ort, an dem Powershell meines Erachtens einen Fehler gemacht hat, ist der Versuch, auch die * nix-Menge anzusprechen.

Abgesehen von den Befehlszeilenschaltern ist das Piping in Powershell sehr unterschiedlich und das erste, was Sie lernen sollten, wenn Sie es in die Hand nehmen.

Und ehrlich gesagt ist es viel mehr wie eine Skriptsprache, a la Perl, als eine Shell, a la Bash. Es gibt einige ernsthafte Fallstricke, wenn Sie versuchen, es als Ihre primäre Shell zu verwenden.

Versuchen Sie beispielsweise, einen einfachen SVN-Speicherauszug von Powershell zu erstellen. Binärdaten in stdout werden nicht sehr gut verarbeitet. Andererseits ist die Bearbeitung eines SVN-Protokolls dank seines integrierten XML-Typs ein absoluter Traum.

Weil die Entwicklung eines zweiten parallelen Windows-Toolset wenig und sehr schmerzhaft ist.

Shells werden durch die Anzahl und Leistungsfähigkeit von Hilfsprogrammen auf einem GNU-System wie sed, find, xargs et al. Die Neuimplementierung dieser Tools ist sehr aufwändig, und es hat sich als viel einfacher erwiesen, eine POSIX-Kompatibilitätsschicht auf Windows aufzubauen. Cygwin ist eine solche POSIX-Kompatibilitätsebene und erfüllt die meisten Anforderungen von Shell-Benutzern, wenn sie gezwungen sind, Windows zu verwenden.

Ich persönlich würde vermuten, dass die Entwickler-Community, die nicht bereit ist, auf POSIX und Linux umzusteigen und sich dennoch ausreichend der Shell-Programmierung widmet, so klein ist, dass die Entwicklung einer stabilen Shell 20 Jahre gedauert hat.

Dies ist eine dieser Fragen, die, wenn man Verschwörungstheorien ignoriert, wahrscheinlich keine einzige Antwort hat und über die Historiker für immer streiten könnten, ohne jemals eine endgültige Antwort zu finden.

Mein Eindruck ist, dass die Kraft der Muschel nicht sofort offensichtlich ist. Ich habe mit der Programmierung in Windows 3.1 begonnen und die Shell wurde nur sehr wenig genutzt. Alles wurde über die Visual C ++ - IDE erledigt, und ich habe mir nie Makefiles und DOS-Batchdateien so genau angesehen, dass ich selten versucht habe, mit einer Batchdatei etwas Komplizierteres als eine einfache Sicherung zu automatisieren. Keines der auf Windows fokussierten Programmierbücher (ich habe gute Erinnerungen an Petzold ), die ich zu der Zeit gelesen habe und die mit der Windows-Shell für irgendetwas besprochen wurden. Erst als ich anfing, Linux zu benutzen und zu programmieren, begriff ich, wie nützlich eine mächtige Shell sein kann. Ich erinnere mich, als Windows herauskam, war es so aufregend, weil man kein altes verwenden musstecommand.comnicht mehr. Endlich hatten wir eine hübsche Oberfläche mit mehr als einer Schriftart und mehreren Programmen, die gleichzeitig liefen, ohne dass ein TSR erforderlich war ...

Ich denke, dass die meisten Programmierer, die in Windows starten, keine Erfahrung mit einer leistungsstarken Shell haben und daher kein dringendes Bedürfnis haben, eine für Windows zu implementieren. Programmierer, die unter Linux arbeiten und die Shell zu schätzen wissen, bevorzugen die Arbeit unter Linux und sind daher nicht geneigt, die Zeit in einer Umgebung zu verbringen, in der sie sich nicht so wohl fühlen, eine für Windows zu implementieren in einer anderen Frage) die Notwendigkeit, auch alle CLI-Tools zu implementieren, die zusammen mit der Shell selbst benötigt werden.

Die zunehmende Beliebtheit von Linux ist wahrscheinlich der Hauptgrund, warum Microsoft endlich eine richtige Shell einführte. Als immer mehr Menschen erkannten, was für eine Shell nützlich ist, wurde immer klarer, dass Windows ein wichtiges Tool fehlte.

Wenn Sie die Unix-Shells für "anständig" halten, gibt es für Windows mindestens eine Shell, die seit Jahrzehnten "anständig" ist. Die Hamilton C-Shell ist der Unix C-Shell einigermaßen ähnlich (obwohl zu beachten ist, dass die C-Shell unter Unix noch nie eine besonders große Marktdurchdringung hatte). Nicht wenige Leute haben auch schon seit geraumer Zeit die verschiedenen Shells von JPSoft (4DOS, 4NT, jetzt Take Command) verwendet - wie Sie wahrscheinlich anhand des Namens erraten können, geht 4DOS auf die MS-DOS-Zeit zurück.

Wenn Sie auf einer Shell bestehen, die vor etwa 15 Jahren von Microsoft vertrieben wurde, enthielt das Windows NT Resource Kit einen NT-Port der PD Korn-Shell ¹ sowie eine Reihe von Unix-Dienstprogrammen. Es war wahrscheinlich nicht genug enthalten, um viele Shell-Skripte ohne Modifikation auszuführen, aber es war genug, um einiges an Gebrauch zu bewältigen, insbesondere ziemlich viel interaktive Arbeit.

¹ Um ehrlich zu sein, ich weiß nicht, dass es sich um eine Portierung genau dieser Shell oder um etwas ganz Ähnliches handelte - ich habe sie ausreichend verwendet, um zu überprüfen, ob sie so ärgerlich war, wie ich es in Erinnerung hatte, und habe sie dabei belassen .

Windows verfügt über Entwurfsfunktionen, die sich nicht für Skripts eignen. Dies ist ein Ergebnis davon, dass die grafische Benutzeroberfläche zum primären Betriebsmodus gemacht wurde. Viele Tools verfügen nicht über funktionierende Befehlszeilenschnittstellen. Ohne eine anständige Befehlszeilenschnittstelle ist es sehr schwierig, eine gute Shell zu generieren.

Oft müssen für Skripte in Windows Mausklicks und Tastenanschläge an verschiedenen Stellen in einem Anwendungsfenster simuliert werden. Die resultierenden Skripte können sehr zerbrechlich sein. In einer Befehlssprache zu beschreiben, wo ein Skript erstellt werden soll, ist keine triviale Aufgabe, da die entsprechende Geometrie nicht ohne weiteres verfügbar ist.

Windows verfügte in früheren Versionen auch nicht über einen funktionsfähigen Pipe-Mechanismus. Wie es beschrieben wurde, würde der erste Prozess ausgeführt und seine Ausgabe in einer temporären Datei gespeichert. Diese Datei würde als Eingabe für den nächsten Befehl verwendet. Dies kann festplattenintensiv sein und schlägt fehl, wenn nicht genügend temporärer Speicher verfügbar ist. Unix-Pipes leiten die Daten im Speicher weiter und planen die Prozesse so, dass Verzögerungen minimiert werden.

Als Windows NT 1993 auf den Markt kam, war es ein Umzug von MS in den Bereich, der zuvor von Unix-Servern belegt war, und zu der Zeit wurde viel über POSIX-Kompatibilität und -Portabilität unternommen. Aber es hat nicht ganz die Arbeit gemacht - stattdessen waren die Benutzer mehr die Menge der Desktops, die bessere Hardware verwendeten (dies waren die Zeiten, als ein 486dx 50MHz mit 32MB RAM nahe am oberen Ende lag) und ein besseres Betriebssystem wollten. Aber sie waren nicht an Muscheln interessiert, so dass alle abrutschten. Zum Zeitpunkt von Windows Server 2000, einem zweiten ernsthaften Versuch, diesen Markt zu knacken, hatte MS meiner Meinung nach erkannt, dass sie auf der Shell-Seite schwach waren - da Administratoren Shell-Skripte lieben -, aber selbst dann brauchten sie einige Zeit, um den Juckreiz zu beseitigen.