64 Windows 7에서 32비트 프로그램을 실행하는 방법

Overwatch, Hurtworld 또는 Subnautica와 같은 대부분의 최신 게임은 64비트 운영 체제에서만 실행될 수 있습니다. 이러한 프로그램 제작자가 32비트와 64비트용 서로 다른 버전의 애플리케이션을 만드는 것은 수익성이 없습니다. 두 버전 모두 매우 일반적이지만. 물론 x64로 전환하는 것은 매우 쉽습니다. 하지만 OS를 바꾸지 않고 여전히 인기 있는 게임을 보고 싶다면 어떻게 해야 할까요? 32비트 시스템에서 Subnautica 및 기타 64비트 프로그램을 실행하는 방법을 알아보세요.

이를 위해서는 컴퓨터가 애플리케이션의 정상적인 작동에 필요한 요구 사항을 충족해야 합니다. 프로세서에는 처음에 x64 아키텍처가 있어야 합니다.

32비트 시스템과 64비트 시스템의 차이점은 무엇입니까?

64비트용으로 설계된 프로그램을 32비트에서 열 수 없는 이유는 무엇입니까? 동일한 애플리케이션을 실행하지 않는데 이러한 버전이 왜 그렇게 다른가요? 그리고 오버워치를 x64에서 플레이할 수 있다면 왜 같은 컴퓨터에서는 플레이할 수 없고 x32에서는 플레이할 수 없나요?

PC에 얼마나 많은 RAM을 설치할 수 있는지, 각 특정 응용 프로그램에 얼마나 많은 RAM을 할당할 수 있는지는 시스템에 따라 다릅니다. x64에서 최대 RAM 용량은 16GB입니다(Windows 7 Professional에서는 최대 192GB). 이 경우 모든 유틸리티는 최대 4GB까지 제공됩니다. x32 버전에서는 표시된 숫자가 훨씬 작습니다(최대 4GB, 별도 프로그램의 경우 2GB).

프로세서의 용량에 따라 정보 처리 방법이 결정됩니다. 이는 성능에 큰 영향을 미칩니다. 64비트에서는 훨씬 더 좋습니다. 데이터 저장을 위한 더 큰 레지스터가 있으며 로드는 한 번에 모든 코어에 분산됩니다. 그리고 32비트 OS에서는 첫 번째 코어가 완전히 채워지면 두 번째 코어가 활성화됩니다.

"약한" 머신에는 x32를 설치합니다. PC에 RAM 용량이 부족하고 프로세서가 가장 좋지 않다면 64비트로 작업할 필요가 없습니다. 이는 생산성을 추가하지 않고 전자 컴퓨터에 "과부하"만 줄 것입니다. 그러나 강력한 x64 컴퓨터가 딱 맞을 것입니다.

이러한 시스템은 표면적으로 서로 유사하지만 소프트웨어 수준에서는 매우 다릅니다. 서로 다른 드라이버 세트가 있으므로 Subnautica, Overwatch, Hurtworld 등은 PC에 필요한 특성이 있더라도 32비트 OS에서 실행되지 않습니다.

최신 게임, 응용 프로그램, 그래픽 또는 비디오 편집 프로그램의 경우 x32가 할당하는 2GB로는 충분하지 않습니다. 새로운 게임 제작자는 x64용으로 특별히 제품을 만듭니다.

프로세서가 x64를 지원하는지 확인하는 방법은 무엇입니까?

다음과 같이 설치된 OS를 확인할 수 있습니다.

  1. 바탕화면에서 “내 컴퓨터” 아이콘을 마우스 오른쪽 버튼으로 클릭하세요.
  2. "속성" 항목입니다. 제어판 섹션에서도 찾을 수 있습니다.
  3. "유형" 줄은 OS 버전에 있는 비트 수를 나타냅니다.

먼저 현재 작업 중인 시스템이 무엇인지 이해해야 합니다.

32비트 시스템에서 Overwatch를 실행하기 전에 PC에서 게임을 처리할 수 있는지 확인하세요. 프로세서가 64비트 명령어를 지원하는지 확인하세요. 이는 특수 테스터 프로그램을 사용하여 수행할 수 있습니다. 예를 들어 무료 유틸리티인 "SecurAble"이 적합합니다. 설치할 필요는 없습니다. 따라서 사용 후 제거할 필요가 없습니다. 실행 파일을 실행하면 됩니다. 이름, 클럭 속도, 비트 심도, D.E.P 지원 여부(버퍼 오버플로로부터 장치를 보호함) 및 하드웨어 시각화 등 프로세서에 대한 정보가 표시됩니다. 결과 중 하나를 클릭하면 해당 설명이 표시됩니다.

64비트 명령에 대한 프로세서 지원 확인

프로그램이 "최대 32비트"라는 결과를 반환하면 x64용으로 설계된 응용 프로그램이 작동할 가능성이 낮다는 의미입니다. 오버워치나 허트워드를 플레이하려면 프로세서를 바꾸거나 원격 서버를 폐기해야 합니다.

32비트 시스템을 64비트 시스템으로 바꾸는 방법은 무엇입니까?

소위 가상화를 위한 여러 유틸리티가 있습니다. 특정 소프트웨어 및 하드웨어를 사용하여 플랫폼의 작동을 에뮬레이트합니다. 32비트 시스템에서 Hurtworld를 실행하는 방법을 알아내려면 다음 유틸리티 중 하나를 사용하세요.

이러한 프로그램은 일종의 "게스트" OS를 만듭니다. 하지만 어떤 경우에도 설치해야 하며 유료인 경우 라이센스 버전을 구입해야 합니다. 이렇게 하려면 필요한 운영 체제가 포함된 디스크(또는 디스크 이미지)가 있어야 합니다.

오라클 버추얼박스

유사한 작업을 위한 범용 프로그램입니다.

  1. 설치하고 실행해 보세요. 왼쪽에는 설치된 운영 체제 목록과 도구 모음이 있습니다. 오른쪽에는 선택한 시스템에 대한 정보가 표시됩니다.
  2. "만들기" 버튼을 클릭하세요. 정보창이 나타납니다. "다음"을 클릭하세요.
  3. OS 유형 및 버전을 선택합니다. 선택할 수 있는 옵션은 다양합니다. Microsoft Windows뿐만 아니라 Linux도 있습니다.
  4. 그런 다음 "게스트" 시스템에 할당할 RAM의 양을 결정해야 합니다.
  5. 그런 다음 OS 파일이 기록될 가상 디스크를 생성해야 합니다. 기존 항목을 선택하거나 새 항목을 만들 수 있습니다. 그리고 "부팅 디스크" 옵션 옆의 확인란을 선택하세요.
  6. 다음 창에서 디스크 용량을 고정할지 아니면 동적(변경)할지 선택합니다. 각 항목에 대한 자세한 설명이 있습니다. 부팅을 고정하는 것이 좋습니다. 나중에 드라이브를 더 추가할 수 있습니다.
  7. 가상 스토리지 크기를 구성합니다. 일반적으로 10GB이면 충분합니다. 메인 시스템이 설치된 곳이 아닌 별도의 장소에 만드는 것이 좋습니다.
  8. 프로세스가 완료될 때까지 기다리십시오. 사용 가능한 항목 목록에 새 항목이 나타납니다.

