Jakie były powody, dla których Windows nigdy nie miał porządnej powłoki? [Zamknięte]

Czytałem temat na SO: Dlaczego języki skryptowe (np. ...) nie są odpowiednie jako języki powłoki? . Szczególnie podobała mi się odpowiedź Jörga W Mittaga , z której dowiedziałam się ciekawych rzeczy Windows PowerShell. Po ponad 20 latach Windows ma wreszcie dobrze zaprojektowaną powłokę (Windows 1.0 - 1985, stabilna wersja PowerShell - 2009). Z drugiej strony systemy Unix mają wiele różnych powłok od 1978 roku Bourne Shell. Przeczytałem kilka artykułów o rozmowach kwalifikacyjnych w MS i mam wrażenie bardzo „geekowskiej” firmy. Zastanawiam się, dlaczego nie potrzebowali narzędzi wiersza polecenia w porównaniu z ludźmi z Uniksa, którzy wykonują całą swoją pracę z tymi narzędziami.

Z tego samego powodu, że iPod, iPhone (jakikolwiek inny telefon) i iPad nie: wiersz poleceń nie jest głównym kanałem interakcji użytkownika z komputerem w systemie Windows. Jest w systemie UNIX lub GNU / Linux - dlatego są bardziej dojrzałe. Ten sam argument, dlaczego pulpity z graficznym interfejsem użytkownika dla Linuksa były tak nieprzyzwoite w porównaniu z Windowsem (rodzaj oszustw w Mac OS, ponieważ otrzymali one za darmo linię poleceń unix).

Może nadmiernie upraszczam, ale myślę o tym jako o kulturze:

1. W kulturze Microsoft programiści koncentrują się na pisaniu programów dla swoich użytkowników . Wszystkie programy są oparte na GUI.
2. W kulturze uniksowej programiści koncentrują się na pisaniu programów dla innych programistów . Programy są małe i koncentrują się na robieniu konkretnej rzeczy dobrze.

Pamiętaj, że nie ma powodu, aby Microsoft był jedynym, który napisał powłokę dla systemu Windows. Faceci, którzy piszą bash, różnią się od facetów, którzy piszą jądra * nix. Nie potrzebujesz nawet uprawnień roota. Skompilowałem swoje własne powłoki, aby używać ich, gdy nie podobała mi się ta, którą zainstalował sysadmin. Gdyby istniało prawdziwe zapotrzebowanie na lepszą powłokę Windows, ktoś by ją napisał.

Ponieważ, jak sądzę, nigdy nie było dość wezwania.

Windows Scripting Host został zainstalowany jako standard od Windows 98 (zakładam, że był już wcześniej); VBScript był bardzo zdolny; lub możesz łatwo napisać narzędzie wiersza polecenia, które miało dostęp do całego interfejsu API systemu Windows.

Mówiąc wprost, PowerShell to tylko kolejny krok w tym samym kierunku. COM nie jest już popularny, więc WSH stał się dość procesem uczenia się. Ale .NET jest obecnie wielką rzeczą w świecie Windows, a nauka Powershell z .NET jest stosunkowo łatwa.

Myślę, że jedno miejsce, w którym Powershell poszło nie tak, to próba odwołania się do tłumu * nix, ze wszystkimi jego aliasami, które sprawiają, że wygląda jak Bash, kiedy wyraźnie nie jest.

Oprócz przełączników wiersza poleceń, potokowanie jest bardzo różne w programie Powershell i jest tak naprawdę pierwszą rzeczą, której powinieneś się nauczyć, kiedy go wybierasz.

I szczerze mówiąc, jest to bardziej język skryptowy, a la Perl, niż powłoka, a la Bash. Istnieje kilka poważnych problemów, jeśli spróbujesz użyć go jako podstawowej powłoki.

Na przykład spróbuj wykonać prosty zrzut SVN z programu Powershell. Nie radzi sobie z danymi binarnymi w standardowym standardzie. Z drugiej strony manipulowanie dziennikiem SVN jest absolutnym marzeniem dzięki wbudowanemu typowi xml.

Ponieważ opracowanie drugiego zestawu równoległych narzędzi systemu Windows jest niewielkie i wymaga dużo bólu.

Powłoki są potężne dzięki liczbie i mocy programów pomocniczych w systemie GNU, takich jak sed, find, xargs i in. Ponowne wdrożenie tych narzędzi jest bardzo pracochłonne, a samo zbudowanie warstwy zgodności z POSIX na Windowsie okazało się znacznie łatwiejsze. Cygwin jest taką warstwą zgodności z POSIX i zapewnia większość potrzeb użytkowników powłoki, gdy są zmuszeni do korzystania z systemu Windows.

Osobiście zgaduję, że społeczność programistów, która zarówno nie chce przeskoczyć modemu POSIX i Linux, jak i nadal wystarczająco poświęca się programowaniu powłoki, jest tak mała, że ​​opracowanie stabilnej powłoki zajęło 20 lat.

Jest to jedno z tych pytań, które, ignorując teorie spiskowe, prawdopodobnie nie mają jednej odpowiedzi i jest to rodzaj rzeczy, o którą historycy mogliby się kłócić na zawsze, nie znajdując ostatecznej odpowiedzi.

