크로스 플랫폼 애플리케이션에“지방 바이너리”가 더 널리 사용되지 않는 이유는 무엇입니까?

내가 아는 한, 소위 "지방 이진"(여러 시스템의 기계어 코드를 포함하는 실행 파일)은 Apple PC에서만 실제로 사용되며 심지어는 전환이 필요했기 때문에 사용 된 것처럼 보입니다. x86의 PowerPC

요즘 많은 소프트웨어가 크로스 플랫폼이며, 단일 지방 바이너리를 만드는 것은 여러 가지 방법으로 운영 체제와 아키텍처의 각 조합에 대해 수십 가지 또는 다른 다운로드를 추적하는 것보다 훨씬 간단합니다. 고객이 원하는 것을

예를 들어이 접근법이 왜 결코 적용되지 않았는 지에 대한 많은 추측을 할 수 있습니다.

• 다중 OS 바이너리를 실행 불가능하게 만드는 크로스 컴파일 도구 부족
• 어쨌든 각 OS에서 코드를 테스트해야하므로 이미 각 OS에 대해 기본적으로 컴파일 할 수있는 시스템이 있어야합니다
• 분명히 32 비트 프로그램은 이미 64 비트 시스템에서 "작동합니다"
• 동적 연결은 각 OS에서 다르게 작동하므로 "뚱뚱한 응용 프로그램"이 작동하더라도 "뚱뚱한 라이브러리"가 작동하지 않을 수 있습니다

그러나 항상이 OS 관련 및 아키텍처 별 세부 정보를 모두 숨기는 라이브러리 또는 프레임 워크로 작업하기 때문에 실제로 그 사실이 무엇인지, 또는 더 많은 문제가 있는지 알 수 없습니다. 약. 그렇다면 지방 바이너리가 일반적으로 다중 아키텍처 및 / 또는 다중 OS 소프트웨어를 만드는 데 사용되지 않는 실제 이유는 무엇입니까? (애플 외부)

다음과 같은 경우 팻 바이너리 접근 방식이 가장 적합합니다.

1. 두 아키텍처 모두 동일한 시스템에 공존
2. 다른 모든 것은 모든 아키텍처에서 거의 동일합니다.

이것이 크로스 플랫폼 코드에 사용되지 않거나 (두 기준 모두 적용되지 않음) 하나의 바이너리로 다른 Linux 배포판 을 지원하기 위해 사용되지 않는 이유입니다 (1. 적용되지 않음, 2. 어느 정도 적용됨).

Linux에서는 단일 Linux 배포에서 32 비트와 64 비트를 모두 지원하려는 경우 두 기준이 모두 적용됩니다 . 그러나 이미 여러 배포판을 지원해야하는 경우 왜 귀찮게합니까?

에 윈도우 16 비트에서 32 비트의 전환은 많은 안부에서 16 비트 Windows 세계에서 주요 편차 (가상 메모리, 다중 사용자 액세스 제어, API 변경 ...)이었다 윈도우 NT의 도입 초기에 일어났다. 이러한 모든 변경 사항으로 32 비트와 16 비트 월드를 분리하는 것이 좋습니다. NT는 이미 "서브 시스템"이라는 개념이 다른 OS "개인"(Win32, POSIX)을 지원하므로 Win16을 세 번째 하위 시스템으로 만드는 것이 간단한 선택이었습니다.

Win32에서 Win64 로의 전환에는 비슷한 주요 변경 사항이 포함되지 않았지만 Microsoft는 입증되고 시도 되었기 때문에 어쨌든 비슷한 접근 방식을 사용했습니다.

인터넷 연령 분포 물류는 두 가지 방식으로 지방 이진을 소독합니다.

1. 판매 시점에는 실제 상품이 포함되지 않으므로 제품이 소매 선반 공간을두고 경쟁하고 고객이 구매할 기회가 제한적인 경우와 같이 SKU가 적습니다.

2. 대역폭 비용은 특정 소프트웨어 패키지에 필요한 최소 비트 만 제공하는 것을 선호합니다. 유선으로 팻 바이너리를 발송하면 고객 경험과 판매자 인프라 효율성이 모두 저하됩니다.

소프트웨어가 압축 된 물리적 미디어를 축소했을 때 팻 바이너리가 더 의미가있었습니다.

팻 바이너리가 성공하지 못한 이유 중 하나는 바이너리 실행 파일을 무효화하는 ABI 및 프로세서 (실제로 명령 세트 ) 사양 보다 많기 때문입니다 . 바이너리 실행 파일은 종종 다른 리소스, 특히 동적 라이브러리 ( DLL hell 참조 ), 외부 서비스 ( PostGreSQL 과 같은 DBMS의 생각 ...), 시스템 구성 (예 : /etc/Linux 에서 구성 파일의 위치 ) 등에 크게 의존합니다. 등 ....

Linux / x86-64의 경우 실제로는 모든 Linux 배포에서 바이너리 실행 파일을 실행할 수 없도록하기가 어렵습니다 (종종 특정 버전 libc또는의 버전에 연결되어 있기 때문에 libstdc++). FatELF는 존재하지만 그다지 성공적이지 않습니다.

잘 정의 된 ABI 및 명령어 세트를 사용하더라도 최적화는 다양한 프로세서 브랜드마다 다릅니다 ( GCC 의 -mtune=native x86 최적화 플래그 참조) .

애플은 뚱뚱한 바이너리를 갖는 데 성공했다. 컴퓨팅 리소스의 매우 닫힌 생태계를 제공하기 때문이다.

자유 소프트웨어 는 이식성 문제를 해결하는 또 다른 방법입니다. 응용 프로그램이 자유 소프트웨어 (휴대 성을 위해 신중하게 코딩 된) 인 경우 유사한 시스템으로 쉽게 이식됩니다. 원래 소스 코드가 시스템에서 의도 한대로 작동하지 않더라도 일반적으로 합리적으로 쉽게 조정할 수 있습니다 (또는 다른 사람에게 비용을 지불). 물론 특정 OS 또는 ABI 또는 프로세서에 연결된 무료 소프트웨어는 쉽지 않습니다. 포트, 당신은 더 많은 노력을 지불합니다). POSIX 또는 Linux Standard Base 와 같은 표준 도 도움이됩니다.

^{사용 가능한 소스 코드로 일부 (무료) 소프트웨어를 이식하도록 비용을 지불하거나 요청할 수 있지만 이진 실행 파일을 이식하는 것은 비현실적입니다.}

마지막으로 Qt & POCO 와 같은 여러 운영 체제 (제공된 소스 코드를 사용할 수 있음)에서 포팅하는 데 도움이되는 몇 가지 프레임 워크가 있습니다 .

JVM 과 같이 잘 지정된 바이트 코드를 사용해도 항상 이식성이 보장되는 것은 아닙니다. 일부 Java 응용 프로그램은 이식성이없는 것으로 잘 알려져 있습니다 (예 : 특정 파일 계층 및 이름 지정이 필요하기 때문에).

BTW, 컴퓨터 시스템은 아마도 1980 년대 나 1990 년대 초 (또는 메인 프레임 시대)보다 이기종이 훨씬 적을 것입니다.

마지막으로 뚱뚱한 바이너리는 뚱뚱합니다. 많은 사람들이 관심을 가질 수없는 이식성 문제에 많은 리소스 (빌드 시간, 대역폭, 실행 가능 크기)를 소비하게됩니다. 격언을 기억하십시오. "휴대용 소프트웨어가 없으며 특정 시스템으로 포팅 된 소프트웨어 만 있습니다".