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 명령줄 제품은 이제 GitHub의 오픈 소스 리포지토리 microsoft/terminal에서 사용할 수 있습니다.

Windows 콘솔 호스트

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

Windows 터미널

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

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

중요한 역사적 사건

콘솔 하위 시스템과 관련된 중요한 역사적 사건은 2014년 이전의 구현으로 시작된 이후, Windows 10 시대에 명령줄에 대한 새로운 초점이 형성된 2014년 이후에 수행된 작업 개요로 이동합니다.

초기 구현

[1989년-1990년대] 초기 콘솔 호스트 시스템은 Windows 운영 체제 내에서 DOS 환경의 에뮬레이션으로 구현되었습니다. 코드는 해당 DOS 환경의 표현인 명령 프롬프트cmd.exe를 사용하여 연결되고 함께 작동합니다. 콘솔 호스트 시스템 코드는 명령 프롬프트 interpreter/shell과 책임 및 권한을 공유합니다. 또한 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 인프라가 도입되었습니다. Pseudoconsole을 사용하면 모든 애플리케이션은 콘솔 호스트를 비 대화형 모드로 시작하고 사용자의 최종 터미널 인터페이스가 될 수 있습니다. 이 과정에서 가장 어려웠던 점은 다른 모든 플랫폼에서 필요한 조건을 충족하는 서버 호스팅 인터페이스 대체품인 가상 터미널 시퀀스를 제공하면서도 게시된 모든 Windows 콘솔 API를 기한 없이 계속 제공한다는 지속적인 Windows 호환성 약속이었습니다. 따라서 이 작업은 클라이언트 단계와 똑같이 진행되었습니다. pseudoconsole은 위임된 호스트의 가상 터미널 시퀀스로 화면에 표시할 내용을 프로젝션하고 그 응답을 클라이언트 애플리케이션에서 사용할 Windows 형식 입력 시퀀스로 해석합니다.

향후 로드맵

터미널 애플리케이션

[2019년-현재] 새 Windows 터미널에 초점을 맞춘 콘솔 하위 시스템의 오픈 소스 시대입니다. 2019년 5월 Microsoft Build 컨퍼런스에서 발표된 Windows 터미널이 GitHub microsoft/terminal에 온전히 보관되어 있습니다. 현 시대에는 구체화된 pseudoconsole용 플랫폼을 기반으로 Windows 터미널 애플리케이션을 빌드하여 Windows 플랫폼의 개발자에게 최고의 터미널 환경을 직접 제공하는 데 집중할 것입니다.

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

여기에는 Windows 운영 체제 내에서 Windows 터미널, ConPTY 및 가상 터미널 시퀀스에 도움이 되도록 기본 위치의 클래식 콘솔 호스트 사용자 인터페이스를 사용 중지하는 것이 포함되어 있습니다.

마지막으로, Windows 터미널 제품이든 다른 대체 터미널이든 기본 환경을 원하는 대로 선택할 수 있도록 하는 것이 이 시대의 목적입니다.

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

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

시퀀스 통과

[미래] 가상 터미널 클라이언트와 서버의 조합을 통해 클라이언트 명령줄과 터미널 호스팅 애플리케이션을 완전히 혼합하고 일치시킬 수 있습니다. 이 조합은 클래식 Windows 콘솔 API 또는 가상 터미널 시퀀스에 사용할 수 있지만, 클래식 호환 Windows 메서드로 변환한 후 보다 일반적인 가상 터미널 메서드로 다시 변환하는 데 오버헤드 비용이 발생합니다.

시장에서 Windows 기반의 가상 터미널 시퀀스 및 UTF-8을 충분히 도입한 후에는 콘솔 호스트의 변환/해석 작업을 선택적으로 해제할 수 있습니다. 그러면 콘솔 호스트는 간단한 API 호출 서비스 공급자가 되어 pseudoconsole을 통해 디바이스 호출에서 호스팅 애플리케이션으로 릴레이합니다. 이렇게 변경하면 성능이 향상되고 클라이언트 애플리케이션과 터미널 사이에서 사용할 수 있는 시퀀스 언어가 최대화됩니다. 이러한 변경을 통해 추가 상호 작용 시나리오를 사용할 수 있으며 (마지막으로) Windows 환경을 명령줄 애플리케이션 공간의 다른 모든 플랫폼 패밀리와 함께 사용할 수 있게 됩니다.