맨위로가기

종료 후 상주 프로그램

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

종료 후 상주 프로그램(TSR)은 MS-DOS 환경에서 프로그램 종료 후에도 메모리에 남아 백그라운드에서 실행되는 방식을 의미한다. TSR은 시스템 콜을 사용하여 구현되었으며, 인터럽트 벡터를 수정하여 다른 프로그램의 호출이나 하드웨어 이벤트에 반응하도록 설계되었다. TSR은 컴퓨터 바이러스의 은신처로 악용되거나, 메모리 부족, 시스템 불안정성, 호환성 문제 등을 야기하기도 했다. 1980년대 후반 확장 메모리 기술이 등장하면서 TSR을 위한 메모리 관리자가 개발되었지만, 윈도우 운영체제의 보급과 DOS 확장자의 등장으로 TSR의 필요성이 줄어들면서 쇠퇴했다.

더 읽어볼만한 페이지

  • 도스 메모리 관리 - QEMM
    QEMM은 쿼터덱 사에서 출시한 메모리 관리 소프트웨어로, 인텔 80286 이상의 CPU를 위한 다양한 도구와 드라이버를 제공하며, DOS 환경에서 메모리 관리에 중요한 역할을 했다.
  • 도스 메모리 관리 - HIMEM.SYS
    HIMEM.SYS는 MS-DOS 및 윈도우 환경에서 확장 메모리를 관리하는 장치 드라이버로, A20 라인 제어, HMA 할당, 인터럽트 관리 등의 기능을 제공하며 다양한 스위치 옵션을 통해 메모리 관리 방식 등을 설정할 수 있다.
  • 도스 기술 - EXE
    EXE 파일 형식은 운영 체제에 따라 다양한 종류가 있는 실행 파일의 한 형태로, DOS MZ 실행 파일에서 PE, PE32+까지 발전해 왔으며, 코드, 데이터, 스택을 별도 관리하고 재배치 항목을 통해 실행 환경에 유연하게 대응하는 특징을 가진다.
  • 도스 기술 - COM 파일
    COM 파일은 CP/M 및 MS-DOS 운영체제에서 사용된 실행 파일 형식으로, 메타데이터 없이 코드와 데이터로 구성되어 64KB 크기 제한을 가지며, 단순한 구조로 극소의 실행 파일을 만들 수 있지만 보안 취약점도 존재한다.
종료 후 상주 프로그램

2. 배경

일반적으로 MS-DOS[7] 환경에서는 한 번에 하나의 프로그램만 실행할 수 있었다. 실행 중이던 프로그램이 끝나면, 운영체제에 제어권을 돌려주기 위해 INT 21H/4CH라는 시스템 콜을 호출했다. 이 과정에서 프로그램이 사용하던 메모리는 모두 시스템에 반환되어 비워졌기 때문에, 해당 프로그램을 다시 사용하려면 처음부터 다시 불러와야 했다.

하지만 프로그램이 종료될 때 다른 종류의 시스템 콜, 구체적으로 INT 27H나 INT 21H/31H를 사용하면, MS-DOS는 해당 프로그램이 사용하던 메모리 공간을 비우지 않고 그대로 남겨둔 채 프로세스만 종료시켰다. 이러한 방식은 프로그램의 일부 코드가 메모리에 계속 남아있도록 하는 기반이 되었다.

2. 1. TSR의 등장

시스템 콜 'INT 27H'는 'Terminate But Stay Resident'(종료 후 상주)라고 불리며, 이 시스템 콜을 사용하는 프로그램을 'TSR'이라고 칭했다. 이 방식을 사용하면 프로그램은 최대 64KB의 메모리만 남길 수 있었다. MS-DOS 2.0에서는 이를 개선한 시스템 콜 'INT 21H/31H' ('Keep Process')가 추가되었다. 이 새로운 시스템 콜은 남길 수 있는 메모리 양의 제한을 없애고, 프로세스의 종료 코드를 지정할 수 있도록 했다.

TSR 프로그램이 종료 후에도 코드를 실행시키기 위한 방법 중 하나는, 특정 인터럽트 벡터가 자기 자신의 인터럽트 핸들러를 가리키도록 수정하여 다시 호출되게 만드는 것이다. 예를 들어, 하드웨어 인터럽트를 이용하면 키보드 입력이나 마우스 움직임 같은 하드웨어 이벤트에 프로그램이 반응하도록 할 수 있다. 소프트웨어 인터럽트를 이용하면, 다른 프로그램 안에서 INT 명령을 통해 간단하게 TSR 루틴을 호출할 수 있다. 또한, 타이머 인터럽트나 VSYNC 인터럽트(화면 재생 빈도 동기화 신호)를 통해 주기적으로 코드를 실행하는 것도 가능하다. 인터럽트를 이용하는 것 외에도, MS-DOS에 장치 드라이버로 등록하는 등 다른 방법들도 존재했다.

TSR은 실행 코드를 가지지 않고 단순히 데이터 저장을 위해 메모리 공간만 확보하는 용도로도 사용되었다. 예를 들어, PC-9801 시리즈는 비교적 후기 기종이 나올 때까지 그래픽 팔레트 정보를 읽는 기능이 없었기 때문에, 사용자들이 직접 만든 "상주 팔레트" 프로그램이 이러한 방식으로 사용되었다.

인터럽트 벡터는 여러 TSR이 연쇄적으로 사용하는 경우도 있었다. 일반적으로 다음과 같은 두 가지 방식으로 사용되었다.

  • 특정 인터럽트를 완전히 독점하여, 그 이전에 같은 인터럽트 벡터를 사용하도록 설정했던 다른 인터럽트 핸들러를 호출하지 않는 방식.
  • 해당 TSR 자신의 코드를 실행하기 전이나 후에, 이전에 설정된 인터럽트 벡터를 따라 다른 인터럽트 핸들러를 연쇄적으로 호출하는 방식.


전자의 경우, 경쟁 관계에 있는 다른 TSR의 기능이 멈추게 되는 문제가 있었다. 후자의 경우 여러 TSR이 공존할 수 있었지만, 항상 문제가 없는 것은 아니었다. 예를 들어, 그래픽 처리와 같이 비슷한 기능을 가진 여러 TSR이 부적절한 타이밍에 동시에 작동하거나, 연쇄 호출로 인해 처리 시간이 길어져 제대로 작동하지 않는 경우가 있었다. 이러한 문제들은 흔히 "상성 문제"라고 불렸다.

'Terminate and Stay Resident' 방식은 컴퓨터 바이러스 제작에도 자주 악용되었다. 바이러스는 이 방식을 이용해 사용자 몰래 PC의 제어권을 빼앗거나, 백그라운드에 숨어서 활동했다. 예를 들어, 디스크 입출력(I/O)이나 프로그램 실행 같은 특정 이벤트가 발생할 때 바이러스가 작동하여, 실행 파일(.EXE나 .COM)이 실행될 때 해당 파일에 감염되거나 데이터 파일을 열 때 감염시키는 등의 활동을 했다.

