Các lý do tại sao Windows không bao giờ có một vỏ tốt? [đóng cửa]

Tôi đã đọc một chủ đề trên SO: Tại sao các ngôn ngữ script (ví dụ ...) không phù hợp làm ngôn ngữ shell? . Đặc biệt tôi thích câu trả lời của Jörg W Mittag , từ đó tôi học được những điều thú vị Windows PowerShell. Vì vậy, sau hơn 20 năm, Windows cuối cùng cũng có vỏ được thiết kế tốt (Windows 1.0 - 1985, PowerShell phát hành ổn định - 2009). Mặt khác, các hệ thống Unix có một loạt các shell khác nhau kể từ 1978 Bourne Shell. Tôi đã đọc một số bài viết về phỏng vấn xin việc của MS và tôi có ấn tượng về công ty rất "đam mê". Tôi tự hỏi tại sao họ không có nhu cầu về các công cụ dòng lệnh so với những người Unix làm tất cả công việc của họ với các công cụ đó.

Lý do tương tự mà iPod, iPhone (bất kỳ điện thoại nào cho vấn đề đó) và iPad không có: dòng lệnh không phải là kênh chính của tương tác người dùng với máy tính trong Windows. Đó là trong UNIX hoặc GNU / Linux - vì vậy đó là lý do tại sao họ trưởng thành hơn. Lập luận tương tự tại sao các máy tính để bàn GUI linux bị rác quá lâu so với Windows (loại gian lận Mac OS ở đây vì chúng có dòng lệnh unix miễn phí).

Có thể tôi quá đơn giản, nhưng tôi nghĩ đó là một điều văn hóa:

1. Trong văn hóa của Microsoft, các nhà phát triển tập trung vào việc viết chương trình cho người dùng của họ . Các chương trình đều dựa trên GUI.
2. Trong văn hóa Unix, các nhà phát triển tập trung vào việc viết chương trình cho các nhà phát triển khác . Các chương trình này nhỏ và tập trung vào làm tốt một việc cụ thể.

Lưu ý rằng không có lý do gì mà Microsoft có thể là người duy nhất viết shell cho Windows. Những người viết bash khác với những người viết hạt nhân * nix. Bạn thậm chí không cần quyền root. Tôi đã biên dịch các shell của riêng mình để sử dụng khi tôi không thích cái sysadmin được cài đặt. Nếu có một nhu cầu thực sự cho một vỏ Windows tốt hơn, ai đó sẽ viết nó.

Bởi vì chưa bao giờ có đủ cuộc gọi cho một người, tôi đoán vậy.

Windows Scripting Host đã được cài đặt theo tiêu chuẩn kể từ Windows 98 (tôi cho rằng nó đã xuất hiện trước đó); VBScript rất có khả năng; hoặc bạn có thể dễ dàng viết một công cụ dòng lệnh, có quyền truy cập vào toàn bộ API Windows.

Powershell, nói một cách đơn giản, chỉ là một bước khác trong cùng một hướng. COM không còn phổ biến nữa, vì vậy WSH đã trở thành một quá trình học tập. Nhưng .NET là Big Thing hiện tại trong thế giới Windows và học Powershell từ nền .NET là tương đối dễ dàng.

Một nơi tôi nghĩ rằng Powershell đã sai lầm khi cố gắng thu hút đám đông * nix, với tất cả các bí danh của nó làm cho nó trông giống Bash khi rõ ràng là không.

Ngoài các công tắc dòng lệnh, đường ống rất khác nhau trong Powershell và thực sự là điều đầu tiên bạn nên tìm hiểu khi nhặt nó lên.

Và thành thật mà nói, nó giống như một ngôn ngữ kịch bản, la Perl, hơn là vỏ sò, la Bash. Có một số vấn đề nghiêm trọng nếu bạn cố gắng sử dụng nó làm vỏ chính của mình.

Ví dụ: thử thực hiện một kết xuất SVN đơn giản từ Powershell. Nó không xử lý dữ liệu nhị phân trong thiết bị xuất chuẩn rất tốt. Mặt khác, thao tác nhật ký SVN là một giấc mơ tuyệt đối, nhờ vào loại xml tích hợp.

Bởi vì có rất ít nhu cầu và nhiều nỗi đau trong việc phát triển bộ công cụ Windows song song thứ hai.

Shell được tạo ra mạnh mẽ thông qua số lượng và sức mạnh của các chương trình trợ giúp trên hệ thống GNU, chẳng hạn như sed, find, xargs et al. Việc triển khai lại các công cụ này là rất nhiều công việc và chỉ cần xây dựng lớp tuân thủ POSIX trên Windows đã được chứng minh dễ dàng hơn nhiều. Cygwin là một lớp tuân thủ POSIX như vậy và cung cấp cho hầu hết các nhu cầu của người dùng shell khi họ buộc phải sử dụng Windows.

Cá nhân tôi đoán rằng cộng đồng nhà phát triển vừa không muốn nhảy băng thông POSIX và Linux và vẫn đủ cống hiến cho lập trình shell quá nhỏ đến nỗi phải mất 20 năm để phát triển lớp vỏ ổn định.

Đây là một trong những câu hỏi mà, bỏ qua các lý thuyết âm mưu, có lẽ không có một câu trả lời duy nhất và là điều mà các nhà sử học có thể tranh luận mãi mãi mà không bao giờ tìm thấy câu trả lời dứt khoát.