한 가지 방법은 가상화 유틸리티를 사용하는 것입니다.

그런 다음 하드웨어를 구성할 수 있습니다.

  1. 게스트 OS를 선택하고 속성을 클릭합니다.
  2. 일반 - 고급 섹션에서 사진 저장 폴더를 편리한 폴더로 변경하세요.
  3. 거기에 클립보드를 설정하세요. 이는 서로 다른 운영 체제 간에 정보가 전송되는 방법을 결정합니다.
  4. "시스템" 탭에서는 가상 마더보드 및 프로세서의 특성을 선택할 수 있습니다.
  5. World Wide Web에 대한 액세스를 구성하려면 "네트워크" 항목이 필요합니다. 기본 설정을 그대로 둘 수 있습니다.
  6. "미디어" 섹션에서 OS를 어디서 구할 것인지 지정합니다. 설치 프로그램이 CD에 있으면 드라이브에 넣으십시오. .ISO에서 다운로드하려면 "드라이브" 목록 옆에 있는 "열기" 버튼을 클릭하세요. 노란색 폴더처럼 보입니다.
  7. 데이터베이스, 애플리케이션, 게임 등 다른 이미지를 추가하여 빠르게 전환할 수도 있습니다.

설정을 완료한 후 “확인”을 클릭하세요. 게스트 OS를 시작하려면 해당 OS와 "시작"버튼을 클릭하십시오. 설치가 진행됩니다. 그리고 시스템 간에 전환할 수 있습니다. 64비트에서 플레이하고 32비트에서 작업할 수 있습니다.

기타 가상 머신

가상 머신 작업을 위한 유틸리티도 있습니다:

  • VMware 워크스테이션. 복잡한 작업을 위한 진지한 전문 프로그램입니다. 유료로 배포됩니다.
  • 하드웨어 에뮬레이션을 위한 간단한 유틸리티입니다. 오픈 소스입니다.
  • 윈도우 가상 PC. Windows 시스템에서만 작동합니다. 프로세스의 우선순위를 구성할 수 있습니다. 이렇게 하면 특정 작업을 수행하는 경우 온라인 머신에 리소스가 자동으로 할당됩니다.
  • Virt-Manager. 하드웨어 구성 요소를 사용자 정의할 수 있는 충분한 기회를 제공합니다. 가상 하드웨어는 모든 취향에 맞게 사용할 수 있습니다.

클라우드 컴퓨팅(원격 서버)

그래도 게임을 실행하기에는 성능이 부족하다면 원격 서버에서 할 수 있습니다. 모든 계산, 모든 정보가 처리됩니다. 이렇게 하면 x32와 관련된 제한 사항으로 인해 방해를 받지 않습니다. 결국, 애플리케이션은 적합한 시스템에서 "열릴" 것입니다. 당신의 컴퓨터에는 없습니다.

Microsoft Azure 프로그램이 이에 적합합니다. 도움을 받으면 다양한 목적으로 여러 운영 체제를 만들 수 있습니다. 게임 애호가들은 또한 전문화된 NVIDIA GRID 비디오 카드 가상화 서비스가 유용하다는 것을 알게 될 것입니다. 이러한 유틸리티에는 고속 인터넷이 필요합니다.

최첨단 클라우드 서비스로 역량 확장

32비트 시스템에서 64비트 응용 프로그램을 사용하는 것이 가능합니다. 하지만 추가 소프트웨어를 설치하거나 일반적으로 원격 서버로 전환해야 합니다. 이것은 매우 어렵습니다. 오버워치, 허트워드 등 인기 게임을 제대로 즐기고 싶다면 x64 OS를 설치하는 것이 좋다. 이렇게 하면 호환성 문제가 발생하지 않습니다. 그리고 아무것도 구성할 필요가 없습니다.

NastroyVse.ru

windows x64 - 아직도 32비트 프로그램이 이렇게 많은 이유는 무엇입니까?

귀하의 컴퓨터는 64비트 버전의 Windows를 실행하고 있을 가능성이 높습니다. 그러나 작업 관리자를 열면 시스템에 있는 대부분의 프로그램이 여전히 32비트임을 알 수 있습니다. 이게 정말 문제인가요? 64비트 버전과 32비트 버전의 Windows에는 많은 차이점이 있습니다. 64비트 버전의 Windows에서는 32비트 소프트웨어를 실행할 수 있지만 32비트 버전의 Windows에서는 64비트 소프트웨어를 실행할 수 없습니다.

프로그램의 비트 심도를 확인하는 방법은 무엇입니까?

작업 관리자를 사용하여 어떤 프로그램이 64비트인지, 어떤 프로그램이 32비트인지 확인해 보겠습니다. 작업 표시줄을 마우스 오른쪽 버튼으로 클릭하고 작업 관리자를 선택하거나 Ctrl + Shift + Esc를 눌러 엽니다. 프로세스 이름이 있는 열을 살펴보세요. 64비트 버전의 Windows 8.1 또는 8을 사용하는 경우 각 32비트 버전의 프로그램 이름 뒤에 "(32비트)"라는 단어가 표시됩니다. 64비트 버전의 Windows 7을 사용하는 경우 대신 "*32"가 표시됩니다. 32비트 프로그램은 일반적으로 64비트 버전의 Windows에서 C:\Program Files(x86)\ 폴더에 설치되는 반면, 64비트 프로그램은 일반적으로 C:\Program Files\ 폴더에 설치됩니다. 그것은 단지 규칙일 뿐입니다. 하지만 C:\Program Files (x86)\ 폴더에 64비트 프로그램을 설치하는 것을 금지하는 다른 규칙이 없다고 말하는 사람은 없습니다. 예를 들어 Steam은 32비트 프로그램이므로 기본적으로 "C:\Program Files (x86)\"에 설치됩니다. Steam에 설치하는 게임은 기본적으로 C:\Program Files (x86)\Steam 폴더에 설치됩니다. 64비트 버전의 게임도 마찬가지입니다. 서로 다른 두 Program Files 폴더를 비교해 보면 대부분의 프로그램이 C:\Program Files(x86) 폴더에 설치되어 있을 가능성이 높다는 것을 알 수 있습니다. 그리고 이러한 프로그램은 대부분 32비트입니다.

64비트 운영 체제에서 32비트 소프트웨어 실행

언뜻 보면 대부분의 Windows 프로그램이 64비트 운영 체제 아키텍처를 사용하지 않는다는 사실이 끔찍해 보입니다. 64비트 운영 체제에서 32비트 프로그램을 실행하면 성능이 저하된다고 생각할 수도 있지만 그렇지 않습니다. Windows는 64비트 버전의 Windows에서 WoW64 호환성 수준을 통해 32비트 프로그램을 실행합니다. 그러나 64비트 Intel 및 AMD 프로세서는 이전 버전과 호환되며 32비트 소프트웨어를 직접 실행할 수 있습니다. 모든 32비트 Windows 프로그램은 32비트 버전의 Windows에서와 마찬가지로 실행됩니다. 따라서 64비트 운영 체제에서 이러한 프로그램을 실행하는 데 장애가 없습니다. 사용하는 모든 프로그램이 여전히 32비트인 경우에도 운영 체제 자체가 64비트 모드에서 실행되므로 이점을 얻을 수 있습니다. 그리고 64비트 버전의 Windows가 더 안전합니다.

