다음을 통해 공유


Windows 콘솔 및 터미널 에코시스템 로드맵

이 문서는 Windows 콘솔 및 Windows 터미널 제품의 대략적인 로드맵입니다. 다음을 다룹니다.

  • Windows 콘솔 및 Windows 터미널이 Windows 및 기타 운영 체제에서 명령줄 애플리케이션의 에코시스템에 적합한 방식

  • 이 플랫폼을 위한 빌드뿐만 아니라 플랫폼 빌드의 일부인 제품, 기능 및 전략의 역사와 미래 로드맵입니다.

Microsoft의 현재 콘솔/터미널 시대의 초점은 Windows 플랫폼의 개발자에게 직접 일류 터미널 환경을 제공하고 클래식 Windows 콘솔 API를 단계적으로 폐지하여 pseudoconsole을 활용하는 가상 터미널 시퀀스로 대체하는 것입니다. Windows 터미널 은 이러한 전환을 개발자 커뮤니티에서 오픈 소스 협업 을 초대하고, 클라이언트 명령줄 및 터미널 호스팅 애플리케이션의 혼합 및 일치의 전체 스펙트럼을 지원하고, 다른 모든 플랫폼과 Windows 에코시스템을 통합하는 일류 환경으로의 전환을 보여줍니다.

정의

계속하기 전에 이 공간에서 사용되는 일반적인 용어의 정의를 숙지하는 것이 좋습니다. 일반적인 용어에는 명령줄(또는 콘솔) 애플리케이션, 표준 핸들(STDIN, , STDOUTSTDERR), TTY 및 PTY 디바이스, 클라이언트 및 서버, 콘솔 하위 시스템, 콘솔 호스트, 의사console터미널이 포함됩니다.

건축학

시스템의 일반 아키텍처는 클라이언트, 디바이스, 서버 및 터미널의 네 부분으로 구성됩니다.

명령줄 통신 흐름 차트 원본에서 클라이언트에서 디바이스, 서버, 터미널로 실행되는 대상으로

클라이언트

클라이언트는 텍스트 기반 인터페이스를 사용하여 사용자가 마우스 기반 사용자 인터페이스가 아닌 명령을 입력하고 결과의 텍스트 표현을 반환할 수 있도록 하는 명령줄 애플리케이션입니다. Windows에서 콘솔 API는 클라이언트와 디바이스 간의 통신 계층을 제공합니다. (디바이스 제어 API를 사용하는 표준 콘솔 핸들일 수도 있습니다).

디바이스

디바이스는 클라이언트와 서버라는 두 프로세스 사이의 중간 메시지 처리 통신 계층입니다. Windows에서는 콘솔 드라이버입니다. 다른 플랫폼에서는 TTY 또는 PTY 디바이스입니다. 파일, 파이프 및 소켓과 같은 다른 디바이스는 전체 트랜잭션이 일반 텍스트이거나 가상 터미널 시퀀스를 포함하지만 Windows 콘솔 API에서는 사용하지 않는 경우 이 통신 채널로 사용할 수 있습니다.

서버

서버는 클라이언트에서 요청한 API 호출 또는 메시지를 해석합니다. 클래식 운영 모드의 Windows에서 서버는 화면에 출력을 표시하는 사용자 인터페이스도 만듭니다. 또한 서버는 동일한 모듈에 번들로 제공되는 터미널과 같이 드라이버를 통해 클라이언트에 응답 메시지를 다시 보내기 위해 입력을 수집합니다. pseudoconsole 모드를 사용하는 대신 연결된 터미널에 가상 터미널 시퀀스로 이 정보를 표시하는 것은 번역기일 뿐입니다.

터미널

터미널은 사용자에게 그래픽 디스플레이 및 대화형 서비스를 제공하는 최종 계층입니다. 입력을 캡처하고 가상 터미널 시퀀스로 인코딩하여 결국 클라이언트 STDIN에 도달합니다. 또한 화면의 프레젠테이션을 위해 클라이언트 STDOUT 에서 다시 수신하는 가상 터미널 시퀀스를 수신하고 디코딩합니다.

추가 연결

