체류 종료 프로그램

Terminate-and-stay-resident program

Terminate-and-Stay-Resident 프로그램(일반적으로 TSR)은 DOS에서 실행되는 컴퓨터 프로그램으로 시스템 호출을 사용하여 DOS에 대한 제어를 마치 완료된 것처럼 되돌리지만 나중에 [1]다시 활성화할 수 있도록 컴퓨터 메모리에 남아 있습니다.이 기술은 한 번에 하나의 프로그램 또는 작업만 실행하는 DOS의 한계를 부분적으로 극복했습니다.TSR은 DOS에서만 사용되며 Windows에서는 사용되지 않습니다.

일부 TSR은 컴퓨터 사용자가 단축키를 사용하여 다른 프로그램에서 작업할 때 하루에 여러 번 호출할 수 있는 유틸리티 소프트웨어입니다.볼랜드 사이드킥은 이런 유형의 초기 인기 있는 사례였다.그 외의 드라이버는, operating system이 직접 서포트하지 않는 하드웨어의 디바이스 드라이버로서 기능합니다.

사용

일반적으로 DOS는 한 번에 하나의 프로그램만 실행할 수 있습니다.프로그램이 종료되면 시스템 호출을 사용하여 DOS로 제어를 되돌립니다. INT 21h/4Ch.[2]사용된 메모리와 시스템리소스는 미사용으로 표시됩니다.이로 인해 프로그램을 모두 새로고침하지 않고서는 프로그램을 재시작할 수 없습니다.단, 프로그램이 INT 27h 또는 INT 21h/31h로 종료되면 운영체제는 메모리의 특정 부분을 재사용하지 않습니다.

원래의 콜 INT 27h는 「종료하지만 상주하고 있다」라고 불리고 있기 때문에, 「TSR」라고 불립니다.이 콜을 사용하면 프로그램은 최대 64KB의 메모리를 확보할 수 있습니다.MS-DOS 버전 2.0 에서는, INT 21h/31h( 「Keep Process」)라고 하는 개량된 콜이 도입되어 이 제한이 없어지고, 프로그램이 종료 코드를 반환할 수 있게 되었습니다.이 콜을 발신하기 전에 프로그램은 자신을 가리키는 인터럽트 핸들러를 1개 또는 여러 개 설치하여 다시 호출할 수 있습니다.하드웨어 인터럽트 벡터를 설치하면 이러한 프로그램이 하드웨어 이벤트에 반응할 수 있습니다.소프트웨어 인터럽트 벡터를 설치하면 현재 실행 중인 프로그램에서 인터럽트 벡터를 호출할 수 있습니다.타이머 인터럽트 핸들러를 설치하면 TSR을 정기적으로 실행할 수 있습니다(ISA 및 프로그램 가능한 인터벌 타이머, 특히 "IBM PC 호환" 섹션 참조).

인터럽트 벡터를 사용하는 일반적인 방법에는 현재 값(주소)을 읽고 TSR의 메모리 공간에 저장하여 자체 코드의 주소로 대체하는 방법이 있습니다.저장된 주소는 TSR에서 호출되며 실제로는 인터럽트 서비스 루틴(ISR)이라고도 불리는 인터럽트 핸들러의 단일 링크 리스트를 형성합니다.ISR 의 인스톨 순서는, 인터럽트 또는 인터럽트 벡터의 체인 또는 후크라고 불립니다.

인터럽트 벡터를 체인으로 함으로써 TSR은 컴퓨터를 완전히 제어할 수 있습니다.TSR에는, 다음의 2개의 동작 중 하나가 있습니다.

  • 이전에 같은 인터럽트 벡터를 변경한 다른 TSR을 호출하지 않음으로써 인터럽트를 완전히 제어합니다.
  • 오래된 인터럽트 벡터를 호출하여 다른 TSR과 캐스케이드합니다.이는 실제 코드를 실행하기 전 또는 실행 후에 수행할 수 있습니다.이렇게 하면 TSR은 각각 다음 콜을 발신하는 체인을 형성할 수 있습니다.

Terminate-and-Stay-Stay-Resident 방식은 대부분의 DOS 바이러스 및 기타 말웨어에서 사용되며 PC를 제어하거나 백그라운드에 남아 있을 수 있습니다.이 멀웨어는 디스크 I/O 또는 실행 이벤트에 대해 실행 파일(.EXE 또는.COM) 파일을 실행하고 데이터 파일을 엽니다.

