Tại sao không phải là nhị phân béo mập mà sử dụng rộng rãi hơn cho các ứng dụng đa nền tảng?

Theo như tôi biết, cái gọi là "nhị phân béo" - các tệp thực thi có chứa mã máy cho nhiều hệ thống - chỉ thực sự được sử dụng trên PC của Apple và thậm chí có vẻ như chúng chỉ sử dụng chúng vì chúng cần chuyển từ PowerPC tới x86.

Ngày nay, rất nhiều phần mềm là đa nền tảng và có vẻ như việc tạo một nhị phân béo duy nhất sẽ đơn giản hơn nhiều so với việc theo dõi hàng tá các bản tải xuống khác nhau cho mỗi kết hợp hệ điều hành và kiến ​​trúc, không đề cập đến việc truyền tải bằng cách nào đó cho khách hàng mà họ muốn.

Tôi có thể đưa ra rất nhiều dự đoán về lý do tại sao phương pháp này không bao giờ bị bắt, chẳng hạn:

• Việc thiếu các công cụ biên dịch chéo làm cho các nhị phân đa hệ điều hành trở nên không khả thi
• Dù sao, bạn cũng cần phải kiểm tra mã trên mỗi HĐH, vì vậy bạn phải có các hệ thống có thể biên dịch tự nhiên cho từng HĐH
• Rõ ràng các chương trình 32 bit "chỉ hoạt động" trên các máy 64 bit
• Liên kết động hoạt động khác nhau trên mỗi HĐH, do đó, "thư viện chất béo" có thể không hoạt động ngay cả khi "ứng dụng béo" sẽ

Nhưng vì tôi luôn làm việc với một thư viện hoặc khung ẩn tất cả các chi tiết cụ thể về kiến ​​trúc và đặc thù của hệ điều hành này với tôi, tôi không biết sự thật đó là như thế nào, hoặc nếu có nhiều vấn đề hơn tôi không biết trong khoảng. Vậy, lý do thực tế tại sao các tệp nhị phân béo thường không được sử dụng để tạo phần mềm đa kiến ​​trúc và / hoặc đa hệ điều hành là gì? (bên ngoài Apple)

Một cách tiếp cận nhị phân chất béo có ý nghĩa nhất nếu:

1. Cả hai kiến ​​trúc cùng tồn tại trên cùng một hệ thống
2. Mọi thứ khác ít nhiều giống nhau cho tất cả các kiến ​​trúc

Đó là lý do tại sao chúng không được sử dụng cho mã đa nền tảng (cả hai tiêu chí không áp dụng) hoặc để hỗ trợ các bản phân phối Linux khác nhau với một nhị phân (1. không áp dụng, 2. áp dụng ở một mức độ nhất định).

Trên Linux, cả hai tiêu chí vẫn sẽ được áp dụng nếu bạn muốn hỗ trợ cả 32 và 64 bit trên một bản phân phối Linux . Nhưng tại sao phải bận tâm, nếu bạn đã phải hỗ trợ nhiều bản phân phối?

Trên Windows , việc chuyển đổi từ 16 bit sang 32 bit ban đầu xảy ra với sự ra đời của Windows NT, đó là sự sai lệch lớn so với thế giới Windows 16 bit về nhiều mặt (bộ nhớ ảo, kiểm soát truy cập nhiều người dùng, thay đổi API ...). Với tất cả những thay đổi này, tốt hơn là giữ các thế giới 32 và 16 bit tách biệt. NT đã có khái niệm "hệ thống con" hỗ trợ "nhân cách" hệ điều hành khác nhau (Win32, POSIX), do đó, biến Win16 thành hệ thống con thứ ba là một lựa chọn đơn giản.

Việc chuyển đổi Win32 sang Win64 không liên quan đến những thay đổi lớn tương tự, nhưng dù sao thì Microsoft cũng đã sử dụng một cách tiếp cận tương tự, có lẽ vì nó đã được chứng minh và thử.

Hậu cần phân phối thời đại Internet không khuyến khích các nhị phân chất béo theo hai cách:

