Які були причини, чому Windows ніколи не мала гідної оболонки? [зачинено]

Я читав тему на SO: Чому мови сценаріїв (наприклад, ...) не підходять як мови оболонки? . Особливо мені сподобалась відповідь Йорга W Міттага , з якої я дізнався цікавого Windows PowerShell. Тому після більш ніж 20 років Windows нарешті має добре розроблену оболонку (Windows 1.0 - 1985, стабільний реліз PowerShell - 2009). З іншого боку, системи Unix мають купу різних снарядів з 1978 року Борн Шелл. Я прочитав кілька статей про співбесіду з роботою з МС і маю враження про дуже "видовищну" компанію. Мені цікаво, чому у них не було потреби в інструментах командного рядка порівняно з людьми Unix, які виконують всю свою роботу з цими інструментами.

З тієї ж причини, що iPod, iPhone (будь-який телефон з цього питання) та iPad цього не роблять: командний рядок не є основним каналом взаємодії користувачів з комп'ютером у Windows. Це в UNIX або GNU / Linux - тому вони більш зрілі. Той самий аргумент, чому настільні інтерфейси linux GUI так довго були сміттям порівняно з Windows (тут читання Mac OS читів, оскільки вони отримали своєрідний командний рядок Unix безкоштовно).

Можливо, я надто спрощую, але я вважаю це культурною річчю:

1. У культурі Microsoft розробники зосереджуються на написанні програм для своїх програм користувачів . Усі програми на основі GUI.
2. У культурі Unix розробники зосереджуються на написанні програм для інших розробників . Програми невеликі та зосереджені на тому, щоб добре робити конкретну справу.

Зауважте, що немає причин, що Microsoft може бути єдиним, хто пише оболонку для Windows. Хлопці, які пишуть bash, відрізняються від хлопців, які пишуть * nix ядра. Вам навіть не потрібні привілеї root. Я склав власні оболонки для використання, коли мені не сподобався встановлений sysadmin. Якби був справжній попит на кращу оболонку Windows, хтось написав би її.

Тому що, мабуть, ніколи не було достатньо дзвінків.

Хост сценаріїв Windows встановлений як стандартний з Windows 98 (я припускаю, що він був раніше); VBScript був дуже здатний; або ви могли легко написати інструмент командного рядка, який мав доступ до всього API Windows.

Powershell, простіше кажучи, - це ще один крок у тому ж напрямку. COM вже не популярний, тому WSH став досить навчальним процесом. Але .NET - це поточна велика річ у світі Windows, і вивчити Powershell на фоні .NET порівняно просто.

Я думаю, що Повершелл помилився, хоча намагається звернутися до натовпу * nix, з усіма своїми псевдонімами, які роблять його схожим на Баша, коли його явно немає.

Крім перемикачів командної лінії, трубопроводи у Powershell дуже різні, і це дійсно перше, що ви повинні дізнатися, коли ви підбираєте його.

І якщо чесно, це набагато більше схоже на мову сценаріїв, a la Perl, ніж на оболонку, a la Bash. Є кілька серйозних проблем, якщо ви спробуєте використовувати його як основну оболонку.

Наприклад, спробуйте зробити простий дамп SVN від Powershell. Він не дуже добре обробляє двійкові дані в stdout. З іншого боку, маніпулювати журналом SVN - це абсолютна мрія, завдяки вбудованому типу xml.

Оскільки в розробці другого паралельного набору інструментів Windows мало необхідності та багато болю.

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

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

Це одне з тих питань, на які, ігноруючи теорії змови, ймовірно, немає однозначної відповіді, і це те, про що історики могли б сперечатися назавжди, не знайшовши остаточної відповіді.

Моє враження, що сила оболонки не відразу очевидна. Я почав займатися програмуванням в Windows 3.1, і оболонки було дуже мало. Все було зроблено за допомогою Visual C ++ IDE, і я ніколи не переглядав makefiles та пакетні файли DOS були настільки обмеженими, що я рідко намагався використовувати пакетний файл для автоматизації нічого складнішого, ніж основна резервна копія. Жодна з програм, орієнтованих на Windows (я захоплююсь спогадами про Петцольда ), яку я читала під час обговорення, використовуючи оболонку 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 зрозуміли, що вони слабкі на оболонці - як адміністратори люблять сценарії оболонок - але навіть тоді їм знадобився певний час, щоб почухати свербіж.