MS-DOS의 버전이 올라가면서, 특히 버전 5.0 이후에는 MS-DOS 자체에 포함된 표준 유틸리티 중에서도 TSR 방식을 사용하는 경우가 늘어났다. 대표적인 예로 DOSKEY 명령행 편집기나 다른 명령행 설치 유틸리티들이 있다. 이들은 CONFIG.SYS 파일에 드라이버로 등록할 필요 없이, AUTOEXEC.BAT 파일에 명령어를 추가하거나 사용자가 직접 명령행에서 실행하여 메모리에 상주시키는 방식으로 사용되었다.

TSR 프로그램은 부팅 과정 중 AUTOEXEC.BAT 파일을 통해 자동으로 로드될 수도 있고, 사용자가 필요에 따라 직접 실행하여 로드할 수도 있었다[8]. 예를 들어, Sidekick나 Turbo Debugger 같은 프로그램들이 이런 방식으로 사용되었다. 일단 로드된 TSR 프로그램은 다른 프로그램을 실행하는 동안에도 메모리에 계속 남아 있었다. 일부 TSR 프로그램은 스스로 메모리에서 제거(언로드)하는 기능을 제공하지 않아, 컴퓨터를 재부팅할 때까지 메모리에 상주하기도 했다. 그러나 TurboPower Software 사의 MARK.EXE/RELEASE.EXE 유틸리티 조합이나, 특정 키 조합으로 모든 TSR을 언로드하는 'soft reboot' TSR 같은 외부 프로그램을 사용하여 강제로 언로드하는 것도 가능했다. 하지만 이러한 강제 언로드는 위험을 수반했다. MS-DOS의 메모리 관리 시스템 상태를 원래대로 복구하는 것은 비교적 간단했지만, 인터럽트 벡터와 같은 시스템 자원을 원래 상태로 되돌리는 것은 복잡한 문제였다. TSR이 시스템 기능을 가로채기 위해 변경한 설정들을 정확히 파악하고 복원해야 했는데, 이는 경험에 의존할 수밖에 없었고 실패할 경우 시스템 충돌이나 멈춤 현상(행업)을 일으켜 결국 재부팅해야 하는 위험이 항상 따랐다.

2. 2. 시스템 콜

일반적으로 MS-DOS[7]에서는 한 번에 하나의 프로그램만 실행할 수 있다. 실행 중인 프로세스가 종료될 때, 제어를 부모 프로세스로 반환하기 위해 INT 21H/4CH라는 시스템 콜을 사용한다. 이때 해당 프로그램이 사용하던 메모리는 해제되므로, 다시 호출하려면 처음부터 프로그램을 다시 로드해야 한다.

그러나 프로그램 종료 시 특정 시스템 콜을 사용하면, MS-DOS는 해당 프로그램의 메모리를 해제하지 않고 프로세스를 종료시켜 메모리에 상주하게 할 수 있다. 이를 가능하게 하는 대표적인 시스템 콜은 다음과 같다.

시스템 콜명칭특징
INT 27HTerminate But Stay Resident (TSR)프로그램이 최대 64KB의 메모리만 남길 수 있음. 초기에 사용된 방식.
INT 21H/31HKeep ProcessMS-DOS 2.0에서 추가됨. 남길 메모리 양의 제한이 없고, 프로세스의 종료 코드를 지정할 수 있음.



이렇게 메모리에 상주한 프로그램(TSR 프로그램)이 종료 후에도 코드를 실행하게 하는 방법 중 하나는, 특정 인터럽트 벡터가 자신의 인터럽트 핸들러를 가리키도록 수정하는 것이다. 예를 들어, 하드웨어 인터럽트를 이용하면 키보드 입력이나 마우스 움직임 같은 하드웨어 이벤트에 반응할 수 있고, 소프트웨어 인터럽트를 이용하면 다른 프로그램이 INT 명령으로 해당 TSR 프로그램을 쉽게 호출할 수 있다. 또한, 타이머 인터럽트나 VSYNC 인터럽트를 이용하여 주기적으로 코드를 실행하는 것도 가능하다. 인터럽트 벡터 수정 외에도 MS-DOS에 장치 드라이버로 등록하는 등 다른 방법으로도 TSR 기능을 구현할 수 있다.

TSR 프로그램은 코드를 실행하는 목적 외에, 단순히 데이터 영역으로 메모리를 확보하는 데 사용되기도 했다. 예를 들어, 초기 PC-9801 시리즈는 하드웨어적으로 팔레트 값을 읽어올 수 없었기 때문에, 사용자들이 화면 색상 정보를 저장하기 위해 만든 "상주 팔레트"가 이러한 용법에 해당한다.

인터럽트 벡터를 여러 TSR 프로그램이 함께 사용하는 방식에는 주로 두 가지가 있다.


  • '''독점 방식:''' 특정 인터럽트를 완전히 점유하여, 이전에 해당 인터럽트 벡터를 사용하던 다른 TSR 프로그램의 핸들러를 호출하지 않는다. 이 경우, 경쟁 관계에 있는 다른 TSR 프로그램의 기능이 멈출 수 있다.
  • '''연쇄 방식:''' 자신의 코드를 실행하기 전이나 후에, 이전 인터럽트 벡터 값에 따라 다른 핸들러를 순차적으로 호출한다. 이 방식은 여러 TSR 프로그램이 공존할 수 있게 하지만, 실행 순서나 타이밍 문제로 충돌이 발생할 수 있다. 예를 들어, 여러 TSR이 동시에 그래픽 처리를 시도하거나, 연쇄 호출로 인한 처리 시간 지연 때문에 시스템이 불안정해지는 등, 소위 "상성 문제"를 일으키기 쉬웠다.


'Terminate and Stay Resident' 기법은 컴퓨터 바이러스 제작에도 자주 악용되었다. 바이러스는 TSR 형태로 메모리에 상주하며 PC의 제어권을 탈취하거나 백그라운드에서 은밀히 활동했다. 예를 들어, 디스크 입출력이나 프로그램 실행 같은 특정 이벤트가 발생할 때 바이러스 코드가 실행되어, 실행 파일(.EXE, .COM)이나 데이터 파일을 감염시키는 방식이다.

MS-DOS 버전이 올라가면서, 특히 버전 5.0 이후부터는 MS-DOS 자체에 포함된 표준 유틸리티 중에서도 TSR 방식을 사용하는 경우가 늘어났다. 대표적인 예로 DOSKEY 명령행 편집기가 있으며, 이들은 CONFIG.SYS에 드라이버로 등록할 필요 없이 AUTOEXEC.BAT 파일에 명령어를 추가하거나 사용자가 직접 명령행에서 실행하여 메모리에 상주시키는 방식으로 사용되었다.