여러 역할을 수행하는 애플리케이션을 엔드포인트 중 하나에 연결하여 추가 연결을 수행할 수 있습니다. 예를 들어 SSH 세션에는 두 가지 역할이 있습니다. 즉, 한 디바이스에서 실행되는 명령줄 애플리케이션의 터미널 이지만 수신된 모든 정보를 다른 디바이스의 클라이언트 역할에 전달합니다. 이 연결은 광범위한 시나리오 유연성을 제공하는 디바이스 및 컨텍스트에서 무기한으로 발생할 수 있습니다.

비 Windows 플랫폼에서 서버터미널 역할은 API 집합과 가상 터미널 시퀀스 간에 변환 호환성 계층이 필요하지 않으므로 단일 단위입니다.

Microsoft 제품

이제 모든 Microsoft Windows 명령줄 제품을 오픈 소스 리포지토리인 Microsoft/터미널의 GitHub에서 사용할 수 있습니다.

Windows 콘솔 호스트

명령줄 애플리케이션의 기존 Windows 사용자 인터페이스입니다. 연결된 명령줄 애플리케이션에서 호출된 모든 콘솔 API 서비스를 처리합니다. 또한 Windows 콘솔은 이러한 모든 애플리케이션을 대신하여 GUI(그래픽 사용자 인터페이스) 표현을 처리합니다. 시스템 디렉터리 또는 오픈 소스 형식에서 conhost.exeopenconsole.exe 찾을 수 있습니다. Windows 운영 체제와 함께 제공됩니다. 또한 pseudoconsole 인프라의 더 up-to-date 구현을 위해 오픈 소스 리포지토리에서 빌드된 다른 Microsoft 제품에서도 찾을 수 있습니다. 위의 정의에 따라, 일반적으로 결합된 서버 및 터미널 역할 또는 기본 pseudoconsole 인프라를 통한 서버 전용 역할에서 작동합니다.

Windows 터미널

명령줄 애플리케이션에 대한 새로운 Windows 인터페이스입니다. Windows 터미널은 모든 비 Windows 플랫폼과 마찬가지로 Pseudoconsole 을 사용하여 API 서비스 및 텍스트 기반 애플리케이션 상호 작용 간의 문제를 구분하는 자사 예제로 사용됩니다.

Windows 터미널은 Windows용 플래그십 텍스트 모드 사용자 인터페이스입니다. 에코시스템의 기능을 보여주며 Windows 개발을 다른 플랫폼과 통합하는 방향으로 이끌고 있습니다. Windows 터미널은 Windows API 및 프레임워크의 기록과 영역을 아우르는 강력하고 복잡한 최신 애플리케이션을 빌드하는 방법의 예이기도 합니다. 위의 정의에 따라 이 제품은 터미널 역할에서 작동합니다.

주요 역사적 이정표

콘솔 하위 시스템의 주요 역사적 이정표는 2014년 이전에 구현된 후 Windows 10 시대에 명령줄에 대한 새로운 포커스가 형성된 2014년 이후 수행된 작업의 개요로 이동합니다.

초기 구현

[1989-1990s] 초기 콘솔 호스트 시스템은 Windows 운영 체제 내에서 DOS 환경의 에뮬레이션으로 구현되었습니다. 해당 코드는 해당 DOS 환경을 나타내는 명령 프롬프트cmd.exe와 얽히고 협조적입니다. 콘솔 호스트 시스템 코드는 명령 프롬프트 인터프롬프트/셸과 책임 및 권한을 공유합니다. 또한 CMD와 유사한 방식으로 서비스를 수행하기 위해 다른 명령줄 유틸리티에 대한 기본 수준의 서비스를 제공합니다.

CJK용 DBCS

[1997-1999] 이 무렵에는 CJK(중국어, 일본어 및 한국어) 시장을 지원하기 위해 DBCS 지원("더블바이트 문자 집합")이 도입되었습니다. 이러한 노력으로 인해 콘솔 내에서 많은 쓰기 및 읽기 메서드를 제공하여 싱글바이트 문자를 처리하는 "서부" 버전과 방대한 문자 배열을 나타내기 위해 2바이트가 필요한 "동부" 버전에 대한 대체 표현을 제공합니다. 이 배분은 콘솔 환경에서 셀의 확장 표현을 포함 1 또는 2 셀 너비, 여기서 1 셀은 좁은 (너비 보다 높이) 2 셀은 넓은, 전체 너비, 또는 그렇지 않으면 일반적인 중국어, 일본어 및 한국어 표기법이 새겨질 수 있는 사각형.