Ấn tượng của tôi là sức mạnh của vỏ không rõ ràng ngay lập tức. Tôi bắt đầu lập trình trong Windows 3.1 và sử dụng shell rất ít. Mọi thứ đã được thực hiện thông qua Visual C ++ IDE và tôi chưa bao giờ xem các tệp bó của tệp Makefiles và DOS bị giới hạn đến mức tôi hiếm khi cố gắng sử dụng tệp bó để tự động hóa mọi thứ phức tạp hơn sao lưu cơ bản. Không có cuốn sách lập trình tập trung nào của Windows (tôi có những kỷ niệm đẹp về Petzold ) Tôi đã đọc vào thời điểm đó thảo luận bằng cách sử dụng Windows shell cho bất cứ điều gì. Mãi đến khi tôi bắt đầu sử dụng và lập trình Linux, tôi mới hiểu được cái vỏ mạnh mẽ có thể hữu ích như thế nào. Tôi nhớ khi Windows ra mắt, nó rất thú vị vì bạn không phải sử dụng cũcommand.comnữa không. Cuối cùng chúng tôi đã có một giao diện đẹp với nhiều hơn một phông chữ và nhiều chương trình chạy cùng lúc mà không cần TSR ...

Tôi nghĩ rằng hầu hết các lập trình viên khởi động Windows đều không có kinh nghiệm với trình bao mạnh mẽ và vì vậy, không cảm thấy cần phải thực hiện một yêu cầu cấp thiết cho Windows. Các lập trình viên làm việc trong Linux và đánh giá cao trình bao, thích làm việc với Linux và vì vậy không cảm thấy có xu hướng dành thời gian làm việc trong môi trường mà họ không thoải mái để thực hiện một cho Windows, đặc biệt là xem xét (như đã được chỉ ra trong một câu hỏi khác) cũng cần phải thực hiện tất cả các công cụ CLI cần thiết cùng với chính trình bao.

Sự phổ biến ngày càng tăng của Linux, có lẽ là lý do chính khiến Microsoft cuối cùng đã đưa một lớp vỏ phù hợp vào. Khi ngày càng nhiều người nhận ra cái vỏ nào hữu ích cho nó ngày càng rõ ràng rằng Windows đang thiếu một công cụ quan trọng.

Nếu bạn coi shell Unix là "đàng hoàng", thì đã có ít nhất một shell cho Windows là "đàng hoàng" trong nhiều thập kỷ. Các Hamilton C shell là hợp lý gần với Unix C shell (mặc dù lưu ý rằng C shell đã không bao giờ có sự thâm nhập thị trường đặc biệt khổng lồ trên Unix). Khá nhiều người cũng đã sử dụng các hệ vỏ khác nhau của JPSoft (4DOS, 4NT, hiện được gọi là Take Command) trong một thời gian - như bạn có thể đoán từ cái tên, 4DOS quay trở lại thời MS-DOS.

Nếu bạn khăng khăng một lớp vỏ được phân phối bởi Microsoft, thì 15 năm trước, bộ công cụ Windows NT Resource được sử dụng để bao gồm một cổng NT của PD Korn shell ¹ , cùng với một số tiện ích Unix-ish hợp lý. Nó có thể không bao gồm đủ để chạy nhiều kịch bản shell mà không sửa đổi, nhưng đủ để xử lý một lượng sử dụng hợp lý, đặc biệt là khá nhiều công việc tương tác.

^{1 Thành} thật mà nói, tôi không biết rằng đó là một cổng của lớp vỏ chính xác đó, hoặc chỉ là một thứ khá giống nhau - Tôi đã sử dụng nó đủ để xác minh rằng nó gây phiền nhiễu như tôi nhớ về các vỏ Unix và để nó ở đó .

Windows có các tính năng thiết kế không cho vay theo kịch bản. Đây là kết quả của việc biến giao diện đồ họa thành chế độ hoạt động chính. Nhiều công cụ không có giao diện dòng lệnh chức năng. Nếu không có giao diện dòng lệnh tốt, rất khó để tạo ra một shell tốt.

Thông thường những thứ cần được viết kịch bản trong Windows yêu cầu nhấp chuột và các nét chính để được mô phỏng tại các vị trí khác nhau trên cửa sổ ứng dụng. Các kịch bản kết quả có thể khá mong manh. Mô tả nơi để kịch bản trong một ngôn ngữ lệnh không phải là một bài tập tầm thường vì hình học có liên quan là không có sẵn.

Windows cũng không có cơ chế đường ống chức năng trong các phiên bản đầu. Như đã mô tả, quá trình đầu tiên sẽ chạy và đầu ra của nó sẽ được lưu vào một tệp tạm thời. Tập tin đó sẽ được sử dụng làm đầu vào cho lệnh tiếp theo. Điều này có thể là đĩa nặng và sẽ thất bại nếu không đủ không gian tạm thời. Các ống Unix truyền dữ liệu trong bộ nhớ và lên lịch cho các quy trình theo cách giảm thiểu độ trễ.

Khi được ra mắt, vào năm 1993, Windows NT là một bước tiến của MS vào không gian bị chiếm giữ bởi các máy chủ Unix và tại thời điểm đó, một vấn đề lớn đã được thực hiện về khả năng tương thích và tính di động của POSIX. Nhưng nó không thực hiện được công việc - thay vào đó người dùng của nó là đám đông máy tính để bàn sử dụng phần cứng tốt hơn (đó là những ngày mà 486dx 50 MHz với 32 MB RAM gần với đầu cuối) và muốn có một hệ điều hành tốt hơn. Nhưng họ không quan tâm đến đạn pháo, vì vậy tất cả đều trượt. Vào thời Windows Server 2000, đây là một nỗ lực nghiêm trọng thứ hai để phá vỡ thị trường này, tôi nghĩ rằng MS đã nhận ra rằng họ yếu về mặt vỏ - vì các quản trị viên yêu thích các kịch bản shell - nhưng ngay cả sau đó họ cũng phải mất một thời gian để gãi ngứa.