TSR 프로그램은 시스템 부팅 시 AUTOEXEC.BAT 파일을 통해 자동으로 로드되거나[8], 사용자가 필요할 때 직접 로드할 수 있다(예: Sidekick, Turbo Debugger). 일단 로드된 TSR 프로그램은 다른 프로그램이 실행되는 동안에도 메모리에 계속 남아 있는다. 일부 TSR 프로그램은 스스로 메모리에서 제거(언로드)하는 기능을 제공하지 않아, 시스템을 재부팅해야만 사라지는 경우도 있었다. 외부 유틸리티(예: TurboPower Software의 MARK.EXE/RELEASE.EXE 조합)나 'soft reboot' TSR을 사용하여 강제로 언로드하는 방법도 있었지만, 이는 위험을 수반했다. MS-DOS의 메모리 관리 상태를 복원하는 것은 비교적 간단했지만, TSR 프로그램이 수정한 인터럽트 벡터 등을 원래대로 되돌리는 과정에서 문제가 발생하기 쉬웠다. 어떤 인터럽트를 복원해야 하는지에 대한 판단이 경험에 의존할 수밖에 없었고, 잘못된 복원은 시스템 충돌이나 멈춤 현상(행업)을 일으켜 결국 시스템을 리셋해야 하는 경우가 많았다.

3. TSR의 작동 방식

종료 후 상주 프로그램(TSR)은 DOS 환경에서 유용하게 사용되었지만, 종종 시스템 충돌을 일으키는 원인이 되기도 했다. 이는 TSR이 운영 체제의 기능을 다양한 방식으로 가로채는 방식으로 작동하여, 특정 응용 프로그램이나 다른 TSR과 함께 사용될 때 문제를 일으키는 경우가 많았기 때문이다.

TSR은 시스템 콜 `INT 27H` ('Terminate But Stay Resident')을 사용하여 메모리에 상주하는 방식으로 처음 구현되었다. 이 방식은 프로그램이 최대 64KB의 메모리만 남길 수 있었다. 이후 MS-DOS 2.0에서는 개선된 시스템 콜 `INT 21H/31H` ('Keep Process')가 도입되어 메모리 크기 제한이 없어지고 종료 코드 지정도 가능해졌다.

TSR이 작동하는 핵심 원리는 인터럽트 벡터를 수정하여 특정 이벤트 발생 시 자신의 코드가 실행되도록 하는 것이다. 예를 들어 하드웨어 인터럽트를 이용해 하드웨어 이벤트에 반응하거나, 소프트웨어 인터럽트를 이용해 다른 프로그램의 특정 명령 실행에 개입할 수 있다. 타이머 인터럽트를 통해 주기적으로 코드를 실행하는 것도 가능했다. 인터럽트 외에도 장치 드라이버로 등록하는 등 다른 방식으로 작동할 수도 있으며, 단순히 실행 코드 없이 데이터 영역 확보를 위해 메모리에 상주하는 경우(예: PC-9801 시리즈의 '상주 팔레트')도 있었다.

그러나 TSR은 DOS의 심각한 메모리 제약 문제와 맞물려 어려움을 겪었다. DOS 환경에서는 물리적 RAM 용량과 관계없이 모든 프로그램이 처음 640KB의 기본 메모리 영역에 로드되어야 했다. TSR 역시 이 영역을 차지하여 다른 응용 프로그램이 사용할 수 있는 메모리를 줄였고, 이는 TSR 개발에 있어 크기 최소화와 호환성 확보라는 과제를 안겨주었다.

특히 1980년대 후반과 1990년대 초반, PC 플랫폼의 많은 비디오 게임은 640KB 메모리 한계에 근접하게 개발되어 CD-ROM 드라이버와 같은 필수 TSR을 위한 공간조차 부족해지는 경우가 많았다. 사용자들은 특정 게임을 실행하기 위해 필요한 TSR만 남기고 나머지는 비활성화하는 복잡한 과정을 거쳐야 했으며, 게임별로 다른 부팅 디스크를 사용하기도 했다. MS-DOS 후기 버전에서는 부팅 메뉴 스크립트를 통해 다양한 구성을 선택할 수 있게 개선되었다.

이러한 메모리 제약을 극복하기 위해 게임들은 데이터 일부를 1MB 이상의 확장 메모리 영역에 배치하고, 기본 메모리에는 최소한의 코드만 남겨 오버레이 기법이나 확장 메모리 관리자(EMS)를 통해 확장 메모리에 접근하는 방식을 사용했다. 더 나아가 DOS 확장기를 사용하여 CPU를 보호 모드로 전환하고, 보호 모드에서 프로그램을 실행하여 확장 메모리 영역에 코드와 데이터를 자유롭게 배치하는 방법도 사용되었다. DOS 확장기는 VCPI나 DPMI 같은 표준 인터페이스를 통해 구현되었다. 하지만 DOS 자체와 대부분의 TSR, 장치 드라이버는 실 모드에서 작동했기 때문에, 보호 모드에서 실행되는 프로그램이 TSR이나 DOS 기능을 호출할 때는 실 모드로 다시 전환해야 했고, 이 과정에서 성능 저하가 발생했다 (단, DPMS나 CLOAKING 같은 기술을 사용하면 이를 완화할 수 있었다).

TSR 프로그램은 AUTOEXEC.BAT 파일을 통해 부팅 시 자동으로 로드되거나, 사용자가 필요할 때 직접 실행하여 로드할 수 있었다.[8] 예를 들어, Sidekick이나 Turbo Debugger와 같은 유틸리티가 이런 방식으로 사용되었다. 한번 로드된 TSR은 다른 프로그램이 실행되는 동안에도 메모리에 계속 남아 있었으며, 자체적으로 메모리에서 제거하는 기능을 제공하지 않는 경우도 많아 시스템을 재부팅해야만 제거할 수 있었다. 외부 유틸리티(예: TurboPower Software의 MARK.EXE/RELEASE.EXE)나 '소프트 리부트' TSR을 사용하여 강제로 제거하는 방법도 있었지만, 이는 인터럽트 벡터 체인을 망가뜨리거나 시스템 자원 상태를 불안정하게 만들어 시스템 충돌이나 정지(행업)를 유발할 위험이 컸다.

3. 1. 인터럽트 공유 문제

