Tại sao WinRT không được quản lý? [đóng cửa]

Windows 8 giới thiệu WinRT, giống như .NET nhưng không được quản lý. Tại sao nó không được quản lý? Đây có phải là một vấn đề hiệu suất? Có nghĩa là bộ sưu tập rác không phù hợp với các API cấp thấp hơn?

WinRT là sự thay thế cho Winapi dựa trên C lâu đời. Nó là một api phải có thể sử dụng được trong nhiều môi trường thời gian chạy. Trở lại 20 năm trước, một api C tương đối dễ dàng để tương tác. Điều đó đã chuyển từ đó, COM trở thành chất keo phổ quát trong nửa cuối thập niên 1990. Thực tế, bất kỳ thời gian chạy ngôn ngữ nào được sử dụng phổ biến trong Windows đều hỗ trợ COM.

Một trình thu gom rác là một chi tiết thực hiện thời gian chạy ngôn ngữ. Ví dụ, trình thu thập cho .NET rất khác với trình thu thập cho Javascript. Các đối tượng bản địa được tạo trong một trong hai phải tuân thủ các quy tắc rất nghiêm ngặt của người sưu tầm. Điều đó có nghĩa là họ sẽ phải tạo các phiên bản WinRT dành riêng cho từng thời gian chạy ngôn ngữ. Điều đó sẽ không xảy ra, ngay cả một công ty lớn như Microsoft không thể đủ khả năng để tạo và hỗ trợ một phiên bản WinRT cụ thể cho mọi ràng buộc ngôn ngữ. Cũng không cần thiết, vì các ngôn ngữ này đã hỗ trợ COM.

Ngay bây giờ, ràng buộc tốt nhất cho WinRT là C ++ vì COM hoạt động hiệu quả hơn với quản lý bộ nhớ rõ ràng. Với sự trợ giúp dồi dào từ các phần mở rộng trình biên dịch C ++ mới giúp nó tự động, rất giống với _com_ptr_t cũ với cú pháp giống như C ++ / CLI để tránh điều đó. Liên kết với các ngôn ngữ được quản lý tương đối đơn giản vì CLR đã có hỗ trợ tương tác COM tuyệt vời. WinRT cũng áp dụng định dạng siêu dữ liệu của .NET. Afaik, không có công việc nào được thực hiện trên các trình biên dịch được quản lý như ngày nay.

EDIT: Larry Osterman, một lập trình viên và blogger nổi tiếng của Microsoft, đã để lại một bình luận khá tốt trong một câu trả lời hiện đã bị xóa. Tôi sẽ trích dẫn nó ở đây để bảo tồn nó:

WinRT không được quản lý vì HĐH không được quản lý. Và bằng cách thiết kế WinRT theo cách nó được thiết kế, nó có khả năng được thể hiện bằng nhiều ngôn ngữ khác nhau, không chỉ C ++, C # và JS. Chẳng hạn, tôi có thể dễ dàng thấy một tập các mô-đun Perl triển khai API WinRT hoạt động trên máy tính để bàn. Nếu chúng tôi đã triển khai nó trong .Net, điều đó sẽ vô cùng khó khăn

WinRT không được quản lý vì dự định thay thế Win32 - API nhà phát triển cấp thấp nhất có thể truy cập cho Windows. API không được quản lý vẫn là API có khả năng hoạt động tốt nhất có thể được tiếp xúc với nhà phát triển và lý do là sẽ luôn có thể bọc API được quản lý lên trên đó, đó chính xác là những gì 'dự đoán' làm.

Điều đó cũng có nghĩa là các nhà phát triển C ++ có thể sử dụng WinRT mà không cần phải nhảy qua các vòng mà C ++ / CLI giới thiệu (xem http://www2.research.att.com/~bs/bs_faq.html#CppCLI ) Điều đó có nghĩa là bạn vẫn sẽ phải học COM nếu bạn muốn sử dụng WinRT.

Câu hỏi thực sự là 'tại sao COM lại cần thiết? Tại sao Microsoft phải phát minh ra nó? ' Bởi vì C ++ đơn giản mà không có tất cả các tiện ích bổ sung của COM là không đủ cho công việc OOP thực sự và các tuyên bố về C ++ của Stroustrup mang lại cho bạn 'tính di động' rất không phù hợp với thực tế làm việc. Xem http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/