Windows'un hiçbir zaman düzgün bir kabuğa sahip olmamasının nedenleri nelerdi? [kapalı]

SO hakkında bir konu okuyordum: Script dilleri (örneğin ...) kabuk dilleri olarak neden uygun değil? . Özellikle hakkında ilginç şeyler öğrendiğim Jörg W Mittag'ın cevabını beğendim Windows PowerShell. 20 yıldan fazla bir süre sonra, Windows nihayet iyi tasarlanmış bir kabuğa sahiptir (Windows 1.0 - 1985, PowerShell kararlı sürümü - 2009). Öte yandan Unix sistemleri, 1978'den beri Bourne Shell'den çeşitli kabuklara sahiptir. MS iş görüşmesi hakkında bazı makaleler okudum ve çok "geekish" bir şirket izlenim var. Merak ediyorum neden tüm araçlarını bu araçlarla yapan Unix insanlarına kıyasla komut satırı araçlarına ihtiyaç duymadılar.

İPod, iPhone (bu konudaki herhangi bir telefon) ve iPad'in yapmamasının aynı nedeni: komut satırı, Windows'daki bilgisayarla kullanıcı etkileşiminin birincil kanalı değildir. UNIX veya GNU / Linux'ta - bu yüzden daha olgunlar. Linux GUI masaüstlerinin Windows'a kıyasla neden bu kadar uzun sürdüğüne dair aynı argüman (Mac OS tür hileleri burada ücretsiz olarak unix komut satırını aldıkları için).

Belki çok basitleştiriyorum, ama bunu kültürel bir şey olarak düşünüyorum:

1. Microsoft kültüründe, geliştiriciler kullanıcıları için program yazmaya odaklanır . Programların hepsi GUI tabanlıdır.
2. Unix kültüründe, geliştiriciler diğer geliştiriciler için programlar yazmaya odaklanır . Programlar küçüktür ve belirli bir şeyi iyi yapmaya odaklanmıştır.

Microsoft'un Windows için bir kabuk yazan tek kişi olmasının hiçbir nedeni olmadığını unutmayın. Bash yazan çocuklar * nix çekirdekleri yazan adamlardan farklıdır. Kök ayrıcalıklarına bile ihtiyacınız yok. Sysadmin'in taktığı sevmediğim zaman kullanmak için kendi mermilerimi derledim. Daha iyi bir Windows kabuğu için gerçek bir talep olsaydı, birisi bir tane yazardı.

Çünkü biri için yeterli çağrı olmadı sanırım.

Windows Scripting Host, Windows 98'den beri standart olarak kuruldu (bundan önce olduğunu varsayıyorum); VBScript çok yetenekliydi; veya tüm Windows API'sına erişimi olan bir komut satırı aracını kolayca yazabilirsiniz.

Powershell, basitçe söylemek gerekirse, aynı yönde atılan başka bir adımdır. COM artık popüler değil, bu yüzden WSH oldukça bir öğrenme süreci haline geldi. Ancak .NET, Windows dünyasındaki mevcut Big Thing'dir ve Powershell'i .NET arka planından öğrenmek nispeten kolaydır.

Powershell'in yanlış gittiğini düşündüğüm bir yer, açıkça * nix kalabalığına hitap etmeye çalışmaktır, açıkça olmadığı zaman Bash gibi görünmesini sağlayan tüm takma adlarıyla.

Komut satırı anahtarlarının yanı sıra, borular Powershell'de çok farklıdır ve gerçekten aldığınızda öğrenmeniz gereken ilk şeydir.

Ve dürüst olmak gerekirse, bir betik dili, bir la Perl, bir kabuktan, bir la Bash'tan çok daha fazla. Birincil merminiz olarak kullanmaya çalışırsanız bazı ciddi gotcha'lar var.

Örneğin, Powershell'den basit bir SVN dökümü yapmayı deneyin. Stdout'taki ikili verileri çok iyi işlemez. Öte yandan, yerleşik xml türü sayesinde bir SVN günlüğünü değiştirmek mutlak bir rüyadır.

Çünkü ikinci bir paralel Windows araç seti geliştirmede çok az ihtiyaç ve acı var.

Kabuklar sed, find, xargs ve ark. Gibi bir GNU sistemindeki yardımcı programların sayısı ve gücü ile güçlü hale getirilir. Bu araçları yeniden uygulamak çok iştir ve sadece Windows'un üzerine bir POSIX uyumluluk katmanı oluşturmak çok daha kolay olmuştur. Cygwin böyle bir POSIX uyumluluk katmanıdır ve kabuk kullanıcılarının Windows'u kullanmaya zorlandıklarında gereksinimlerinin çoğunu sağlar.

Şahsen hem POSIX hem de Linux bandwagonunu atlamak istemeyen ve hala kabuk programlamaya yeterince sadık olan geliştirici topluluğunun o kadar küçük olduğunu ve istikrarlı bir kabuk geliştirmenin 20 yıl sürdüğünü tahmin ediyorum.

Bu, komplo teorilerini göz ardı ederek muhtemelen tek bir cevabı olmayan ve tarihçilerin kesin bir cevap bulamadan sonsuza kadar tartışabilecekleri şeylerden biri.

