По каким причинам у Windows никогда не было достойной оболочки? [закрыто]

Я читал тему о SO: Почему языки сценариев (например ...) не подходят в качестве языков оболочки? , Особенно мне понравился ответ Jörg W Mittag , из которого я узнал много интересного Windows PowerShell. Таким образом, после более чем 20 лет Windows наконец-то имеет хорошо спроектированную оболочку (Windows 1.0 - 1985, стабильный выпуск PowerShell - 2009). С другой стороны, в системах Unix с 1978 года существует множество различных оболочек Bourne Shell. Я прочитал несколько статей о собеседовании при приеме на работу в MS и у меня сложилось впечатление, что это очень «отвратительная» компания. Мне интересно, почему они не нуждались в инструментах командной строки по сравнению с людьми из Unix, которые делают всю свою работу с этими инструментами.

По той же причине, по которой iPod, iPhone (любой телефон в этом отношении) и iPad этого не делают: командная строка не является основным каналом взаимодействия пользователя с компьютером в Windows. Это в UNIX или GNU / Linux - поэтому они более зрелые. Тот же самый аргумент, почему рабочие столы Linux с таким графическим интерфейсом так долго были мусором по сравнению с Windows (здесь читы вроде Mac OS, потому что они получили командную строку unix вроде бесплатно).

Может быть, я упрощаю, но я думаю об этом как о культурной вещи:

1. В культуре Microsoft разработчики сосредоточены на написании программ для своих пользователей . Все программы основаны на графическом интерфейсе.
2. В культуре Unix разработчики сосредоточены на написании программ для других разработчиков . Программы маленькие и ориентированы на то, чтобы хорошо выполнять определенную работу.

Обратите внимание, что нет причин, по которым Microsoft может быть единственной, кто пишет оболочку для Windows. Парни, которые пишут bash, отличаются от парней, которые пишут ядра * nix. Вам даже не нужны привилегии root. Я собрал свои собственные оболочки для использования, когда мне не нравился тот, который установил системный администратор. Если бы существовал реальный спрос на лучшую оболочку Windows, кто-то написал бы ее.

Я полагаю, что звонка на одного человека никогда не было достаточно.

Windows Scripting Host был установлен как стандарт с Windows 98 (я предполагаю, что это было до этого); VBScript был очень способным; или вы могли бы легко написать инструмент командной строки, который имел доступ ко всему API Windows.

Проще говоря, Powershell - это еще один шаг в том же направлении. COM больше не популярен, поэтому WSH стал довольно учебным процессом. Но .NET - текущая большая вещь в мире Windows, и изучение Powershell из .NET является относительно простым делом.

Я думаю, что в одном месте Powershell ошибся, пытаясь апеллировать к толпе * nix, со всеми ее псевдонимами, которые делают его похожим на Bash, хотя это явно не так.

Помимо переключателей командной строки, в Powershell сильно различаются трубопроводы, и это действительно первое, что вы должны изучить, когда поднимете их.

И, честно говоря, это больше похоже на язык сценариев, а-ля Perl, чем на оболочку, а-ля Bash. Есть некоторые серьезные ошибки, если вы попытаетесь использовать его в качестве основной оболочки.

Например, попробуйте сделать простой дамп SVN из Powershell. Он не очень хорошо обрабатывает двоичные данные в stdout. С другой стороны, манипулирование журналом SVN - абсолютная мечта благодаря встроенному типу xml.

Потому что в разработке второго параллельного набора инструментов для Windows нет необходимости и много боли.

Оболочки становятся мощными благодаря количеству и мощности вспомогательных программ в системе GNU, таких как sed, find, xargs et al. Повторная реализация этих инструментов - большая работа, и просто создать уровень соответствия POSIX поверх Windows оказалось гораздо проще. Cygwin - это такой уровень соответствия POSIX, который обеспечивает большинство потребностей пользователей оболочки, когда они вынуждены использовать Windows.

Лично я бы предположил, что сообщество разработчиков, которые не желают прыгать на подножку POSIX и Linux и все еще достаточно преданы программированию оболочки, настолько мало, что потребовалось 20 лет, чтобы разработать стабильную оболочку.

Это один из тех вопросов, на которые, игнорируя теории заговора, вероятно, нет единого ответа, и именно об этом историки могут спорить вечно, не найдя окончательного ответа.