64비트 프로그램과 32비트 프로그램 중 어느 것이 더 좋나요?

32비트 프로그램은 64비트 버전의 Windows 운영 체제에서 문제 없이 실행됩니다. 하지만 모든 프로그램이 64비트라면 더 좋을까요? 64비트 프로그램에는 확실히 장점이 있습니다. 32비트 프로그램은 2GB의 메모리만 사용할 수 있는 반면, 64비트 프로그램은 훨씬 더 많은 메모리를 사용할 수 있습니다. 프로그램이 공격을 받을 가능성이 있는 경우 64비트 프로그램에 추가 보안 기능을 적용하면 도움이 될 수 있습니다. Google Chrome은 현재 64비트 버전의 Windows OS에서도 32비트 애플리케이션이지만 이 프로그램의 64비트 베타 버전이 이미 등장했습니다. 그리고 Google은 64비트 버전의 Chrome이 더 빠르고 안전하며 안정적일 것이라고 약속합니다. 일부 프로그램은 64비트 버전을 제공합니다. 예를 들어 Photoshop, iTunes, Microsoft Office 및 가장 널리 사용되는 일부 Windows 프로그램은 모두 64비트 형식으로 제공됩니다. 최신 게임도 64비트인 경우가 많아 2GB 이상의 메모리를 사용할 수 있습니다. 많은 프로그램이 64비트로 전환하지 않았고 앞으로도 전환하지 않을 것입니다. 개발자가 이미 업데이트한 경우에도 10년 전에 출시된 프로그램을 포함하여 오늘날 대부분의 32비트 Windows 프로그램을 64비트 버전의 Windows에서 계속 실행할 수 있습니다. 64비트 버전의 프로그램을 제공하려는 개발자는 많은 추가 작업을 수행해야 합니다. 그는 기존 코드가 64비트 소프트웨어로 올바르게 컴파일되고 실행되는지 확인해야 합니다. 32비트 버전의 Windows를 실행하는 사용자는 64비트 버전을 사용할 수 없으므로 두 가지 별도 버전의 프로그램을 제공하고 지원해야 합니다. Windows 데스크톱용 Evernote를 예로 들어보겠습니다. 64비트 버전의 Evernote를 출시하더라도 사용자는 차이점을 전혀 느끼지 못할 것입니다. 32비트 프로그램은 64비트 버전의 Windows에서 제대로 실행될 수 있으며 눈에 띄는 이점이 없으면 64비트 버전을 사용할 필요가 없습니다.

64비트 응용 프로그램을 찾을 수 있는 위치

일반적으로 소프트웨어 버전은 32비트와 64비트 중에서 선택할 수 없습니다. 예를 들어, Windows용 iTunes를 설치하면 Apple 웹 사이트는 Windows 버전에 따라 자동으로 32비트 또는 64비트 버전의 설치 프로그램으로 연결됩니다. Windows용 Photoshop을 설치하면 일반적으로 32비트 및 64비트 실행 파일이 모두 설치됩니다. Photoshop에서는 자동으로 선택합니다. 경우에 따라 32비트 버전과 64비트 버전의 프로그램에 대한 별도의 다운로드 링크가 표시될 수 있지만 이는 일반적이지 않습니다. 중요한 것은 64비트 응용 프로그램을 검색하는 것이 아니라 자신에게 잘 맞는 응용 프로그램을 찾는 것입니다. 대부분의 애플리케이션의 경우 버전이 64비트인지 32비트인지는 실제로 중요하지 않습니다.

작업 관리자를 열면 왜 그렇게 많은 응용 프로그램이 여전히 32비트인지 궁금해하기 쉽습니다. 그러나 이것은 그다지 큰 문제가 아니며 그 이유는 다음과 같습니다. 대부분의 응용 프로그램은 64비트 버전의 프로그램으로 전환해도 아무 것도 얻을 수 없기 때문입니다. 개발자가 모든 작업을 수행하고 Windows에서 사용하는 모든 작은 데스크톱 응용 프로그램과 유틸리티의 64비트 버전을 출시하더라도 대부분의 차이점을 알 수 없을 것입니다.

itchief.ru

프로그램을 64비트 시스템으로 전송하는 7단계

이 문서에서는 32비트 Windows 애플리케이션을 64비트 Windows 시스템으로 올바르게 전송하기 위한 주요 단계에 대해 설명합니다. 이 문서는 Visual Studio 2005/2008에서 C/C++ 언어를 사용하는 개발자를 대상으로 하지만 응용 프로그램을 64비트 시스템으로 이식하려는 다른 개발자에게도 유용할 것입니다. 이 문서에서는 32비트 프로그램을 64비트 시스템으로 마이그레이션하려는 개발자가 직면하는 주요 사항에 대해 설명합니다. 물론 고려된 문제 목록이 완전하지는 않지만 시간이 지남에 따라 이 기사의 확장된 버전이 제공되기를 바랍니다. 저자는 이 기사의 정보 내용을 개선하는 데 도움이 될 피드백, 의견 및 질문에 대해 감사하게 생각합니다. 컴퓨팅 아키텍처에서 "64비트"라는 용어는 64비트 정수 및 크기가 64비트인 기타 데이터 유형을 나타냅니다. "64비트" 시스템은 64비트 마이크로프로세서 아키텍처(예: EM64T, IA-64) 또는 64비트 운영 체제(예: Windows XP Professional x64 Edition)를 의미할 수 있습니다. AMD64(일명 x86-64, Intel 64, EM64T, x64)는 AMD에서 개발한 64비트 마이크로프로세서 아키텍처 및 해당 명령어 세트입니다. 이 명령어 세트는 Intel에서 EM64T(Intel64)라는 이름으로 라이센스를 받았습니다. AMD64 아키텍처는 이전 버전과 완전히 호환되는 x86 아키텍처의 확장입니다. 이 아키텍처는 개인용 컴퓨터와 워크스테이션의 기반으로 널리 보급되었습니다. IA-64는 Intel과 Hewlett Packard가 공동으로 개발한 64비트 마이크로프로세서 아키텍처입니다. Itanium 및 Itanium 2 마이크로프로세서에서 구현됩니다. 이 아키텍처는 주로 다중 프로세서 서버 및 클러스터 시스템에서 사용됩니다. AMD64와 IA-64는 서로 호환되지 않는 서로 다른 두 가지 64비트 아키텍처입니다. 따라서 개발자는 이러한 아키텍처를 모두 지원해야 하는지 아니면 하나만 지원해야 하는지 즉시 결정해야 합니다. 대부분의 경우 클러스터 시스템을 위한 고도로 전문화된 소프트웨어를 개발하거나 자체 고성능 DBMS를 구현하지 않는 한 IA-64보다 훨씬 더 널리 퍼져 있는 AMD64 아키텍처에 대한 지원만 구현하면 됩니다. 이는 AMD64 아키텍처가 거의 100% 점유하고 있는 개인용 컴퓨터 시장용 소프트웨어의 경우 특히 그렇습니다. 이 기사에서는 AMD64 아키텍처(EM64T, x64)에 대해서만 설명할 것입니다. 그 이유는 AMD64 아키텍처의 사용이 이제 애플리케이션 소프트웨어 개발자에게 가장 관련성이 높기 때문입니다.