TSR 는, DOS 기동 시퀀스중에(AUTOEXEC 로부터 등) 언제라도 로드할 수 있습니다.BAT) 또는 사용자의 요청에 따라(예: Borland의 Sidekick and Turbo Debugger, Quicken의 QuickPay 또는 FunStuff Software의 Personal Calendar).DOS 자체의 일부에서는 특히 DOS 버전 5.0 이후에 이 기술을 사용합니다.예를 들어 DOSKEY 명령줄 에디터 및 기타 다양한 유틸리티는 명령줄에서(수동으로 또는 AUTOEXEC에서) 실행하여 설치합니다.BAT 또는 CONFIG 내에서 통과합니다.SYS)를 통해 디바이스 드라이버로서 로드하는 것이 아니라DEVICE명령어를 지정합니다.시스템

일부 TSR은 스스로 언로드할 방법이 없기 때문에 재부팅할 때까지 메모리에 남아 있습니다.그러나 외부에서는 MARK와 같은 유틸리티를 사용하여 언로딩이 가능합니다.EXE/릴리스TurboPower 소프트웨어의 EXE 콤보 또는 소프트 리부트 TSR이 특정 키 조합을 포착하여 로드된 모든 TSR을 해제합니다.ISR 체인은 개별적으로 링크되어 있으며 TSR은 이전 체인에 대한 링크를 원하는 위치에 저장할 수 있기 때문에 일반적으로 TSR이 체인을 분리할 수 있는 방법은 없습니다.따라서 보통 TSR을 언로드할 때는 stub를 메모리에 남겨두어야 하며 이로 인해 메모리 플래그멘테이션이 발생합니다.이 문제는 TesSeRact와 AMIS와 [3]같은 TSR 협력 프레임워크를 발생시켰다.

공유 중단

다수의 TSR이 같은 인터럽트를 공유하는 문제를 관리하기 위해 Alternate Multiplex Interrupt Specification(AMIS; 대체 멀티플렉스 인터럽트 사양)이라고 불리는 방법이 Ralf D에 의해 제안되었습니다. 갈색은 INT 2Fh를 통해 제공되던 기존 서비스보다 개선되었습니다.AMIS는 소프트웨어 인터럽트를 제어된 방식으로 공유할 수 있는 방법을 제공합니다.원래 x86 프로세서의 하드웨어 인터럽트를 공유하기 위해 개발된 IBM의 Interrupt Sharing Protocol을 모델로 합니다.AMIS 서비스는 Int 2Dh를 [4]통해 이용할 수 있습니다.

그 제안은 당시 프로그래머들 사이에서 널리 받아들여진 적이 없었다.그것은 다양한 [5]정교함의 다른 경쟁 사양과 함께 존재했다.

장애

TSR은 DOS의 한계를 극복하는 데 매우 유용하거나 심지어 필수적이지만 문제아로 정평이 나 있습니다.많은 경우 문서화되어 있거나 문서화되어 있지 않은 다양한 방법으로 운영체제를 가로채고 있으며, 특정 애플리케이션이나 다른 TSR과 함께 사용할 경우 활성화 또는 비활성화 시 시스템이 크래쉬하는 경우가 많습니다.위에서 설명한 바와 같이 일부 바이러스 및 기타 악성코드는 TSR로 코드화되어 있어 의도적으로 문제가 되고 있습니다.또, DOS 에서는, 물리 RAM 의 대용량을 가지는 프로그램도 포함해, 모든 프로그램을 RAM 의 최초의 640 KB(기존의 메모리)에 로드할 필요가 있습니다.TSR도 예외는 아닙니다.따라서 다른 응용 프로그램에서 사용할 수 없는 640KB의 청크를 가져옵니다.즉, TSR의 작성은 가능한 한 작은 크기를 달성하고, 다른 벤더의 많은 소프트웨어 제품과의 호환성을 확인하는 것이 과제였습니다.이것은 많은 경우 매우 짜증나는 작업입니다.