여러 상주 프로그램이 동일한 인터럽트를 사용하려고 할 때 충돌이 발생할 수 있다. 이러한 문제를 관리하기 위해 랄프 D. 브라운은 대체 멀티플렉스 인터럽트 사양(AMIS, Alternate Multiplex Interrupt Specification)이라는 방법을 제안했다. 이는 이전에 INT 2Fh를 통해 제공되던 서비스의 개선안으로, 소프트웨어 인터럽트를 제어된 방식으로 공유하는 방법을 제공한다. AMIS는 원래 x86 프로세서의 하드웨어 인터럽트 공유를 위해 개발된 IBM의 인터럽트 공유 프로토콜을 모델로 삼았으며, INT 2Dh 서비스를 통해 사용할 수 있었다.[4] 하지만 이 제안은 당시 프로그래머들 사이에서 널리 채택되지 못했는데, 여러 다른 경쟁 사양들이 존재했기 때문이다.[5]

상주 프로그램은 특정 인터럽트 벡터가 자신을 가리키도록 수정하여, 해당 인터럽트가 발생했을 때 자신의 코드가 실행되도록 만들 수 있다. 예를 들어, 하드웨어 인터럽트를 이용하면 키보드 입력이나 마우스 움직임 같은 하드웨어 이벤트에 반응할 수 있고, 소프트웨어 인터럽트를 이용하면 다른 프로그램이 특정 명령(INT 명령어)을 실행할 때 끼어들 수 있다. 타이머 인터럽트나 VSYNC 인터럽트를 이용해 주기적으로 코드를 실행하는 것도 가능하다.

이렇게 인터럽트 벡터를 사용하는 방식은 크게 두 가지로 나눌 수 있다.

  • 독점 방식: 특정 인터럽트를 완전히 점유하여, 이전에 해당 인터럽트 벡터를 사용하도록 설정된 다른 프로그램의 코드는 전혀 실행되지 않도록 막는다. 이 경우, 경쟁 관계에 있는 다른 상주 프로그램의 기능이 멈출 수 있다.
  • 연쇄 호출 방식: 자신의 코드를 실행하기 전이나 후에, 원래 해당 인터럽트 벡터가 가리키고 있던 이전 프로그램의 코드를 호출해준다. 이 방식은 여러 상주 프로그램이 공존할 수 있게 하지만, 항상 문제가 없는 것은 아니다. 예를 들어, 여러 프로그램이 그래픽 처리와 같이 민감한 작업을 부적절한 타이밍에 동시에 수행하려 하거나, 연쇄적인 호출로 인해 처리 시간이 길어져 시스템이 불안정해지는 등의 문제가 발생할 수 있다. 이를 흔히 '호환성 문제' 또는 '충돌 문제'라고 부른다.


이러한 '종료 후 상주' 방식은 컴퓨터 바이러스 제작에도 자주 악용되었다. 바이러스는 이 방식을 이용해 사용자의 컴퓨터 제어권을 빼앗거나, 눈에 띄지 않게 백그라운드에서 활동했다. 예를 들어, 디스크 입출력이나 프로그램 실행 같은 특정 이벤트가 발생할 때 바이러스 코드가 실행되도록 하여, 실행 파일(.EXE 또는 .COM)이 실행될 때 해당 파일을 감염시키거나 데이터 파일을 열 때 감염시키는 방식으로 작동했다.

3. 2. 인터럽트 체이닝

인터럽트 벡터를 체이닝(chaining)함으로써 TSR은 컴퓨터 제어권을 확보할 수 있다. TSR의 인터럽트 처리 방식은 크게 두 가지로 나눌 수 있다.

  • 이전에 같은 인터럽트 벡터를 사용하던 다른 TSR의 처리 루틴을 호출하지 않고, 인터럽트를 독점하여 완전히 제어한다.
  • 이전 인터럽트 처리 루틴을 호출하여 다른 TSR과 연결(chain)된다. 이 호출은 TSR 자신의 코드를 실행하기 전이나 후에 이루어질 수 있으며, 이를 통해 여러 TSR이 순차적으로 호출되는 체인을 형성한다.


인터럽트를 독점하는 방식은 다른 TSR과의 충돌을 일으켜 해당 TSR의 기능을 정지시킬 수 있다. 반면, 인터럽트를 연쇄시키는 방식은 여러 TSR이 공존할 수 있게 하지만, 처리 시간 지연이나 예상치 못한 상호작용(예: 그래픽 처리 충돌)으로 인해 시스템 불안정이나 오작동을 유발하는 등, 소위 "상성 문제"를 일으키기 쉬웠다. 이러한 인터럽트 제어 방식은 컴퓨터 바이러스나 악성코드가 시스템 제어권을 탈취하거나 백그라운드에서 활동하기 위해 악용되기도 했다. 예를 들어, 디스크 입출력이나 프로그램 실행 같은 이벤트에 반응하여 실행 파일(.EXE 또는 .COM)이나 데이터 파일을 감염시키는 방식이다.

한편, 다수의 TSR이 동일한 인터럽트를 공유할 때 발생하는 문제를 관리하기 위해, 랄프 D. 브라운은 소프트웨어 인터럽트를 제어된 방식으로 공유하는 대체 멀티플렉스 인터럽트 사양(AMIS, Alternative Multiplex Interrupt Specification)을 제안했다.[4] AMIS는 INT 2Dh를 통해 서비스를 제공했으며, 하드웨어 인터럽트 공유를 위해 IBM이 개발한 인터럽트 공유 프로토콜을 모델로 삼았다. 그러나 이 제안은 당시 여러 경쟁 사양과의 경합 속에서 프로그래머들에게 널리 채택되지는 못했다.[5]

4. 문제점

종료 후 상주 프로그램(TSR)은 DOS 환경에서 매우 유용하거나 필수적인 기능을 제공하기도 했지만, 동시에 여러 가지 문제점을 안고 있어 사용자들에게 불편을 주기도 했다. TSR은 운영 체제의 작동 방식에 직접 개입하는 경우가 많아 특정 응용 프로그램이나 다른 TSR과의 조합에 따라 시스템 충돌을 일으키는 등 시스템 불안정성을 유발하기 쉬웠다.[9] 또한, TSR의 작동 방식은 컴퓨터 바이러스와 같은 악성 코드에 의해 악용될 수 있는 취약점을 가지고 있었다.

가장 큰 제약 중 하나는 메모리 부족 문제였다. DOS 환경에서는 물리적 RAM 용량과 관계없이 프로그램이 실행될 수 있는 기본 메모리가 640KB로 제한되었는데, TSR 역시 이 공간을 차지하여 다른 프로그램, 특히 비디오 게임처럼 많은 메모리를 요구하는 프로그램의 실행을 어렵게 만들었다. 이로 인해 사용자들은 필요한 TSR과 프로그램을 함께 사용하기 위해 복잡한 메모리 관리를 해야 했으며, 이는 다양한 소프트웨어 간의 호환성 문제로 이어지기도 했다.

마지막으로, 한번 메모리에 로드된 TSR을 필요 없을 때 안전하게 제거하는 언로드 문제도 존재했다. MS-DOS의 메모리 관리 방식의 한계와 공식적인 언로드 기능 지원 미비로 인해, 사용하지 않는 TSR이 메모리에 남아 시스템 자원을 불필요하게 점유하는 경우가 많았다.[9] 이러한 문제점들은 TSR의 편리함에도 불구하고 사용상의 어려움을 야기하는 주요 원인이었다.