Mam wrażenie, że siła pocisku nie jest od razu oczywista. Zacząłem od programowania w Windows 3.1 i korzystanie z powłoki było bardzo małe. Wszystko odbywało się za pomocą Visual C ++ IDE i nigdy nie patrzyłem na pliki makefile i pliki wsadowe DOS były tak ograniczone, że rzadko próbowałem użyć pliku wsadowego do zautomatyzowania czegoś bardziej skomplikowanego niż podstawowa kopia zapasowa. Żadna z książek o programowaniu w systemie Windows (mam miłe wspomnienia o Petzoldu ), którą czytałam w tym czasie, nie omawiała używania powłoki Windows do czegokolwiek. Dopiero kiedy zacząłem używać i programować Linuksa, zrozumiałem, jak użyteczna może być potężna powłoka. Pamiętam, kiedy pojawił się Windows, było to tak ekscytujące, ponieważ nie musiałeś używać staregocommand.comjuż. W końcu mieliśmy ładny interfejs z więcej niż jedną czcionką i wieloma programami działającymi w tym samym czasie bez potrzeby TSR ...

Myślę, że większość programistów, którzy zaczynają w systemie Windows, po prostu nie mają doświadczenia z potężną powłoką, więc nie odczuwam pilnej potrzeby implementacji jednego z nich dla systemu Windows. Programiści, którzy pracują w Linuksie i doceniają powłokę, wolą pracować w Linuksie, więc nie czują skłonności do spędzania czasu w środowisku, w którym nie są tak wygodne, aby wdrożyć jeden dla systemu Windows, szczególnie biorąc pod uwagę (jak już wspomniano) w innym pytaniu) potrzeba wdrożenia wszystkich narzędzi CLI, które są potrzebne wraz z samą powłoką.

Rosnąca popularność Linuksa jest prawdopodobnie głównym powodem, dla którego Microsoft w końcu umieścił odpowiednią powłokę. W miarę jak coraz więcej osób zdawało sobie sprawę z tego, że powłoka jest przydatna, coraz bardziej jasne było, że Windowsowi brakuje ważnego narzędzia.

Jeśli uważasz, że powłoki uniksowe są „przyzwoite”, to istnieje co najmniej jedna powłoka dla systemu Windows, która była „przyzwoita” przez dziesięciolecia. Hamilton C powłoka jest dość blisko do Unix powłoki C (choć uwaga, że powłoka C nigdy nie miała szczególnie ogromne penetracji rynku na Unix). Sporo osób używało również różnych powłok JPSoftu (4DOS, 4NT, teraz nazywane Take Command) - jak zapewne domyślacie się po nazwie, 4DOS wraca do czasów MS-DOS.

Jeśli nalegasz na powłokę dystrybuowaną przez Microsoft, około 15 lat temu zestaw Windows NT Resource zawierał kiedyś port NT powłoki PD Korn ¹ , a także całkiem sporo narzędzi uniksowych. Prawdopodobnie nie zawierał wystarczającej ilości, aby uruchomić wiele skryptów powłoki bez modyfikacji, ale wystarczył, aby obsłużyć spory użytek, zwłaszcza sporo interaktywnej pracy.

¹ Szczerze mówiąc, nie wiem, czy był to port tej dokładnej powłoki, czy po prostu coś całkiem podobnego - użyłem jej wystarczająco, aby sprawdzić, czy było to tak irytujące, jak pamiętałem, że były to powłoki uniksowe, i zostawiłem to .

System Windows ma funkcje projektowe, które nie nadają się do pisania skryptów. Jest to wynikiem uczynienia interfejsu graficznego podstawowym trybem działania. Wiele narzędzi nie ma funkcjonalnych interfejsów wiersza poleceń. Bez przyzwoitego interfejsu wiersza poleceń bardzo trudno jest wygenerować dobrą powłokę.

Często rzeczy wymagające skryptowania w systemie Windows wymagają symulacji kliknięć myszką i naciśnięć klawiszy w różnych miejscach w oknie aplikacji. Powstałe skrypty mogą być dość delikatne. Opisanie, gdzie należy pisać skrypty w języku poleceń, nie jest trywialnym ćwiczeniem, ponieważ odpowiednia geometria nie jest łatwo dostępna.

System Windows również nie miał funkcjonalnego mechanizmu rurociągów we wczesnych wersjach. Jak opisano, pierwszy proces zostanie uruchomiony, a jego dane wyjściowe zostaną zapisane w pliku tymczasowym. Plik ten zostanie użyty jako dane wejściowe do następnego polecenia. Może to wymagać dużej ilości miejsca na dysku i zakończy się niepowodzeniem, jeśli nie będzie wystarczającej ilości miejsca tymczasowego. Potoki uniksowe przekazują dane do pamięci i planują procesy w sposób minimalizujący opóźnienia.

Kiedy został uruchomiony, w 1993 roku, Windows NT został przeniesiony przez MS w przestrzeń poprzednio zajmowaną przez serwery Unix. W tym czasie wiele uwagi poświęcono kompatybilności i przenośności POSIX. Ale to nie do końca zadziałało - zamiast tego jego użytkownicy bardziej skupiali się na pulpicie, używając lepszego sprzętu (były to czasy, gdy 486dx 50 MHz z 32 MB pamięci RAM było blisko górnej granicy) i chcąc lepszego systemu operacyjnego. Ale nie byli zainteresowani pociskami, więc wszystko wymknęło się. Do czasu Windows Server 2000, który był drugą poważną próbą złamania tego rynku, myślę, że MS zdało sobie sprawę, że są słabi po stronie powłoki - jako administratorzy skryptów miłosnych - ale nawet wtedy zajęło im to trochę czasu.