답변:
커널 64 비트를 만드는 데 필요한 작업은 한참 전에 DEC Alpha 시스템을 사용하여 수행되었습니다 . 그러나 프로그램은 다른 문제입니다.
지금까지 본 일반적인 합의는 다음과 같습니다.
/lib와 /lib64혼합 된 바이너리를 시스템 디렉토리그 외에는 혼합 된 32/64 비트 빌드에서 많은 "슬픔"을 보지 못할 것입니다.
multilib alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib
Windows와 * ix는 전환에 다른 데이터 모델을 사용했습니다. 이 UNIX.org 페이지 는 약간 오래되었지만 여전히 장단점에 대한 좋은 개요를 제공합니다 ( long long나중에 C99에 추가되었으며 64 비트 이상이어야 함). 같은 주제에 대한 Wikipedia 기사 를 볼 수도 있습니다 . UNIX.org 기사 끝에서 주장한 바와 같이, 대부분의 유닉스 계열 시스템은 LP64를 사용했습니다. 즉 long, long long포인터는 모두 64 비트입니다.
Windows는 LLP64 데이터 모델과 함께 제공 long long되었으며 포인터는 64 비트입니다. long32 비트로 유지됩니다. 그 이유 중 하나는 단순히에 long적합 하다고 생각되는 깨진 코드를 해결하고 싶지 않기 때문 int입니다.
리눅스 배포판이 대부분 오픈 소스이므로 이미 큰 전환이 이루어졌습니다. 적절한 소프트웨어 (예 : skype)를 사용하지 않으면 단점없이 순수한 64 비트 시스템을 실행할 수 있습니다.
그러나 실제 차이점 IMHO는 일반적으로 먼저 포팅되는 오픈 소스 소프트웨어 (일부 volonteer는 무언가를 재 컴파일해야 함-컴파일 문제를 해결해야 함)-또는 대부분의 경우 포팅되지 않았기 때문에보다 적절한 vs. 단지 다시 컴파일 된;)-그리고 마지막으로 포팅되는 속성.
추가로 Linux에서는 repos가 있으므로 설치가 자동으로 처리되므로 64 비트 또는 32 비트 버전을 선택할 필요가 없습니다 (시스템이 자동으로 선택합니다). Windows에서 프로그램이 다운로드되고 별도의 64 비트 및 32 비트 버전이 있습니다.
이것이 Windows 바이너리가 일반적으로 32 비트 인 이유 일 것입니다. 모두 하나의 크기에 적합하며 모든 사람이 64 비트 버전으로 이동 한 것은 아닙니다.
실제로 ACM 큐에서 "64 비트로의 긴 길"을 시도하십시오. http://queue.acm.org/detail.cfm?id=1165766 나중에 ACM의 통신에 의해 포착되었다. 최초의 64 비트 마이크로는 MIGI R4000으로, SGI Crimson 1Q1992에 출하되었고 Dec Alphas는 그해 말에 출하되었습니다.
R4000은 처음에 32 비트 모드에서 실행 된 다음 64/32 모드, 즉 64 비트 OS, 64 또는 32 비트 사용자 코드에서 실행되었습니다. Alpha는 항상 64 비트 전용으로 UNIX를 실행했습니다 (32 비트 앱의 기본 설치가 없으므로 합리적인 선택).
1990 년대 후반에 SGI는 XFS가 Linux로 포팅 된 시간 (실제로 64 비트를 원함)에 대해 64 비트 Linux (Itanium에서 실행)에 노력을 기울였습니다.