4. 1. 시스템 불안정성

종료 후 상주 프로그램(TSR)은 DOS 환경에서 매우 유용하거나 필수적인 기능을 제공하기도 했지만, 시스템 불안정성을 유발하는 원인으로 지목되기도 했다. 많은 TSR은 문서화되지 않은 방식으로 운영 체제의 작동 방식에 개입하여 특정 애플리케이션이나 다른 TSR과 함께 사용할 때 시스템 충돌을 일으키는 경우가 잦았다. 이는 TSR이 인터럽트 벡터를 '체이닝(chaining)'하는 방식으로 컴퓨터 제어권을 가로챌 수 있었기 때문이다. TSR은 인터럽트를 완전히 독점하거나, 다른 TSR과 연쇄적으로 연결되어 작동할 수 있었다.[9]

이러한 TSR의 작동 방식은 바이러스를 비롯한 악성 코드 제작에 악용되기도 했다. 악성 코드는 TSR 형태로 시스템에 상주하며 디스크 입출력이나 프로그램 실행 같은 특정 이벤트에 반응하여 실행 파일(.EXE, .COM)이나 데이터 파일을 감염시키는 방식으로 작동했다.

또한, MS-DOS 환경의 고질적인 문제였던 메모리 제약은 TSR 사용에 큰 걸림돌이었다. 당시 컴퓨터에 물리적으로 많은 RAM이 장착되어 있어도, 모든 프로그램은 시스템 메모리의 처음 640KB (이를 기본 메모리 또는 컨벤셔널 메모리라고 한다) 내에 로드되어야 했다. TSR 역시 예외는 아니어서, TSR이 로드되면 그만큼 다른 애플리케이션이 사용할 수 있는 기본 메모리 공간이 줄어들었다. 이 때문에 TSR 개발자들은 프로그램 크기를 최대한 작게 만들고 다양한 소프트웨어와의 호환성을 확보해야 하는 어려움을 겪었다.

1980년대 후반에서 1990년대 초반, PC 플랫폼의 많은 컴퓨터 게임들은 점점 더 많은 메모리를 요구하게 되면서 이러한 640KB 메모리 한계에 부딪혔다. 필수적인 TSR(CD-ROM 드라이버 등)조차 로드할 공간이 부족해졌고, 필요한 TSR을 유지하면서 게임을 실행할 충분한 메모리를 확보하는 것은 매우 복잡한 작업이 되었다. 많은 게이머들은 각기 다른 게임을 실행하기 위해 서로 다른 구성의 부팅 디스크를 여러 개 만들어 사용해야 했다. 이후 MS-DOS 버전에서는 부팅 시 메뉴를 통해 다양한 설정을 선택할 수 있는 기능이 추가되기도 했다.

1990년대 중반 이후에도 DOS용 게임이 계속 출시되었지만, 개발자들은 640KB의 한계를 극복하기 위해 다양한 기술을 사용했다. 게임 데이터나 코드 일부를 1MB 이상의 확장 메모리 영역에 배치하고, 오버레이 기법을 사용해 필요할 때마다 기본 메모리로 불러와 실행하는 방식이 사용되었다. 프로그램 크기가 약 512KB를 넘어서면 오버레이 프로그래밍이 복잡해지기 때문에, DOS 확장기를 사용하는 것이 일반적인 해결책이 되었다. DOS 확장기는 VCPI나 DPMI 같은 표준 인터페이스를 통해 x86 프로세서를 실 모드에서 보호 모드로 전환시켜, 1MB 이상의 확장 메모리 영역에 직접 접근하고 코드를 실행할 수 있게 해주었다.

하지만 DOS 확장기에도 한계는 있었다. DOS 자체와 대부분의 DOS 프로그램, 그리고 TSR 및 장치 드라이버는 여전히 실 모드에서 작동했기 때문에, 보호 모드에서 실행되던 프로그램이 이들과 상호작용하려면 다시 실 모드로 전환해야 했다. 이러한 모드 전환 과정에는 시간 지연이 발생했다(DPMS나 CLOAKING 같은 기술로 일부 완화 가능).

더불어, 한번 실행된 TSR을 메모리에서 제거(unload)하는 기능이 제공되지 않는 경우도 많았다. 이는 MS-DOS의 메모리 관리 방식(소위 "아레나(arena)" 구조)과 관련이 있는데, 특정 TSR이 메모리 어디에 있는지 추적하고 제거하기 위한 공식적인 방법이 부족했기 때문이다. 이를 위한 시스템 호출(비공식적으로 ''Get List-of-Lists'' 등으로 불림)은 문서화되지 않은(undocumented) API였기에 안정성을 보장할 수 없었다.[9]

4. 2. 메모리 부족 문제

DOS 환경에서는 컴퓨터에 물리적인 RAM 용량이 크더라도 모든 프로그램은 메모리 공간의 처음 640KB (이를 기본 메모리라고 한다) 내에 로드되어야 하는 제약이 있었다. TSR 역시 이 제한에서 예외가 아니었기에, 기본 메모리의 일부를 점유하여 다른 응용 프로그램이 사용할 수 있는 공간을 줄였다. 이로 인해 TSR 개발자들은 프로그램 크기를 최소화하고 다양한 소프트웨어와의 호환성을 확보해야 하는 어려움을 겪었다.

1980년대 후반부터 1990년대 초반에 걸쳐 비디오 게임 등 메모리 요구량이 큰 프로그램들이 등장하면서 이러한 제약은 더욱 심화되었다. CD-ROM 드라이버와 같은 필수적인 TSR조차 로드할 공간이 부족해지는 상황이 발생했으며, 필요한 TSR을 유지하면서 동시에 게임을 실행할 충분한 메모리를 확보하는 것은 매우 복잡한 작업이 되었다. 많은 사용자들은 각기 다른 게임이나 작업 환경에 맞춰 별도의 부팅 디스크를 만들어 사용해야 했다. 이후 MS-DOS 버전에서는 부팅 메뉴를 통해 여러 구성 설정을 선택하는 기능이 추가되어 다소 불편함이 해소되었다.

이 640KB 메모리 한계를 극복하기 위해 여러 기술이 개발되었다. 1990년대 중반 이후의 DOS 게임들은 게임 데이터나 코드 일부를 1MB 이상의 확장 메모리 영역에 배치하고, 기본 메모리에는 최소한의 실행 코드만 남겨둔 채 오버레이 기법을 활용하여 필요할 때마다 확장 메모리의 데이터를 불러와 사용하는 방식을 채택했다. 그러나 오버레이 방식은 프로그래밍이 복잡했기 때문에, 프로그램 크기가 약 512KB를 초과하면 다른 해결책이 모색되었다.