1980년대 후반과 1990년대 초반에는 PC 플랫폼 상의 많은 비디오 게임이 이 한계를 극복하고 TSR을 위한 공간이 점점 줄어들었으며, 심지어 CD-ROM 드라이버와 같은 필수적인 게임도 마찬가지였습니다.또한 필요한 TSR을 유지하면서 게임을 실행할 수 있는 충분한 빈 RAM이 확보되도록 배치하는 것은 하나의 예술이 되었습니다.많은 게이머들이 게임마다 구성이 다른 부팅 디스크를 여러 개 가지고 있었습니다.이후 버전의 MS-DOS에서는 "부팅 메뉴" 스크립트를 사용하여 단일 "부팅 디스크"를 통해 다양한 구성을 선택할 수 있었습니다.1990년대 중후반에는 많은 게임들이 여전히 DOS용으로 작성되었지만, 640KB의 제한은 결국 게임의 데이터나 코드의 일부를 처음 1MB의 메모리 위에 두고 640KB 미만의 코드를 사용하여 확장 메모리에 액세스함으로써 극복되었다(DOS 확장 방법을 사용). 코드는 오버레이로 가장 낮은 1MB의 RAM으로 스왑되었다.많은 오버레이를 사용한 프로그래밍은 그 자체로 어려운 과제이기 때문에 프로그램이 너무 커서 512KB에 완전히 들어갈 수 없게 되면 확장 메모리는 거의 항상 VCPI 또는 DPMI를 구현하는 서드파티제의 DOS 익스텐더를 사용하여 사용할 수 있게 됩니다.이는 1MB 경계 이상의 메모리에 훨씬 쉽고 빠르게 접근할 수 있기 때문입니다.e: x86 프로세서가 실제 모드에서 보호 모드로 전환되었을 때.다만, DOS 및 대부분의 DOS 프로그램은 리얼 모드로 동작하기 때문에(VCPI 또는 DPMI는 2개의 모드를 왔다 갔다 하는 것으로, 보호 모드 프로그램을 DOS 및 시스템의 나머지 부분에서는 리얼 모드 프로그램처럼 보이게 합니다), DOS TSR 및 디바이스 드라이버도 리얼 모드로 동작하기 때문에, 제어가 되면, DOS 익스텐더는 리얼 모드로 돌아옵니다.(DPMS나 CLOCKING 등의 기술을 사용하지 않는 한) 제어가 해제되어 시간 패널티가 발생합니다.

돌아가다

1980년대 후반 확장 메모리 보드, 특히 인텔 80386 프로세서가 등장하면서 TSR 로드에 640KB 이상의 메모리를 사용할 수 있게 되었습니다.이를 위해서는 확장 메모리 매니저라는 복잡한 소프트웨어 솔루션이 필요했습니다.일부 메모리 매니저는 QRAM과 QEMM by Quarterdeck, 386MAX by Qualitas, CEMM by Compaq, 그리고 이후 EMM386 by Microsoft입니다.640KB 이상의 TSR 로드에 사용할 수 있는 메모리 영역을 "Upper Memory Blocks"(UMB; 상위 메모리 블록)라고 하며, 이에 프로그램을 로드하는 영역을 "Loading High"(높이 로드)라고 합니다.이후 메모리 매니저는 메모리 부족과 고메모리 간에 TSR을 할당하는 최선의 방법을 결정함으로써 최초 640KB의 사용 가능한 공간을 최대화하려고 하는 Quarterdeck의 Optimize나 Microsoft의 MEMMAKER 등의 프로그램을 포함하기 시작했습니다.

사양

DOS 익스텐더를 사용한 게임의 개발로 (640KB의 장벽을 뛰어넘은 초기 예로는 Doom이었다) TSR과 관련된 많은 문제들이 사라졌고, 특히 Microsoft Windows와 Windows 95(이후 Windows 98)의 광범위한 채택으로 대부분의 TSR이 불필요해지고 TSR과 호환되지 않는 일부 TSR이 사라졌습니다.Windows 에서는 허가하고 있기 때문에, Win16 애플리케이션은 인터럽트 디스크립터 테이블(IDT)의 패치등의 TSR과 같은 트릭을 실행할 수 있습니다.

Windows Me 및 Windows NT(Windows XP의 소비자용 운영체제 포함)는 항상 보호모드 또는 롱모드로 실행되므로 TSR이 기능하기 위해 필요한 리얼모드로 전환할 수 없습니다.대신 이들 운영체제는 메모리 보호와 프리엠프티브 멀티태스킹 기능을 갖춘 최신 드라이버와 서비스 프레임워크를 갖추고 있어 특별한 프로그래밍 트릭 없이 여러 프로그램과 디바이스 드라이버를 동시에 실행할 수 있습니다.커널과 그 모듈은 인터럽트 테이블의 수정을 전적으로 담당합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Maybury, Rick (1998). "Beat the Bug—Computer Viruses". PC Top Tips. Retrieved 2012-02-09.
  2. ^ [1] HelpPC 레퍼런스: INT 21,0 –프로그램 종료
  3. ^ 프레임워크라고도 불리는 웨이백 머신에서 아카이브된 2007-08-17 TSR 라이브러리 목록.
  4. ^ "int 2D". Archived from the original on 2017-12-01. Retrieved 2019-11-14.
  5. ^ "TSR Libraries". 2016-06-19. Archived from the original on 2016-06-19. Retrieved 2019-11-14.

외부 링크