1. Điểm bán hàng không liên quan đến hàng hóa vật lý và do đó ưu tiên ít SKU hơn như trường hợp khi các sản phẩm cạnh tranh không gian kệ bán lẻ và khách hàng có cơ hội hạn chế để mua hàng.

2. Các chi phí của băng thông ưu tiên chỉ cung cấp các bit cần thiết tối thiểu cho một gói phần mềm cụ thể. Vận chuyển một nhị phân chất béo xuống dây làm suy giảm cả kinh nghiệm của khách hàng và hiệu quả cơ sở hạ tầng của người bán.

Các nhị phân béo có ý nghĩa hơn khi phần mềm được thu nhỏ bọc phương tiện vật lý.

Một phần lý do tại sao các nhị phân chất béo không thành công là có nhiều thông số kỹ thuật của ABI & bộ xử lý (thực tế là tập lệnh ) để vô hiệu hóa tệp thực thi nhị phân. Một tệp thực thi nhị phân thường phụ thuộc rất nhiều vào các tài nguyên khác, đặc biệt là các thư viện động (xem địa ngục DLL ), các dịch vụ bên ngoài (nghĩ về DBMS như PostGreQuery ....), cấu hình hệ thống (ví dụ: vị trí của các tệp cấu hình trong /etc/Linux), v.v. v.v ....

Chỉ dành cho Linux / x86-64, trên thực tế rất khó để tạo một tệp thực thi nhị phân có thể chạy trên mọi bản phân phối Linux (vì nó thường được gắn với các phiên bản cụ thể của libchoặc libstdc++). Béo tồn tại nhưng không thành công lắm.

Ngay cả với ABI và tập lệnh được xác định rõ, việc tối ưu hóa sẽ khác nhau trên các nhãn hiệu bộ xử lý khác nhau - xem cờ -mtune=native tối ưu hóa x86 của GCC .

Apple đã thành công một phần khi có các nhị phân béo chỉ vì họ cung cấp một hệ thống tài nguyên điện toán rất khép kín.

Phần mềm miễn phí là một cách khác để giải quyết mối quan tâm về tính di động của bạn: Nếu một ứng dụng là phần mềm miễn phí (được mã hóa cẩn thận cho tính di động), thì nó khá dễ dàng được chuyển đến các hệ thống tương tự. Và ngay cả khi mã nguồn ban đầu không hoạt động như dự định trên hệ thống của bạn, bạn có thể điều chỉnh nó (hoặc trả tiền cho ai đó để thực hiện công việc) thường dễ dàng một cách hợp lý (tất nhiên, phần mềm miễn phí gắn với HĐH hoặc ABI cụ thể hoặc bộ xử lý không dễ dàng cổng, bạn sẽ trả nhiều nỗ lực hơn cho điều đó). Và các tiêu chuẩn như POSIX hoặc Linux Standard Base cũng có ích.

^{Bạn có thể trả tiền (hoặc yêu cầu) ai đó chuyển một số phần mềm (miễn phí) bằng mã nguồn có sẵn, nhưng việc chuyển một tệp thực thi nhị phân là không thực tế.}

Cuối cùng, một số khung tồn tại để giúp chuyển trên một số hệ điều hành (cung cấp mã nguồn có sẵn), ví dụ: Qt & POCO .

Ngay cả khi sử dụng một mã byte được chỉ định tốt như JVM không phải lúc nào cũng đảm bảo tính di động: một số ứng dụng Java nổi tiếng là không thể mang theo được (ví dụ vì chúng mong đợi một số phân cấp và đặt tên tệp cụ thể).

BTW, các hệ thống máy tính có lẽ ít đồng nhất hơn nhiều so với những năm 1980 hoặc đầu những năm 1990 (hoặc trong thời đại máy tính lớn).

Cuối cùng, nhị phân béo là chất béo: bạn sẽ tiêu tốn rất nhiều tài nguyên (thời gian xây dựng, băng thông, kích thước thực thi) cho một vấn đề về tính di động có thể không liên quan đến nhiều người. Hãy nhớ câu cách ngôn: "không có phần mềm di động, chỉ có phần mềm đã được chuyển" (cho một số hệ thống cụ thể).