더 효과적인 방법은 DOS 확장기를 사용하는 것이었다. DOS 확장기는 x86 프로세서를 실 모드에서 보호 모드로 전환시켜 1MB 이상의 메모리 영역에 직접 접근하고 코드를 실행할 수 있게 했다. VCPI나 DPMI 같은 표준을 구현한 DOS 확장기가 등장하면서 확장 메모리 활용이 용이해졌다. 하지만 DOS 자체와 대부분의 DOS 프로그램, TSR, 장치 드라이버는 실 모드에서 작동했으므로, 보호 모드 프로그램이 이들과 상호작용하려면 실 모드로 다시 전환해야 했고, 이 과정에서 성능 저하가 발생하기도 했다.

1980년대 후반, 확장 메모리 보드와 인텔 80386 프로세서의 등장은 640KB 이상의 메모리 영역, 즉 상위 메모리 블록(UMB)에 TSR을 로드할 가능성을 열었다. 이를 위해서는 쿼터덱의 QEMM, 퀄리타스의 386MAX, 컴팩의 CEMM, 마이크로소프트의 EMM386과 같은 별도의 "확장 메모리 관리자" 소프트웨어가 필요했다. TSR을 UMB에 로드하는 것을 "높은 곳에 로드(loading high)"라고 불렀으며, 이후 메모리 관리자들은 Quarterdeck의 Optimize나 Microsoft의 MEMMAKER와 같은 최적화 도구를 포함하여 TSR을 기본 메모리와 상위 메모리 영역에 효율적으로 배치함으로써 기본 메모리의 가용 공간을 최대한 확보하도록 지원했다.

한편, TSR을 메모리에서 제거하는 언로드(unload) 기능이 제대로 지원되지 않는 경우도 많았다. 이는 MS-DOS의 메모리 관리 방식과 관련이 있는데, MS-DOS는 메모리를 "아레나(arena)"라는 연결 리스트 구조로 관리했다. 특정 TSR을 찾아 제거하려면 이 리스트의 시작 주소를 알아야 했지만, 이를 위한 시스템 호출(`Get List-of-Lists` 등으로 불림)은 공식적으로 문서화되지 않은(undocumented) API였기 때문에 안정성을 보장하기 어려웠다[9]。 이러한 메모리 관리의 복잡성과 불안정성 역시 TSR 사용의 어려움을 가중시키는 요인이었다.

4. 3. 호환성 문제

종료 후 상주 프로그램(TSR)은 매우 유용하며 DOS의 한계를 극복하는 데 필수적인 역할을 했지만, 잦은 문제 발생으로 인해 말썽꾼이라는 평판을 얻었다. 많은 TSR은 문서화되지 않은 방식으로 운영 체제의 기능을 가로채는 경우가 많았고, 이로 인해 특정 애플리케이션이나 다른 TSR과 함께 사용할 때 시스템 충돌을 일으키곤 했다.

TSR은 인터럽트 벡터를 가로채고 연결(체이닝)하는 방식으로 작동한다. 이 과정에서 TSR은 컴퓨터 시스템에 대한 완전한 제어권을 가질 수 있다. TSR은 두 가지 방식으로 동작할 수 있다:

  • 다른 TSR이 먼저 변경한 인터럽트 벡터를 무시하고 자신만의 코드를 실행하여 인터럽트를 완전히 독점한다.
  • 이전에 설치된 TSR의 코드를 호출한 후 자신의 코드를 실행하거나, 그 반대로 실행하여 여러 TSR이 사슬처럼 연결되어 동작한다.


이러한 종료 후 상주 방식은 대부분의 DOS 바이러스나 기타 악성 코드에서도 사용되었다. 악성 코드는 실행 파일(.EXE, .COM)이나 데이터 파일을 감염시킨 뒤, 디스크 입출력이나 프로그램 실행 같은 특정 이벤트가 발생할 때 활성화되어 시스템을 제어하거나 백그라운드에 상주했다.

가장 큰 호환성 문제 중 하나는 RAM 사용과 관련이 있었다. DOS 환경에서는 물리적 RAM 용량이 아무리 크더라도 모든 프로그램은 첫 640KB의 기본 메모리 (컨벤셔널 메모리) 영역에 로드되어야 했다. TSR도 예외는 아니어서, 이 소중한 기본 메모리 공간을 차지하게 되었고, 이는 다른 애플리케이션, 특히 많은 메모리를 요구하는 프로그램들이 사용할 수 있는 메모리 양을 줄이는 결과를 낳았다. 따라서 TSR 개발자들은 프로그램 크기를 최대한 작게 만들어야 했고, 수많은 다른 소프트웨어와의 호환성을 일일이 확인해야 하는 어려움을 겪었다.

특히 1980년대 후반과 1990년대 초반에는 PC 플랫폼의 많은 컴퓨터 게임들이 640KB 메모리 한계에 근접하게 개발되었다. 이로 인해 CD-ROM 드라이버와 같은 필수적인 TSR조차 설치할 공간이 부족해지는 경우가 많았다. 게이머들은 필요한 TSR을 유지하면서 동시에 게임을 실행할 충분한 메모리를 확보하기 위해 각 게임마다 다른 구성 설정을 가진 부팅 디스크를 여러 개 만들어 사용해야 했다. MS-DOS 후기 버전에서는 부팅 시 메뉴를 통해 다양한 설정을 선택할 수 있는 기능이 추가되기도 했다.

1990년대 중반 이후에도 여전히 DOS용 게임이 출시되었지만, 개발자들은 640KB의 한계를 극복하기 위해 다양한 기술을 사용했다. 게임 데이터나 코드의 일부를 1MB 이상의 확장 메모리 영역에 배치하고, 오버레이 기법을 사용하여 필요할 때마다 기본 메모리 영역으로 불러와 실행하는 방식이 사용되었다. 또 다른 접근 방식은 DOS 확장기를 사용하는 것이었다. DOS 확장기는 x86 프로세서를 실 모드에서 보호 모드로 전환시켜 프로그램이 1MB 이상의 확장 메모리 영역에 직접 접근하고 코드를 실행할 수 있게 해주었다. VCPI나 DPMI 같은 표준 인터페이스를 구현한 DOS 확장기가 널리 사용되었다.

하지만 DOS 확장기를 사용하는 것에도 문제가 있었다. DOS 자체와 대부분의 DOS 프로그램, 그리고 TSR과 장치 드라이버는 여전히 실 모드에서 작동했기 때문에, 보호 모드에서 실행되던 프로그램이 TSR이나 DOS 기능을 호출해야 할 경우, DOS 확장기는 다시 실 모드로 전환해야 했다. 이러한 모드 전환 과정은 상당한 시간적 손실을 발생시켰다. (물론 DPMS나 CLOAKING 같은 기술로 이러한 오버헤드를 줄이려는 시도도 있었다.)

