도스 메모리 관리(DOS Memory Management)는 마이크로소프트 도스(MS-DOS)를 비롯한 도스 계열 운영체제에서 프로그램에 메모리를 할당하고 사용하는 방식과 이를 최적화하기 위한 기술들을 통칭한다. 16비트 아키텍처와 리얼 모드(Real Mode)의 한계로 인해, 도스 환경의 메모리 관리는 매우 복잡하고 최적화가 중요했다. 특히 640킬로바이트(KB) 장벽으로 알려진 문제는 도스 시스템의 가장 큰 제약 사항 중 하나였다.
메모리 영역 구분
도스 시스템은 물리적인 메모리를 여러 논리적인 영역으로 나누어 관리했다.
- 컨벤셔널 메모리 (Conventional Memory): 0KB부터 640KB까지의 영역으로, 도스 시스템 및 대부분의 도스 프로그램이 실행되는 데 필수적인 공간이었다. 이 공간이 고갈되면 프로그램 실행이 불가능해졌다. 640KB라는 제한은 IBM PC의 초기 설계에서 비롯된 것으로, 1MB 주소 공간 중 하위 640KB를 사용자 프로그램 영역으로, 상위 384KB를 하드웨어(비디오, BIOS 등) 예약 영역으로 할당했기 때문이었다.
- 어퍼 메모리 (Upper Memory, UMA): 640KB부터 1024KB(1MB)까지의 영역으로, 비디오 메모리, BIOS, 네트워크 카드 ROM 등 하드웨어 예약 공간으로 주로 사용되었다. 하지만 일부 사용되지 않는 영역(UMBs: Upper Memory Blocks)은 메모리 관리 프로그램을 통해 활용될 수 있었다.
- 확장 메모리 (Extended Memory, XMS): 1MB 이상의 메모리 영역을 지칭한다. 도스 리얼 모드에서는 직접 접근할 수 없었으나, HIMEM.SYS와 같은 확장 메모리 관리자(XMS manager)를 통해 DPMI(DOS Protected Mode Interface)를 지원하는 프로그램들이 활용할 수 있었다. 이 공간은 가상 디스크(RAM disk)나 디스크 캐시(Disk cache) 등으로도 사용되었다. 1MB 바로 위의 64KB 영역은 HMA(High Memory Area)라고 불리며, 도스 자체를 이 영역에 로드하여 컨벤셔널 메모리를 절약하는 데 사용되었다.
- 익스팬디드 메모리 (Expanded Memory, EMS): 인텔 8088/80286 프로세서 시절 1MB 이상의 메모리를 활용하기 위해 개발된 기술이다. 특수 메모리 보드와 EMS 관리자(예: EMM.SYS)를 필요로 했으며, 어퍼 메모리 영역에 64KB의 페이지 프레임(page frame)을 만들고, 이 프레임을 통해 뱅크 스위칭(bank switching) 방식으로 1MB 이상의 메모리에 접근했다. 주로 로터스 1-2-3와 같은 대용량 데이터를 다루는 스프레드시트 프로그램에서 사용되었다. 386 이상의 프로세서에서는 EMM386.EXE를 통해 확장 메모리의 일부를 익스팬디드 메모리처럼 에뮬레이션할 수 있게 되었다.
메모리 관리 도구 및 기술
도스 환경에서 메모리 효율성을 높이기 위해 다양한 도구와 기술이 사용되었다.
- HIMEM.SYS: 확장 메모리 관리자(XMS Manager)로, 1MB 이상의 확장 메모리를 표준화된 방식으로 사용할 수 있도록 했다. CONFIG.SYS 파일에
DEVICE=C:\DOS\HIMEM.SYS와 같이 로드되었다. - EMM386.EXE: 익스팬디드 메모리 에뮬레이터이자 어퍼 메모리 블록(UMB) 관리자였다. 386 이상의 프로세서에서 작동하며, 확장 메모리의 일부를 익스팬디드 메모리처럼 사용하거나, 어퍼 메모리 영역을 UMB로 할당하여 도스 드라이버나 상주 프로그램(TSR)을 그곳에 로드할 수 있게 해주었다. CONFIG.SYS에
DEVICE=C:\DOS\EMM386.EXE RAM과 같이 로드되었다. - DOS=HIGH,UMB: CONFIG.SYS에 설정되는 명령어로, 도스 자체를 HIMEM.SYS가 관리하는 HMA(High Memory Area)에 로드하고, EMM386.EXE가 생성한 UMB를 활성화하여 활용할 수 있게 했다. 이를 통해 컨벤셔널 메모리에서 도스 커널이 차지하는 공간을 최소화할 수 있었다.
- LOADHIGH (LH) / DEVICEHIGH: AUTOEXEC.BAT 파일에서 프로그램 실행 시(LOADHIGH 또는 LH) 또는 CONFIG.SYS 파일에서 드라이버 로드 시(DEVICEHIGH) 사용되는 명령어로, 해당 프로그램이나 드라이버를 어퍼 메모리 블록(UMB)에 로드하여 컨벤셔널 메모리를 절약할 수 있게 해주었다.
- CONFIG.SYS 및 AUTOEXEC.BAT의 역할: 도스 메모리 관리는 이 두 파일의 설정에 크게 의존했다. 메모리 관리 드라이버 로드 순서, 각 드라이버나 프로그램의 로드 위치 설정 등이 이 파일들을 통해 이루어졌으며, 최적의 설정을 찾는 것이 도스 시스템 성능에 결정적인 영향을 미쳤다.
- 서드파티 메모리 관리 프로그램: QEMM, 386MAX와 같은 서드파티 프로그램들은 도스 기본 유틸리티보다 더 효율적이고 유연하게 메모리를 관리하고 최적화할 수 있도록 지원했다. 이들은 시스템을 분석하여 사용 가능한 모든 UMB를 찾아내고, 드라이버와 TSR 프로그램을 최적으로 배치하는 기능을 제공했다.
제약 및 문제점
- 640KB 장벽: 컨벤셔널 메모리의 한계로, 아무리 많은 RAM이 설치되어 있어도 대부분의 도스 프로그램은 기본적으로 640KB 이상의 메모리를 직접 사용할 수 없었다. 이는 특히 대용량 프로그램을 실행하거나 여러 프로그램을 동시에 로드할 때 큰 제약으로 작용했다.
- 단편화 (Fragmentation): 프로그램들이 메모리에 로드되고 해제되는 과정에서, 사용 가능한 메모리 공간이 여러 조각으로 나뉘어 실제로 사용할 수 있는 총량은 충분해도 연속적인 큰 블록이 없어 프로그램 실행이 불가능해지는 현상이다.
- 복잡성: 각기 다른 메모리 유형, 관리자, 설정 명령어들로 인해 사용자가 최적의 메모리 구성을 만드는 것이 매우 복잡하고 어려웠다. 잘못된 설정은 시스템 충돌이나 성능 저하로 이어지기도 했다.
의의 및 영향
도스 메모리 관리는 윈도우 3.x와 같은 그래픽 사용자 인터페이스(GUI) 환경이 등장하기 전까지, 제한된 자원 속에서 최대한의 성능을 끌어내기 위한 필수적인 기술이었다. 이러한 노력은 이후 운영체제의 발전과 메모리 관리 기술의 진화에 중요한 토대가 되었으며, 가상 메모리, 보호 모드 등의 개념이 도입되는 데 영향을 미쳤다. 도스 메모리 관리의 복잡성은 현대 운영체제가 사용자에게 메모리 관리의 세부 사항을 숨기고 자동으로 처리하는 방식이 얼마나 큰 발전인지를 보여주는 대표적인 사례이다.
같이 보기
- MS-DOS
- CONFIG.SYS
- AUTOEXEC.BAT
- HIMEM.SYS
- EMM386.EXE
- 640KB 장벽
- 리얼 모드
- 보호 모드