훨씬 큰 크기의 주소 공간을 제공하는데 64비트 윈도우에서 프로세스의 사용자 모드 주소 공간은 기본적으로 8TB이며 커널 모드 주소공간도 8TB이다. 32비트 윈도우의 사용자 모드 기본 주소공간이 2GB이므로 4,096배에 해당하는 엄청난 공간이다.
그리고 <그림 2>와 같이 64비트 윈도우는 최대 32GB(일부 윈도우 서버 에디션은 최대 1TB)의 물리 메모리를 지원하고 프로세스 간에 이 영역을 공유하지 않고도 사용할 수 있을 만큼 크기 때문에 메모리 페이지의 디스크 스왑이 많이 발생하지 않을 수 있고 프로세스의 수행 성능이 높아질 수 있다.
<그림 2> 64비트 윈도우에서의 메모리 사용 예
그렇다면 64비트 프로세스라도 기존의 32비트 프로세스처럼 2GB만 사용자 모드 주소공간으로 사용할 수도 있을까? 답은 ‘그렇다’이다. 예를 들어 2GB 주소공간이면 충분한 애플리케이션이거나 소스코드 내에서 너무 많은 포인터 연산과 포인터와 정수형 간에 형변환이 발생해서 포인터 사용이 안전하지 않을 경우에는 기존의 32비트 소스코드를 크게 수정하지 않고 64비트 프로세스로 사용할 수 있는 방법이 있다.
이 방법은 컴파일 시 특수한 스위치인 /LARGEADDRESSAWARE:NO를 사용하게 되는데 이 옵션을 이용해 컴파일된 64비트 프로세스는 시스템이 메모리 할당을 2GB 안에서만 하게 되고 64비트 포인터 중 32비트만 유효한 상태가 되기 때문에 포인터 사용이 안전해진다. 그러나 주의할 점은 64비트 프로세스에서 사용하게 되는 다른 DLL들이 64비트 주소공간 모두를 의미 있게 사용하게 될 경우 심각한 오류를 발생시킬 수도 있다. 다른 DLL들까지 2GB 안에서만 주소공간을 사용하도록 강제하는 것이 아니기 때문이다.
결국 64비트 프로세스에서 기존의 32비트 프로세스처럼 2GB만 주소공간으로 사용하려면 프로세스 안에서 사용되는 모든 모듈을 /LARGEADDRESSAWARE:NO 스위치로 컴파일해야 하지만 현실적으로는 어려움이 많으며 빠른 시일 안에 64비트 윈도우를 위한 완벽한 소스코드를 작성하는 것이 좋다.
결론적으로 64비트 윈도우가 가고자 하는 방향은 기존의 32비트와 64비트 모두를 원활하게 지원하고 하나의 소스코드를 이용해 32비트와 64비트 애플리케이션 개발을 할 수 있으며 향후 기업 환경이나 엔터프라이즈 환경에 맞는 진정한 64비트 애플리케이션을 개발하기 쉬운 환경을 제공하는 것을 목표로 하고 있다.