다양한 아키텍처에 관해 이야기하면서 "데이터 모델"이라는 개념을 언급해야 합니다. 데이터 모델은 개발 환경 내에서 허용되는 유형 차원 간의 관계로 이해되어야 합니다. 하나의 운영 체제에는 다양한 데이터 모델을 준수하는 여러 개발 도구가 있을 수 있습니다. 그러나 일반적으로 하드웨어 및 소프트웨어 환경에 가장 잘 맞는 모델 하나만 사용됩니다. 기본 데이터 모델이 LLP64인 64비트 Windows 운영 체제를 예로 들 수 있습니다. 그러나 호환성을 위해 64비트 Windows 시스템은 ILP32LL 데이터 모델 모드에서 실행되는 32비트 프로그램의 실행을 지원합니다. 표 N1은 주요 데이터 모델에 대한 정보를 제공합니다.


표 N1. 데이터 모델

프로그램 코드는 사용된 데이터의 비트 심도를 고려해야 하기 때문에 사용된 데이터 모델은 64비트 애플리케이션의 개발 프로세스에 영향을 미칩니다.

"64비트 시스템용 프로젝트를 다시 빌드해야 합니까?"라는 질문으로 64비트 시스템 마스터링을 시작해야 합니다. 이 질문에 답해야 하지만, 생각한 후에 서두르면 안 됩니다. 한편으로는 64비트 솔루션을 제때 제공하지 않으면 경쟁업체에 뒤처질 수 있습니다. 반면, 경쟁 우위를 제공하지 못하는 64비트 애플리케이션에서는 시간을 낭비할 수 있습니다. 우리는 귀하가 선택하는 데 도움이 되는 주요 요소를 나열합니다. 수명 주기가 짧은 64비트 버전의 애플리케이션을 생성해서는 안 됩니다. WOW64 하위 시스템 덕분에 오래된 32비트 응용 프로그램은 64비트 Windows 시스템에서 꽤 잘 작동하므로 2년 후에 더 이상 지원되지 않는 64비트 프로그램을 만드는 것은 의미가 없습니다. 더욱이, 실제로는 64비트 버전의 Windows로의 전환이 지연되고 있으며 아마도 단기적으로는 대부분의 사용자가 32비트 버전의 소프트웨어 솔루션만 사용할 것으로 나타났습니다. 소프트웨어 제품의 장기적인 개발 및 지원을 계획하고 있다면 64비트 버전의 솔루션 작업을 시작해야 합니다. 이 작업은 천천히 수행할 수 있지만, 완전한 64비트 버전이 없으면 64비트 버전의 Windows에 설치된 해당 응용 프로그램을 지원하는 데 더 많은 어려움이 발생할 수 있다는 점을 명심하십시오. 64비트 시스템용으로 프로그램을 다시 컴파일하면 엄청난 양의 RAM을 사용할 수 있으며 작업 속도도 5-15% 향상됩니다. 64비트 프로세서의 아키텍처 기능(예: 더 많은 수의 레지스터)을 사용하면 5~10%의 속도 향상이 발생합니다. 32비트 애플리케이션과 64비트 운영 체제 간의 API 호출을 변환하는 WOW64 레이어가 없기 때문에 속도가 1%-5% 더 향상됩니다. 프로그램이 대용량 데이터(2GB 이상)로 작동하지 않고 속도가 중요하지 않은 경우 가까운 시일 내에 64비트 시스템으로 전환하는 것은 그리 중요하지 않습니다. 그런데 간단한 32비트 애플리케이션이라도 64비트 환경에서 실행하면 이점을 얻을 수 있습니다. 32비트 Windows 운영 체제가 /3gb 키로 실행되는 경우 /LARGEADDRESSAWARE:YES 키로 컴파일된 프로그램이 최대 3GB의 메모리를 할당할 수 있다는 것을 알고 계실 것입니다. 64비트 시스템에서 실행되는 동일한 32비트 프로그램은 거의 4GB의 메모리(실제로는 약 3.5GB)를 할당할 수 있습니다. 타사 개발자가 소프트웨어를 만드는 데 사용하는 라이브러리, 구성 요소 또는 기타 요소를 개발하는 경우 제품의 64비트 버전을 만드는 데 적극적으로 참여해야 합니다. 그렇지 않으면 64비트 버전 출시에 관심이 있는 고객은 대체 솔루션을 찾아야 할 것입니다. 예를 들어, 일부 소프트웨어 및 하드웨어 보호 개발자는 64비트 프로그램의 출현에 대해 오랜 지연으로 대응했으며 이로 인해 많은 클라이언트가 프로그램을 보호하기 위해 다른 도구를 찾게 되었습니다. 64비트 버전의 라이브러리를 출시함으로써 얻을 수 있는 추가적인 이점은 이를 별도의 제품으로 판매할 수 있다는 것입니다. 따라서 32비트 및 64비트 응용 프로그램을 모두 생성하려는 고객은 2개의 서로 다른 라이센스를 구입해야 합니다. 예를 들어, 이 정책은 Spatial ACIS 라이브러리를 판매할 때 Spatial Corporation에서 사용됩니다. 64비트 버전의 제품을 만들 계획을 세우기 전에 제품에서 사용하는 라이브러리와 구성 요소의 64비트 버전이 있는지 확인하세요. 또한 64비트 버전의 라이브러리에 대한 가격 정책이 무엇인지 알아보세요. 이 모든 것은 도서관 개발자의 웹사이트를 방문하면 알 수 있습니다. 지원이 불가능할 경우 64비트 시스템을 지원하는 대체 솔루션을 미리 찾아보십시오. 솔루션에 여전히 16비트 모듈이 포함되어 있으면 이를 제거해야 할 때입니다. 64비트 버전의 Windows에서는 16비트 애플리케이션을 실행할 수 없습니다. 여기서는 16비트 설치 프로그램 사용과 관련된 한 가지 사항을 명확히 해야 합니다. 일부 32비트 응용 프로그램을 설치하는 데 여전히 사용됩니다. 가장 널리 사용되는 여러 16비트 설치 프로그램을 최신 버전으로 즉시 교체하는 특별한 메커니즘이 만들어졌습니다. 이로 인해 16비트 프로그램이 여전히 64비트 환경에서 실행된다는 오해가 발생할 수 있습니다. 이는 사실이 아님을 기억하십시오. 많은 양의 어셈블리 코드를 사용하면 64비트 버전의 애플리케이션을 만드는 비용이 크게 증가할 수 있다는 점을 잊지 마십시오. 나열된 모든 사실과 모든 장단점을 고려한 후 프로젝트를 64비트 시스템으로 포팅해야 할지 여부를 결정하십시오. 그렇다면 계속 진행하겠습니다. 64비트 버전의 제품을 개발하기로 결정하고 이에 시간을 투자할 의향이 있다고 해서 성공이 보장되는 것은 아닙니다. 사실 필요한 모든 도구가 있어야 하며 여기서 불쾌한 사건이 발생할 수 있습니다.