보안/격리

[2005-2009] 중요한 시스템 프로세스 csrss.exe내에서 실행되는 콘솔 하위 시스템 환경을 사용하여 다양한 액세스 수준에서 다양한 클라이언트 애플리케이션을 매우 중요하고 권한 있는 단일 프로세스에 연결하는 것은 특히 위험한 것으로 나타났습니다. 이 시대에 콘솔 하위 시스템은 클라이언트, 드라이버 및 서버 애플리케이션으로 분할되었습니다. 각 애플리케이션은 자체 컨텍스트에서 실행되어 각 애플리케이션의 책임과 권한을 줄일 수 있습니다. 이 격리는 콘솔 하위 시스템의 모든 오류가 더 이상 다른 중요한 프로세스 기능에 영향을 주지 않으므로 시스템의 일반적인 견고성을 향상했습니다.

사용자 환경 개선 사항

[2014-2016] 조직 전체의 다양한 팀이 콘솔 하위 시스템을 오랫동안 분산한 후, 새로운 개발자 중심 팀이 콘솔의 개선을 소유하고 추진하도록 구성되었습니다. 이 시간 동안 향상된 기능으로는 줄 선택, 부드러운 창 크기 조정, 텍스트 재배치, 복사 및 붙여넣기, 높은 DPI 지원, "서부" 및 "동부" 스토리지와 스트림 조작 알고리즘 간의 분할 수렴을 비롯한 유니코드에 대한 포커스가 포함되었습니다.

가상 터미널 클라이언트

[2015-2017]Linux용 Windows 하위 시스템이 출시되면서 Microsoft는 Windows의 Docker 환경을 개선하기 위한 노력과 OpenSSH 를 최고의 명령줄 원격 실행 기술로 채택하면서 가상 터미널 시퀀스의 초기 구현이 콘솔 호스트에 도입되었습니다. 이를 통해 기존 콘솔은 해당 환경에서 해당 Linux 네이티브 애플리케이션에 직접 연결되고 그래픽 및 텍스트 특성을 디스플레이에 렌더링하고 적절한 언어로 사용자 입력을 반환하는 터미널 역할을 할 수 있습니다.

가상 터미널 서버

[2018] 지난 20 년 동안 받은 편지함 콘솔 호스트에 대한 타사 대안은 풍부한 사용자 지정 및 탭 인터페이스를 중심으로 추가 개발자 생산성을 제공하기 위해 만들어졌습니다. 이러한 애플리케이션은 콘솔 호스트 창을 실행하고 숨기는 데 여전히 필요했습니다. 보조 "클라이언트" 애플리케이션으로 연결하여 기본 명령줄 클라이언트 애플리케이션이 작동함에 따라 폴링 루프에서 버퍼 정보를 긁어냅니다. 그들의 목표는 다른 플랫폼과 마찬가지로 터미널이 되는 것이었으나 터미널을 교체할 수 없는 Windows 세계에서였습니다.

이 기간에 의사콘솔 인프라가 도입되었습니다. Pseudoconsole은 모든 애플리케이션이 비대화형 모드에서 콘솔 호스트를 시작하고 사용자의 최종 터미널 인터페이스가 되도록 허용합니다. 이러한 노력의 주요 제한 사항은 다른 모든 플랫폼에서 예상되는 것과 일치하는 대체 서버 호스팅 인터페이스인 가상 터미널 시퀀스를 제공하면서 게시된 모든 Windows 콘솔 API를 무기한으로 서비스하는 Windows의 지속적인 호환성 약속이었습니다. 따라서 이러한 노력은 클라이언트 단계의 미러 이미지를 수행했습니다. 의사콘솔은 화면에 표시되는 내용을 위임된 호스트에 대한 가상 터미널 시퀀스 로 프로젝션하고 클라이언트 애플리케이션 사용을 위한 Windows 형식 입력 시퀀스로 회신을 해석합니다.