또한, 한번 메모리에 상주한 TSR을 안전하게 제거(언로드)하는 기능이 제공되지 않는 경우도 많았다. MS-DOS는 메모리를 "아레나(arena)"라는 연결 리스트 구조로 관리했는데, TSR이 자신을 메모리에서 제거하려면 이 리스트 구조에 대한 정보를 알아야 했다. 하지만 이 정보를 얻기 위한 시스템 호출(비공식적으로 Get List-of-Lists영어 등으로 불림)은 공식적으로 문서화되지 않은(undocumented) API였기 때문에, 이를 사용하는 것은 불안정성을 내포하고 있었다.[9] 게다가 BIOS와의 호환성 문제도 존재했다.

4. 4. 언로드 문제

TSR 프로그램은 MS-DOS의 기능을 확장하는 데 유용했지만, 여러 문제를 안고 있었다. 운영체제의 작동 방식에 개입하는 특성상 다른 프로그램이나 TSR과의 충돌로 시스템 오류를 일으키는 경우가 잦았다. 일부 컴퓨터 바이러스는 TSR 형태로 제작되어 시스템에 해를 끼치기도 했다.

가장 큰 문제는 메모리 관리였다. 당시 MS-DOS 시스템은 컨벤셔널 메모리라고 불리는 초기 640KB(일부 기종에서는 768KB) 영역에만 프로그램을 로드할 수 있었다. TSR 프로그램 역시 이 제한된 공간에 상주해야 했기 때문에, 다른 응용 프로그램이 사용할 수 있는 메모리가 줄어드는 결과를 낳았다. 이로 인해 TSR 개발자들은 프로그램 크기를 최대한 줄이고 다른 소프트웨어와의 호환성을 확보해야 하는 부담을 안았다.

한번 실행된 TSR 프로그램을 메모리에서 제거하는 언로드 기능이 제대로 지원되지 않는 경우가 많았는데, 여기에는 기술적인 이유가 있었다. MS-DOS는 "아레나(arena)"라는 독특한 방식으로 메모리를 관리했는데, 특정 TSR을 찾아 제거하기 위해서는 이 관리 구조에 접근해야 했다. 하지만 이를 위한 공식적인 방법이 제공되지 않았고, 'Get List-of-Lists'와 같이 비공식적으로 알려진 API는 안정성을 보장할 수 없었다.[9] 이러한 불안정성 때문에 TSR 언로드 기능을 구현하는 것은 쉽지 않았다.

1980년대 후반부터 고사양 컴퓨터 게임이 등장하면서 메모리 부족 문제는 더욱 심화되었다. TSR 프로그램을 유지하면서 게임 실행에 필요한 메모리를 확보하기 어려워지자, 사용자들은 게임마다 다른 부팅 디스크를 만들어 사용하는 불편을 겪기도 했다.

이후 640KB의 한계를 넘어서기 위해 오버레이 기법이나 프로텍트 모드를 활용하는 DOS 익스텐더(VCPI, DPMI) 등이 도입되었다. 이를 통해 1MB 이상의 메모리 공간을 활용할 수 있게 되었지만, 리얼 모드에서 작동하는 MS-DOS나 기존 TSR과의 호환성을 위해 모드 전환이 필요했고, 이는 성능 저하를 유발했다. 또한 BIOS 관련 문제도 여전히 해결해야 할 과제로 남았다.

5. 쇠퇴와 복권

도스 확장자를 사용하는 게임들, 예를 들어 둠과 같은 프로그램이 등장하면서 640KB 메모리 장벽 문제가 일부 해소되었고, 이로 인해 종료 후 상주 프로그램(TSR)과 관련된 문제 상당수가 줄어들었다.[1][2] 이후 마이크로소프트 윈도우, 특히 윈도우 95와 윈도우 98이 널리 보급되면서 대부분의 TSR은 더 이상 필요하지 않게 되었으며, 일부는 아예 호환되지 않았다.[3] 그럼에도 불구하고 Win16 기반 애플리케이션 중 일부는 윈도우 환경에서도 TSR과 유사한 방식으로 인터럽트 서술자 테이블(IDT)을 수정하는 등의 기법을 사용하기도 했다.[4]

1980년대 후반 EMS 보드와 인텔 80386 프로세서가 등장하면서 TSR을 640KB 이상의 상위 메모리 영역에 로드하는 기법이 개발되기도 했으나, 이는 메모리 관리자라는 별도의 소프트웨어를 필요로 하는 등 복잡성을 야기했다.

결정적으로 윈도우 미와 윈도우 NT 계열 운영체제(윈도우 XP 이후의 소비자용 윈도우 포함)가 등장하면서 TSR은 설 자리를 잃게 되었다. 이 운영체제들은 항상 보호 모드나 롱 모드로 작동하여 TSR이 기능하는 데 필수적인 리얼 모드로의 전환을 허용하지 않았다.[5] 대신, 현대적인 메모리 보호 기능과 선점 멀티태스킹을 지원하는 드라이버 및 서비스 프레임워크를 통해 여러 프로그램과 장치 드라이버가 특별한 기법 없이도 동시에 안정적으로 실행될 수 있게 되었다.[6] 인터럽트 테이블 수정과 같은 저수준 작업은 커널 및 커널 모듈의 책임으로 넘어갔다.

5. 1. 메모리 관리자

1980년대 후반 확장 메모리 보드와 인텔 80386 프로세서가 등장하면서, MS-DOS 환경에서도 640KB 이상의 메모리를 활용할 수 있게 되었다. 이를 통해 종료 후 상주 프로그램(TSR)을 기본 메모리(처음 640KB) 영역 바깥에 로드하는 것이 가능해졌다.

하지만 이러한 방식은 "확장 메모리 관리자"라는 새로운 종류의 소프트웨어가 필요했다. 이 관리자들은 복잡한 방식으로 추가 메모리 영역을 관리했으며, TSR을 640KB 이상의 메모리 영역, 즉 "상위 메모리 블록"(Upper Memory Blocks, UMBs)에 로드하는 기능을 제공했다. 프로그램을 UMBs에 로드하는 것을 "상위 로드"(loading high)라고 불렀다.

당시 유명했던 메모리 관리자로는 쿼터덱(Quarterdeck)의 QRAM과 QEMM, 퀄리타스(Qualitas)의 386MAX, 컴팩(Compaq)의 CEMM 등이 있었다. 마이크로소프트(Microsoft) 역시 나중에 EMM386을 출시했다.

이후 메모리 관리자들은 TSR을 기본 메모리와 상위 메모리 블록 사이에서 최적으로 배치하여, 중요한 기본 메모리 영역의 가용 공간을 최대한 확보하려는 기능을 포함하게 되었다. 예를 들어 쿼터덱의 Optimize나 마이크로소프트의 MEMMAKER 같은 프로그램이 이러한 최적화 역할을 수행했다.