가장 간단하면서도 가장 극복하기 어려운 문제는 64비트 컴파일러가 없다는 점일 수 있습니다. 이 기사는 2009년에 작성되었지만 Codegear의 64비트 C++ Builder 컴파일러는 아직 없습니다. 출시는 올해 말까지만 예상됩니다. 물론, 예를 들어 Visual Studio를 사용하여 전체 프로젝트를 다시 작성하지 않는 한 유사한 문제를 해결하는 것은 불가능합니다. 그러나 64비트 컴파일러가 없어 모든 것이 명확하다면 다른 유사한 문제가 더 숨겨져 있을 수 있으며 프로젝트를 새 아키텍처로 이전하는 작업 단계에서 이미 나타날 수 있습니다. 따라서 64비트 버전의 제품을 구현하는 데 필요한 모든 필수 구성 요소가 있는지 확인하기 위해 사전 조사를 수행하는 것이 좋습니다. 불쾌한 놀라움이 당신을 기다리고 있을 수 있습니다.

물론 프로젝트에 필요할 수 있는 모든 항목을 여기에 나열하는 것은 불가능하지만 방향을 파악하고 64비트 프로젝트 구현에 필요한 다른 사항을 기억하는 데 도움이 되는 목록을 제공하겠습니다. 64비트 컴파일러의 중요성에 대해 달리 말하기는 어렵습니다. 그래야만 합니다. Visual Studio 2008의 최신 버전(작성 당시)을 사용하여 64비트 응용 프로그램을 개발할 계획이라면 다음 표 N2가 필요한 Visual Studio 버전을 결정하는 데 도움이 될 것입니다.

표 N2. 다양한 버전의 Visual Studio 2008 기능 물론 가상 컴퓨터를 사용하여 32비트 하드웨어에서 64비트 응용 프로그램을 실행할 수 있지만 이는 매우 불편하며 필요한 수준의 테스트를 제공하지 않습니다. 컴퓨터에는 최소 4~8GB의 RAM이 설치되어 있는 것이 좋습니다. 라이브러리가 소스 코드로 제공되는 경우 64비트 프로젝트 구성이 있어야 합니다. 64비트 시스템용 라이브러리를 구축하기 위해 라이브러리를 직접 업그레이드하는 것은 힘들고 어려운 작업일 수 있으며 결과는 신뢰할 수 없고 오류가 발생하기 쉽습니다. 그렇게 하면 라이센스 계약을 위반할 수도 있습니다. 라이브러리를 바이너리 모듈로 사용하는 경우 64비트 모듈이 있는지도 확인해야 합니다. 64비트 애플리케이션 내에서는 32비트 DLL을 사용할 수 없습니다. COM을 통해 특수 하네스를 생성할 수 있지만 이는 별도의 크고 복잡한 작업이 됩니다. 또한 64비트 버전의 라이브러리를 구입하면 추가 비용이 발생할 수 있습니다. Visual C++는 64비트 인라인 어셈블러를 지원하지 않습니다. 외부 64비트 어셈블러(예: MASM)를 사용하거나 동일한 기능의 C/C++ 구현이 있어야 합니다. 테스트 방법론의 대폭 개정, 단위 테스트 현대화, 새로운 도구 사용. 이에 대해서는 아래에서 더 자세히 설명하겠지만, 애플리케이션을 새 시스템으로 마이그레이션하는 데 소요되는 시간을 추정할 때 이 점을 고려하는 것을 잊지 마십시오. 많은 양의 RAM을 소비하는 리소스 집약적인 애플리케이션을 개발하는 경우 테스트 입력 데이터 데이터베이스를 보충해야 합니다. 64비트 애플리케이션 로드 테스트 시 메모리 소비량은 4GB를 초과하는 것이 좋습니다. 이러한 조건에서만 많은 오류가 나타날 수 있습니다. 사용되는 보호 시스템은 필요한 만큼 64비트 시스템을 지원해야 합니다. 예를 들어 Aladdin은 Hasp 하드웨어 키를 지원하는 64비트 드라이버를 신속하게 출시했습니다. 그러나 오랫동안 64비트 바이너리 파일(Hasp Envelop 프로그램)을 자동으로 보호하는 시스템이 없었습니다. 따라서 보호 메커니즘은 프로그램 코드 내에서 독립적으로 구현되어야 했으며 이는 자격과 시간이 필요한 추가적인 복잡한 작업이었습니다. 보안, 업데이트 시스템 등과 관련된 유사한 문제를 잊지 마십시오. 64비트 애플리케이션을 완전히 설치할 수 있는 새 설치 프로그램이 필요합니다. 한 가지 전통적인 실수에 대해 즉시 경고하고 싶습니다. 이는 32/64비트 소프트웨어 제품을 설치하기 위한 64비트 설치 프로그램을 만드는 것입니다. 64비트 버전의 애플리케이션을 준비할 때 개발자는 종종 완전히 64비트 버전으로 만들고 싶어합니다. 그리고 그들은 32비트 운영 체제 사용자가 그러한 설치 패키지를 실행하지 않는다는 사실을 잊고 64비트 설치 프로그램을 만듭니다. 시작되지 않는 것은 64비트와 함께 배포판에 포함된 32비트 응용 프로그램이 아니라 설치 프로그램 자체라는 점에 유의하십시오. 결국 배포판이 64비트 응용 프로그램이라면 당연히 32비트 운영 체제에서는 실행되지 않습니다. 가장 짜증나는 점은 사용자가 무슨 일이 일어나고 있는지 추측할 수 없다는 것입니다. 그는 시작할 수 없는 설치 패키지만 보게 될 것입니다. Visual Studio 2005/2008에서 64비트 프로젝트 구성을 만드는 것은 매우 간단해 보입니다. 새로운 구성을 조립하고 오류를 검색하는 단계에서 어려움이 발생할 것입니다. 64비트 구성을 생성하려면 다음 4단계를 완료하십시오. 그림 N1과 같이 구성 관리자를 시작하십시오.

그림 1. 구성 관리자 실행 구성 관리자에서 새 플랫폼에 대한 지원을 선택합니다(그림 N2). 그림 2. 새 구성 만들기 64비트 플랫폼(x64)을 선택하고 32비트 버전에서 설정을 선택합니다. 기본으로 사용됩니다(그림 N3). Visual Studio 환경은 빌드 모드 자체에 영향을 미치는 설정을 조정합니다.

그림 3. x64를 플랫폼으로 선택하고 Win32 구성을 기본으로 사용합니다. 새 구성 추가가 완료되면 64비트 구성 옵션을 선택하고 64비트 애플리케이션 컴파일을 시작할 수 있습니다. 조립을 위한 64비트 구성 선택은 그림 N4에 나와 있습니다. 그림 4. 이제 32비트 및 64비트 구성을 사용할 수 있습니다. 운이 좋으면 64비트 프로젝트를 추가로 구성할 필요가 없습니다. 그러나 이는 프로젝트, 복잡성 및 사용되는 라이브러리 수에 따라 크게 달라집니다. 즉시 변경해야 할 유일한 것은 스택 크기입니다. 프로젝트에서 기본 스택 크기, 즉 1MB를 사용하는 경우 64비트 버전의 경우 2MB로 설정하는 것이 좋습니다. 꼭 필요한 것은 아니지만 미리 안전을 확보하는 것이 좋습니다. 기본 크기와 다른 스택 크기를 사용하는 경우 64비트 버전에 대해 2배 더 크게 만드는 것이 좋습니다. 이렇게 하려면 프로젝트 설정에서 스택 예약 크기 및 스택 커밋 크기 매개변수를 찾아서 변경하세요. 여기에서는 64비트 구성의 컴파일 단계에서 발생하는 일반적인 문제에 대해 이야기하는 것이 좋습니다. 타사 라이브러리에서 어떤 문제가 발생하는지 고려하고, WInAPI 함수와 연결된 코드의 컴파일러가 더 이상 LONG 유형에 포인터 배치를 허용하지 않으므로 코드를 현대화하고 LONG_PTG 유형을 사용해야 한다는 점을 알려주세요. 그리고 다른 많은 것들이 있습니다. 불행하게도 이런 내용이 너무 많고 오류가 너무 다양해서 한 기사나 심지어 책으로도 제시할 수 없습니다. 컴파일러가 생성하는 모든 오류와 이전에는 없었던 새로운 경고를 살펴보고 각 개별 사례에서 코드를 현대화하는 방법을 파악해야 합니다.