У меня сложилось впечатление, что сила снаряда не сразу очевидна. Я начал заниматься программированием в Windows 3.1, и оболочка использовалась очень мало. Все было сделано с помощью Visual C ++ IDE, и я никогда не смотрел на make- файлы, и командные файлы DOS были настолько ограничены, что я редко пытался использовать командный файл для автоматизации чего-либо более сложного, чем обычное резервное копирование. Ни одна из книг по программированию, посвященных Windows (у меня есть приятные воспоминания о Petzold ), которые я читал в то время, обсуждал, используя оболочку Windows ни для чего. Только когда я начал использовать и программировать Linux, я понял, насколько полезной может быть мощная оболочка. Я помню, когда Windows вышла, это было так увлекательно, потому что вам не нужно было использовать старыеcommand.comбольше. Наконец-то у нас появился симпатичный интерфейс с более чем одним шрифтом и несколькими программами, запущенными одновременно без необходимости в TSR ...

Я думаю, что большинство программистов, начинающих в Windows, просто не имеют опыта работы с мощной оболочкой, и поэтому не испытывают острой необходимости реализовывать ее для Windows. Программисты, которые работают в Linux и ценят оболочку, предпочитают работать в Linux и поэтому не склонны тратить время на работу в среде, в которой им не так удобно внедрять среду для Windows, особенно с учетом (как уже указывалось) в другом вопросе) необходимость также реализовать все необходимые инструменты CLI вместе с самой оболочкой.

Вероятно, растущая популярность Linux является основной причиной того, что Microsoft наконец-то создала подходящую оболочку. По мере того, как все больше и больше людей осознавали, что такое оболочка, становится все более и более очевидным, что в Windows отсутствует важный инструмент.

Если вы считаете, что оболочки Unix «приличные», то для Windows существует по крайней мере одна оболочка, которая была «приличной» в течение десятилетий. Гамильтон C оболочки находится достаточно близко к Unix оболочки С (хотя заметим , что C оболочка никогда не было проникновения особенно огромный рынок на Unix). Многие люди также использовали различные оболочки JPSoft (4DOS, 4NT, теперь называемые Take Command) в течение достаточно долгого времени - как вы, вероятно, догадываетесь из названия, 4DOS восходит к временам MS-DOS.

Если вы настаиваете на оболочке, распространяемой Microsoft, 15 лет назад или около того комплект ресурсов Windows NT использовался для включения порта NT оболочки PD Korn ¹ , а также значительного количества утилит Unix-ish. Вероятно, он не включал достаточно для запуска большого количества сценариев оболочки без изменений, но его было достаточно, чтобы справляться с большим количеством использования, особенно с небольшой интерактивной работой.

¹ Честно говоря, я не знаю, что это был порт с той же самой оболочкой, или просто что-то очень похожее - я использовал его достаточно, чтобы убедиться, что он такой же раздражающий, как я помнил, как существовали оболочки Unix, и оставил это при этом. ,

Windows имеет конструктивные особенности, которые не поддаются написанию сценариев. Это результат превращения графического интерфейса в основной режим работы. Многие инструменты не имеют функциональных интерфейсов командной строки. Без приличного интерфейса командной строки очень сложно создать хорошую оболочку.

Зачастую для сценариев в Windows требуется, чтобы щелчки мыши и нажатия клавиш имитировались в разных местах окна приложения. Получающиеся сценарии могут быть довольно хрупкими. Описание того, где писать сценарии на командном языке, не является тривиальным упражнением, поскольку соответствующая геометрия недоступна.

В ранних версиях Windows также не было функционального механизма трубопровода. Как было описано, первый процесс будет запущен, а его выходные данные будут сохранены во временном файле. Этот файл будет использоваться в качестве входных данных для следующей команды. Это может занять много места на диске и завершиться сбоем, если достаточное временное пространство будет недоступно. Каналы Unix передают данные в память и планируют процессы таким образом, чтобы минимизировать задержки.

Когда он был запущен в 1993 году, Windows NT была движением MS в пространство, ранее занимаемое Unix-серверами, и в то время было принято решение о совместимости и переносимости POSIX. Но он не вполне справился с этой задачей - вместо этого его пользователи были больше настольными пользователями, использующими более качественное оборудование (это были дни, когда 486dx 50 МГц с 32 МБ ОЗУ были близки к верхнему уровню) и желали более совершенную ОС. Но они не были заинтересованы в снарядах, так что все поскользнулись. Ко времени Windows Server 2000, который был второй серьезной попыткой взломать этот рынок, я думаю, что MS поняла, что они слабы на стороне оболочки - поскольку администраторы любят сценарии оболочки - но даже тогда им потребовалось некоторое время, чтобы почесать зуд.