미래를 위한 로드맵

터미널 애플리케이션

[2019-Now] 새 Windows 터미널에 초점을 맞춘 콘솔 하위 시스템의 오픈 소스 시대입니다. 2019년 5월 Microsoft Build 컨퍼런스에서 발표된 Windows 터미널은 전적으로 Microsoft/터미널의 GitHub에 있습니다. pseudoconsole을 위한 세련된 플랫폼 위에 Windows 터미널 애플리케이션을 빌드하는 것이 이 시대의 초점이 될 것이며, Windows 플랫폼의 개발자에게 직접 일류 터미널 환경을 제공합니다.

Windows 터미널WinUI 인터페이스 기술, MSIX 패키징 모델 및 C++/WinRT 구성 요소 아키텍처를 비롯한 플랫폼을 플랫폼 자체의 유효성 검사로 소개하려고 합니다. Windows 터미널은 개발자의 생산성을 높이기 위해 필요에 따라 Windows 조직이 앱 플랫폼을 열고 발전하도록 유도하고 있습니다. Windows 터미널의 고유한 전원 사용자 및 개발자 요구 사항 집합은 이러한 시장이 Windows에서 진정으로 필요로 하는 것에 대한 최신 Windows 플랫폼 요구 사항을 충족합니다.

Windows 운영 체제 내에서는 Windows 터미널, ConPTY가상 터미널 시퀀스를 위해 기본 위치에서 클래식 콘솔 호스트 사용자 인터페이스를 사용 중지하는 것이 포함됩니다.

마지막으로, 이 시대는 Windows 터미널 제품이든 대체 터미널이든 기본 환경보다 완전한 선택을 제공하려고 합니다.

클라이언트 지원 라이브러리

[미래] 클라이언트 쪽 의 가상 터미널 시퀀스에 대한 지원 및 설명서를 통해 Windows 명령줄 유틸리티 개발자는 클래식 Windows API를 통해 먼저 가상 터미널 시퀀스를 사용하여 모든 플랫폼과 통합된 에코시스템의 이점을 얻는 것이 좋습니다. 그러나 한 가지 중요한 누락된 점은 다른 플랫폼에는 읽기 라인ncurses와 같은 그래픽 디스플레이와 같은 입력을 처리하기 위한 다양한 클라이언트 쪽 도우미 라이브러리가 있다는 것입니다. 이 특정 미래 로드맵 요소는 에코시스템이 제공하는 기능과 클래식 콘솔 API를 통해 Windows 명령줄 애플리케이션에서 가상 터미널 시퀀스의 채택을 가속화할 수 있는 방법을 설명합니다.

시퀀스 통과

[미래] 가상 터미널 클라이언트와 서버 구현의 조합을 사용하면 클라이언트 명령줄 및 터미널 호스팅 애플리케이션의 전체 혼합 및 일치를 허용합니다. 이 조합은 클래식 Windows 콘솔 API 또는 가상 터미널 시퀀스에 대해 말할 수 있지만 이를 클래식 호환 Windows 메서드로 변환한 다음 보다 범용 가상 터미널 메서드로 다시 변환하는 오버헤드 비용이 발생합니다.

시장이 Windows에서 가상 터미널 시퀀스와 UTF-8을 충분히 채택하면 콘솔 호스트의 변환/해석 작업을 선택적으로 사용하지 않도록 설정할 수 있습니다. 그런 다음 콘솔 호스트는 간단한 API 호출 서비스 공급자가 되고 디바이스 호출에서 pseudoconsole을 통해 호스팅 애플리케이션으로 릴레이합니다. 이렇게 변경하면 성능이 향상되고 클라이언트 애플리케이션과 터미널 간에 말할 수 있는 시퀀스의 언어가 최대화됩니다. 이 변경을 통해 추가 대화형 시나리오를 사용하도록 설정하고 (마지막으로) 명령줄 애플리케이션 공간에서 다른 모든 플랫폼의 제품군과 일치하도록 Windows 세계를 가져옵니다.