6. 종언

도스 확장자를 사용하는 게임(둠 등)이 등장하면서 메모리 제약 문제가 완화되었고, 윈도우, 특히 윈도우 95와 윈도우 98이 널리 보급되면서 대부분의 종료 후 상주 프로그램(TSR)은 점차 불필요해졌다. 일부 TSR은 새로운 운영체제 환경과 호환되지 않는 문제도 발생했다.[1][2][3]

이후 윈도우 NT 계열 운영체제가 등장하면서 TSR의 시대는 사실상 막을 내렸다. 이 운영체제들은 항상 보호 모드나 롱 모드에서 작동하며, 메모리 보호와 선점형 멀티태스킹을 지원하는 현대적인 구조를 갖추었다. 이를 통해 여러 프로그램과 장치 드라이버가 TSR과 같은 특별한 기법 없이도 동시에 안정적으로 실행될 수 있게 되었으며, 인터럽트 관리는 커널이 전담하게 되었다. 이로써 TSR은 기술적으로 필요성이 사라지고 점차 사용되지 않게 되었다.[1][2][3]

6. 1. DOS 확장자와 윈도우

도스 확장자를 사용한 게임들(초기 예시로 ''둠''이 있다)이 개발되면서 MS-DOS의 640KB 메모리 제한을 넘어서는 것이 가능해졌고, 이로 인해 종료 후 상주 프로그램(TSR)과 관련된 많은 문제들이 해결되었다. 윈도우, 특히 윈도우 95와 그 후속 운영 체제인 윈도우 98이 널리 사용되면서 대부분의 TSR은 더 이상 필요하지 않게 되었고, 일부는 윈도우 환경과 호환되지 않아 사용할 수 없게 되었다. 그럼에도 불구하고, Win16 기반 응용 프로그램들은 윈도우가 허용했기 때문에 인터럽트 서술자 테이블(IDT)을 직접 수정하는 등 TSR과 유사한 방식을 사용하는 경우가 있었다. 윈도우 Me는 사용자가 운영 체제를 종료하고 DOS 커널로 직접 부팅하는 것을 허용하지 않았기 때문에, 이 운영 체제 환경에서는 TSR이 사실상 쓸모없게 되었다.

윈도우 NT 계열 운영 체제들(윈도우 NT, 윈도우 2000, 윈도우 XP 등)은 MS-DOS를 완전히 대체했다. 이 운영 체제들은 항상 보호 모드나 롱 모드(64비트 버전의 경우)에서 실행되므로, TSR이 작동하는 데 필요한 리얼 모드로 전환하는 기능 자체가 비활성화되었다. 대신, 윈도우 NT 계열은 메모리 보호와 선점형 멀티태스킹 기능을 갖춘 현대적인 드라이버 및 서비스 프레임워크를 제공한다. 이를 통해 여러 프로그램과 장치 드라이버가 TSR과 같은 특별한 프로그래밍 기법 없이도 동시에 안정적으로 실행될 수 있게 되었다. 인터럽트 테이블의 수정과 관리는 운영 체제의 커널과 커널 모듈의 책임이 되었다.

6. 2. 윈도우 NT 계열

윈도우 NT 계열 운영체제(윈도우 2000, 윈도우 XP 등)는 기존의 DOS를 완전히 대체하며 등장했다. 이 운영체제들은 항상 보호 모드 또는 롱 모드(64비트 버전의 경우)에서 실행되므로, TSR이 작동하는 데 필수적이었던 리얼 모드로의 전환 기능이 비활성화되었다.

대신 윈도우 NT 계열은 메모리 보호와 선점형 멀티태스킹 기능을 갖춘 현대적인 드라이버 및 서비스 프레임워크를 도입했다. 이를 통해 여러 프로그램과 장치 드라이버가 TSR과 같은 특별한 프로그래밍 기법 없이도 동시에 안정적으로 실행될 수 있게 되었다. 커널과 그 모듈들이 인터럽트 테이블 수정을 전담하게 되었다. 이는 시스템 안정성 향상으로 이어졌다. 이러한 방식은 윈도우 95나 윈도우 98과 같은 이전 버전의 윈도우에서 일부 Win16 애플리케이션이 사용했던 TSR 유사 기법과는 다르며, NT 계열에서는 더 이상 허용되지 않는다.

7. 다른 운영체제

(내용 없음)

7. 1. macOS

macOS 이전의 Mac OS에서는 구현 방식은 다르지만 비슷한 목적으로 사용된 데스크 액세서리(Desk Accessory, DA)가 있었다. 초기 매킨토시의 운영체제는 MS-DOS와 같이 싱글 태스킹 방식이었기 때문에, 이러한 제약을 해결하기 위해 DA가 등장했다. DA는 특정 애플리케이션을 사용하던 중에도 언제든지 불러와 실행할 수 있는 작은 프로그램을 의미하며, 계산기가 대표적인 예이다. 여러 서드파티 개발사들이 다양한 애플리케이션을 DA 형태로 구현하여 제공했다. 예를 들어, 워드 프로세서 작업을 하면서 프로그램을 종료하지 않고도 그림판을 불러와 삽화를 그릴 수 있는 그림 그리기 소프트웨어 등이 있어, 멀티태스킹과 유사한 작업 환경을 구현했다.

참조

[1] 웹사이트 Beat the Bug—Computer Viruses http://www.pctoptips[...] 1998
[2] 웹사이트 HelpPC reference: INT 21,0 – Program Terminate http://stanislavs.or[...]
[3] 웹사이트 a list of TSR libraries http://hdebruijn.soo[...]
[4] 웹사이트 int 2D https://www.ctyme.co[...] 2019-11-14
[5] 웹사이트 TSR Libraries https://www.ctyme.co[...] 2016-06-19
[6] 문서 IBM PC DOS
[7] 문서 IBM PC DOS
[8] 문서 메모리를 단편화 방지
[9] 문서 Microsoft에서 나온 서적의 샘플 코드
[10] 문서 정보통신용어사전: 종료 후 상주 프로그램 - 기억 장치에 적재되어 실행한 후에도 기억 영역을 해방시키지 않고 그대로 상주하면서 키보드의 입력에 의해 다시 실행을 기동시킬 수 있는 프로그램. 다른 프로그램을 기동하기 전에 이 프로그램을 종료시킬 필요는 없으나 다른 프로그램을 위하여 사용할 수 있는 기억 영역의 크기는 감소된다.
[11] 웹사이트 BEAT THE BUG -- COMPUTER VIRUSES http://www.pctoptips[...] 2012-02-09
[12] 웹사이트 HelpPC reference: INT 21,0 - Program Terminate http://stanislavs.or[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com