1. 개요2. 하드웨어 설계 상 생기는 문제3. 소프트웨어상의 제한으로 인해 생기는 문제
3.1.
Windows 3.1의 256 MiB 문제3.2.
Windows 95의 480 MiB 문제3.3.
Windows 98 이후의
Windows 9x 운영 체제의 1 GiB 문제3.4.
32비트 Windows에서의 PAE 제한3.5.
32비트 Windows에서의 2 GiB 할당 제한3.6.
64비트 Windows의 메모리 제한3.7. VRAM 4 GiB 제한
4. 전망1. 개요
본 문서는 IBM PC 호환기종의 하드웨어나 마이크로소프트 운영 체제(MS-DOS나 Windows) 문제로 설치된 메모리 주소를 처리하지 못하여 생기는 메모리 용량 문제를 설명한다. 메모리 컨트롤러, CPU 아키텍처 등의 한계로 인해 하드웨어가 관리할 수 있는 주소가 한정적이거나 운영 체제, 응용 프로그램 등 소프트웨어에서 사용할 수 있는 주소가 제한되어 그 주소의 범위를 넘어가는 메모리를 쓸 수 없기 때문에 생긴다.현실에 비유하면 서울시의 전화번호 체계가 02-xxxx-xxxx이기 때문에 8천만 회선을 초과하여(02-2000-0000부터 02-9999-9999까지) 부여할 수 없는 것과 같은 이치이다. 서울시 전화국 교환기에 전화를 8천만대 이상 달아 봤자 8천만대에만 전화번호를 부여할 수 있으므로 나머지는 무용지물이 된다.
후술할 문단을 제외하면 하드웨어적으로 사용할 수 없는 경우는 메모리 컨트롤러가 원인인 경우가 대부분이다. 메모리 컨트롤러가 CPU에 통합되기 전에는 메인보드 칩셋에 있어서 메인보드 칩셋 종류에 따라서 제한이 있었지만 통합된 후에는 CPU에 의해서 걸린다.
2017년 AMD 기준 EPYC 7551P의 256GiB, RYZEN THREADRIPPER 1950X의 128GiB, 인텔 기준 Xeon E7-8890 v4의 3TiB나 Core i7-6950X의 128GiB를 최대 메모리로 보면 된다. 이런 문제는 메모리 가격의 하락→대용량의 메모리가 일반에 보급→더 큰 메모리를 제어하는 새로운 메모리 컨트롤러 내장의 수순으로 점진적으로 개선이 되는 부분이니 사용자 입장에선 대개 신경쓰지 않아도 되는 부분.
2. 하드웨어 설계 상 생기는 문제
2.1. 64 KiB 문제
과거 주소 버스가 16비트인 CPU들은[1] 레지스터의 주소지정이 64 KiB(216 = 64 × 210 바이트)로 제한되어 있었다. 예를 들어 인텔 8085/6502 등 대부분의 8비트 CPU와 DEC PDP-11 등 일부 16비트 미니컴퓨터는 주소지정이나 어드레스선이 16비트밖에 안 되어 메모리를 최대 64 KiB까지만 사용할 수 있었다. PDP-11은 메모리 관리 확장을 사용해서 물리적으로 256 KiB ~ 4 MiB까지 늘릴 수는 있었다. Apple-II나 일부 CP/M 시스템은 RAM 뱅크 스위치 컨트롤러 등 별도 하드웨어의 도움을 받아 RAM을 64 KiB보다 더 확장할 수도 있긴 했으나 아래에 설명된 EMS와 마찬가지로 응용 소프트웨어가 이를 인식하고 프로그램해야 하고 사용이 까다롭고 (프로그램용이 아닌) 데이터용으로만 사용할 수 있는 등 제약이 심했다.다른 컴퓨터 기종의 경우, 64KiB 문제 이전에 32KiB, 48KiB 문제가 있었다. 주소 버스가 16비트라도 그 주소 안에 RAM뿐만 아니라 ROM, I/O 영역까지 위치하기 때문. Apple II를 예로 들면 RAM에 할당된 영역은 48KiB이고[2] I/O 및 시스템 모니터가 16KiB, Applesoft BASIC ROM이 나머지를 차지한다. 따라서 64KiB RAM 장착 Apple II 또한 상단 16KiB는 전술한 뱅크 스위칭 방식으로 사용한다.
일반인들에게는 잘 와닿지 않은 문제였는데, 이 당시만 해도 컴퓨터가 느리고 메모리도 적어서 각종 소프트웨어는 운영체계를 거치지 않고 알아서 직접 하드웨어와 소통했다. 멀티태스킹에 관한 문제로, 하드 디스크가 장착된 8비트 PC는 국내에 전무하여 당시 PC 사용자들은 원하는 소프트웨어를 돌리려면 그냥 그 소프트웨어가 들어 있는 플로피 디스크를 넣어 부팅하고, 또 다른 소프트웨어를 돌리려면 그 소프트웨어가 들어 있는 디스크를 넣고 리부팅하는 것이 일반적이었다. 다시 말해 아래 640KiB와 달리 64KiB의 문제는 소프트웨어 개발사들이 알아서 해결해야 하는 일이지 사용자들이 신경써야 할 부분이 아니었다. 사용자들은 해당 소프트웨어의 최소 RAM 요구사항이 자신의 PC에 적합한지 확인만 했다.
2.2. 640 KiB 문제
- 해당 운영 체제: MS-DOS 및 그 호환 운영 체제
MS-DOS의 기본 메모리(Conventional Memory)와 그에 관련된 IBM PC 메모리 맵 체계가 프로그램이 사용하는 메모리 영역이 640 KiB로 제한되어 있어서 발생하는 문제이다. IBM이 IBM PC 설계를 할때 비디오 버퍼와 BASIC ROM 등의 펌웨어의 주소 할당에 대한 논의를 운영 체제를 공급하는 마이크로소프트와 협의를 했는데, 641 KiB부터 1024 KiB까지 할당하고 IBM PC 프로그램이 사용하는 메모리 영역을 최대 640 KiB까지 확장(업그레이드)을 할 수 있도록 한 것이 화근이었다.
사실 유저 영역은 0번지부터, 시스템 영역은 마지막 번지부터 중앙으로 먹어 들어오는 것이 상식적이고 확장성이 있으나, 당시에는 이럴 수밖에 없는 현실적 이유가 있었다. PC의 초창기인 8비트 시절에는 서로 다른 회사에서 만든 개인용 컴퓨터들이 수십 종 이상 난립하고 있었기 때문에 소프트웨어가 서로 호환되지 않았다. 하지만 다른 아키텍처의 PC임에도 8비트 CPU는 인텔 8080, Z80, 모토로라 6800, 모스 테크놀로지 6502 등으로 몇 종류 되지 않았던 덕에 CPU는 서로 비슷했다.[3] 이런 경우 프로그램 메모리 영역은 0번지부터 출발하게 하고 기종마다 서로 다른 ROM, I/O 등의 메모리 영역을 특정 번지에 위치시키면, 프로그래머 입장에서 기반이 되는 프로그램은 똑같이 만들어 코드 재사용성이 높아지고, 개별 기종에 따른 I/O 포트 제어 등만 기종별로 만들면 되니 CPU는 같지만 아키텍처가 다른 많은 컴퓨터에 대한 소프트웨어 개발이 편해진다. IBM PC 또한 이런 당대의 유행을 따른 것이었다.[4]
현실은 때때로 엔지니어의 예측을 아득히 뛰어넘어 엔지니어가 공밀레 하게끔 만든다.
사실 근본적인 문제는 IBM PC 및 IBM PC XT에서 이용된 인텔 8088 CPU 아키텍쳐의 문제다. 이 CPU는 내부적으로 주소에 20비트를 이용했으므로 주소 지정을 220=1 MiB까지만 할 수 있었다. 이에 맞춰 MS-DOS가 사용자 영역으로 640 KiB, 하드웨어 영역인 UMB(Upper Memory Block)를 384 KiB를 할당하면서 이런 문제가 발생한다.[5] 물론 IBM PC AT에서 채용된 80286 CPU는 주소를 최대 16 MiB(24비트)까지 이용할 수 있었고 80386 이후의 32비트 CPU에서는 4 GiB(32비트)까지 늘어났지만 MS-DOS에서는 그런 거 상관없이 CPU를 뭘 쓰든지 여전히 640 KiB만 이용할 수 있었다. 후술할 4 GiB 문제에서 32비트 운영 체제에서는 램 8 GiB, 16 GiB를 달아도 4 GiB밖에 인식이 안 되고 그 중 몇백 MiB를 못 쓰는 것처럼( 램 디스크를 써서 이용하는 방법 제외) 장착된 램이 16 MiB라도 기본적으로 640 KiB를 넘는 메모리는 못 썼다. 왜 하드웨어가 발전했음에도 불구하고 이렇느냐 하면, MS-DOS는 기본적으로 x86의 실제 모드(Real mode)에서 동작하기 때문이다. x86 CPU의 실제 모드는 하위 호환성을 위해서 8086과 동일하게 동작하는 모드로 8086과 마찬가지로 20비트 주소 지정을 하므로 메모리는 1 MiB까지만 접근할 수 있다. 1 MiB보다 상위의 메모리 영역에 접근하기 위해서는 보호 모드(Protected mode)로 동작해야 하는데 MS-DOS에서는 보호 모드를 지원하지 않았다.
Himem.sys와 EMM386/QEMM386 등의 메모리 관리자를 사용하면 보호 모드로 전환해 640 KiB보다 상위에 있는 메모리를 사용할 수는 있었으나, CPU에서 실행되는 코드처럼 프로그램의 중요한 부분은 640 KiB 영역에 두고 용량 많이 먹는 데이터 쪽을 EMS/XMS 영역으로 넘긴다는 개념이었다. 원래 EMS(Expanded Memory Specification/중첩 확장 메모리)는 IBM PC AT가 등장한 1984년에 대용량의 메모리를 필요로 하는 기업 사용자를 위해 만들어진 규격인데, 당시에는 메모리 집적도가 낮았으므로 커다란 확장 카드에 메모리를 다닥다닥 붙여서 ISA 슬롯에 장착해서 쓰는 물건이었다. 이렇게 생겼다. EMS가 필요한 소프트웨어, 예를 들어 게임의 경우 1990년대 초반( 심시티[6], 윙 커맨더, 윙 커맨더 2: 킬라시의 복수, 스타워즈: 엑스 윙 등) MS-DOS 게임이나 일본 DOS/V 게임을 구동할 때, EMM386은 XMS(Extended Memory Specification/연속 확장 메모리) 영역의 일부를 EMS 영역처럼 에뮬레이션하여 구동하는 것이다.
기본 메모리에 이것저것 올리다 보면 남은 용량이 점점 사라지는데, 이런 상태에서 기본 메모리를 많이 소모하는 프로그램을 돌리려 하면 메모리가 부족하다는 메시지가 출력되면서 실패할 수도 있다. 따라서 아무리 장착된 메모리에 여유가 있더라도 결국 원활한 프로그램 실행을 위해서는 이 하위 640 KiB 영역을 확보하기 위해 사활을 걸어야 했다. MS-DOS 후반기인 1990년대 중반 무렵에 나온 게임은 기본 메모리를 특히 많이 써서, 피나는 노력을 들여 실행하기 전에 570~610 KiB의 메모리를 확보해 두어야 했다.
예를 들면 마우스나 CD-ROM 드라이버 등 백그라운드에서 실행되는 메모리 상주 프로그램은 상시 동작하고 있기 때문에 기본 메모리에 올라가 있어야 한다. 장치 드라이버는 config.sys에서 DEVICEHIGH 명령어를 통해 하드웨어를 위해 예약된 공간인 UMB로 올릴 수 있었지만, 메모리 상주 프로그램은 이것이 불가능했다. 이런 것이 하나에 많으면 30 ~ 150 KiB 정도 차지하므로 메모리 상주 프로그램을 최대한 줄여서 기본 메모리를 확보해 줘야 했다. CD-ROM 드라이버 같은 드라이버도 사용하지 않을 때는 제거하는 등 필사적인 노력을 했지만 다행히 MS-DOS 6.0 이후에는 DEVICEHIGH나 LOADHIGH 또는 INSTALLHIGH 명령어를 이용해 UMB에 올릴 수 있게 됐다. 당대에 보편적으로 쓰였던 셸 프로그램인 Mdir은 이런 상황을 반영하여 다른 파일 실행 시 자신을 종료하여 메모리를 반환받은 후 파일을 실행하고 실행 파일을 종료하면 다시 복귀하는 일괄 실행 파일(.bat)을 만드는 기능이 있었을 정도. 이 경우에도 일괄 실행 파일은 실행중이라 메모리에 상주하지만 많아봤자 몇십 바이트라 큰 문제는 되지 않았다.
이런 사용자들의 피나는 투쟁을 지원하기 위해 상주 프로그램들을 XMS/UMB로 넘겨서 610 KiB 이상으로 만들어주는 QEMM386이라는 메모리 관리 프로그램이 선풍적인 인기를 끌었으나 어스토니시아 스토리, 신검의 전설 2 같은 몇몇 게임과의 충돌 문제가 있었으며, 삼성 등의 메이커 PC는 기본 세팅에서 이미 UMB의 일부 영역을 사용 중인 경우가 있었다. 결국 Microsoft도 MS-DOS 6.0부터 QEMM386만큼은 못하지만 자체적으로 640 KiB 영역을 튜닝해 주는 Memmaker.exe를 지원하기에 이른다. 하지만 6.0은 멀티 부팅할 수 있었지만 Memmaker가 멀티 부팅을 인식하지 못한다는 문제가 있었고, 6.22에서 해당 문제가 수정되었다.
기본 메모리를 어떻게 확보한 다음 UMB 영역과 XMS 영역을 사용한다 하더라도 문제가 또 있었는데 프로그램마다 요구하는 메모리 영역이 달랐던 것이다. 어떤 프로그램은 XMS를 요구하기도 하고, 또 어떤 프로그램은 EMS를 요구하기도 하는 식의 제각각이었다.
| What is DOS Protected Mode? / 유튜브 Nostalgia Nerd - 도스 보호 모드에 관한 설명 영상. |
후기에는 대체로 XMS를 많이 사용했는데, DOS4GW 모듈이 대표적이었다. DOS4GW는 보호 모드를 활용해 XMS 메모리 영역에 접근할 수 있게 해 주는 DOS 익스텐더 런타임 환경이다. 대표적으로 1990년대 중반에 발매된 어지간한 북미산 DOS 게임(대표적으로 둠)[7]들은 이 런타임 환경을 기본으로 사용했다. 게임뿐 아니라 일반적인 소프트웨어도 마찬가지로 국산 소프트웨어의 경우 도스에서 실행되던 초기의 아래아 한글도 해당 런타임을 경유해 실행되었다. 게임 개발사들은 이것을 이용해 편리하게 메모리를 관리할 수 있었다. 반면 PC-9801에서 이식한 DOS/V 게임들은 PC-9801이 확장성이 떨어져 주로 메모리 확장을 C버스용 EMS 메모리 보드로 했던 탓에 대부분 EMS를 사용했다.[8]
상황이 이 모양이다 보니 그때 그때마다 메모리 설정을 바꾸고 리부팅을 해야 하는 귀찮음을 감수해야 하는 경우도 드물지 않았다. 용도에 따라서 부팅 디스켓을 따로 만들어서 그나마 귀찮음을 줄일 수 있었다. CD롬 드라이버 유무, 마우스 유무 등에 따라 부팅 디스켓을 따로 준비해 두고 각 게임이 원하는 세팅으로 나눠두는 것. 당시에는 게임에 따라 정확히 세팅을 하는 것이 쾌적한 게임을 위한 최소한의 준비였다.[9] 심하면 config.sys의 files와 buffer의 설정도 따지는 게임도 있었는데, 해당 게임에 꼭 맞는 수치라기 보다는 복잡한 메모리 설정 방법 대신 게임이 돌아갈 수 있게만 시동 파일 설정을 해주는 경우에 더 가까웠다. 하지만 부팅 디스켓을 쓰면 문제가 하나 있는데, 운영 체제를 플로피 디스크에 저장하기 때문에 뭔가 할 때마다 플로피디스크를 벅벅 소리내며 긁어 댄다는 점이다.[10] MS-DOS 6.0부터는 자체에서 멀티부팅을 지원하면서 Config.sys와 Autoexec.bat에 각각의 설정을 추가해 원하는 설정으로 부팅할 수 있게 되었다.[11]
근데 이렇게 고생을 해도, 결국 게임 하다가 다른 거 하려면 심한 경우 컴퓨터를 재부팅해야 한다는 건 변하지 않는다. 그나마 EMM386 등의 메모리 관리자를 안 올렸거나 EMS를 끈 경우를 제외하면 설정만 잘 해 놓으면 보통 재부팅까지는 가지 않을 수 있었다. MS-DOS가 단순한 운영 체제라 하드 디스크로 부팅하는 경우엔 금방 재부팅할 수 있긴 했지만 귀찮기 그지 없는 상황인 것은 사실이다. MS-DOS 6.0 이후에는 기본 메모리를 너무나 열심히 확보한 나머지 프로그램이 안 돌아가는 상황도 가끔 발생했는데, 이 경우는 LOADFIX를 이용해 기본 메모리의 첫 64 KiB 영역에 올라가지 못하도록 설정해야 했다.
이렇게 기본 메모리를 확보하고 관리하는 능력은 1990년대 중반까지 컴퓨터 초보자와 중급자를 가르는 기준이었으며 각종 PC 잡지의 단골 기사거리였다. 서점에는 10여 종 이상 관련 서적이 나오기도 했다. 그리고 집에서 게임이 안 돌아간다고 학교 친구에게 메모리 잡아 달라고 부탁하는 경우도 종종 있었다. 당시 동급생 같은 일본의 에로게를 즐기던 게이머들은 설명서를 보고 따라하다가 정신을 차리고 보니 메모리 관리의 고수가 되기도 했다.
이렇게 수많은 이들을 고통에 빠트리던 640 KiB의 벽은 1995년 Windows 95가 나오면서 서서히 사라지게 된다. Windows 2.0부터 이미 보호 모드를 사용하고 있어 Windows에서는 기본 메모리 문제가 없었지만 3.1까지는 DOS 위에서 돌아가는 GUI 셸에 가까웠고 보급률이 낮아 DOS를 주로 사용하는 일반 사용자는 이를 체감하지 못했다. 게다가 Windows 3.1까지는 DOS 수준의 그래픽 속도를 제공하는 API도 없었기 때문에 게임이 거의 대부분 DOS용이기도 했다.[12] Windows 95로 PC 운영 체제의 패러다임 자체가 이동하면서 일반 유저들도 기본 메모리를 신경쓰지 않아도 되는 시대가 열렸다. 그렇지만 Windows 95는 MS-DOS 7.0을 내장하고 있었으나 이는 어디까지나 '호환용'이라서 게임을 비롯한 MS-DOS 프로그램이 제대로 돌아가지 않았다. 오작동은 흔하고 좀 까다롭다 싶은 프로그램은 그냥 <이 버전에서 사용할 수 있는 프로그램이 아닙니다>라는 메시지만 내고 튕기는 일도 잦았다. 그래서 한동안 Windows 95와 MS-DOS 6.22로 멀티부팅을 하면서 이 고통에서 헤어나지 못하는 사람들이 많았다. 그러다가 시간이 흐르면서 MS-DOS 프로그램들도 본격적으로 Windows로 옮겨가고, 이 모든 고통의 원인(?)이었던 게임 역시 DirectX의 등장과 함께[13] 신작이 Windows용으로 줄줄이 나오면서 서서히 옛말이 되어 갔다. 당시의 몇몇 게임들( 워크래프트 2, 커맨드 앤 컨커 레드얼럿 등)은 MS-DOS/Windows 95용 실행 파일을 모두 제공하기도 했다. 그 뒤로 시간이 좀 더 흘러 NT 커널로 완전히 전환한 Windows XP가 나오면서 이 기본 메모리 문제는 완전히 사라지게 된다.
이제는 에뮬레이터로 MS-DOS 게임을 하려 들지 않는 이상엔 전혀 신경 쓰지 않아도 되는 문제였으나, 시간이 흐르면서 DOSBox 같은 에뮬레이터는 메모리를 알아서 잡아주기 때문에 기본 메모리 확보를 위한 피나는 투쟁은 호랑이 담배 먹던 시절의 무용담이 되었다. 하지만 그 시절 야겜 좀 해 보려다가 어느새 메모리 관리의 달인이 되었듯이, command.com, config.sys, autoexec.bat의 사용법이 몸에 배도록 강요당하면서 역시 자신들도 모르는 사이 프로그래밍 언어에 친숙해지게 되었다. 여기서 한 발 더 나가면 HEX 값을 직접 건드리는 에디터가 나오고, 더 나가면 베이식에서 시작되는 프로그래밍 언어 교육이 이어진다.[14]
2.3. 1 MiB의 벽과 A20 Line
이 부분은 하드웨어적 문제라기보단 8086과의 하위 호환성 때문에 생긴 구조이다. 8086/8088은 20비트의 주소선을 사용하여 1 MiB까지의 메모리에 접근할 수 있었다. 8086 문서에도 나와 있지만 8086은 주소를 표시할 때 16비트 레지스터 2개를 사용하여 세그먼트( 16비트):오프셋(16비트)의 형태로 표현한다. 그런데 주소를 16 MiB(24비트)까지 사용할 수 있는 80286이 나오면서, 이 세그먼트:오프셋 표기가 꼬이게 되어[15] 하위 호환성에 문제가 생겼다. 그래서 기존 8086과의 호환성을 유지하기 위해서 주소 부분의 21번째 비트(0부터 카운트하므로)인 A20 라인을 기본적으로 비활성화하고 1 MiB보다 위의 메모리에 접근할 때 활성화하는 A20 Gate라는 구조를 집어넣었다.[16] 이는 지금도 계속 이어져 오고 있으며, A20 Line을 활성화하지 않고 1 MiB를 넘어가면 실제와는 다른 엉뚱한 주소에 접근하는 것이 된다. 때문에 1 MiB 이상을 접근하고자 하는 운영 체제는 반드시 A20 Line을 활성화해야 한다. 지금은 BIOS에서 자동으로 활성화시켜 주기도 한다. 인텔은 네할렘부터는 A20 Line을 활성화하기 위한 물리적인 구조를 없애고 논리적인 명령으로만 처리하며, 하스웰부터는 A20 Line이 항상 활성화된 상태로 출시된다.메인보드에 따라 A20 Gate를 활성화하는 방법이 서로 다르다. BIOS 인터럽트를 호출하거나 시스템 제어 포트를 통하거나 또는 키보드 컨트롤러로 활성화하는 방법 등이 있다. 그러므로 A20 Gate 활성화 코드를 여러 개 만들어야 한다.
2.4. 4 GiB 문제
- 해당 운영 체제: 32비트 운영 체제. 설명은 주로 Windows 위주로 되어 있으나 다른 운영 체제에서도 대동소이한 문제가 있다.
16비트 시대와 마찬가지로 주소의 일부는 하드웨어 영역으로 할당되어 있고, 나머지에서 다시 커널 공간이 빠지기 때문에 사용자가 실제로 쓸 수 있는 양은 더 작다. 하드웨어 영역으로 할당된 메모리 주소 중 일부는 다른 장치와 통신하기 위해서 예약된 메모리 영역이며, 이를 Memory-mapped I/O (MMIO)라고 한다.[18] 여기에 더해 운영 체제의 종류에 따라 시스템 영역에 할당되는 용량도 개개 컴퓨터마다 다르다. 따라서 딱 얼마만큼 쓸 수 있다고 잘라 말할 수는 없지만 실제로는 대략 2~3.75 GiB 정도 쓸 수 있다고 보면 된다. 이러한 근본적인 제약은 모바일 장치도 마찬가지라서, 많은 안드로이드 제조사들이 2 GiB 메모리 다음 PC처럼 4 GiB로 가지 않고 3 GiB로 간 이유 중 하나도 ARM 프로세서가 32비트에 머물러 있어 4 GiB를 달아봤자 전부 쓸 수 없었던 것이었다.
이 문제를 해결하기 위해서 32비트 CPU가 상용화된 후 펜티엄 프로에서 PAE(Physical Address Extension/물리 주소 확장)이라는 개념이 도입돼서 최대 36비트 메모리 주소를 사용하여 64 GiB까지 사용할 수 있었다. 하지만 32비트 구조의 근본적인 문제는 이것으로 해결하지 못했기 때문에 64비트 아키텍처가 등장한 뒤에야 근본적인 문제가 해결되었다. 2010년부터는 대부분의 운영 체제와 CPU가 64비트를 이용하면서 이 문제에서 벗어났다.
2.4.1. 4 GiB 문제의 해결책
32비트 시대에도 4 GiB 문제를 예견하지 못한 건 아니라서 일찌감치 1996년에 펜티엄 프로에서 PAE(Physical Address Extension: 물리 주소 확장)라는 기술이 일종의 과도기적 대안으로 도입되었고, 이를 이용하면 주소에 36비트를 이용하여 총 64 GiB까지 이용할 수 있었다. 하지만 이것은 전체 메모리를 64 GiB까지 꽂아서 쓸 수 있다는 것이지 프로그램 내부에서 이용하는 가상 주소는 이전과 마찬가지로 32비트이므로 애플리케이션에서 할당할 수 있는 메모리 크기에는 변함이 없었다. 단, 여러 개의 물리 페이지를 할당해 놓고, 필요한 부분만 가상 주소에 매핑해서 사용하는 구조 특성상 최대 2 GiB까지만 사용할 수 있다는 것은 아니었다. 그러나 한 번에 매핑해서 사용할 수 있는 크기는 2 GiB로 제한되므로 매핑된 페이지를 교체하려면 작업이 번거로웠다. 여기까지 고려하고 만든다면 2 GiB의 한계를 극복하고 사용할 수 있었지만, 많은 수의 응용 프로그램들이 이를 고려하지 않고 만들어졌던 데다가 결정적으로 64비트가 도입되면서 더 이상 이런 복잡한 체계를 붙들고 있을 필요가 없어졌다.PAE가 아니더라도 32비트 시스템에서 4 GiB 공간을 넘어서 사용하는 또 다른 방법은 페이지 크기를 4 MiB로 하는 것이다. 이 방법은 PDE에 물리 주소 4비트를 추가로 지정하여 PAE처럼 물리 메모리를 64 GiB까지 사용할 수 있었다(단, 하드웨어가 지원한다면). 하지만 관리가 불편해서인지 현재는 거의 사장된 거나 다름없는 기법이다. 현재 대부분의 32비트 운영 체제들은 4 KiB 페이지를 사용하고 있다.
결국 근본적인 해결책은 64비트를 도입해 주소 자체를 늘리는 것으로, CPU 아키텍처와 운영 체제를 전부 64비트로 변경하면 된다. 4 GiB 문제가 점차 현실적으로 다가옴에 따라 PowerPC나 MIPS 같은 다른 아키텍처에서는 일찌감치 64비트로의 이전을 실시하고 있었으나 x86은 호환성의 문제로 이전이 늦어졌다가 AMD의 AMD64 아키텍처가 나오면서 64비트 시대가 열렸다. 인텔 역시 64비트 아키텍처인 IA-64를 일찌감치 만들어뒀지만 이쪽은 기존의 x86 호환성이 없는 것이나 마찬가지였다. AMD64 아키텍처에서는 메모리 주소를 최대 64비트까지 지정할 수 있도록 했지만, 64비트 주소의 용량인 16 EiB(18,446,744,073,709,551,615 바이트) 메모리를 단시일 내에는 사용할 수 없다고 판단해 최초에는 40비트까지만 사용할 수 있게 했다가 2000년대 후반에 48비트로 늘렸다. 이런 제약을 둔 이유는 여러 가지가 있지만 그 중 하나는 페이징 때문으로, 주소 지정을 하는 비트 수만큼 필요한 페이지 테이블의 용량이 함께 늘어나기 때문이다.[19] 이론적으로 페이지 테이블의 구조 상 최대 52비트까지 확장할 수 있으며 이때는 메모리를 최대 4 PiB(4096 TiB)까지 사용할 수 있지만, 48비트 주소만 사용해도 메모리를 최대 256 TiB까지 사용할 수 있다. 아직까지 CPU 하나당 최대 지원 메모리가 수백 GiB ~ 2 TiB 정도라 당분간은 충분할 듯하다. 실제로 52비트 주소체계는 AMD64 아키텍처가 나온지 20년이 지난 2020년대 초반에 가서야 겨우 등장하기 시작했다. AMD64 아키텍처는 이 주소 공간을 절반으로 나누어서 아래쪽 절반은 사용자 영역, 위쪽 절반은 커널 및 하드웨어 영역으로 사용한다. 그래서 64비트 리눅스는 사용자 공간으로 아래쪽 절반인 최대 8 EiB까지만 쓸 수 있다. 현재는 서버 쪽에서 메모리 용량이 빠르게 증가하면서 48비트로는 부족해질 예정이라, 인텔에서는 5-level paging 등 57비트까지 확장하는 것도 내놓은 상태이다.
어쨌거나 4 GiB를 넘는 메모리를 사용하려면 하드웨어와 운영 체제가 모두 64비트를 지원해야 한다. 컴퓨터 부품은 싫어도 CPU와 아키텍처를 맞춰야 하므로 하드웨어 쪽은 일찌감치 64비트로 갈아탔다. AMD는 2003년( 애슬론 64/옵테론), 인텔은 2004년(펜티엄4 프레스캇 - 초기 모델은 제외)부터 64비트 지원 프로세서가 나오기 시작했다. 사실 소프트웨어 쪽이 대응이 늦어 이런 장벽이 만들어졌다. 특히 클라이언트용 Windows는 2010년대 초반까지만 해도 32비트가 여전히 많이 쓰였다.
Microsoft Windows의 클라이언트 버전은 AMD64의 등장에 발맞추어 Windows XP x64 에디션을 내놓았지만 인지도는 매우 낮았고, 호환성 문제 등으로 사용하기 불편한 점[20]이 있었다. Windows Vista부터 64비트 버전을 동봉해 놓았으나, DSP 버전은 비트별로 나누어져 있다(다만 라이선스는 서로 호환된다). 응용 프로그램의 메모리 요구량은 갈수록 높아지기만 하니 32비트 운영 체제는 몇 년 내로 자취를 감추게 될 것이다. 실제로 서버용 Windows는 Server 2008 이후 즉, 좀 더 정확하게는 Server 2008 R2 부터 32비트 버전을 일절 출시하지 않고 있다. Red Hat의 RHEL도 Version 7부터는 64비트 버전만 나온다.
일반 사용자의 64비트 Windows 사용은 2010년대 중반부터 본격적으로 시작되었는데, 이 무렵부터 8 GiB를 탑재하는 PC가 일반화되었기 때문이다. 32비트 Windows로는 죽었다 깨어나도 8 GiB 메모리를 모두 사용하는 건 불가능했으므로 64비트로 넘어갈 수 밖에 없었던 것이다. 다행히 64비트 Windows의 32비트 호환 모드( WOW64)의 호환성이 완벽에 가까울 정도로 좋았기 때문에 큰 어려움 없이 넘어갈 수 있었다.
Windows 10은 32비트 버전과 64비트 버전이 같이 출시되었는데, 2020년 4월에 배포된 20H1 버전부터 OEM 용으로 32비트 제품군의 출하가 중단된다. 단, 일반 사용자용의 판매 및 지원은 2025년 10월까지 계속된다. #
2021년 6월 24일 Windows 11이 공개되었고, 최소 요구 사양이 물리적인 듀얼코어 이상의 64비트 프로세서로 제한되는 데다, 32비트 버전의 미출시가 확정됨에 따라 Windows 10의 사후 지원이 종료되어 완전히 단종되고 Windows 11이 주요 운영 체제로 거듭나게 되는 2025년 후반에는 64비트로의 이주가 완전하게 끝나게 될 것이다.
CPU가 64비트 아키텍처라고 하더라도 칩셋 등 다른 하드웨어 때문에 제한이 걸리기도 한다. 예를 들어 인텔 945 및 965 칩셋 시리즈는 칩셋이 4 GiB의 메모리 주소만 처리할 수 있기 때문에 64비트라고 하더라도 4 GiB의 메모리를 모두 사용하지 못한다. 물론 이 하드웨어가 나왔을 당시의 스펙에 맞추어서 세팅이 된 것이라 이런 경우는 해당 하드웨어가 현역일 당시에는 문제가 되지 않았던 것이 대부분. 이 외에도 32비트 시스템과 호환성을 위해서 하드웨어 영역은 지금도 4 GiB 아래에 위치하는 경우가 대부분이다. 물론 운영 체제가 똑똑하다면 하드웨어용으로 예약된 메모리 주소를 우회해서 실제 장착된 RAM에 매핑해 준다.
2.5. 16 EiB 문제
- 해당 운영 체제: 64비트 Windows를 비롯한 대부분의 64비트 운영 체제
3. 소프트웨어상의 제한으로 인해 생기는 문제
3.1. Windows 3.1의 256 MiB 문제
Windows 3.1은 256 MiB까지의 램만 인식할 수 있으며, 288 MiB 이상이면 페이지 오버 문제가 발생하여 부팅이 되지 않는다.하지만 당시 쓰이던 MS-DOS에서는 최대 64 MiB까지만 인식했고[21] 1995년 Windows 95 발매 이후 거의 쓰이지 않았는데 512 MiB 램이 대세가 된 것은 그보다 한참 뒤라(즉 Windows 3.1이 일반 사용자 시장에서 자취를 감춘 지 오래라) 거의 문제가 되지 않았다.
3.2. Windows 95의 480 MiB 문제
32비트 운영 체제임에도 480 MiB를 초과하는 메모리를 쓸 수 없게 되어 있으며, 이를 초과하는 메모리를 장착했을 경우 메모리 부족이라는 오류를 내뱉는다.이 문제에 대처하려면 시스템 파일 설정을 건드려서 운영 체제가 인식하는 메모리를 512 MiB로 제한해야만 한다. 아래 문서를 참고하자.
이 문제는 다른 메모리 문제와 달리 아키텍처와는 무관하며 일종의 운영 체제 설계상의 한계로 인한 오류이다. 위의 문서에도 나와있지만 Windows 9x의 32비트 보호 모드 캐시(Vcache)의 크기는 메모리의 크기에 따라서 자동으로 최대 캐시 크기와 메모리 주소를 설정하는데, 메모리가 480 MiB가 넘어가면 최대 캐시 크기가 지나치게 커짐과 동시에 가상 메모리 주소가 전부 소진되어버려서 생기는 현상이다. 운영 체제 구조 자체가 전혀 다른 Windows NT 계열에는 이런 문제가 없다.
Windows 9x가 현역이던 시절엔 램값이 컴퓨터 부품 중 제일 비쌌기 때문에 이런 설계라고 해도 480 MiB를 초과하는 메모리를 장착할 사람이 없어 전혀 문제가 없었다. 128 MiB는커녕 64 MiB만 돼도 램 많다는 소리를 들을 수 있었다. Windows 9x는 가정용이다. 서버나 워크스테이션 같은 전문 영역에서 Windows를 쓸 경우에는 NT를 사용했고 NT는 저런 문제가 없다. 또한 1995년의 가정용 PC는 16 MiB가 대세였고, 1998년은 32 MiB, 2000년은 64 MiB, 2001년은 128 MiB, 2002년에서야 256 MiB로 갈아탔다. 이미 일부 파워유저가 480 MiB나 그 이상의 메모리를 장착하기 시작했지만 그 정도의 골수 파워유저들은 저러한 문제를 이미 충분히 인지하고 있었고 안정성 문제도 있어 NT 커널인 Windows 2000으로 넘어가는 게 일반적이었기 때문에 역시 문제가 되지 않았다. 480 MiB 이상 메모리가 대중화됐을 때는 2003년 이후로, 이미 대세가 Windows XP로 넘어간 후였으므로 결과적으로 이 480 MiB 문제는 거의 문제가 되지 않은 이슈이며 한참 지나 램 업체간의 치킨 게임이 벌어지고 나서야 일반에게 인지된 문제였다.
Windows 95 출시 당시의 사용자가 이 문제를 접했던 관점은 2018년에 RAM 4 GiB 달아서 쓰는 가정용 사용자가 '256 GiB 이상 램을 장착하면 오류나서 꺼진다'[22] 라는 소리를 듣는 것과 동일한 기분이다. 그러니 당연히 당시에 전혀 문제삼지 않을 법하다.
현재는 9x가 시장 수명이 다한 지 오래되었으므로 별 의미는 없는 문제이지만, 고전게임 구동을 위해서 VMware 같은 가상 머신이나 실 기기에 9x를 올려 사용하는 경우가 있으므로 하드웨어 설정을 할 때 이 점을 미리 염두에 두는 것이 좋다. 윈도우 9x 시스템은 RAM이 128 MiB만 돼도 매우 쾌적해지므로 무리해서 구성을 할 필요는 없다.
3.3. Windows 98 이후의 Windows 9x 운영 체제의 1 GiB 문제
서버/워크스테이션 판매 회사들이 Windows 98을 설치해 판매하기 위해 마이크로소프트에 요청했고, 마이크로소프트는 커널을 개선해 1 GiB까지 쓸 수 있도록 개선했다. 이를 초과하는 메모리를 장착했을 경우 계속 재부팅이 된다.마찬가지 방법으로 시스템 파일 설정을 손 대서 운영 체제가 인식하는 메모리를 1 GiB로 제한해야만 한다.
3.4. 32비트 Windows에서의 PAE 제한
- 해당 운영 체제: 32비트 Windows NT 계열 중 일부 서버 버전을 제외한 대부분의 버전.
그나마 일반 사용자용 Windows에서도 제한적인 PAE 지원 덕분에 낭비되는 메모리를 램디스크로 활용할 수는 있으며, 프로세스의 메모리 영역 보호에도 PAE의 기능을 적용하고 있다. 하지만 4 GiB 이상 영역을 램디스크에서 끌어다 쓰는 것도 문제가 있어서, 다 끌어다 쓰면 블루스크린이나 프리징 등 문제가 생기는 경우가 많아서 일정 용량은 남기고 안 쓰는 설정이 되어 있는 경우가 대부분이다. 보통 최소 8 MiB 정도는 남겨 놓으며, 프로그램에 따라 설정 방법 및 기본값이 조금씩 다르다.
Windows XP x64 Edition는 완성도가 부족하다는 의견이 많았으며, 이어 나온 Windows Vista도 다양한 문제점으로 사용자들의 지지를 얻지 못했다. 그래서 4 GiB 이상의 메모리를 장착한 컴퓨터가 어느 정도 일반 사용자의 가시권 안에 들어온 이후에도 4 GiB 문제는 사용자들에게 현실적인 문제점이었고, 그나마 해결책이라고 할 수 있는 PAE도 Microsoft의 정책으로 막혔기 때문에 제한에 불만을 품은 사람들이 관련 시스템 파일만 서버에서 가져오는 식으로 클라이언트용 Windows에서도 64 GiB PAE를 쓸 수 있게 하는 개조가 여럿 나왔다.
예를 들면 이런 거. 물론 저런 임의 개조에 따른 모든 결과(어떠한 문제가 발생하든 간에)는 자기 책임이므로 주의할 것. Windows 7이 시장에서 대호평을 받고 사용자들이 대거 64비트로 옮겨탄 이후에는 큰 의미가 없어졌다.
3.5. 32비트 Windows에서의 2 GiB 할당 제한
- 해당 운영 체제: Windows XP를 포함한 32비트 Windows NT 계열 운영 체제
이 제약은 Windows NT를 설계했을 당시부터 있던 구조상의 한계라서 64비트 Windows에서 32비트 애플리케이션을 동작할 때도 똑같이 적용된다. 64비트 애플리케이션을 동작할 때는 이런 제약이 없다. 이 때문에 하드웨어-운영 체제-애플리케이션이 모두 64비트여야 진짜 64비트 기능을 이용할 수 있다는 이야기가 나오는 것.
설정을 건드려서 커널 영역의 크기를 변경하면 32비트 Windows 기준 3 GiB까지[23], 64비트 Windows 기준 4 GiB까지 사용할 수 있기는 하며 이를 Large Address Aware(LAA)라고 한다. 이론상 3 GiB까지 쓸 수 있지만, 기본적으로 사용할 수 있는 것이 아니라 1차적으로 Windows 설정을 건드려 LAA를 활성화해야 하며, LAA가 활성 상태이더라도 애플리케이션이 LAA를 지원해야 하는 문제가 있다. LAA 지원이 기본적으로 비활성화된 이유 중에는 포인터 처리 문제가 있다. 32비트 포인터의 최상위 비트가 1이면 하드웨어 및 커널 주소라서 프로그램에서는 사용할 수 없다. 따라서 대부분 프로그램에서는 포인터 연산 결과 최상위 비트가 1이 되면 오류가 있는 것으로 취급했고, 일부 프로그램[24]에서는 이 값을 특수한 용도로 사용했다. 그런데 LAA 지원 환경에서는 실제 할당된 메모리 주소가 최상위 비트 1이 될 수 있으므로 이 가정이 모두 깨진다. 64비트 Windows에서는 기본적으로 32비트 애플리케이션을 구동할 때 LAA가 활성화된 상태로 구동되므로 애플리케이션이 LAA를 지원하기만 하면 4 GiB를 다 끌어다 쓸 수가 있다. 커널 영역은 64비트 영역의 Higher Half로 이사 갔기 때문에 호환성 문제도 없다. 다만 실제로는 여기저기서 끌어다 쓰는 게 많은지 2.1~2.5 GiB 정도밖에 할당 못 하는 듯, LTSB에서 시작메뉴와 작업 관리자도 안 뜰 정도로 모든 프로세스와 서비스를 최대한 종료해도 329XMB 정도인 듯하다. # (다만 구체적인 수치는 하드웨어와 소프트웨어 구성에 따라 달라질 수 있다.)
구체적으로 LAA Flag를 강제로 고쳐주는 프로그램은 Large Address Aware.exe란 프로그램이 훨씬 편리해서 이쪽이 대세이다. 또한 치팅 방지 보호가 되어있는 게임은 유저의 임의 해킹(실행 파일 변조)로 걸려서 이용제한시간을 먹거나 밴을 먹을 수도 있으니 조심할 것. 싱글플레이만 있는데도 이게 문제가 되는 대표적인 사례가 베데스다의 폴아웃 3와 옵시디언 엔터테인먼트의 폴아웃: 뉴 베가스[25]. 아무래도 Steam DRM에 걸리는 것 같다. 그래서 전용 로더를 통해 우회하는 프로그램이 나왔다. 폴아웃3용, 뉴 베가스용
LAA 활성화 예외에는 네이버에서 검색을 하면 32비트에서도 메모리 4 GiB를 사용할 수 있게 하는 법들이 보인다. 그걸로 해결해보자.[26]
3.6. 64비트 Windows의 메모리 제한
- DDR2, DDR3 메모리만 해당
2017년에는 일반 사용자 대상으로 DDR4 32 GiB 모듈이 나왔다. 실험실 단계에서는 256 GiB 모듈까지 있다. 어쨌든 저 메모리로 인텔 X99 칩셋 메인보드에 8슬롯 풀뱅크 하면 256 GiB를 쓸 수 있긴 하지만 대다수의 가정용 운영 체제에서 128 GiB 사용제한에 걸린다. Windows 8.1 혹은 10의 Pro 버전을 사용하면 된다. CPU에 내장된 메모리 컨트롤러가 지원해야 쓸 수 있는데, X99에 사용할 수 있는 일반 유저용 Core i 시리즈 계열 CPU인 하스웰-E는 최대 64 GiB, 브로드웰-E는 128 GiB까지만 지원하므로 이렇게 꽂아봐야 부팅도 안 될 것이다. 굳이 128 GiB를 넘는 용량을 쓰고 싶으면 Xeon 계열을 사용해야 한다. 그런데 브로드웰-E로도 128 GiB의 램 용량을 넘어 144 GiB 램 용량을 사용할 수 있음을 확인한 사람이 있다! 단순 표기상 오류도 아니고 143 GiB까지 램 사용량이 채워짐 또한 인증했다. 256 GiB까지 인식되나 계속 순차적 램 업그레이드를 할 모양.
물론 이러한 제한은 기술적인 문제가 아닌 운영 체제 운영의 편의, 자원 활용의 효율성 등의 문제 때문에 Microsoft가 일부러 걸어둔 제한으로, 대용량의 메모리가 일반화되어 제한치에 가까워질 때마다 Microsoft에서 그 제약을 풀어주는 조치를 취할 것이므로 피부에 와닿을 만한 문제는 아니다. 진짜로 64비트로 동작하면 1억 기가바이트(10 EiB)가 넘는 용량이 되는데, 기껏해야 GiB, 1천 GiB(TiB) 단위인 현존 가용 용량으로는 엄청난 공간 낭비가 발생하므로[28] 하드웨어 아키텍처만 64비트이고 실사용은 48비트 같은 식으로 제한해두는 것이다. 물론 64비트라는 '틀'을 만들어놓고 그 안에서 제한된 비트만 쓰게끔 만들어놓은 것이라 메모리가 커질수록 제한을 풀어 최종적으론 진짜 64비트까지 도달할 수 있다. 어쨌거나 64비트 아키텍처가 가지는 물리적인 제약은 16 EiB이니 이렇게 반복하면 언젠가는 16 EiB를 모두 사용할 수 있게 될 것이다. 이건 아주 초기 세대 하드웨어도 마찬가지라서 처음에는 40비트 정도만 사용하다가 세대가 올라가면서 조금씩 풀고 있다. 반면 Windows에서의 제한은 소프트웨어로 한 것이므로 불가피한 상황이 생긴다면 패치로 제한을 풀 수도 있다. 당장 Windows 10부터가 Windows 7보다 메모리 상한이 크게 늘어난 것도 예시가 될 수 있다. 결국 상위 에디션의 고급 기능을 원하는 사용자는 더 많은 컴퓨팅 파워가 필요하며 그렇지 않은 일반 사용자는 오버스펙의 대비가 오히려 성능의 비효율을 가져오므로 컴퓨터 사용 목적에 맞게 비효율적인 부분을 잘 조절하라는 의도로 만들어진 셈이다.
3.7. VRAM 4 GiB 제한
- Windows 8 이후와 Windows 10 1709 미만의 운영 체제와 DirectX 9 기반 32비트 응용 소프트웨어
VRAM이 4 GiB를 초과하는 그래픽 카드가 나오면서 문제가 발견되었다. VRAM 6 GiB였던 라데온 HD 7970 6 GB, HD 7990, 지포스 GTX TITAN, GTX 780 6 GB부터 나타나기 시작했으며, 이보다 더 많은 대용량 VRAM이 탑재된 다른 그래픽 카드들도 마찬가지로 주의해야 될 문제이다.
이 문제는 5년이나 지난 Windows 10 버전 1709(레드스톤 3)부터 해결되었다.
4. 전망
미래에 RAM 주소할당문제에 부딪히는 시기는 무어의 법칙이 어떻게 될지에 따라 달라진다.먼저 컴퓨터 부품의 발전속도가 느려지고 무어의 법칙이 깨진다면 이런 문제에 늦게 부딪힌다.
반면 18개월이 지날 때마다 2배를 훨씬 초과한 속도로 일종의 변곡점에 해당하는 극단적인 상승세로 튀어오를 경우 예측값보다 더 빨리 부딪히게 된다. 상온 초전도체, 양자컴퓨터 기술이 영향을 미친다.
양자기술을 이용하면 1비트당 1개의 정보를 처리하던 게 전자의 양쪽 스핀 모두를 공존하게 할 수 있으므로 1비트당 2개의 정보를 처리할 수 있게 되고, 2비트는 4개의 정보. 4비트는 16개의 정보를 처리할 수 있게 된다. 하드디스크 같은 곳에 적용한다면, 1 TiB 하드디스크에 양자기술이 적용되면 단순무식 산수로는 1 TiB(제조업체 측 표기방식대로 10진법 표기일 경우 1012)를 제곱한 1024 = 1 YB가 된다 (백만 ZB = 1조 TiB = 1000조 GiB)
물론 이 수치는 이론적 최대치이고 양자기술이 적용된 초창기 저장장치는 저 정도는 아닐 것이다. 하지만 최소 수백 PiB에서 수 EiB가 될 것은 자명하다. 이런 식으로 만들면 지금의 집적률으로는 양자기술로 제곱 뻥튀기를 한다 한들 어마무시한 크기와 발열과 전력소모를 자랑할 것이다. 하지만 상온초전도체가 나오면 전기저항이 사실상 0으로 수렴하게 되어 저항이 없으니 열도 거의 안 날 것이다.
또한 현재 반도체의 전력 소모 중 상당부분은 전기 저항으로 인한 것이지만 손실률이 0에 수렴하고, 꽂아넣은 전기 에너지를 100% 사용할 수 있다면 이 문제가 해결될 것이다. 어쩌면 지금 성능 정도의 가정용 CPU는 상온 초전도체 기술을 끌어오면 최소한 절반 미만, 어쩌면 밀리와트 단위의 전력 소모로 동작할 수도 있다.
[1]
흔히 말하는 x비트 CPU 는 주소 버스가 아니라 데이터 버스의 크기(범용 레지스터의 크기와 대부분 동일)를 의미한다. 6502, Z80 등의 8비트 CPU들은 주소 버스는
16비트이다. 주소 버스가 8비트라면 주소 지정을 256바이트밖에 못하기 때문에 한계가 너무 많다.
[2]
그것도 그래픽 영역 및 DOS와 나눠 쓴다. 그래픽 영역으로 8K x 2, DOS 영역으로 12K가 빠진다. 따라서 게임 프로그램 같으면 아예 자체적인 부팅 프로세스를 지녀서 DOS를 사용하지 않는데, 그래도 게임이니 만큼 그래픽 영역 8K 한개는 안 쓸 수 없다.
[3]
일본은 거의 대부분의 8비트 PC가 Z80을 채용하고 있었지만 파편화는 미국보다 몇 배 더 심각했다.
[4]
근본적 원인은 아니다. 프로그램 메모리 영역이 어디냐의 문제는 부차적인 것이기 때문.
[5]
그렇기 때문에 설령 하드웨어 영역을 최소화한다고 해도 둘이 합해서 1 MiB라는 것 자체는 변하지 않아서 640KiB에 비해 고작 20~30% 정도 늘어날 뿐이다.
[6]
1993년에 나온 리메이크 버전 한정. 1989년에 나온 초기판은 기본 메모리로도 잘 돌아간다.
[7]
위의 영상에서 예시로 든 게임은
라이즈 오브 더 트라이어드.
[8]
한국 게임인
일루전 블레이즈는 EMS가 모자라면 기본 4개 스테이지가 자동으로 스킵되어 후반 스테이지로 넘어가는 문제가 있었다.
[9]
그 유명한
듀크 뉴켐 3D 또한 이렇다. 아니, 1990년대 중반 이후 발매된 좀 유명한 MS-DOS용 게임들은 대부분 이렇다고 보면 된다.
[10]
COMMAND.COM의 위치를 지정해 주는 SHELL을 통해 기본 셸의 위치를 하드 디스크로 설정해 놓았으면 부팅할 때 빼고는 플로피 디스크를 읽어댈 일이 없다. 물론 버전이 일치해야 한다.
[11]
이러한 이유로 그 당시
OS/2에서 사용하는 부트 매니저를 설치하는 예도 많았다. 아예 서로 다른 파티션에 서로 다른 OS를 설치하도록 만든 물건이니 OS/2를 사용하지 않더라도 복수의 파티션에 게임에 최적화된 세팅값의 MS-DOS와 Windows 95를 별도로 설치하는 것. 90년대 중반에는 여러 가지 이유로 비 MS 운영체계가 컴퓨터 잡지 등에서 크게 다뤄졌을 시대라서 OS/2에 대한 접근성이 좋았다.
[12]
몇몇 게임은 Windows 3.1용으로 나오기는 했는데, 거의 대부분이 빠른 그래픽 속도가 필요 없는 장르에서 나왔다.
문명 2의 최초 버전이 Windows 3.1용이었던 것도 빠른 그래픽 처리가 필요 없는 턴제 전략 시뮬레이션 장르였기 때문이다.
[13]
Windows 95보다 한 발짝 늦게 나왔기 때문에 본격적으로 게임이 Windows용으로 나오기까지는 시간차가 좀 있었다.
[14]
그러나 DOSBox를 쓴다고 해서 저 3대장에서 자유로울 수는 없다. DOSBox는 메모리만 해결해 줄 뿐, 자신이 쓸 환경은 자신이 직접 짜야 하기 때문이다. 결국 그때로 되돌아가는 수밖에 없다.
[15]
상세한 것은
이 포스팅을 참조하기 바란다.
[16]
오해하기 쉬운데, 이 A20 Gate 구조는 IBM이 IBM PC AT에 넣은 것이다. 즉 80286 CPU와는 관계가 전혀 없으며 실제로 80286 데이터시트를 보면 A20 Gate라는 용어는 어디에도 등장하지 않는다.(IBM PC AT Technical Reference 같은 문서에나 나온다) 즉 메인보드에 회로를 넣어서 구현한 것이지 CPU 자체에 내장된 기능 같은 게 아니다. 실제로 80286을 쓰는 비 IBM PC 계열 컴퓨터 중에서는 이런 구조가 없는 컴퓨터도 있다.(반대로
PC-9801처럼 IBM PC 가 아니면서도 A20 Gate 와 비슷한 기능을 넣어서 설계한 컴퓨터도 있다)
[17]
64비트는 264 바이트 = 16 × 260 바이트 = 16 EiB이다. 하드디스크도 커 봐야 수십 TiB인 현상황에서는 거의 무한한 수 같지만, 언젠간 저 용량도 부족할 것이다.
[18]
장치의 메모리가 1:1로 MMIO에 매칭될 수도 있지만 아닐 수도 있다. 그래서 장치 메모리가 크다고 항상 주소크기가 커지진 않는다.
[19]
그 외에는 어차피 거의 쓰지도 않을 주소 때문에 CPU 어드레스 핀을 늘려서 회로를 더 복잡하게 만들고 트랜지스터만 낭비된다는 이유 등이 있다. 뭐든 결론은 안 쓸 주소 때문에 여러 가지가 낭비돼서이다. 사실 원래 옛날부터 CPU의 레지스터 크기와 주소지정 크기가 일치하지 않는 경우는 많았다. 애초에 8비트 CPU 시절에는 지정할 수 있는 주소 영역이 너무 작아서(256바이트) 거의 모든 8비트 CPU는 16비트 주소로 지정할 수 있었으며, 이것도 부족해서 뱅크 스위치 컨트롤러를 쓰곤 했다. 16비트 CPU에서도 당장
인텔 8086만 봐도 20비트 주소를 지정할 수 있었다. 물론 보다시피 보통은 레지스터 크기보다 주소 지정 영역이 더 큰 경우였지 더 작은 경우는 없었기는 하다.
[20]
Windows Server 2003 기반이라 호환되지 않는 프로그램이 많았으며, 영문판과 일본어판만 발매돼서 한글은 언어팩으로 해결해야 했다.
[21]
DOSBox SVN 빌드와 같은 몇몇 에뮬레이터만 그 이상을 지원한다.
[22]
Windows 8.1/10의 Home버전이 최대 장착할 수 있는 용량은 128GiB이다. 실제로 이 이상 꽂아도 128 GiB로만 인식할 뿐 아무런 이상은 없다.
[23]
바이오스에서 Memory Remapping를 활성화 시켜야 인식할 수 있다. 간혹 3.5 GiB까지 인식할 수도 있다.
[24]
장치 제어, 기능 관리 프로그램 등.
[25]
폴아웃 4부터는 64비트라서 이런 문제가 없다.
[26]
ReadyFor4GB라는 프로그램을 사용하면 된다. 이 프로그램은 4 GiB 이상의 메모리를 32비트에서 사용할 수 있게 만드는 것으로 128 GiB까지 사용할 수 있다.
[출처]
http://blogs.technet.com/b/sankim/archive/2009/11/04/windows-7-w2k8-server-r2-version-6-1-32bit-64bit.aspx
[28]
공간이 실재하지 않지만, 메모리 집약 작업에서 매번 64비트의 주소 공간을 다 써야하게 만들면 성능 저하가 발생한다. 이해하기 쉽게 비유하면 향후 휴대폰 사용자가 늘어날 때를 대비한다고 지금부터 전화번호를 010-21345-67890 이런 체계로 만들어 사용한다면 매번 전화번호 외우고 누르고 명함 등에 인쇄하고 하는데 불필요한 낭비가 초래되는 것과 같다. 향후 정말 그만큼의 번호체계가 필요할 때가 생기면 그때 바꾸면 된다.