64비트 애플리케이션 개발 전용 리소스에 대한 링크 모음은 삶을 부분적으로 더 쉽게 만들 수 있습니다: http://www.viva64.com/links/64-bit-development/. 컬렉션은 지속적으로 업데이트되며 독자가 관심을 가질만한 리소스에 대한 링크를 보내면 저자는 독자에게 감사할 것입니다.

여기서는 애플리케이션을 마이그레이션할 때 개발자가 관심을 가질 수 있는 유형에만 중점을 둘 것입니다. 이러한 유형은 표 N3에 나와 있습니다. 대부분의 컴파일 오류는 이러한 유형의 사용과 연관됩니다.

유형 플랫폼 x32 / x64의 치수 유형 메모
정수 32 / 32 기본형. 64비트 시스템에서는 32비트로 유지됩니다.
긴 32 / 32 기본형. 64비트 Windows 시스템에서는 32비트로 유지됩니다. 64비트 Linux 시스템에서는 이 유형이 64비트로 확장되었습니다. Windows 및 Linux 시스템에서 작동하고 컴파일되어야 하는 코드를 개발하는 경우 이 점을 잊지 마십시오.
size_t 32 / 64 기본 부호 없는 유형입니다. 유형의 크기는 이론적으로 가능한 배열의 최대 크기를 수용할 수 있도록 선택됩니다. 포인터는 size_t 유형에 안전하게 배치될 수 있습니다(클래스 함수에 대한 포인터는 예외이지만 이는 특별한 경우입니다).
ptrdiff_t 32 / 64 size_t 유형과 유사하지만 서명됨. 한 포인터를 다른 포인터에서 뺀 표현식(ptr1-ptr2)의 결과는 ptrdiff_t 유형이 됩니다.
바늘 32 / 64 포인터의 크기는 플랫폼의 비트 용량에 직접적으로 의존합니다. 포인터를 다른 유형으로 캐스팅할 때는 주의하세요.
__int64 64 / 64 부호 있는 64비트 유형.
DWORD 32 / 32 32비트 부호 없는 유형. WinDef.h에서 다음과 같이 선언되었습니다. typedef unsigned long DWORD;
DWORDLONG 64 / 64 64비트 부호 없는 유형. WinNT.h에서 다음과 같이 선언되었습니다. typedef ULONGLONG DWORDLONG;
DWORD_PTR 32 / 64 포인터를 보유할 수 있는 부호 없는 유형입니다. BaseTsd.h에서 다음과 같이 선언되었습니다. typedef ULONG_PTR DWORD_PTR;
DWORD32 32 / 32 32비트 부호 없는 유형. BaseTsd.h에서 다음과 같이 선언되었습니다. typedef unsigned int DWORD32;
DWORD64 64 / 64 64비트 부호 없는 유형. BaseTsd.h에서 다음과 같이 선언되었습니다. typedef unsigned __int64 DWORD64;
HALF_PTR 16 / 32 반 포인터. Basetd.h에서 다음과 같이 선언됩니다:#ifdef _WIN64 typedef int HALF_PTR;#else typedef short HALF_PTR;#endif
INT_PTR 32 / 64 포인터를 배치할 수 있는 부호 있는 형식입니다. BaseTsd.h에서 다음과 같이 선언됩니다.#if 정의(_WIN64) typedef __int64 INT_PTR; #else typedef int INT_PTR;#endif
긴 32 / 32 32비트로 유지되는 부호 있는 유형입니다. 따라서 이제 많은 경우 LONG_PTR을 사용해야 합니다. WinNT.h에서 다음과 같이 선언되었습니다. typedef long LONG;
LONG_PTR 32 / 64 포인터를 배치할 수 있는 부호 있는 형식입니다. BaseTsd.h에서 다음과 같이 선언됩니다.#if 정의(_WIN64) typedef __int64 LONG_PTR; #else typedef long LONG_PTR;#endif
LPARAM 32 / 64 메시지 전송을 위한 매개변수입니다. WinNT.h에서 다음과 같이 선언되었습니다. typedef LONG_PTR LPARAM;
SIZE_T 32 / 64 size_t 유형과 유사합니다. BaseTsd.h에서 다음과 같이 선언되었습니다. typedef ULONG_PTR SIZE_T;
SSIZE_T 32 / 64 ptrdiff_t 유형과 유사합니다. BaseTsd.h에서 다음과 같이 선언되었습니다. typedef LONG_PTR SSIZE_T;
ULONG_PTR 32 / 64 포인터를 보유할 수 있는 부호 없는 유형입니다. BaseTsd.h에서 다음과 같이 선언됩니다.#if 정의됨(_WIN64) typedef unsigned __int64 ULONG_PTR;#else typedef unsigned long ULONG_PTR;#endif
단어 16 / 16 부호 없는 16비트 유형입니다. WinDef.h에서 다음과 같이 선언됩니다. typedef unsigned short WORD;
WPARAM 32 / 64 메시지 전송을 위한 매개변수입니다. WinDef.h에서 다음과 같이 선언되었습니다: typedef UINT_PTR WPARAM;
표 N3. 32비트 프로그램을 64비트 Windows 시스템으로 포팅할 때 관심 있는 유형입니다. 모든 컴파일 오류를 수정한 후에 오랫동안 기다려온 64비트 응용 프로그램을 얻을 수 있다고 생각한다면 실망할 것입니다. 가장 어려운 부분은 아직 오지 않았습니다. 컴파일 단계에서는 주로 암시적 유형 캐스팅 불가능과 관련된 컴파일러가 감지할 수 있는 가장 명백한 오류를 수정합니다. 그러나 이것은 빙산의 일각이다. 대부분의 오류는 숨겨져 있습니다. 추상 C++ 언어의 관점에서 보면 이러한 오류는 안전해 보이거나 명시적인 유형 캐스트로 위장됩니다. 컴파일 단계에서 식별된 오류 수보다 이러한 오류가 몇 배 더 많습니다.

/Wp64 키에 희망을 걸면 안 됩니다. 이 키는 종종 64비트 오류를 ​​찾는 기적의 도구로 알려져 있습니다. 실제로 /Wp64 스위치를 사용하면 32비트 코드를 컴파일할 때 코드의 특정 섹션이 64비트 모드에서 올바르지 않을 것이라는 일부 경고를 받을 수만 있습니다. 64비트 코드를 컴파일할 때 어떤 경우에도 컴파일러에서 이러한 경고가 표시됩니다. 따라서 64비트 애플리케이션을 컴파일할 때 /Wp64 키는 무시됩니다. 더욱이 이 키는 숨겨진 오류를 찾는 데 도움이 되지 않습니다.