Benim izlenimim, kabuğun gücünün hemen belli olmadığıdır. Windows 3.1'de programlamaya başladım ve kabuğun çok az kullanımı vardı. Her şey Visual C ++ IDE aracılığıyla yapıldı ve ben asla makefiles baktım ve DOS toplu iş dosyaları çok sınırlıydı ben nadiren temel bir yedek daha karmaşık bir şey otomatikleştirmek için bir toplu iş dosyası kullanmaya çalıştı. Windows odaklı programlama kitaplarının hiçbiri ( Petzold'un çok güzel anılarım var ) O zamanlar Windows kabuğunu kullanarak herhangi bir şey için okudum. Linux'u kullanmaya ve programlamaya başlayana kadar güçlü bir kabuğun ne kadar yararlı olabileceğini anlayamadım. Windows çıktığında çok heyecan verici olduğunu hatırlıyorum çünkü eski kullanmak zorunda kalmadınızcommand.comArtık. Nihayet bir TSR'ye ihtiyaç duymadan aynı anda çalışan birden fazla yazı tipi ve birden fazla program ile güzel bir arayüze sahiptik ...

Windows'da başlayan çoğu programcının güçlü bir kabukla ilgili deneyimi olmadığını ve bu nedenle Windows için bir tane uygulamak için acil bir ihtiyaç hissetmediğini düşünüyorum. Linux'ta çalışan ve kabuğu takdir eden programcılar, Linux'ta çalışmayı tercih ederler ve bu nedenle, Windows için bir tane uygulamak için rahat olmadığı bir ortamda çalışmak için zaman harcamaya meyilli hissetmezler, özellikle de (işaret edildiği gibi) başka bir soruda), kabuğun kendisi ile birlikte ihtiyaç duyulan tüm CLI araçlarını da uygulama ihtiyacı.

Linux'un artan popülaritesi, muhtemelen, Microsoft'un nihayet uygun bir kabuk yerleştirmesinin ana nedenidir. Gittikçe daha fazla insan, bir kabuğun neyin yararlı olduğunu fark ettiği için, Windows'un önemli bir aracı kaçırdığı daha açık hale geldi.

Eğer siz "düzgün" Unix kabukları düşünün, o zaman yıllardır "düzgün" oldu Windows için en az bir kabuk olmuş. Hamilton C kabuk oldukça yakın Unix C kabuğuna (C kabuk Unix üzerinde özellikle büyük bir pazar penetrasyonu olmadı o notta gerçi) 'dir. Oldukça az sayıda insan da JPSoft'un çeşitli kabuklarını (4DOS, 4NT, şimdi Komut Al olarak adlandırılır) kullanmıştır - muhtemelen adından tahmin edebileceğiniz gibi, 4DOS MS-DOS günlerine geri döner.

Microsoft tarafından dağıtılan bir kabukta ısrar ederseniz, 15 yıl önce Windows NT Kaynak kiti, PD Korn kabuğunun ^1'in NT bağlantı noktasını ve adil sayıda Unix-ish yardımcı programını içermekteydi. Muhtemelen değişiklik yapmadan çok fazla kabuk betiği çalıştırmak için yeterli değildi, ancak adil bir miktarda kullanımı, özellikle de biraz etkileşimli çalışmayı idare etmek için yeterliydi.

¹ Dürüst olmak gerekirse, o tam kabuğun bir limanı olduğunu bilmiyorum, ya da oldukça benzer bir şey - Unix mermilerinin olduğunu hatırladığım kadar can sıkıcı olduğunu doğrulamak için yeterince kullandım ve bunu bıraktım .

Windows, komut dosyalarına uygun olmayan tasarım özelliklerine sahiptir. Bu, grafik arayüzü birincil çalışma modu haline getirmenin bir sonucudur. Birçok aracın işlevsel komut satırı arabirimleri yoktur. İyi bir komut satırı arayüzü olmadan iyi bir kabuk oluşturmak çok zordur.

Genellikle Windows'da komut dosyası yazılması gereken şeyler, bir uygulama penceresinin çeşitli konumlarında fare tıklamaları ve tuş vuruşlarının simüle edilmesini gerektirir. Ortaya çıkan komut dosyaları oldukça kırılgan olabilir. Komut dilinde nerede komut dosyası yazılacağını tanımlamak, ilgili geometri kolayca bulunmadığından önemsiz bir alıştırma değildir.

Windows'un ilk sürümlerde işlevsel bir boru tesisatı mekanizması da yoktu. Açıklandığı gibi, ilk süreç çalışacak ve çıktısı geçici bir dosyaya kaydedilecektir. Bu dosya bir sonraki komuta giriş olarak kullanılır. Bu disk yoğun olabilir ve yeterli geçici alan yoksa başarısız olur. Unix boruları verileri bellekten geçirir ve işlemleri gecikmeleri en aza indirecek şekilde zamanlar.

1993'te başlatıldığında, Windows NT, MS tarafından daha önce Unix sunucularının işgal ettiği alana taşındı ve o zaman POSIX uyumluluğu ve taşınabilirliği hakkında önemli bir şey yapıldı. Ancak işi tam olarak yapmadı - bunun yerine kullanıcıları daha iyi bir donanım kullanan masaüstü kalabalığıydı (32MB RAM'e sahip 486dx 50MHz'in en üste yakın olduğu günlerdi) ve daha iyi bir işletim sistemi istiyorlardı. Ama mermilerle ilgilenmiyorlardı, böylece hepsi kaymıştı. Bu pazarı kırmak için ikinci ciddi bir girişim olan Windows Server 2000'e gelindiğinde, MS'in kabuk tarafında zayıf olduklarını fark ettiğini düşünüyorum - yöneticiler kabuk komut dosyalarını sevdiği için - ama o zaman bile kaşıntıyı çizmek biraz zaman aldı.