숨겨진 오류의 몇 가지 예를 살펴보겠습니다. 가장 간단하지만 감지하기 쉽지 않은 오류 클래스는 중요한 비트가 잘리는 명시적 유형 캐스팅과 연관됩니다. 일반적인 예는 SendMessage와 같은 함수에 포인터를 전달할 때 32비트 유형에 대한 포인터를 캐스팅하는 것입니다.

MyObj* pObj = ... ::SendMessage(hwnd, msg, (WORD)x, (DWORD)pObj);
여기서 명시적인 유형 캐스트는 포인터를 숫자 유형으로 변환하는 데 사용됩니다. 32비트 아키텍처의 경우 위의 예는 SendMessage 함수의 마지막 매개 변수가 32비트 아키텍처의 DWORD와 동일한 LPARAM 유형이기 때문에 정확합니다. 64비트 아키텍처의 경우 DWORD 사용이 잘못되었으므로 LPARAM으로 바꿔야 합니다. LPARAM 유형의 크기는 아키텍처에 따라 32비트 또는 64비트입니다.

이는 간단한 경우이지만 유형 캐스트가 더 정교해 보이고 컴파일러 경고나 프로그램 텍스트 검색을 통해 감지할 수 없는 경우가 많습니다. 명시적 유형 캐스트는 유형 캐스트가 정확하고 프로그래머가 코드 안전에 대한 책임을 수락했음을 컴파일러에 알리기 위한 것이므로 컴파일러 진단을 억제합니다. 명시적인 검색도 도움이 되지 않습니다. 유형에는 표준 이름(프로그래머가 typedef를 통해 지정함)이 없을 수 있으며 명시적 유형 캐스팅을 구현하는 방법도 꽤 많습니다. 이러한 오류를 안정적으로 진단하려면 Viva64 또는 PC-Lint 분석기와 같은 특수 도구만 사용해야 합니다.

다음 예는 암시적 유형 캐스트와 관련되어 있으며 이로 인해 중요한 비트도 손실됩니다. fread 함수 코드는 파일에서 읽지만 64비트 시스템에서 2GB가 넘는 데이터를 읽으려고 하면 올바르지 않습니다.

size_t __fread(void * __restrict buf, size_t 크기, size_t 개수, FILE * __restrict fp); size_t fread(void * __restrict buf, size_t size, size_t count, FILE * __restrict fp) ( int ret; FLOCKFILE(fp); ret = __fread(buf, size, count, fp); FUNLOCKFILE(fp); return (ret) ;)
__fread 함수는 size_t 유형을 반환하지만 int 유형은 읽은 바이트 수를 저장하는 데 사용됩니다. 결과적으로 많은 양의 데이터를 읽으면 함수는 실제로 읽혀지는 바이트 수와 다른 수를 반환할 수 있습니다. 이것은 초보자를 위한 무지한 코드이고, 컴파일러는 그러한 유형 캐스트를 보고하며, 일반적으로 그러한 코드는 찾아서 수정하기 쉽다고 말할 수 있습니다. 이것은 이론적입니다. 그러나 실제 생활에서는 대규모 프로젝트의 경우 모든 것이 다를 수 있습니다. 이 예제는 FreeBSD 소스 코드에서 가져온 것입니다. 이 오류는 2008년 12월에야 수정되었습니다! 이는 FreeBSD의 첫 번째 (실험적) 64비트 버전이 2003년 6월에 출시되었다는 사실에도 불구하고 그렇습니다. 수정 전의 소스 코드는 다음과 같습니다.

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.14

수정된 버전은 다음과 같습니다(2008년 12월).

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.15

개별 비트로 작동하는 코드에서는 실수를 하기 쉽습니다. 다음 유형의 오류는 교대 작업과 관련이 있습니다. 예를 살펴보겠습니다:

ptrdiff_t SetBitN(ptrdiff_t 값, 부호 없는 bitNum) ( ptrdiff_t 마스크 = 1
위의 코드는 32비트 아키텍처에서 작동하며 0부터 31까지의 비트를 1로 설정할 수 있습니다. 프로그램을 64비트 플랫폼으로 전송한 후에는 0에서 63까지의 비트를 설정해야 합니다. 그러나 이 코드는 32-63의 비트를 설정하지 않습니다. "1"은 int 유형이고 그림 5와 같이 32개 위치로 이동하면 오버플로가 발생합니다. 결과가 0(그림 5-B)인지 1(그림 5-C)인지는 컴파일러에 따라 다릅니다. 구현.

그림 5. A - 32비트 코드에서 31번째 비트의 올바른 설치 B,C - 64비트 시스템에서 32번째 비트 설정 오류(두 가지 동작 옵션) 코드를 수정하려면 마스크 변수와 동일한 유형의 상수 "1"을 만들어야 합니다.

ptrdiff_t 마스크 = ptrdiff_t(1)
수정되지 않은 코드는 또 다른 흥미로운 버그로 이어질 수도 있습니다. 64비트 시스템에서 31비트를 설정하는 경우 함수의 결과는 0xffffffff80000000 값이 됩니다(그림 6 참조). 식 1의 결과 size_t ArraySize = N * 4; size_t *Array = (size_t *)malloc(ArraySize); 64비트 플랫폼으로 전환할 때 주의해야 할 주요 숫자는 표 N4에 나와 있습니다.

표 N4. 32비트에서 64비트 플랫폼으로 애플리케이션을 전송할 때 위험한 주요 매직값 대용량 데이터를 처리하는 프로그램에서는 큰 배열을 인덱싱하는 것과 관련된 오류가 발생하거나 영원한 루프가 발생할 수 있습니다. 다음 예에는 한 번에 2개의 오류가 포함되어 있습니다.

const size_t 크기 = ...; char *배열 = ...; char *end = 배열 ​​+ 크기; for (unsigned i = 0; i != size; ++i) ( const int one = 1; end[-i - one] = 0; )
첫 번째 오류는 처리된 데이터의 크기가 4GB(0xFFFFFFFF)를 초과하는 경우 변수 "i"가 "unsigned" 유형이고 결코 0xFFFFFFFF 값에 도달하지 않기 때문에 영원한 루프가 발생할 수 있다는 것입니다. 나는 그러한 일이 일어날 수 있다고 구체적으로 썼지만 반드시 그런 일은 일어나지 않을 것입니다. 컴파일러가 빌드하는 코드에 따라 다릅니다. 예를 들어, 디버그 모드에서는 영구 루프가 존재하지만 릴리스 코드에서는 루프가 사라지므로 컴파일러는 카운터에 대해 64비트 레지스터를 사용하여 코드를 최적화하기로 결정하고 루프가 정확해집니다. 이 모든 것이 혼란을 가중시키고 어제 작동했던 코드가 다음 날 갑자기 작동을 멈출 수도 있습니다. 두 번째 오류는 음수 인덱스 값이 사용되는 배열을 끝에서 처음으로 통과하는 것과 관련됩니다. 위의 코드는 32비트 모드에서 작동하지만 64비트 시스템에서 실행될 때 루프의 첫 번째 반복에서 배열이 경계를 넘어 액세스되고 프로그램이 충돌합니다. 이 동작의 이유를 생각해 봅시다. 32비트 시스템의 C++ 언어 규칙에 따라 "-i - one" 표현식은 다음과 같이 평가됩니다(첫 번째 단계에서 i = 0).
  1. "-i" 표현식은 부호 없는 유형이며 값은 0x00000000u입니다.
  2. 변수 "one"은 "int" 유형에서 unsigned 유형으로 확장되며 0x00000001u와 같습니다. 참고: int 유형은 두 번째 인수가 unsigned 유형인 작업에 참여하는 경우 "unsigned" 유형으로 확장됩니다(C++ 언어 표준에 따라).
  3. unsigned 유형의 두 값을 포함하는 빼기 연산이 발생하고 연산 결과는 0x00000000u - 0x00000001u = 0xFFFFFFFFu입니다. 결과는 부호 없는 유형입니다.
  4. 32비트 시스템에서 인덱스 0xFFFFFFFFu의 배열에 액세스하는 것은 인덱스 -1을 사용하는 것과 같습니다. 즉, end는 end[-1]과 유사합니다. 결과적으로 배열 요소가 올바르게 처리됩니다.
마지막 단락의 64비트 시스템에서는 그림이 달라집니다. 부호 없는 유형은 부호 있는 ptrdiff_t로 확장되고 배열 인덱스는 0x00000000FFFFFFFFFi64와 같습니다. 결과적으로 배열은 범위를 벗어납니다. 코드를 수정하려면 ptrdiff_t 및 size_t와 같은 유형을 사용해야 합니다. 일반적으로 누구도 비난할 수 없는 실수가 있지만 이것이 실수하는 것을 막지는 못합니다. 오래 전 먼 은하계(Visual Studio 6.0)에서 CWinApp의 자손인 CSampleApp 클래스를 포함하는 프로젝트가 개발되었다고 상상해 보십시오. 기본 클래스에는 WinHelp라는 가상 함수가 있습니다. 상속인은 이 기능을 무시하고 필요한 작업을 수행합니다. 이는 그림 7에 시각적으로 표시되어 있습니다.

그림 7. Visual Studio 6.0에서 생성된 올바른 코드 작업 그런 다음 프로젝트는 Visual Studio 2005로 전송되어 WinHelp 함수의 프로토타입이 변경되었지만 32비트 모드에서는 DWORD 및 DWORD_PTR 유형이 있기 때문에 아무도 이를 눈치채지 못했습니다. 동일하며 프로그램은 계속해서 올바르게 작동합니다(그림 8).

그림 8. 부정확하지만 실행 가능한 32비트 코드 오류는 DWORD 및 DWORD_PTR 유형의 크기가 다른 64비트 시스템에서 나타나기를 기다리고 있습니다(그림 9). 64비트 모드에서는 클래스에 두 개의 다른 WinHelp 함수가 포함되어 있는데 이는 당연히 잘못된 것입니다. 이러한 트랩은 일부 함수가 인수 유형을 변경한 MFC뿐만 아니라 응용 프로그램 및 타사 라이브러리의 코드에서도 숨겨질 수 있습니다.

그림 9. 오류는 64비트 코드에서 나타납니다. 유사한 64비트 오류의 예가 제공될 수 있습니다. 이러한 오류에 관심이 있고 이에 대해 더 자세히 알고 싶은 사람들은 "C++ 코드를 64비트 플랫폼으로 포팅할 때의 20가지 함정" 기사에 관심이 있을 것입니다. 보시다시피, 숨겨진 오류를 찾는 단계는 사소한 작업이 아닙니다. 특히 많은 오류가 불규칙적으로 나타나거나 대량의 입력 데이터에만 나타나기 때문입니다. 정적 코드 분석기는 입력 데이터 및 실제 조건에서 해당 섹션의 실행 빈도에 관계없이 전체 애플리케이션 코드를 확인할 수 있기 때문에 이러한 오류를 진단하는 데 매우 적합합니다. 초기 단계에서 대부분의 오류를 찾기 위해 애플리케이션을 64비트 플랫폼으로 이식하는 단계와 64비트 솔루션의 추가 개발 단계 모두에서 정적 분석을 사용하는 것이 합리적입니다. 정적 분석은 프로그래머에게 64비트 아키텍처와 관련된 오류의 특징을 더 잘 이해하고 보다 효율적인 코드를 작성하도록 경고하고 가르칩니다. 이 기사의 저자는 Viva64라는 특수 코드 분석기 중 하나의 개발자입니다. Software Verification Systems LLC 회사의 웹사이트에서 도구에 대해 더 자세히 알아보고 데모 버전을 다운로드할 수 있습니다. 공정하게 말하면 Gimpel PC-Lint 및 Parasoft C++Test와 같은 코드 분석기에는 64비트 오류를 ​​진단하기 위한 규칙 세트가 있다고 해야 합니다. 그러나 첫째, 이들은 범용 분석기이며 64비트 오류 진단 규칙이 제대로 표현되지 않습니다. 둘째, Linux 운영 체제 제품군에 사용되는 LP64 데이터 모델에 더 중점을 두므로 LLP64 데이터 모델을 사용하는 Windows 프로그램에 대한 유용성이 줄어듭니다. 앞 절에서 설명한 프로그램 코드에서 오류를 찾는 단계는 필수 단계이지만 충분 단계는 아닙니다. 정적 코드 분석을 포함한 어떤 방법도 모든 오류를 완벽하게 감지할 수 있도록 보장하지 않으며, 최상의 결과는 다양한 기술을 결합해야만 얻을 수 있습니다.

64비트 프로그램이 32비트 버전보다 더 많은 데이터를 처리하는 경우 4GB보다 큰 데이터 처리를 포함하도록 테스트를 확장해야 합니다. 이는 많은 64비트 오류가 나타나기 시작하는 경계입니다. 이러한 테스트는 훨씬 더 오랜 시간이 걸릴 수 있으므로 사전에 준비해야 합니다. 일반적으로 테스트는 각 테스트에서 소수의 요소를 처리하여 모든 내부 단위 테스트를 통과할 수 있는 방식으로 작성됩니다. 몇 분 안에, 자동화된 테스트(예: AutomatedQA TestComplete 사용)는 몇 시간 안에 완료됩니다. 32비트 시스템의 정렬 기능은 100개의 요소를 정렬하는 경우 100,000개의 요소에서 올바르게 작동하는 것이 거의 보장됩니다. 그러나 64비트 시스템에서 동일한 기능이 50억 개의 요소를 처리하려고 하면 실패할 수 있습니다. 단위 테스트의 실행 속도는 수백만 배나 느려질 수 있습니다. 64비트 시스템을 마스터할 때 테스트 조정 비용을 고려하는 것을 잊지 마십시오. 한 가지 해결책은 단위 테스트를 빠른 테스트(소량의 메모리로 작업)와 느린 테스트로 나누어 기가바이트 단위로 처리하고 밤에 실행하는 것입니다. 리소스 집약적인 64비트 프로그램의 자동화된 테스트는 분산 컴퓨팅을 기반으로 구축될 수 있습니다.