Engineering Windows 7

Windows 7 부팅 애니메이션 엔지니어링

 

 

 Windows 7에 대한 논의에서 부팅/시작의 시퀀스 및 부팅을 신속히 행하는 것이 얼마나 중요한지 알았습니다. 동시에 최대 절전 모드 상태에서 머신을 다시 시작할 때 또는 머신을 켰을 때 HDD 라이트가 반짝반짝 하는 것을 바라보는 것이 얼마나 지루한 일인지도 이해하고 있습니다. PC를 실행 했을 때의 첫경험을 향상시키기 위해, 부팅 시퀀스 개선에 착수했습니다. 매우 간단한 일이라 생각하실지 모르지만 문제해결은 그렇지 않습니다. 우리의 목표는 시스템 부팅 성능에 영향을 미치지 않고 즐겁게 하는 것입니다. 이 엔지니어링에 대한 설명과 부팅 시퀀스을  해설하기 위해 코어 사용자 경험팀의 프로그램 관리자인 Karen Wong이 이 글을 집필했습니다. --Steven-

디자인

사람과 감정적으로 연결되어 있는 소프트웨어 특징의 일부를 언급하기 위해 「퍼스낼러티 (개성)」라는 말을 사용했습니다. 「light (빛)」와「energy (에너지)」는 Windows 7 의 퍼스낼러티를 표현하기 위해서 사용합니다.

디자인 관점에서 말하면, 기능의 시각적 표현은 성능과 품질에 대한 사용자의 사고 방식에  중요한 역할을 합니다. 우리의 목적은 Windows 를 멋지게 실행하는 것으로, Windows 7 의 퍼스낼러티인 “light”와 “energy”에서 온 것입니다. 그리고, 자연에서 이것들이 이루는 형태들이 디자인 팔레트가 되었습니다. 예를 들어, 「bioluminescence (생물 발광)」, 「organic (유기적인)」, 「humble beauty (소박한 아름다움)」, 「atmosphere (분위기)」등이 브레인 스토밍(brainstorming)에서 자주 언급된 말이었습니다. 다소 진부하게 들릴지도 모르지만, Windows 7 의 전체적인 목표입니다.

20개 이상의 부팅 시퀀스 디자인을  생성 및 리뷰, 테스트하였습니다. 디자인은 색 채도나 밝기, 움직임의 복잡함, 조명 효과등에 의해서 달라집니다.  다음은 설계 중에 그려진 스케치입니다:

 

Windows 7 의 최종 디자인은 4가지 방향에서 에너지가 접근하여 하나가 되고, 창에 투영된 빛을 형성한다는 것입니다 (물론, Windows의  창과 닮은 것은 우연이 아닙니다!). .

최고의 성능

만약 모든 것을 Vista 와 같이 부팅 애니메이션을 새로운 폴더 Windows 7 용으로만 업데이트 한다면, 우리가 목표로 하는 새로운 폴더 수준의 성능이과 품질을 달성할 수 없습니다. 실제로, Windows 7에서 새로운 폴더 부팅 애니메이션을 구현하려면 방대한 코드 변경이 필요합니다.

Vista에서 부팅 로더는 640x480 의 저해상도 스크린을 사용하며, 녹색 진행 상황 막대에 필요한 파일크기도 매우 작습니다. 게다가 Vista 부팅 스크린은 색농도도 낮고, 16 bpp (bit per pixel) 입니다. Windows 7에서는 새로운 폴더 부팅 애니메이션에서 풍부한 색채를 구현하기 위해 32 bpp 로 늘렸습니다. Vista에서 실행시의 진행 상황을 보여주는 업데이트는 CPU 경유로 구현했지만, I/O 시간의 영향을 받기 쉽기 때문에 가끔 애니메이션에 어려움이 발생합니다. 저해상도의 스크린으로, 색농도도 한정되고, 영향을 받기 쉬워 Windows 7에서 작업을 하려면 많은 수고를 해야 합니다.

우선, 부팅 애니메이션을 표시하는데, Windows 7 부팅 로더에서는 지금까지와는 다른 메커니즘을 사용합니다. 컴퓨터의 데이터 보존부분 (BIOS 또는 UEFI)에서 frame buffer에 포인터를 설정하여, 고해상도의 이미지 (1024 x 768)를 표시합니다. 커널과 실행에 필요한 장치 드라이버가 메모리를 로드하는 동안에 이미지를 애니메이션화합니다. 디스플레이용의 네이티브 그래픽 드라이버는 아직 메모리에 로드되어 초기화되지 않기 때문에 애니메이션은 CPU 를 사용하고, 또 그래픽 디스플레이의 frame buffer를 업데이트 하여 실행됩니다.  성능을 신속화하기 위해서 CPU 가 기입을 병용 하는 캐시를 사용합니다.

Michael Fortin 에 의한 부팅 성능에 대해 블로그에서 실행 초기 단계는 커널, 장치 드라이버 파일 및 그 다른 시스템구성요소의 파일을 로드하여, I/O 의 제약을 받는 것이 설명됩니다. 따라서 실행 초기에 지연이 발생하는 것을 피하기 위해, 부팅 애니메이션 크기를 스크린의 좁은 범위로 한정했습니다. 넓은 크기의 애니메이션은 그 만큼 큰 애니메이션의 이미지를 로드해야 하기때문에, 그 결과 파일 I/O 가 증가합니다. 애니메이션의 이미지는 비트맵을 리소스로서 압축되고, WIM 이미지 압축에 의해 압축됩니다. WIM 이미지 압축은 전체적인 파일크기를 줄여서 로드하는데 필요한 I/O 를 줄일 수 있습니다. 스크린의 좁은 범위에 애니메이션을 표시하여 약간 낮은 프레임비율을 사용하여, frame buffer를 업데이트하는 CPU 오버헤드를 필요 최저한의 수준으로 유지하여, 실행 시간에 오버헤드를 추가합니다.

실행 성능 뿐만 아니라 품질을 향상하기 위한 변화도 있습니다. 그것은 그래픽 모드의 마이그레이션을 줄이는 것입니다. 이 마이그레이션은 그래픽 하부구조나 Windows 셸의 초기화 시에 일어납니다. Vista에서는 이 때문에 사용자에게 로그온 화면을 표시하기까지 (또는 시스템 사용자가 한명밖에 없는 경우는 사용자의 데스크톱을 표시하기까지) 몇차례 디스플레이를 변경하여 (검게 점멸), 실행 경험을 원활하지 않았습니다.

새로운 애니메이션을 가능하게 하기 위해 성능과 품질 향상을 위해서 실행 구조를 자세히 살펴보았는데, 부팅 애니메이션 활동에 의해 데스크톱까지의 시간을 한층 더 단축할 기회가 생겨 기쁩니다. Vista에서는 사용자가 머신을 켜면, 부팅 시퀀스는 Windows 플래그 또는 「펄」 애니메이션이 로그온 스크린 (사용자가 자동 로그인 설정을 한 경우는 데스크톱)  표시됩니다. Vista  실행 구조의 제약에 따라 이 펄 애니메이션은 실행 코드가 이미 완료된 경우에만 재생됩니다.

 

Vista 의 부팅 시퀀스, 펄 애니메이션을 포함한다

그런데, 새로운 폴더 실행 영상은 Windows 7 의 퍼스낼러티를 반영한 표현력 풍부한 애니메이션을 표시합니다. 펄 애니메이션은 장황한 느낌이 들어 삭제했습니다. 그 결과, 실행이 완료된 후 애니메이션을 재생하는 시간이 절약되었습니다. 

 

Windows 7 의 부팅 시퀀스, 펄 애니메이션 삭제

Vista에서는 최고 품질 경험을 만들기 위해, 사운드는 펄 애니메이션과 동시에만 실행됩니다. 그러나, 이것은 일부 하드웨어에 대해서 성능에 영향을 줄 가능성이 있었습니다. 이것은 시스템의 사운드 스택은 펄의 시퀀스를 완료하기 위해서 로드되어야 하기 때문입니다. 시스템의 사운드 재생 준비가 갖추어질 때까지 기다리는 경우, 데스크톱이 표시 될 때까지 지연될 가능성이 있습니다. 따라서 이번 사운드는 비동기적으로, 로그온 화면이 로드된 후에 재생되도록 변경했습니다. 테스트된 대부분의 하드웨어에서는 로그온 화면이 표시된 타이밍입니다. 즉 이 변경은 성능 장점에 추가하여 사용자 머신이 사용 가능한 상태가 된 것을 알려주어 사용자 경험을 향상시킵니다.

실행에 관한 코드의 최적화와 Vista 의 펄 애니메이션 삭제에 의해, 데스크톱에 도달할 때까지의 시간을 증가시키지 않고 실행중에 표현력 풍부한 고품질 애니메이션을 추가할 수 있습니다.

폭넓은 하드웨어 대응

실행시의 경험은 사용자의 하드웨어에 따라서 크게 다릅니다. 다양한 하드웨어에 최고의 비주얼 경험을 확실히 하기 위해 몇가지 설계 의사결정을 했습니다. 그러나, 시스템이 데스크톱을 표시하기까지 걸리는 시간은 주로 하드웨어에 의존합니다.

예를 들어, 실행시 애니메이션이 시작되기까지 지연된다는 것을 알고 계실지 모르지만, 이 지연시간은 시스템의 하드웨어에 따라서 다릅니다. 즉각 반응을 보이도록 최적화하기 위해서 Windows 가 시스템상의 모든 프로세서를 시작하는 기회를 얻기 전에 실제로는 실행 화면상에 텍스트를 표시합니다. 그것은 실행중에 애니메이션이 나머지 I/O 와 비동기로 실행할 수 있는 경우에만 가능합니다 (앞서한 얘기와 같이 최선의 성능과 품질에 필요합니다).

또, 실행 중에 Windows 플래그 크기가 스크린 크기에 의해서 조금 바뀌는 것을 알고 계실지도 모릅니다. Windows 7 의 기술적인 제한 때문에 시스템의 원래 해상도와 관계없이 실행시에는 항상 추천되는 최저 해상도인 1024x768 로 표시됩니다. 요즘 대부분의 하드웨어는 부팅 시퀀스를 중앙에 표시하는 것이 아니라, 확대하여 화면 가득 표시하도록 설정됩니다. 그 결과, 부팅 애니메이션도 1024x768 와는 다른 비율로 스크린상에 확대됩니다. 그러나, 시각적인 품질이 유지되도록 일반적인 비율로 일련의 흐름을 테스트 했습니다.

실행, 재시동 및 최대 절전 모드 상태에서 다시 시작

사용자는 최대 절전 모드 상태에서 복귀할 때에도 같은 경험을 체험할 수 있습니다.

사용자 지정

여러분의 상당수는 애니메이션을 사용하거나 일련의 흐름을 사용자가 지정할 수 있는지 궁금해 하실 것입니다. 아쉽지만, Windows 7에서는 지원하지 않습니다. 이미 Windows 7에서 많은 「개인 설정」요소, 예를 들어 베타에서 시험할 수 있는 새로운 폴더 테마 팩 등을 소개했습니다. 이유는 매우 명백한데, 실행시에 임의의 요소가 메모리에 로드되는 것을 허가하면, 시스템의 보안을 보장할 수 없기 때문입니다. Windows 를 시작하는 초기 단계에서는 파이어 월이나 바이러스 소프트웨어는 아직 이용 가능한 상태가 아니기 때문에 시스템은 주의깊게 감시된 기존 상태에서 실행해야 합니다. 성능에 주는 영향을 고려하여, 모든 타사가 그것을 실시하는 것을 보장 하기 위해서 필요한 코드를 기본 제공할 수는 없습니다. Windows 7 의 설계 목표 중 하나는 사용자 여러분 한사람 한사람을 표현하는 충분한 기회가 되어, 자신의 PC 를 정말로 자신만의 PC로 만드는 것입니다.

Windows 7에서는 Windows PC 를 시작할 때의 경험을 좀 더 즐겁게 만든는 것을 목표로 했지만, 이 블로그나 다른 포럼을 통해 보내주시는 피드백에서 우리는 올바를 방향으로 나아가고 있다고 믿고 있습니다. --Karen

Published Thursday, March 12, 2009 12:52 AM by e7blog

Filed under: Design

Windows 7 필기 입력 인식 성능 향상

 

 

Microsoft는 Windows 3.0 용 펜 확장기능에 대해 15 년이상 필기 입력 인식 향상을 위해 노력해 왔습니다. Windows Vista 의 필기 입력 구성요소의 새로운 폴더 통합 및 광범위한 가용성에 의해, Windows PC 필기 입력이 한층 더 많이 사용되고 있습니다. 우리는 학교, 병원, 은행, 보험 등 여러가지 응용 프로그램에서 필기 입력 기능을 사용하고 있는 많은 사용자를 볼 수 있습니다. 이 자연스러운 상호작용 방식이 새로운 폴더 시나리오에서 사용되어  매우 기쁩니다. 물론, 우리가 지속적으로 해야 할 일은 인식 품질을 향상시키는 일과 세계의 많은 언어에서 인식 엔진을 사용할 수 있도록 하는 일입니다. 이 글에서는 Yvonne (User Interface Platform 팀의 프로그램 관리자)가 Windows 7의 새로운 폴더 인식 엔진 및 인식 향상 엔지니어링에 관한 분석을 제공합니다. --Steven

Tablet PC & Handwriting Recognition 팀의 프로그램 관리자인 Yvonne 입니다.
이 글은 Windows 7 용 필기 입력 인식을 향상하기 위한 실행한 과정을 소개하는 글입니다.

Microsoft 는 1990 년대 초부터 펜 기반의 컴퓨팅에 지속적으로 투자하여 Windows Vista 출시에서는 필기 입력 인식 엔진을 영어, 독일어, 프랑스어, 스페인어, 이탈리아어, 네델란드어, 브라질 포르투갈어, 중국어 (번자체와 간자체), 일본어 및 한국어를 포함한 12 개의 언어에서 사용할 수 있습니다. 사용자 여러분은 한층 더 많은 언어 지원과 왜 특정 언어가 아직 지원되지 않는지 자주 문의합니다. 우리는 Windows 7에서 노르웨이 스웨덴어, 핀란드어, 덴마크어, 러시아어 및 폴란드 등 새로운 폴더에서 많은 언어 인식 엔진을 출시하려고 계획하고 있습니다. 이 목록은 계속 추가될 것입니다.
그럼, 새로운 폴더 필기 입력 인식 엔진을 개발하기 위해서 무엇이 필요한지 고찰해 나가겠습니다.

Windows 는 속필 필기 입력도 인식합니다. 특별한 쓰기 방법을 배울 필요는 없습니다. 실제로 우리가 Windows 에 몇 천명의 사용자 필기 입력 스타일을 가르치고 있으며 (「트레이닝」), Windows 는 사용자가 그것을 사용할 때의 필기 입력 스타일에 대해 실제로 자주 학습하고 있습니다. 지난 16 년에 걸쳐서 우리는 필기 입력 인식용의 강력한 엔진을 개발해 왔습니다. 그리고, 보다 정확하고, 보다 빠르게 하기 위해서 이것들을 조정하여, 새로운 폴더 기능 (Vista 의 사용자에서 배우는 기능 등)을 계속 추가하고 있습니다. 새로운 언어를 지원하는 것은 새로운 폴더 사전을 추가하는 이상으로, 새로운 폴더 언어에는 큰 투자가 필요합니다. 우선, 네이티브 필기 입력의 수집에서 시작되어, 데이터를 분석하여, 트레이닝과 튜닝을 반복하여, 마지막으로 이 시스템이 사용자에게 가게되고, 사용자가 사용하면서 지속적으로 향상해 갈 것입니다.

데이터 수집

새로운 필기 입력 인식 엔진의 개발은 방대한 데이터 수집에서 시작했습니다. 우리는 전세계에서 몇 만 명의 작가가 쓴 텍스트의 몇 백만 개의 단어 및 문자를 수집했습니다.

데이터 수집을 설명하기 전에 자주 물어보는 질문에 대답하고 싶습니다.「새로운 사전에서 기존 인식 엔진을 사용할 수 없습니까?」이런 경우 하는의 이유는 각 언어에 특수 문자 또는 엑센트 부호가 있는 경우입니다. 그러나, 대부분의 이유는 다른 지역의 사용자는 (영국과 미국과 같은 언어를 가지는 나라들 사이에도) 각각 다른 쓰기 방법을 배웁니다. 사람들은 많이 비슷해 보이는 문자가 컴퓨터에서는 실제로 완전히 다른 경우가 있습니다. 따라서  우리는 문자 및 자형이 어떻게 쓰여져 있는지 정확하게 capture 하는 실제 데이터를 수집해야 했습니다.

확실하고 「정확한 데이터」를 수집해야 했기 때문에 데이터 수집에 많이 시간이 걸렸습니다. 인식 엔진을 개발하는 각각의 나라에서 컬렉션 실습을 신중하게 헸습니다.

실습으로 데이터 수집을 시작하기 전에 수집 도구를 구성하여, 문서를 준비하고, 수집 프로세스에서 지원자를 가이드하는 언어 스크립트를 컴파일 했습니다. 스크립트는 올바른 데이터, 다른 필기 입력 스타일의 데이터 및 특정 언어에 관련된 모든 문자, 숫자, 기호 및 부호를 모두 다루는 데이터가 확실히 수집되도록, 각각의 언어 네이티브 스피커들에 의해  신중하게 준비되었습니다. 스크립트는 컬렉션 실습에서 사용되기 전에 모두 교정되어 편집되었습니다.

도구와 스크립트가 준비된후 우리는 실습을 통해 필기 인식 샘플을 제공해줄 지원자를 모집했습니다. 신인 모집에서는 성별, 연령, 교육 등의 비율이 그 나라의 대다수를 맞도록 밸런스를 유지했습니다. 

실습 감독자는 지원자에게, 수집 도구에 표시된 텍스트를 지원자가 독자적인 필기 입력 스타일로 쓰도록 지시했습니다. 주의해야 할 중요한 것은 우리가 사용자의 자연스러운 쓰기 방법을 정확하게 나타내는 필기 인식 샘플을 수집행야 하는 것입니다. 따라서 우리는 「펜과 종이」와 같이 「펜과 태블릿」을 취급하도록, 지원자에게 당부했습니다.

이것은 수집 도구가 어떤 것인지 보여주는 스냅샷입니다.

그림1: 수집 도구

 

수집 세션은 60  ~ 90 분으로, 지원자가 꽤 많은 양의 필기 입력 데이터를 피로를 느끼지 않고 제공할 수 있는 정도의 시간입니다. 그 후, 제공된 데이터는 앞으로의 사용에 대비하여 업로딩되어 Microsoft 데이터베이스에 보관됩니다. 필기 인식 샘플에는 스트로크의 순서와 시작점과 종점, 간격, 새로운 폴더 인식 엔진을 트레이닝하는데 꼭 필요 여러가지 특성에 대한 중요한 정보가 포함되어 있습니다.

실로 다양한 필기 인식 샘플이 있다는 것을 보여주기 위해, 데이터베이스 샘플을 몇가지를 보여드립니다.

그림2: 다른 스트로크 순서를 보여주는 필기 인식 샘플

이 스크린 샷은 3 명의 다른 지원자가 어떻게 「black」이라는 단어를 손으로 썼는지 보여줍니다. 다른 색으로 필기 입력된 단어내에서의 정확한 스트로크 순서를 보여줍니다. 처음 2 명의 지원자는 「black」이라는 단어를 쓰기 위해서 5 개의 스트로크를 사용했습니다. 3 번째 지원자는 4 개의 스트로크로 쓰고 있습니다. 또한 문자 「ck」를 쓰기 위해서 3 번째 지원자는 하나의 스트로크를 사용하는 반면, 첫번째 지원자는 이 문자와 같은 조합을 위해 세개의 스트로크를 사용했다는 것에 주의해 주세요. 이 정보는 모두 인식 엔진의 트레이닝용으로 사용됩니다.

신경망과 언어 모델

일단 충분한 양의 필기 입력 데이터를 수집하여, 우리는 데이터를 개발 팀이 사용하는 트레이닝 집합과 테스트 팀이 사용하는 「블라인드」집합에 분할합니다. 그리고 트레이닝 집합은 신경망 네트워크를 트레이닝하기 위해서 사용됩니다. 그것은 인식 프로세스 결과를 크게 좌우합니다. 자연스럽게 쓰여진 데이터는 고품질인식 엔진 개발에 대해 꼭 필요하며, 인식 엔진은 그 트레이닝 집합 없이는 조금도 향상되지 않습니다. 신경망에 의해 많은 고품질의 데이터 공급하는 만큼, 우리는 한층 더 복잡한 필기체의 필기 입력을 처리할 수 있습니다.

신경망은 필기체 스크립트가 접속하고 있는 문자를 처리할 수 있는 Time-Delay Neural Network (TDNN)입니다. TDNN 는 필기 입력의 각 세그먼트 문자, 숫자 및 기호의 가능성을 계산하는 경우,스트로크와 이후에 계속되는 스트로크의 각 필기 입력 세그먼트를 고려합니다. TDNN 결과는 도움이 되지만, 정리가 없는 필기 입력의 경우는 충분하지는 않습니다. 인간에 의한 인식의 정확도가 동일한 정도가 되기 위해서 우리는 문자 형태를 넘는 정보를 사용해야 합니다. 이것을 언어 모델의 문맥이라고 부릅니다. 이 언어 모델 문맥의 대부분은 사전 형식이 되어 있습니다. 그것은 임의의 언어 용무의 유효한 처리 단어 목록입니다. 많은 언어의 경우, 이것은 spelling checker가 사용하는 것과 같은 사전입니다. TDNN 와 사전은 긴밀히 공동으로 기능하고, 임의의 입력에 대해서 단어의 확률을 계산하고 가장 확률의 높은 결과를 출력합니다.

신경망 트레이닝은 시간이 걸리는 복잡한 프로세스입니다. 인식의 정확성 향상이라는 최종 목표를 위해서 우리는 다른 언어에서 데이터를 차용하여 트레이닝 데이터를 늘리려면 실험합니다. 다른 언어의 문자 차용은 언제나 성공적 이지는 않습니다. 위에서 말한 것처럼, 스트로크 순서 문자 형태, 필기 입력 스타일 및 문자 크기는 나라 마다 다르고, TDNN  성능에 마이너스의 영향을 가져올 가능성이 있습니다. 그 때문에 인식의 정확성을 높이는 「올바른 공식」을 찾아내기 전에 자주 트레이닝, 재트레이닝, 그리고 튜닝을 몇 번이나 반복해야 합니다.

새로운 인식 엔진을 구축할 때, 올바를 방향을 향하고 있는지 어떻게 알 수 있을까요? 이것은 테스트 팀이나 네이티브 스피커가 우리에게 묻는 중요한 질문입니다. 테스트 팀은 인식 엔진의 품질을 반영하는 인식의 정확도 메트릭 생성을 담당하고 있습니다. 정확도 메트릭은 개발에서 트레이닝에 사용하지 않았던 수집 데이터인 블라인드 테스트 집합에 근거합니다. 정확도 메트릭에 추가하여 피드백 및 더 많은 입력을 얻기 위해서 사내 및 세계적인 자회사의 네이티브 스피커와 협력하고 있습니다

개인 설정에 의한 인식 엔진 향상

앞 단락에서는 우리가 다양한 다른 필기 입력 스타일을 처리할 수 있는 고품질 인식 엔진을 개발하는 방법을 소개했습니다. 그러나, 각 사용자가 자신의 독특한 필기 입력 스타일에 대해 인식 엔진을 트레이닝할 수 있으면 한층 더 향상됩니다. 개인의 필기 입력 스타일에 대해 인식 엔진에 가르치기 위한 트레이닝은 Microsoft 가 출시 전에 실시하는 것과 같은 트레이닝입니다. 유일한 차이점은 특정 사용자 (몇 천명의 사용자 대신)로 부터 독특한 트레이닝 데이터를 수집합니다. 우리는 이 프로세스를 「개인 설정」이라 부릅니다.

그림 3: 개인 설정 마법사 (문장 모듈)

개인 설정 마법사의 스크린 샷과 같이, 사용자는 필기 인식 샘플을 제공하기 위해 요청되는 문장을 쓰도록 지시됩니다. 사용자가 개인 설정 프로세스에서 보다 많은 데이터를 제공하는 만큼, 인식 엔진은 향상됩니다. 지정된 문장에 근거한 필기 인식 샘플의 제공에 추가하여, 사용자는 트레이닝에 사용되는 특정 인식 오류, 자체 및 문자를 손으로 쓸 수 있습니다. 개인 설정 기능은 복잡하여, 사용자가 최적으로 인식 엔진을 튜닝할 수 있도록 다양한 모듈을 제공합니다. 개인 설정이 모든 Vista 의 언어 및 모든 새로운 폴더 Windows 7 의 언어에서 이용할 수 있습니다. 인식의 정확도를 향상시키는 이 기능을 사용하도록 꼭 권장합니다.

우리는 지속적으로 인식 엔진을 향상시키기 위해 노력하고 있습니다. 이것은 온라인 원격 측정 (익명, 사적, 임의, 옵트인)을 통해 사용자의 피드백을 받는 것을 의미합니다. Windows Vista에서 「필기 입력 인식 오류 보고」라는 새로운 폴더 기능을 출시했습니다. 이것에 의해, 사용자는 인식 엔진이 올바르게 인식하지 못했던 필기 인식 샘플을 제출할 수 있습니다. 사용자가 Tablet 입력 패널 (TIP)로 단어를 수정한 후에 우리 팀에 잘못 인식된 필기 입력을 수정한 것과 함께 송신할 수 있는 메뉴가 제공됩니다.

다음 스크린 샷은 오류 보고 도구가 어떠한 것인지 보여줍니다.

그림4: 「필기 입력 인식 오류 보고」에서 사용자는 잘못 인식된 잉크 샘플의 어디를 제출할지 선택할 수 있습니다.

우리는 일주일에 대략 2,000 건의 오류 보고를 받고 있습니다. 오류 보고를 분석하여 차세대 인식 엔진 향상을 위해 사용하기 위해,데이터베이스에 보관합니다. 실제 데이터는 우리의 인식 엔진의 결점을 명확하게 말해주는 유일한 데이터이므로, 많은 도움이 됩니다.

우리는 모든 오류 보고를 귀중하게 생각하며, 진심으로 감사드립니다. 현재와 미래의 인식 엔진 기능을 향상시키기 위해서 사용할 수 있도록, 계속하여 많은 피드백을 보내주시길 바랍니다.  

Yvonne.

 

Published Thursday, March 05, 2009 7:35 AM by e7blog

Filed under: input

UAC 업데이트 정보

 

 

안녕하세요. 이번에는 Jon DeVaan 이 최근에 UAC 에 대해 받은 피드백에 대해 이야기하겠습니다. 

Windows 7 을 완성하기 위한 작업의 많은 부분은 피드백 대응에 집중하고 있습니다. UAC 피드백은 엔지니어링의 의사결정 프로세스의 몇가지 측면에서 흥미로우며, e7 블로그에서 다룰 만한 내용도 많이 있습니다. 실제로 이 블로그에서 UAC를 다루는 것은 세번째입니다. Windows 의 UAC 기능 진화에 대해 관심이 있는 분은 이전에 쓴 글(글 1 및 글 2) 을 먼저 보시면 도움이 되실 것입니다. 

지금까지 Windows 7 베타 판에 보여준 뜨거운 반응에 매우 기뻐하고 있습니다.  그리고, RC (= Release Candidate, 출시 후보판)를 앞두고 피드백이나 원격 측정에 근거하여 제품을 한층 더 연마할 수 있도록 열심히 작업 중입니다.  스스로의 작업이 전세계의 매우 많은 사람들에게 영향을 미치는 것을 생각하면 겸허하게 됩니다.  보내주신 의견과 댓글에 대해 진심으로 감사 말씀드립니다.

UAC 는 「끝」의 입장과 그 중간에 있는 입장을 주장하는 (상당히 강력하게 주장) 지지자를 가진 폭넓은 관점을 가진 기능의 하나입니다. 이번 경우에서는 한쪽을 「보안」, 다른 한쪽을 「사용성 (쓰기)」입니다. 물론, 실제로 이 문제는 두가지의  끝만이 존재하는 것이 아니라 그 사이에는 완벽하게 실행 가능 설계 포인트가 있습니다. 개인적인 예를 들면,  최근 온라인 뱅킹의 보안 관리방법을 변경했지만, 매우 복잡하고 사용하기 불편하여 은행을 바꾸려고 생각합니다. 진심으로!

오해 풀기

여러분이 현재 UAC 설계에 대한 댓글에서 보듯이 (그리고, 그 댓글에 대해서도 댓글 하고 있지만), 몇가지 오해가 있는 것이 분명하여, UAC 에 대한 엔지니어링 의사결정에 대해 이야기하기 전에 말해두고자 합니다. 엔지니어링 의사결정은 Windows XP SP2 가 선구가 되었던 secure development lifecycle principles , 특히 SD3+C (Secure by Design; Secure by Default; Secure in Deployment; and Communications)의 「Secure by Default (기본 설정으로 안전)」를 중시하면서 이루어졌습니다. Windows 7 은 이 원리를 따라, 모든 사람이 적절한 PC 경험을 느낄 수 있도록 하는 것에 초점을 맞추고 있습니다.

우선 먼저 해결해야 할 문제는 PC 에서 실행하기 시작하는 악의적 소프트웨어 (맬웨어) vs. 그것이 한번 실행되면 어떻게 되는지에 대한 것입니다. 맬웨어가 승낙없이 PC 에 침입하는 방법에 대한 보고는 아직 없습니다. 지금까지 받은 모든 피드백은 맬웨어가 일단 PC 에 침입하여 실행하는 UAC 동작을 걱정하는 것입니다. UAC 에 관한 보고는 취약성을 부르지 않는다는 Microsoft 입장 보고는 명시적인 승낙없이 맬웨어가 머신에 침입하는 방법이 원래 나타나지 않기 때문입니다. 「취약성은 아니다」라는 입장을 우리가 문제의 다른 부분을 진지하게 파악하지 않다고 생각하는 사람도 있는 것 같습니다. 그러나, 우리는 모든 피드백을 진지하게 받아 들이고 있습니다. 

보안 분야에 있어 「취약성」이라는 말은 특별한 의미를 가지고 있습니다. Microsoft는 Microsoft Security Response Center (secure@microsoft.com)에 세계 유수한 보안 기관을 두고, 거대한 에코시스템 전체의 보안에 대한 위협을 모니터하고 Microsoft 제품에 관계된 모든 위협이나 취약성 대응을 관리하고 있습니다. 전세계의 보안 커뮤니티에서 일반적으로 받아 들여지고 있는 정의에 의하면, 최근의 피드백은 취약성에 해당하지 않습니다. 왜냐하면, 원래 악의가 있는 소프트웨어가 컴퓨터에 도달하는 것을 허락하지 않기 때문입니다.

Windows Vista 의 방어 기능은 원래 맬웨어가 PC 침입을 막는 것이라는 것을 말해 두겠습니다. 예를 들어, Internet Explorer  사용 중 (다른 브라우저에서도 비슷한 보안 처치가 있습니다) .vbs 파일이나 .exe 파일을 브라우징하려면, 아래와 같은 프롬프트가 표시됩니다:

 

 

Internet Explorer 8에서는 또, 맬웨어 확대를 저지하기 위한 많은 새로운 폴더 기능이 도입되었습니다 (http://blogs.msdn.com/ie/archive/2008/08/29/trustworthy-browsing-with-ie8-summary.aspx 를 봐 주세요). 제가 사용하는 즐겨 찾기의 하나는 SmartScreen® Filter에서 악의적 사이트로 이동하려고 할때 알려줍니다. 그 밖에도, 맬웨어가 PC 에 침입을 보다 어렵게 만드는 가시적 및 잠재적인 기능이 있습니다.

IE8 의 SmartScreenR 화면

또한 최근의 전자 메일 프로그램 (Windows Live Mail 등)에서 첨부 파일을 열려면, 악의가 있는 파일은 차단됩니다:

 

최근 피드백의 상당수는 원래 Windows 7 은 맬웨어가 PC 에 침입을 미리 막는 방법이 Windows Vista 보다 뛰어난 것은 아닙니다. Windows 7에서는 맬웨어가 설치 또는 PC 내에서 실행되기 전에 저지하는 능력을 향상시키는 것에 초점을 두었습니다.

두번째 오해를 풀어야 할 문제는 UAC 설정에 따라서 다른 동작입니다. Windows 7에서는 UAC 기능에 대해 4가지 설정이 있습니다. 4 가지란, 「통지하지 않는다」, 「프로그램이 컴퓨터를 변경할 때만 통지한다 (데스크톱은 어둡게 안 된다)」, 「프로그램이 컴퓨터를 변경을 할 때만 통지 (데스크톱도 어두워진다)」 및 「항상 통지한다」입니다. Windows Vista에서는 「통지하지 않는다」 및 「항상 통지한다」라는 두가지 선택사항 밖에 없었습니다. Vista UI에서는 「통지하지 않는다」를 선택하는 것은 곤란하고, 구현의 양극단을 선택하게 되었습니다. Windows 7에서는 선택사항 및 기능에 대한 컨트롤이 늘어났습니다.

UAC 에 관한 최근의 피드백은 「프로그램이 컴퓨터에 대해서 변경을 할 때만 통지한다」 설정 동작에 대한 것입니다. 피드백이 「항상 통지한다」로 설정되어 있는 UAC 와는 관계없는 것은 분명합니다. 따라서 누군가가 「UAC 가 망가졌다」라고 하면, 그것은 피드백을 잘못 파악하게 됩니다.

UAC 목적

Windows 7 에서 「프로그램이… 때에게만 통지한다」가 어떻게 기능할까에 관한 피드백에 주목하고 있습니다. 설계 선택에 대해 설명하려면 우선 전후관계를 설명하는 것이 중요합니다. 기본 설정은 전체적으로 UAC 개선에 대해 전해진 피드백에 근거하여 많은 사용자에게 도움이 되도록 선택되었습니다. 우리는 고객의 경험 향상 프로그램, Windows 피드백 위원회, 사용자 설문 조사, 현장 테스트 및 사내의 사용성 테스트에 협력해 주신 고객에게서 UAC 승인 대화상자가 증가하는 것에 따라 통지 정보의 장점이 크게 감소되는 것을 알았습니다. 따라서 일반적인 사용자에는 반사적으로 「[네] 를 누른다」 것을 막기 위해, 주요한 메시지만 표시하도록 해야 합니다.

하나 중요한 것은 UAC 는 보다 안전하게 하는 점에서는 도움이 되지만, 구제해 주는 것이 아닙니다. UAC 는 소프트웨어가 설치 되기 전에 프롬프트를 표시하는 것으로, 대부분의 경우에 도움이 됩니다. UAC 의 이 부분은 설정이 「프로그램이… 때만 통지한다」의 경우에서도 유효합니다. UAC 는 또 관리자 권한이 필요한 시스템 전체에 대한 변경의 경우에도 프롬프트를 표시합니다. 이것은 이론상, 맬웨어가 실행된 후에 생각하면 그러한 소프트웨어에의 효과적 대책으로 보이지만, 실제 경험에서는 효과는 한정되어 있습니다. 예를 들어, 교묘한 맬웨어는 권한의 승격이 필요한 오퍼레이션은 피하겠지요. 그 외에도, 지금까지의 블로그 (글 1 및 글 2)에서도 논해 온 것처럼, 인간 행동의 요인도 있습니다.

UAC 는 또, 소프트웨어 개발자가 관리자 권한을 필요로 하지 않고 실행할 수 있도록 프로그램을 개선하는 것을 도와 줍니다. 맬웨어에 대해서 시스템을 안전하게 하는 가장 효과적 방법은 표준 사용자 권한으로 실행하는 것입니다. 많은 소프트웨어가 관리자 권한을 필요로 하지 않고 움직이게 되면, 보다 많은 사람들이 표준 사용자 권한으로 실행하게 되겠지요. Windows 7 의 머신을 설정할 책임에 있는 사람 (IT 관리자나 가족 PC 담당 (저도!))는 여러분 표준 사용자 계정을 사용하도록 머신을 관리해 주시길 바란다고 생각합니다. 최근의 피드백은 표준 사용자로서 실행해도 제대로 동작한다고 말합니다. 관리자는 또, 표준 사용자 계정 대신 관리자 계정으로 머신을 관리하는 경우, 그룹 정책에서 자유롭게 UAC  설정을 「항상 통지한다」에 강제할 수도 있습니다.

지금까지의 논의를 반복하면, 최근의 피드백은 보안의 취약성을 나타내지 않은 것을 알 수 있었습니다. 왜냐하면, 악의가 있는 소프트웨어는 시스템 위에서 이미 실행되기 때문입니다. Windows 7에서 IE8 는 모두, 맬웨어가 시스템에 침입을 막는 보호 기능이 향상되었다는 것을 알 수 있었습니다. 또, 피드백은 UAC 의 「항상 통지한다」 설정에는 맞지 않고, 일단 맬웨어가 실행하기 시작하면 UAC 는 그것을 저지하는데 100% 유효하지 않은 것을 알 수 있었습니다. 왜 「프로그램이… 때에게만 통지한다」라는 설정이 있고, 게다가 그것이 기본인지 질문하는 사람이 있을지도 모릅니다.

고객 주도형 엔지니어링

「프로그램이… 때에게만 통지한다」라는 설정을 기본으로 선택한 것은 먼저도 말한 것처럼, 보안 설계에 고유의 다양성에 근거하여 선택한 설계입니다. Windows 7 을 시작하기 전, Vista 의 UAC 기능은 프롬프트를 너무 표시한다는 피드백을 많이 받았습니다. 새로운 폴더 UAC  설정은 이 피드백에 응하는 형태로 설계된 것입니다. 

Windows 7 베타판의 기본 설정을 결정할 때, M3 빌드를 실행하는 두가지 일반인 그룹의 행동을 관찰했습니다. 하나는 「프로그램이… 때만 통지한다」 설정으로, 나머지는 「항상 통지한다」입니다. 이 사람들의 결과와 태도를 분석하여, 우리의 전형의 참고로 했습니다. 이 조사 및 고객 경험 향상 프로그램, Windows 피드백 위원회, 사용자 설문 조사, 사내의 사용성 테스트에서 얻은 데이터는 베타판 전형 재료가 되어, 최종적인 설정 선택을 확인하기 위해서 베타판에서  어떻게 원격 측정을 실시할지 정보가 되었습니다.

조사의 주요한 측정 기준은 세션중에 2 회의 프롬프트를 반응을 일으키는 최소의 물리량으로 했습니다. 만약 세션 중에 2 회 이상 프롬프트를 보면, 사람은 프롬프트에 초조해져 컴퓨터 이용을 간섭한다고 생각합니다. 두 그룹의 비교에서 「항상 통지한다」 설정 그룹은 2 회 이상 프롬프트가 표시되는 세션이 4 배 가까운 것을 알 수 있었습니다 (6.7 회에 1 회 vs. 24 회에 1 회).또, 우리는 샘플중의 몇 사람이 맬웨어를 머신에 들어가게 했는지 (Windows Defender 의 클리닝 상황으로 측정)의 통계도 수집했지만, 두 그룹간에 맬웨어 침입율의 의미가 차이는 없었습니다. 베타 기간중에도 광범위한 조사에서도 이 결과가 올바른지 어떤지 확인하기 위해서 데이터를 계속 수집할 예정입니다.

우리는 베타 테스터나 개인의 사용자에서 전해진 UAC 에 관한 건설적인 피드백을 몹시 기쁘다고 생각합니다. 이러한 피드백은 계속 고려하여 절충의 관점에서 “일반인”에 초점을 맞춘 유효성 검사의 도움이 됩니다. 앞으로 UAC 설계 선택을 계속 개선하기 위해 피드백이나 원격 측정 데이터를 모니터해 갈 것입니다.

Windows 7에서는 UAC 그 자체와 맬웨어가 PC 에 도달하는 것을 막는 방법을 개선했습니다. Vista 때 보내 주신 피드백을 반영하여 모든 유형의 사람에 대해서 적절한 쓰기와 보안을 제공하도록 열심히 작업하고 있습니다.  UAC  변경에 대한 피드백에 주의 깊게 귀를 기울이고 있습니다. Windows 7 에 대한 정열 및 피드백에 대해, 거듭하여 진심으로 감사 드립니다. 여러분 한사람 한사람이 바라는 기능을 구현 할 수 없지만, 다양한 시점을 적절히 평가하기 위해, 귀를 기울이면서 진지하게 임하고 있습니다. 우리의 목표는 모든 유형의 사람에 대해서 실용적이고, 사용하기 편리하고, 안전한 Windows 를 만드는 것입니다.

Jon

Published Thursday, March 05, 2009 7:18 AM by e7blog

Filed under: e7blog, Design, Security

앞으로의 엔지니어링 이정표

 

 

이 글은 Windows 팀 전체를 대표하여, Windows 7 Beta 를 설치하여 사용하시는 분들께 특별한 감사의 말씀으로 시작하고 싶습니다. 원격 측정에 의하면 Windows 7 은 몇 백만 건 이상이 설치되었는데, 이것은 정말로 대단한 일입니다. 그리고, [피드백 보내기] 버튼을 클릭하여 주신 분들에게서  세부 사항 버그 리포트와 제안을 받고 있습니다. 또한 여러분 중에는 어떻게 Windows 7 Beta 를 자신의 머신에 설치했는지, 매우 쾌적하게 사용하고 있는 것에 대해서 블로그에 쓰시는 분들도 많이 있습니다. 가장 많은 받고 있는 질문은 「베타 버전이 8 월에 만료되면 어떻게 해야 하는지? 오래된 OS 를 다시 사용하고 싶지는 않다」는 것입니다. 베타 버전의 출시는 보충물이지만, 우리는 뜨거운 관심에 감사드립니다. 

이 글은 현재 우리가 있는 지점인 베타 판에서 RTM (= Release To Manufacturing, 정식판)까지의 과정에서 PDC에서 이야기한 토픽을 기본으로 논의를 진행시키고 싶습니다. 이 글은 출시일, 계획 변경, 지금까지 설명한 프로세스 변경 등의 소식 대신, RTM 이 일반적으로 제공되게 될 때까지의 과정에 대해, 추가적인 세부 사항이나 적극적인 견해를 제공하는 것입니다. Windows 7 에 대한 높은 수준의 관심과 Windows 를 출시 하는 것은 Microsoft가 「단독」으로 실시하는 것은 아니고, PC 에코시스템 전체의 일부라고 생각합니다. 물론, 우리는 자신의 역할을 완수하는 것에 중대한 책임을 무겁게 받아 들이고 있습니다. Windows 출시의 최종 단계는 에코시스템 전체에 걸친 파트너십으로, 다양하고 풍부한 PC, 소프트웨어, 주변기기가 함께 동작하여 완전하고 만족할 수 있는 Windows 7 을 사용자 여러분에게 드리는 것입니다.

Windows 7 개발의 다음 이정표는 「RC」 (= Release Candidate, 출시 후보판)입니다. 역사적으로 RC 는 「곧 있으면 완성하므로 테스트를 시작해 주세요. 특히, 모든 기능이 들어가 있다」는 싸인 이었습니다. 이전에 말씀드린 것처럼, Windows 7에서는 조금 다른 접근 방식을 취하고 있습니다. 그것은 정직하게 실정을 공개하여, 현재 여러분과 함께 체험하는 것입니다. PDC 에서 배포한 프리베타판에서는 대부분의 API 는 완성됐다고 말씀드렸습니다. 아직 포함되지 않은 부분도 API 나 경험의 세부 사항에 대해 PDC 세션에서 설명했습니다. 동시에 2009 년초의 베타 버전은 API 와 기능 모두가 완성되어 넓리 제공되는 유일한 베타검사일 것이라고 알렸습니다. WinHEC에서도 이것에 대해 하드웨어 파트너에게 전했습니다. 또, PC 배급업체, 소프트웨어 공급업체, 하드웨어 제조업체라고 한 많은 에코시스템 파트너에 대해, 지금처럼 정기적으로 중간 빌드를 제공해 나갈 계획을 전했습니다. 이것이 현재 저희 입장입니다. 기능이 완성된 베타 버전을 출시하여, 전세계에서 넓게 이용할 수 있도록 했습니다 ( 더 많은 언어버전에 대한 요망이 있던 것은 알고 있지만). 개발 팀으로서 우리는 여러분의 대부분이 하고 있는 것을 실시하고 있습니다. 즉, 집과 회사의 많은 PC에서 언제나 베타 버전을 사용하여 (개인적으로는 9 대 이상의 머신에서 사용하고 있습니다), Microsoft 사내에서도 몇 천 개의 개인용 머신과 실습 머신에서 실행하고 있습니다.

베타 버전을 실행하고 있는 사람은 적극적으로 베타 버전의 수정에 공헌해 주시게 됩니다. 우리는 원격 측정 성능, 응용 프로그램의 호환성 데이터, 사용 상황 정보, 다른 분야의 장치 요건 세부 사항 등을 받고 있습니다. 이러한 데이터는 매우 체계적이고 실용적입니다. 우리는 파트너와 매우 강한 관계를 만들어 훌륭한 경험을 제공하기 위해서 뛰어난 도구를 사용하고 있습니다. 하드웨어 및 소프트웨어 배급업체가 Windows 7 용으로 개선된 업데이트 판의 드라이버나 소프트웨어를 시험하는 것을 보셨을지도 모릅니다. 예를 들어, 안티 바이러스 소프트 배급업체의 상당수는 벌써 호환 팩 또는 업데이트 판을 출시하여, 설치 시에 자동적으로 적용됩니다. 많은 GPU 의 칩 세트는 자동인식 되어 Windows 7 은 업데이트 된 WDDM 1.1 대응 드라이버를 다운로드합니다. Windows Vista 용의 드라이버에서도 움직이지만, 새로운 1.1 드라이버는 개선 된 성능을 제공하여 메모리 공간도 줄어듭니다. 이것은 1GB 밖에 메모리를 탑재하고 있지 않는 머신에서는 큰 차이입니다. 또, 장치를 삽입하여 최신 업데이트 판의 드라이버를 입수되었을지도 모릅니다. Logitech 의 QuickCam 에서 그것이 자동 실행된 것을 확인했습니다. 다른 예로서 베타 버전을 설치하면, Skype 소프트웨어를 현재 테스트의 업데이트 판으로 하도록 요청되는 것이 보셨을 지도 모릅니다. 오래된 버전을 설치 하려고 하면, 오류 메시지가 나오고, 계속적으로 문제와 해결 방법이 쓰여진 사용자 인터페이스가 표시되어 베타의 사이트로 리디렉션 됩니다. 이런 종류의 오류 처리가 잘 알려지면, 또 에코시스템이 새로운 지원을 쌓아 감에 따라 실시간으로 배포 되어서 갑니다. 이것은 에코시스템 전체의 파트너십이 있기 때문에 베타 기간에도 이러한 대처가 구현됩니다.

물론, 설계의 목표는 현재 Windows Vista 에서 운영되고 있고, 배급업체가 아직 지원하고 있는 장치와 소프트웨어는 Windows 7에서도 같은 소프트웨어로 움직이는 것입니다. 지금까지 이야기한 것처럼, 다양한 이유로, Windows 버전을 한정한 소프트웨어 및 장치가 있지만, Windows 7은 솔루션을 제공하기 위해 계속 노력하고 있습니다.  많은 선택사항을 제공하고 Windows 플랫폼의 정보를 개시하는 것으로써, 이러한 모든 것이 장대한 대처가 됩니다. 개선을 계속해 가는 것과 동시에 에코시스템 전체의 건전성과 다양성에서 매우 중요한 선택과 차별화 기회를 계속 제공해 나갈 것입니다. 파트너와 함께 하는 데이터와 대처는 RC 단계에 도달하기 위해 현재 진행되고 있는 매우 중요한 일입니다.

또, 베타 기간 중에 수집한 모든 품질 측정도 주의 깊게 보고 있습니다. 크래쉬, 행, 응용 프로그램의 상호교환성 문제, 주요한 시나리오의  실제 성능 등에 대해서 조사하고 있습니다. 베타에서 RC 출시를 앞에 두고 대부분의 노력을 품질과 성능에 포커스하고 있습니다. 고객이 실제로 사용하고 체험한 버그와 광범위한 일련의 테스트나 자동화 테스트로 발견된 버그도, 수정하고 있습니다. 이 일의 핵심은 사람들이 실제로 만난 버그를 수정함에 있어, 어느 버그를 수정할지 차례나 우선 순위를 생각하면서 수집한 데이터에 주력하고 있습니다. Internet Explorer 가 RC 에 마이그레이션 했을 때, 이 대처가 잘 작용했습니다. 자세한 것은 IE Blog 를 읽어 주세요.

물론 다른 작업도 하고 있으며 실제로 사용 상황이나 피드백에 근거해 최종 제품을 준비하고 있습니다. 우리는 사용자 경험에 관해서 많은 세부 사항피드백을 받고 있습니다. 예를 들면, 기본 설정, 키보드 바로 가기, 바람직한 옵션 등에 대한 것입니다. 말할 필요도 없이 이 피드백을 처리하고 구성하여, 「집계」하는 것만으로도 방대한 작업으로, 우리 중에는 여기에만 전념하고 있는 사람도 있습니다. 집중기간에는 「피드백 송신」에 의한 리포트를 15초 간격으로 받고 있었습니다! 이 블로그에서도 이야기한 것처럼, 보내 주신 의견의 내용을 잘 검토해야 할 필요가 있습니다. 지금부터 수주간 중에 이러한 제품에 대한 특정 변화에 대해 블로그에서 이야기할 예정입니다. 바뀐것은 프로세스의 일부 및 베타에서 RC 사이로 예정했던 시간의 일부입니다.

그런데, 우리는 매일 문제를 조사하여, 해결하고, 그 해결책이 제품을 (성능, 동작, 호환성, 또는 안정성 면에서) 퇴화 시키는 원인이 되지 않는지 확인하고 있습니다. RC 까지의 과정은 내부적인 관점에서도 외부적인 관점에서도 (베타 버전의 사용 및 파트너 에코시스템의 준비가 갖추어지는 것), 제품이 출시 가능한 상태로 만드는 것입니다. 

그리고, RC 를 베타의 업데이트 판으로서 제공해 갈 것입니다. 베타 버전을 경험하면, 많은 분들이 흥미를 가져주시기를 기대합니다.

RC에서도 원격 측정에 근거하는 피드백 프로세스는 인계됩니다. 다만, 이 이정표에서는 RC에서 최종제품의 사이에 무엇을 변경할지에 대해, 선택이 아주 어려워 질것입니다. RC 의 취지는 출시 준비를 확실히 하는 것으로, PC 배급업체에 출시 할 때까지 프리 베타 이후에 모든 작업을 유효성 검사 하는 것입니다. 반복이 되지만, 코드에 대한 변경은 매우 한정될 것입니다. 이 시기는 개발 팀의 생산성이 최악이 된다는 「농담」을 자주 합니다. 왜냐하면, 모두 제품에 집중하여 작업하지만, 거의 코드는 쓰지 않기 때문입니다.  모든 일은 그러하겠지요.－ 우주선은 발사대에 설치 되면, 모든 공구는 만일의 경우에 대비해 도구상자에 정리되어 있습니다.

먼저도 말했습니다만, 이것은 파트너십으로 프로젝트의 이 단계에서 행해지는 주된 일은 정말로 에코시스템 준비를 갖추는 것입니다. PC 배급업체, 소프트웨어 공급업체, 하드웨어 제조업체는 각각 준비 기간이 필요합니다. 신제품, 새로운 구성, 소프트웨어의 업데이트, 그 외 모든 부수물을 준비하는 시간입니다만, 즉, Windows 7 은 전원이 함께 준비가 갖추어질 때까지 (말하자면) 등장할 수 없습니다. 웹 사이트, 다운로드 페이지, 안내서, 트레이닝 교재, 주변기기의 패키지 등, 생성 하지 않으면 안 되는 것을 생각해 보세요. 여기에는 것에는 시간이 걸립니다. RC 는 공으로 테스트 하는 마지막 코드로, 에코시스템을 안심시키는 것입니다. 우리의 목표는 신중하고, 예측 가능하고, 안정성이 있는 것으로, 완전한 PC 경험을 고객에게 제공하는 것입니다.

호환성 목록 생성도 계속해 가고 있습니다. 우선 로고 제품에서 착수하고 있어, 어떤 제품이 있는지 궁금하신 분은http://www.microsoft.com/windows/compatibility 사이트에서 확인하면 좋을 것입니다. 이것들은 모두, 소프트웨어, 하드웨어, 드라이버를 포함한 Windows 7 PC 의 완전한 「이미지」를 생성하는 PC 배급업체와 협력해 가고 있습니다. 이것은 다음의 단계를 위한 리허설과 같은 것입니다.

그 시점에서, 제품은 출시 할 수 있는 상태가 되는 것으로, 이것이 확실히 우리가 할 것입니다.

또 하나, GA (= General Availability, 일반 공급)라는 추가 단계가 있습니다. 이 단계는 Windows 7 이 설치된 PC 가 문자대로 「유통경로 확보」, 소프트웨어가 (온라인 또는 실제의) 매장에 진열될 때입니다. 많은 사람은 RTM 판을 곧바로 다운로드 할 수 있기를 원한다고 생각하는데요, 이번 출시에서는 보다 확립된 패턴으로 갈 예정입니다. 또, GA 를 향해서 지방 분권을 위한 시간을 확보할 수 있어 비교적 단기간에 (이전 어느 출시보다 짧은 시간에) 확실히 전세계에 Windows 7 을 전달할 수 있습니다. 덧붙여 RC 는 충분히 긴 기간 계속 기능하도록 되어 있으므로, 안심하고 RC 를 계속 사용해주세요.

간단하게 정리하면:

• 프리베타 - PDC 에서 배포되어 개발자 커뮤니티에 Windows 7 을 소개했습니다. 또, 플랫폼이 완성되어 기능을 공표한 출시입니다.
• 베타 (Beta) -  200만 명에 대해서 완성된 Windows 7 을 사용할 기회를 제공한 출시입니다. 또, 품질, 안정성, 호환성 및 Windows 7  경험을 유효성 검사 하기 위해서 필요한 원격 측정이나 피드백 시스템도 제공했습니다. 앞에서 얘기와 같이 베타로 이행하는 즈음해, Windows 7 기반의 제품 테스트, 유효성 검사 및 개발이 최종 단계에 들어가도록 에코시스템 파트너와 협동하고 있습니다.
• RC (Release Candidate) - Windows 7 을 출시할 고려한 릴리스입니다. 계속해 피드백이나 원격 측정을 받아들이지만, 가장 중대한 문제에 대해서만 포커스하여 대처합니다. 제품에 대해서 가시적인 영향이 있는 변화에 대해 명확하게 전달합니다. 이 출시는 에코시스템 전체가 주지된 상태가 되어, 전원이 함께 RTM 를 위해 준비된 것을 확인하기 위한 것입니다. RC 에 이르면, 다음의 단계에 대비한 「무대 연습」모드가 됩니다.
• RTM (Release to Manufacturing) - PC 배급업체나 소매점에 대해, 또 볼륨 라이선스 제품으로서 이용 가능하게 하게 되는 것 최종적인 Windows 7 의 빌드에 의한 출시입니다.
• GA (General Availability) - 비즈니스적인 이정표로, Windows 7 이 설치 된 PC 나 Windows 7 의 패키지 제품을 구입할 수 있을 때를 의미합니다.

프리베타는 2008 년 10 월 28 일로, 베타는 2009 년 1 월 7 일이었습니다. 그럼, RC 는 언제가 될까요? RTM 는 언제 일까요? 대답은 가까운 시일내에 밝혀지겠지요. 현재, 피드백이나 원격 측정을 평가하고 예측 가능한 형태로 적정한 수준의 품질로 만들기 위한 건전한 스케줄을 세우고 있습니다. 많은 사람들이 보다 구체적인 정보를 알고 것은 충분히 알고 있습니다. 우리는 순조로운 방향으로 전진하고 있습니다. 제품 완성즈음하여, 품질 중시의 접근 방식이 미리 정해진 마감일에 좌우되지 않습니다. 내부적인 평가지표와 이정표가 있어, 파트너는 정기적으로 빌드를 받도록 됩니다. 그러므로, RC 가 될 때조차, 우리는 파트너로서 함께 합니다. 그리고, 베타를 테스트해 주신 여러분과 함께 완성하기 위해서 협업하고 있는 파트너 여러분의 평가에 크게 의존하고 있습니다.

Windows 를 출시하는 것은 확실히 업계 전체에 걸치는 파트너십을 구현화하는 것입니다. 처음에 이야기한 것처럼, 우리는 지금까지 Windows 출시에서 제일 좋은 것을 전달할 것을 약속했습니다. 그것이 우리의 목표입니다. 함께, 그리고 좀 더 인내하여 그 목표를 달성합니다.

우리는 Windows 7 에 대한 여러분의 요구, 그리고 업계 전체의 요구를 계속 채우는 제품을 제공할 수 있도록 열심히 노력할 것입니다.

--Steven, Windows 7 팀

Published Friday, February 20, 2009 2:25 AM by e7blog

Filed under: Planning

Windows 7 애플릿 소개

 

 

대략 10년마다, 우리는 Windows 에서 애플릿으로 불리는 업데이트에 대한 큰 결정을 실행합니다. 덧붙여 애플릿을 설명할 경우에 애플릿을 응용 프로그램, 프로그램, 또는 도구라고도 부르기 때문에 주의해 주십시오.애플릿은 긴 역사를 가지는 Calc (계산기) 페인트 (MS 페인트, 또는 페인트 브라시), 워드 패드 (Write), Windows 7에서의 새로운 스티커 메모등입니다. 예전부터 아는 사람으로서 이러한 도구에 대해 생각할 때는 언제나, 이러한 역사의 모두 이것들이 어떻게 등장해 왔는지 생각합니다. 많은 사람들이  현재의 CEO에 의한, 지금은 「고전」이 되었던 video 를 보는 것으로 생각합니다. 이 비디오는 영업 담당자들의 주의를 Windows 로 끌어당겼습니다 (이 비디오의 마지막의 말은 이 비디오가 Microsoft 내에서 구현한 것의 실마리가 됩니다). Windows 7 은 이러한 도구를 업데이트 하는 절호의 기회라고 생각됩니다. 이 출시로 애플릿을 업데이트 하는 이유는 애플릿에 고유의 기능을 추가하는 정확히 10 년 마다 시기이니까 라는 것은 아니고, 개발자 여러분이 여러분의 응용 프로그램을 Windows 7 데스크톱 경험과 통합하는 새로운 기회이기 때문입니다. 많은 사람들은 애플릿을 기본툴로서 사용합니다. 애플릿은 모든 사람용으로 「바로 이용 가능한」가치를 제공하고 있습니다만, 우리는 전체적인 플랫폼 경험을 나타내, Windows 7 에서 통합해 구축하는 방법에 대해 개발자에 가이드를 제공할 때, 애플릿을 보다 가치 있는 것이라고 생각합니다. 우리는 주로 Windows 에서 무엇이 새로운가를 보이는 일로 초점을 맞히고 있습니다. 많은 전체 기능의 도구가 같은 기능을 무료로 제공하고 있으므로, 이러한 도구 실수 끝내는 많은 기능을 추가하지 않으면 안 된다는  「긴장」상태에는 없습니다. 보다 고정밀도의 비트맵 편집 기능이나 고도의 과학 계산용 계산기 기능에의 희망으로 댓글이 가득 차지 않게 바라고 있습니다 :-).

이 글에서 다루어진 모든 API는 Windows 7 developer guide 의  Windows 7용으로 업데이트 된 개발자 대상 영역의 MSDN 로 설명 됩니다. 또, 다루어진 각 영역은 PDC와 WinHEC  사이트의 각 세션으로 지원됩니다.

이 글은 Riyaz Pishori (그룹 프로그램 관리자)와 응용 프로그램 및 개지트 팀원들에 의해 작성되었니다. --Steven

이 글에서는 Windows 7 플랫폼의 이노베이션(innovation) 몇가지와 Windows 7 응용 프로그램이 그러한 이노베이션(innovation)를 어떻게 채용하고 공개했는지를 설명합니다. 개발자와 파트너가 Windows 7에서 기대할 수 있는 플랫폼 기능 몇가지와 Windows 7 프로그램이 그러한 이노베이션(innovation)를 어떻게 공개했는지를 설명합니다. 이 글에서는 또한 주요 Windows 설계 원칙 및 플랫폼의 이노베이션(innovation)에 초점을 두고 사용자 경험 및 기능의 점으로 응용 프로그램이 어떻게 혁신되었는지를 설명합니다. 이 글은 몇가지 새로운 Windows 플랫폼 이노베이션(innovation)에 익숙해 지기 위한 응용 프로그램 개발자와 소프트웨어 배급업체 대상의 지침 또는 가이드이기도 합니다. 여러분의 소프트웨어의 개발에 이러한 API를 활용하는 방법을 알아보시기를 바랍니다.

Windows 리본

Windows 리본 사용자 인터페이스는 풍부하고 새로운 Windows 개발용 사용자 인터페이스입니다. Windows 리본은 현재 익숙한 Office 2007 리본 사용자 인터페이스를 Windows 7에 가져와, 응용 프로그램 개발자와 소프트웨어 배급업체를 이용할 수 있도록 했습니다.

Windows 리본 사용자 인터페이스를 채용하면, 몇가지 장점이 있습니다. 그러한 대부분은 Office 2007 blogs에 기술되어 있습니다. 리본은 다양한 기능이나 커멘드를 다른 메뉴나 도구 막대 아래에 공개하지 않고 모든 커멘드의 풍부한 그래픽 유저 인터페이스를 하나의 장소에서 제공합니다. 리본 UI 는 직접적으로 설명을 필요로 하지 않고, 논리적으로 관련된 커멘드가 이름붙여져 그룹화 됩니다. 리본 UI 플랫폼상에 구축되는 응용 프로그램을 사용할 때, 사용자는 특정 기능이 어디에 있어, 어디서 액세스 할 수 있는지 배려할 필요없이 필요한 것은 워크플로와 작업에 집중하는 것 뿐입니다. 또, 리본 UI 에 의해 레이아웃이 조정되어, 크기, 장소 및 컨텐츠를 사용자를 사용자 지정 할 수 있는 도구 막대와 비교하면, 일관성이 유지됩니다. 또한 리본 UI 에는 향상한 기본 제공 키보드 사용자 보조가 있어, 리본을 사용하여, 응용 프로그램 DPI 와 테마가 보다 쉽게 구현됩니다. 마지막으로 리본 사용자 인터페이스 업무의 XML 마크업에 근거한 프로그래밍모델에 의해, 사용자 인터페이스의 개발 및 변경은 매우 신속히 실시할 수 있습니다.

페인트와 워드 패드는 처음 Windows 리본 UI 플랫폼을 이용한 것입니다. Windows 7에서는 응용 프로그램이 일련의 새로운 기능에 의해서 확장 되어, 이러한 응용 프로그램의 사용자 인터페이스는 Windows 7 경험에 어울리는 표준입나다. Windows 리본 UI 는 이러한 응용 프로그램이 각 사용자 경험을 개조하고 일관성있고 리치하고 즐겁게 쉽게 사용할 수 있습입니다. 또, 이러한 응용 프로그램의 작업 및 커멘드에서는 리본 UI 프레임워크를 쉽게 적용할 수 있었습니다. 이것에 의해, 인기 있는 네이티브 Windows 응용 프로그램이 개발자와 소프트웨어 배급업체와 같이 소비자에 Windows 리본 UI 플랫폼을 공개하는 호기가 되었습니다. 많은 사람들에게, 리본을 사용하는 Windows Explorer 와 IE에 대해 묻는데, 우리는 Windows 7에서는 계획하지 않았습니다. Windows 7의 중점은 플랫폼에서 페인트와 워드 패드와 같은 문서 중심의 응용 프로그램용 플랫폼입니다.

두가지 응용 프로그램은 Windows UI 리본의 여러가지 요소를 공개합니다. 페인트와 워드 패드의 두가지 응용 프로그램 메뉴에서는 응용 프로그램의 [파일] 메뉴에 의해서 일반적으로 참조할 수 있는 응용 프로그램에 관련한 커멘드를 표시합니다. 두가지 응용 프로그램에는 대부분의 커멘드를 표시하는 [홈] 및 응용 프로그램의 옵션을 표시하는 이미지 또는 문서를 표시하는 [뷰] 이라든지 등 되는 코어 탭 집합이 있습니다. 두가지 탭의 각 커멘드는 관련하는 기능의 그룹내에 논리적으로 레이아웃 됩니다.

퀵 엑세스 도구 막대 (QAT)는 페인트 및 워드 패드 모두에서 제공됩니다. 이것은 응용 프로그램에서 중요한 [저장], [실행 취소], 또는 [반복] 와 같은 특정 초기설정을 갖추고 있습니다. 사용자는 QAT 드롭 다운을 사용해 QAT 를 사용자 지정 하거나 리본으로 임의의 커멘드나 그룹을 오른쪽 클릭하여 그것을 QAT 에 추가 할 수 있습니다.

커멘드 단추, 분할 단추, 갤러리, 드롭 다운, 체크 박스, 토글 버튼 등의 여러가지 리본 커멘드가 두가지 응용 프로그램에서 사용됩니다.

 

또한 두가지 응용 프로그램은 문맥중의 이미지나 문서의 인쇄 프리뷰를 보이는 [인쇄 프리뷰] 모드를 제공합니다. 모드내에서는 코어 탭은 모두 삭제되어 사용자가 상호작용적으로 조작하기 위해서 그 모드만이 표시됩니다. 모드를 종료하면, 사용자는 바로 코어 탭으로 돌아올 수 있습니다.

페인트는 한층 더 텍스트 도구 용무의 조작별 탭을 표시합니다. 텍스트 도구는 텍스트 컨트롤이 캔버스에 있는 경우에 한정해 표시됩니다. 조작별 탭은 텍스트 도구에 포커스가 맞을 때 코어 탭 집합의 옆에 나타나 텍스트가 캔버스의 이미지에 적용되면 삭제됩니다. 조작별 탭 집합은 텍스트 도구에만 고유의 관련 도구를 포함합니다.

두가지 응용 프로그램은 리본 갤러리에 의해서 라이브 프리뷰를 제공합니다. 리본 갤러리는 워드 패드로 텍스트를 포맷 할 때의 폰트 크기 및 폰트명, 워드 패드의 줄머리 문자나 행, 페인트로의 색 선택, 윤곽선크기 선택 및 도형의 테두리 선과 그림 채우기의 스타일 등입니다. 라이브 프리뷰에 의해서, 사용자는 마우스 이동이 가져오는 변경을 순간에 이해하여, 선택 대상으로 그러한 변경을 적용하는 것을 가능하게 합니다. 이러한 프리뷰는 리본 UI 의 중요한 요소의 하나로, 리본 UI 가 새로운 상호작용 스타일로, 왜 「큰 도구 막대」이상의 것인가 하는 것을 나타내고 있습니다.
리본 사용자 인터페이스의 채용에 의해서, 두가지 응용 프로그램은 리본 KeyTip를 사용하는 기본 제공 키보드 사용자 보조 지원을 상속하여, 모든 커멘드는 힌트를 가져, DPI 와 Windows 의 테마용 지원을 갖추고 있습니다.

페인트와 워드 패드는 리본 UI 가 MFC 응용 프로그램에서 얼마나 쉽게 사용할 수 있는지 보여주는 예입니다. Windows 리본은 개발자와 소프트웨어 배급업체가 리본 사용자 인터페이스를 사용해 응용 프로그램을 개발하는 새로운 기회 및 옵션을 제시합니다. Windows Scenic Ribbon 프로그래밍모델 및 아키텍처는 개발자가 UI 의 프레젠테이션과 사용자 지정을 기본으로 되는 응용 프로그램 코드에서 분리하는 지원하기 위해서, 마크업 파일과 C++ 코드 파일의 분리를 강조하고 있습니다. 이 플랫폼은 디자이너는 UI 의 프레젠테이션과 레이아웃에 집중해, 개발자는 응용 프로그램 논리에 집중할 수 있는 개발자 디자이너 워크플로를 촉진합니다. 우리는 리본 UI 에는 큰 투자를 실시하고 있습니다. PDC 에서 Scott Guthrie 에 의해서 나타난 것처럼 .NET Framework 로의 구현을 포함해 한층 더 Microsoft 의 제품 전체에 걸쳐 리본 UI 가 계속해 사용되는 것을 기대 주세요. 또한 장래의 Windows 7에서는 네이티브로 지원 구축될 예정입니다.

멀티 터치 플랫폼

Windows 7 은 멀티 터치 입력 데이터 지원 및 Windows 메시지에 의한 Win32 멀티 터치 지원을 제공합니다. 멀티 터치 플랫폼에의 투자 끝에는 응용 프로그램에 터치 API 를 공개하는 개발 플랫폼이 포함되어 있습니다. 이것은 Windows 7에서 코어 사용자 인터페이스를 확장해 터치 경험용으로 최적화해, 응용 프로그램이 실행하는 멀티 터치 제스처를 제공합니다. Windows 7에서의 개발자는 이러한 API 상에 구축해, 소프트웨어로 제공하는 터치 지원의 적절한 수준에 대해 결정할 수 있습니다.

워드 패드는 멀티 터치 플랫폼의 사용 및 줌 제스처와 이동 제스처의 사용에 의해, 문서 읽기 경험을 확장합니다. 줌 한다, 느긋하게 움직인다, 또는 관성에 맡기는 등에 의해, 사용자는 직감적인 방법으로 특정 컨텐츠에 매우 신속히 도착할 수 있습니다. 줌 제스처의 사용에 의해서, 사용자는 워드 패드의 상태 막대의 우측에서 줌 슬라이드블록-를 사용한 것처럼, 문서에 줌인 또는 줌 아웃 할 수 있습니다. 멀티 터치가 가능한 하드웨어에서는 사용자는 핑거를 문서 윈도우 안의 임의의 장소에 두고, 줌 제스처를 실행하는 것으로써, 문서에 줌인 또는 줌 아웃 할 수 있습니다. 워드 패드는 워드 패드로 열려 있는 문서의 페이지로 이동 위한 이동 제스처도 지원 하고 있습니다. 이동 제스처의 실행에 의해서, 사용자는 워드 패드 응용 프로그램의 스크롤바를 사용하여, 문서를 스크롤다운 또는 스크롤업 할 수 있습니다.

페인트에서 멀티 터치 데이터는 사용자가 여러개의 핑거로 드로잉 하는 것을 가능하게 하기 위해서 사용됩니다. 이것은 제스처를 사용하지 않고 멀티 터치 입력을 가능하게 하는 응용 프로그램의 예입니다. 페인트의 기능의 경우, 여러개의 핑거 페인트 능력의 제공은 편집 모드 대신 읽기 전용 모드로 이미지에 대해서 실행하는 줌, 이동, 회전, 또는 다른 제스처를 가능하게 한다고 하는 이상으로, 보다 매력적으로 보다 리치한 것으로 합니다. 페인트로의 새로운 브러쉬는 멀티 터치 대응으로, 여러개의 핑거에 의한 터치 입력을 처리합니다. 사용자는 동시에 핑거를 드래그 시켜 캔버스 위에 여러개의 스트로크를 그릴 수 있습니다. 이러한 브러쉬에는 감압성도 있으므로, 화면에 대한 압력에 근거해 스트로크 폭이 바뀌어, 터치에 의한 현실적인 경험이 제공됩니다. 멀티 터치 플랫폼을 채용해 페인트의 최종 사용자 경험을 확장하는 것에 즈음해, 색 선택, 확대, 텍스트 도구 등의 멀티 터치 시나리오가 적용되지 않는 기능용으로 싱글 터치 경험을 보관 유지하기 위해서, 설계에 관해서 의식적인 결정이 이루어졌습니다.
멀티 터치 API 를 사용해 구축하는 것으로써, 페인트와 워드 패드는 터치 대응 하드웨어 위에서 보다 자연스럽게 보다 직감적인 인터페이스를 생성하여, 소프트웨어로 개발자가 얼마나 다른 기능을 공개할 수 있을지 「바로」보여줍니다.

작업 표시

스티커 메모는 Windows 7에서 사용 가능한 TabletPC 애플릿의 확장기능입니다. 데스크톱의 노트 경험으로 중요한 일의 하나는 계속해 새로운 노트를 확실히 쉽게 생성 할 수 있는 한편으로, 신속히 모든 노트를 제거하여, 또 되돌릴 수 있는 것입니다. 우리는 스티커 메모 응용 프로그램용의 단일 톱 레벨 윈도우를 가지는 것으로, 이것을 달성했습니다. 싱글 클릭으로, 노트를 모두 최소화해, 코맨드 바에서 노트를 프리뷰로 표시할 수 있습니다. 거듭해 표시되는 프리뷰는 새로운 축소 표시 프리뷰 API 를 사용해 구현 되었습니다. 이 API는 응용 프로그램이 실질적으로 톱 레벨의 응용 프로그램 윈도우의 리디렉션 된 스냅샷인 기본값의 각 작업 표시 프리뷰를 오버라이드(override) 해, 독자적으로 제공할 수 있도록 합니다. 이것에 의해, 응용 프로그램은 톱 레벨의 응용 프로그램 윈도우에서 이 프리뷰를 떼어내, 시나리오에 근거했던 것보다 생산적인 프리뷰를 제공할 수 있게 됩니다. 이것은 예를 들어, 마지막에 터치된 노트를 신속히 보는 것으로 생산적인 워크플로가 구현 할 수 있는 스티커 메모 시나리오에 대해 매우 가치가 있었습니다. 일단 프리뷰가 작업 표시에게 줄 수 있으면, 작업 표시는 그처럼 프리뷰 축소 표시 이미지를 캐시 합니다. 응용 프로그램은 그것 유지할 필요는 없습니다. 다만, 그것이 변화했을 경우는 응용 프로그램은 업데이트 된 프리뷰를 송신할 필요가 있습니다.

작업 표시 의 또 하나의 유효한 사용자 지정 끝점(endpoint)는 대상 메뉴 (별명 jumplist)입니다. 이 메뉴는 사용자가 작업 표시로 이 응용 프로그램을 오른쪽 클릭 하는지, [시작] 메뉴로 이 응용 프로그램 아이콘을 포인트 한다고 표시됩니다. 스티커 메모 응용 프로그램에는 단일의 메인 응용 프로그램 윈도우가 없습니다. 이 때문에 응용 프로그램은 실로 가볍게 느껴져 Windows 7 의 간단하고 강력한 사용자 경험을 생성 한다고 하는 철학에 잘 맞습니다. 과제는 주요한 장소 또는 잠재적으로는 다른 사용자 지정 「작업」에서 새로운 노트를 생성 할 수 있는 기능을 공개하는 것이었습니다. 대상 메뉴는 간단에서 만나도 지금까지 없는 듯한 방법으로 이러한 시나리오를 공개하는데 도움이 됩니다.

 

 

새로운 작업 표시의 기능성과 확장성에 의해, 개발자는 소프트웨어를 Windows 데스크톱과 통합할 때, 사용자가 생산적이고 효율적인 방법으로 응용 프로그램/시나리오를 실행하는 것을 보다 간단하게 구현 할 수 있습니다.

검색

Windows 로의 검색의 긴 역사 및 Windows 7에서의 중요한 확장기능에 근거해, 각 컨텐츠를 Windows 7 의 데스크톱 검색 사용자 경험과 보다 깊게 통합할 수 있는 개발자가 사용 가능한 API 가 있습니다. 이러한 API 의 사용 방법의 일례를 스티커 메모로 보여줍니다.

스티커 메모 응용 프로그램은 [시작] 메뉴의 Windows 인라인 검색에 의해서 컨텐츠를 검색하는 것으로써, 사용자가 노트로 돌아오는 것을 가능하게 합니다. 이것에 의해, 응용 프로그램이 닫혀지고 있는 경우에마저, 사용자는 관련하는 노트에 가능한 한 신속히 액세스 할 수 있습니다. 텍스트와 잉크 두가지 컨텐츠에 대해서 검색을 실행할 수 있었다고 해도, 잉크에서는 여러가지 자필의 스타일이 있기 위해 성공율이 낮기 때문에 텍스트에 제한 됩니다. 응용 프로그램은 각 노트의 URL 를 생성하는 프로토콜 처리기를 등록합니다. 스티커 메모 필터 처리기는 검색 인프라에 의해서 인덱스를 붙일 수 있는 각 노트에 관련된 컨텐츠용으로 요청 됩니다. 이러한 인덱스는 사용자가 잠시 후에 Windows 셸에 의해서 제공되는 검색 인터페이스를 검색하는 경우에 사용되어 신속한 참조를 실행합니다. 사용자가 결과상에서 클릭 하면, 검색은 프로토콜 처리기가 생성한 대응하는 URL 로, 관련된 응용 프로그램을 호출합니다. 그것은 필터 처리기가 Search indexer 에 송신 한 컨텐츠와 관련 지은 것입니다.

 

검색 플랫폼에는 건네받은 컨텐츠의 언어를 지정해, 언어를 계산하는데 사용하는 기본값의 검색 경험적 접근(heuristics)를 오버라이드(override) 하는 것을 가능하게 하는 기능도 있습니다. 이것에 의해, 검색의 정확함이 매우 높아져,  에코시스템의 국제적 지원이 확장됩니다.

스티커 메모가 프로토콜 처리기를 필터 처리기에 가세해 구현 한 이유는 그것이 Windows 파일시스템의 톱에 독자적인 통합 저장소 스키마를 구현 하고 있기 때문입니다. 모든 노트는 단일의 .snt 파일에 의해서 나타내집니다. 프로토콜 처리기는 개개의 엔터티 (이 경우는 노트)의 URL 를 생성합니다. 필터 처리기는 이러한 각 URL 의 컨텐츠를 선택하여, 검색에 인덱스 생성용으로 제공합니다.
이것은 응용 프로그램이 쉽게 Windows 7에서 검색 플랫폼에 접속할 수 있어 플랫폼 와 같이 응용 프로그램에서도 전체적인 사용자 경험을 확장하는 것으로 오는 검색 처리기를 추가할 수 있는 것을 나타내고 있습니다.

Real-Time Stylus

Real-Time Stylus (RTS)는 펜 또는 터치 디지타이저에서의 stylus 이벤트에의 액세스를 제공하는 인프라입니다. 이것은 스트로크와 포인트에 관한 정보를 제공해, 잉크 관련의 이벤트에의 액세스를 제공합니다. RTS 를 사용하면, 응용 프로그램은 stylus 정보로 액세스 할 수 있어 매력적인 최종 사용자 시나리오 및 경험을 개발할 수 있습니다.
스티커 메모에서는 손 그림 입력 하드웨어의 가용성에 의해서, 사용자는 노트상에서 잉크와 유형을 사용할 수 있습니다. 사용자는 키보드입력을 사용해 노트에 유형 할 수 있어 stylus를 사용해 노트에 잉크 할 수 있습니다. 이 경험은 사용자가 특정 노트로 잉크 또는 텍스트의 어느 쪽인지를 사용하는 것을 염두에 두어 설계되었습니다만, 같은 노트에 잉크와 유형 모두가 가능합니다. 다만, 이러한 면은 서로 알 수 없게 유지됩니다. 또한 스티커 메모는 노트를 자동으로 넓혀 잉크 컨텐츠에 맞도록 노트의 크기를 조정하는 실시간 경험을 제공합니다.

Real-Time Stylus (RTS)는 스티커 메모로 제공되는 손 그림 입력 기능용으로 사용됩니다. 또, 손 그림 입력 제스처가 응용 프로그램에서 사용 가능하고, 잉크를 지우는 제스처가 컨텐츠를 삭제하기 위해서 스티커 메모에 구현 되었습니다.

 

 

또한 페인트는 RTS 를 사용하고, 캔버스로 스트로크를 그리기 위해서 사용되는 마우스, stylus, 또는 터치에서 위치 입력을 얻습니다. 페인트는 또한 입력이 디지타이저에서 사용 가능한 경우, 압력이나 터치 면적 등 다른 입력변수를 capture 합니다. 그리고, 캔버스로 페인트 스트로크 생성하기 위해서 사용되는 스트로크 알고리즘에 이러한 입력을 매핑 합니다. 사용자는 이 알고리즘을 사용하고, 캔버스 위의 압력이나 터치 면책 기초를 두는 스트로크의 폭이나 다른 매개 변수-를 조정할 수 있습니다.

RTS 의 사용은 손 그림 입력 플랫폼상에 구축하는 응용 프로그램 및 소프트웨어의 개발을 가능하게 해, 마우스나 키보드를 넘는 응용 프로그램과의 상호작용 방법을 제공합니다. stylus, 손 그림 입력 및 제스처를 사용하면, 개발자는 최종 사용자용으로 상호작용 형식 경험을 생성 할 수 있습니다.

재시동과 복구

Windows 오류 보고 (WER) 인프라는 Windows 7 및 다른 이전의 버전의 Windows 클라이언트 및 서버에  일련의 피드백 기술입니다. WER는 응용 프로그램이 응용 프로그램 오류용으로 등록해, 그것을 보고하는 것을 동의 한 최종 사용자 때문에 데이터를 capture 하는 것을 가능하게 합니다. 이 데이터는 개발자가 액세스 해 분석해, 오류 경향 및 다운로드 디버그 정보를 감시하기 위해서 사용할 수 있습니다. 또, 개발자나 소프트웨어 배급업체가 응용 프로그램 오류의 근본적 원인을 판정하는데 도움이 됩니다.

WER는 개발 중이나 최종 사용자에서 초기의 피드백을 얻을 수 있는 베타검사 또는  중요한 수정 프로그램을 분석해 우선 순위를 두어 제품 출시 후에 그리고 제품의 수명 주기의 최후 등, 소프트웨어 개발의 다양한 단계에서 매우 유익합니다.

응용 프로그램이 실행되고 있을 때에 Windows 패치에 의해서 다시 시작하거나, 컴퓨터가 재시동 되었을 경우, 리포트를 올리기 위해서 응용 프로그램은 WER를 사용할 수 있습니다. 응용 프로그램의 크래쉬나 행 또는 응답하지 않는 상태를 일으키는 장해에의 대응이나, 옵션으로 분실 데이터의 복구용으로도 이용할 수 있어 복구용으로 독자적인 기구를 개발할 수 있습니다.
여러개의 Windows 응용 프로그램은 데이터를 수집해 분석하기 위해서 WER 인프라를 채용하고 있습니다. 계산기, 페인트 및 워드 패드는 재시동용으로, 동작하고 있던 응용 프로그램의 세션의 현재의 데이터를 회복합니다. 스티커 메모는 재시동과 복구 때문에 데스크톱 위에서 열고 있는 일련의 노트에 사용자를 돌려줍니다. WER 를 사용하면, 최종 사용자는 Windows 에 의해서 문제 데이터를 capture 해 수집할 수 있어 그 때문에 전과 같은 상태로 응용 프로그램에 돌아올 수 있습니다.

벌써 분 덧없는 세상 게, 우리가 Windows 7 의 애플릿으로 주로 임한 것은 개발자를 사용할 수 있는 새로운 플랫폼 API 와 이노베이션(innovation)의 몇 가지를 공개하는 것입니다. 이러한 응용 프로그램을 사용해 주면, 몇가지 일반적으로 요청을 받은 기능도 추가된 것들을 이해해 주실 수 있다고 생각합니다. 그 일부는 다음과 같습니다. 계산기로의 확인과 수정, 각 계산모드 및 템플릿, 페인트로의 새로운 브러쉬, 도형 및 멀티 터치 지원, 워드 패드로의 오픈 스탠다드 지원, 스티커 메모로의 잉크와 텍스트, 작업 표시 및 검색 통합.우리는 10년을 기다리지 않고 다시 이것들을 업데이트 할 예정입니다 :-)

 

--Riyaz Pishori 와 팀원들

Published Wednesday, February 18, 2009 3:29 AM by e7blog

Filed under: Platform

디스크 최적화 - 배경과 Windows 7 개발 개선

 

 

여러분이 잘 알고 있는 주제의 하나는 ( 100개 이상의 전자 메일을 받았습니다!) Windows 7 의 디스크 최적화 유틸리티를 개선입니다. 저희는  개선을 위해 많은 노력을 했습니다. 또, 블로그 커뮤니케이션에서 여러분의 지적에서 몇 가지를 이해했습니다. 그것은 훌륭한 일입니다. 이것은 생각만큼 간단한 일은 아닙니다. 우리는 최적화에 오랜 역사가 있다는 것을 알고 있습니다. 그리고 「훨씬 이전에는」그것이 대부분의 사용자에서 얼마나 중요한 성능 문제점이었는지 그리고, 한층 더 큰 미스터리였는지 알고 있습니다. 컴퓨터 동작이 늦은 경우에 특수한 최적화 프로세스를 거치지 않으면 안 된다는 것이 널리 알려지게 되었습니다. Windows Vista에서는 사용자 여러분에게 불필요한 염려를 주지 않기, 프로세스를 자동 조종하에 두는 것을 결정했습니다. 실제로, 이것은 구현되었지만, 적어도 프로세스의 자동 실행이라는 제한이 있습니다 (즉, 매일 저녁 컴퓨터의 전원이 꺼지면, 동작하지 않습니다).실행중의 최적화 상태에 대해 보다 많은 정보를 원하는 지식이 풍부한 분들로 부터 많은 피드백을 받았습니다. 또, 프로세스 관리 전체에 관해, 보다 많은 유연성을 원하는 분들로 부터 피드백을 받았습니다. 이 글에서는 그 피드백에 근거하여 변경된 세부 사항을 설명합니다. 또, 주신 메일과 댓글을 읽으면서 프로세스, 성능 향상의 인식과 현실, 그리고 특정 향상점에 관해서 보다 자세하게 아는 것은 가치가 있는 것이라고 생각했습니다. 이 글은 우리 파일시스템 기능 팀의 프로그램 관리자인  Rajeev Nagar 과 Matt Garson이 쓴 글입니다. --Steven

이 블로그에서는 Windows 7 의 디스크 최적화에 초점을 맞췄습니다. Windows 7 에서 변화된 점을 설명하기 전에 조각화란 무엇인가 그리고, 그 적용에 대해 간단하게 설명하겠습니다.

하드 디스크와 CPU 사이의 하드웨어 파이프라인을 포함한 저장소 및 메모리 계층 내에서는 하드 디스크는 동작이 늦고, 대기시간이 길어집니다. 하드 디스크간의 읽기/쓰기 시간은 밀리초 단위로 측정됩니다 (일반적으로 2~5ms). 이것은 데이터가 프로세서의 L1 메모리 캐쉬에 보관되면 (평균) 10 나노초 미만으로 데이터를 계산할 수 있는 2 GHz CPU 와 비교하면 매우 빠릅니다.

이 성능 차이가 증가하는 것은 과거 20 년간에 한정됩니다. 아래와 같은 그림은 주목해 주세요.

 

요컨대, 이러한 그림은 디스크 용량은 증가하고 있지만, 데이터를 전송하거나 새로운 데이터를 쓰는 능력은 같은 비율로 증가하지 않는다는 것을 보여줍니다. 따라서, 디스크는 보다 많은 데이터를 입수 할 수 있도록, 읽고 쓰는데 보다 많은 시간이 소요합니다. 그 결과, 고속 CPU 는 데이터를 처리할 수 있을 때까지 기다리게 되고, 비교적 유휴 상태가 길어집니다.

컴퓨터 과학의 중요한 연구에서는 시스템 전체의 I/O 성능을 향상에 초점을 맞췄습니다. 그 결과, 다음 두가지 원칙을 세우고, 운영 체제는 이 원칙에 따르기로 했습니다.

1. I/O동작을 적게하여, 즉  디스크의 읽기/쓰기 요청 회수를 최소화하도록 시도한다.
2. I/O가 발행되는 경우, 가능한 다량의 데이터를 전송 한다, 즉 대량으로 읽고 쓰기 한다.

두 가지 규칙은 합리적으로 생각하면, 간단히 이해되는 다음과 같은 논리적 근거가 있습니다.

1. I/O 가 CPU 에 의해서 발행될 때마다, 여러 소프트웨어 및 하드웨어의 구성요소가 요청을 만족하기 위해 처리해야 합니다. 이것은 대기시간 (즉, 요청이 만족 댈 때까지의 시간 길이) 증가에 기여합니다. 데이터를 읽을 때, 사용자는 대기시간에 자주 직면하여, 기대가 채워지지 않은 경우에는 사용자 불만이 증가됩니다.
2. 기계 목표 부품의 움직임은 발생하는 대기시간에 본질적으로 기여합니다. 하드 디스크의 경우, 「회전 시간」(디스크헤드의 아래에 디스크의 적절한 부분이 오도록, 디스크 플래터가 회전하는데 필요로 하는 시간) 및 「검색 시간」(헤드를 위치 결정하여 대상 트럭을 읽기/쓰기 할 수 있도록 하기 위해서, 헤드가 이동하는데 필요로 하는 시간)이 큰 요인이 됩니다. 대량으로 읽고 쓰기하여, 발생한 비용이 줄어들어  많은 양의 데이터가 전송됩니다. 바꿔 말하면 「1개의 유닛 당」데이터 전송 비용이 감소합니다.

NTFS 등의 파일시스템은 위의 규칙을 지키기 위해  매우 신속히 동작합니다. 예로서 이글스 ( 지금까지로 가장 즐겨 찾는 밴드 중 하나)의 「호텔 캘리포니아」라는 노래를 들을 때를 생각해 봅니다. NTFS 볼륨에 5MB  파일을 처음 저장할 때, 파일시스템은 디스크 위에 5MB 데이터를 「요약」하여 배포 할 수 있도록 충분한 인접한 비어 있는 영역을 찾아내려고 합니다. 왜냐하면, 논리적으로 관련된 데이터 (예를 들면 같은 파일 또는 디렉터리 컨텐츠)는 거의 동시에 로드 하거나 써질 가능성이 높기 때문입니다. 예를 들어, 일반적으로 「호텔 캘리포니아」 노래의 일부 뿐만이 아니라 노래 전체를 재생합니다. 노래가 재생되는 3 분간에 파일 전체가 소비될 때까지, 컴퓨터는 디스크에서  「관련 컨텐츠」(즉 파일의 서브 부분) 부분을 가져옵니다. 데이터가 요약이라고 배포된 것을 확인하여, 시스템은 대량의 읽기 요청 (많은 경우, 곧 사용될 것이라고 하는 예상되는 읽기 전 데이터)을 발행하여, 하드 디스크드라이브 구성요소의 기계적인 움직임을 최소한으로 억제하여 발행되는 I/O 를 줄일 수도 있습니다.

파일시스템이 데이터를 인접시켜 배포하는 것을 시도한다면, 조각화는 언제 생길까요? 보관된 데이터로 변경을 하면 (예를 들면, 컨텐츠 추가 변경, 삭제), 디스크 위의 데이터 레이아웃에 변화가 생겨 조각화로 연결될 가능성이 있습니다. 예를 들어, 파일 삭제를 실시하면, 필연적으로, 영역 할당이 해제되어 결과적으로 매핑 영역에 「구멍」이 생깁니다. 이것이 우리가 「사용 가능한 비어 있는 영역의 조각화」라고 부르는 상태입니다. 시간이 지나면, 인접한 비어 있는 영역은 찾아내는 것이 곤란해져, 새롭게 보관된 컨텐츠의 조각화로 연결됩니다. 분명한 일이지만, 삭제가 조각화의 유일한 원인이 아닙니다. 전에 말한 것처럼, 컨텐츠 위치의 변경이나, 기존의 파일에의 데이터 추가 등의 다른 파일 조작에 의해서, 최종적으로 같은 상태가 될 가능성이 있습니다.

그렇다면, 최적화는 어떻게 도움이 되는 것입니까. 본질적으로 최적화란, 데이터를 여기저기로 이동하고, 한번 더 하드 디스크 위에 보다 최적으로 배포 하는 것으로, 아래와 같은 이점을 제공합니다.

1. 조각화 된, 논리적으로 관련하는 어떤 컨텐츠라도 인접시켜 배포 할 수 있다
2. 비어 있는 영역을 요약이라고, 디스크에의 새로운 컨텐츠 쓰기를 매우 효율적으로 실시할 수 있다

아래 밑그림은 지금 설명하고 있는 내용을 도식화한 것입니다. 첫번째 그림은 디스크의 이상적인 상태를 나타내고 있습니다. 3개 파일, A, B 및 C 가 있고 모두 인접한 장소에 보관됩니다. 즉, 조각화는 없습니다. 두번째 그림은 조각화된 디스크를 나타내고 있습니다. 파일 A 에 관련된 데이터의 일부는 현재 인접하지 않는 장소에 배포됩니다 (파일 증가 방법에 의해). 세번째의 그림은 일단, 디스크가 최적화되었을 경우, 디스크 위의 데이터가 어떻게 보이는지 보여줍니다.

 

 

최신 파일시스템은 거의 모두, 최적화를 지원하고 있습니다. 차이점은 최적화의 메커니즘에 있습니다. 예를 들어, Windows 의 경우와 같이 개별 스케줄 가능한 작업인지 또는 그 메커니즘은 보다 암시적으로 관리되어 파일시스템 내부의 것인지 등입니다. 설계 결정 사항에는 단지, 시스템 및 필요한 절충의 특정의 설계목표가 반영됩니다. 또한 조각화가 생기지 않도록, 일반 파일시스템이 설계될 가능성은 별로 없습니다.

최근 몇년간 최적화가 매우 강조되어 왔습니다. 역사적으로, 조각화가 매우 큰 영향을 가져올 가능성이 있는 문제였기 때문입니다. 퍼스널 컴퓨팅의 초기의 시기에는 디스크 용량이 메가바이트로 측정 되어, 디스크는 곧바로 가득 차서 조각화도 빈번히 발생하고 있었습니다. 또한 메모리 캐쉬는 큰폭으로 제한되어 시스템응답 성은 더욱 더 디스크 I/O 성능에 근거하게 되었습니다. 이 결과, 일부의 사용자는 최적화 도구를 매주, 혹은 그 이상의 페이스로 실행하게 되었습니다! 현재, 매우 큰 디스크드라이브를 싸게 살 수 있지만, 평균적인 소비자-대상의 디스크 사용율 (%)은 보다 낮아져, 그 결과 비교적 조각화의 발생은 적게 됩니다. 또한 컴퓨터는 보다 많은 RAM 를 싸게 (많은 경우, 사용중의 데이터 집합을 액티브하게 캐시 하는데 충분한 수준으로) 이용할 수 있습니다. 거기에 추가하여, 파일시스템 매핑 방침이나 캐싱과 프리펫팅의 알고리즘을 개선하여, 전체적인 응답성을 향상시킬 수 있습니다. 따라서, CPU 와 디스크의 사이의 성능 차이가 계속 커져 조각화가 생기는 한편으로, 다른 영역에서 하드웨어와 소프트웨어가 일체화하여 진보되어 Windows 조각화의 영향 감소와 보다 좋은 응답성이 구현됩니다.
그렇다면, 우리는 현재의 소프트웨어 및 하드웨어를 사용하는 것을 전제로 했을 경우, 어떻게 조각화를 평가하면 좋은 것일까요. 첫번째 질문은 다음과 같이 될지도 모릅니다 : 「조각화는 실제 어느 정도의 빈도로 발생하고 어느 정도까지 생기는 것인가」. 조각화가 1% 의 500 GB의 데이터와 조각화가 50% 의 500GB 의 데이터에서는 같은 크기의 데이터에서 만나도, 큰폭으로 다르기 때문입니다. 두번째 질문은 「현재의 하드웨어 및 소프트웨어를 사용하는 것을 전제로 했을 경우, 조각화에 의한 실제의 성능 위의 패널티는 어떤 것이 됩니까」가 될지도 모릅니다. 여러분 중에서 꽤 다수의 사람이 과거 20년간에 걸쳐 도입된 다양한 제품을 생각날지도 모릅니다. 이것들은 당시 , 다양한 성능 향상 (예를 들면 RAM 최적화, 디스크 압축 등) 을 가져왔지만, 그 이후 그 대부분은 하드웨어와 소프트웨어의 진보에 의해 낡은 것이 되어 버렸습니다.

평균적인 가정용 컴퓨터의 조각화 발생율 및 범위는 사용 가능한 디스크 용량, 디스크 소비량 및 사용 패턴에 의해서 크게 바뀝니다. 바꿔 말하면, 일반적인 대답은 없습니다. 조각화에 의한 실제 성능에 대한 영향은 재미있는 질문이지만, 정확하게 측정하려면 너무나 복잡합니다. 조각화에 의한 성능 위의 패널티의 평가를 의미 있는 것으로 하려면 , 아래와 같이 요청 되겠지요.

• 일반적으로 목표 또는 대표적인 방식으로 조각화를 생성 하는데 「오래된」시스템의 가용성. 그러나,  앞에서 말한 것처럼, 단일한 대표적인 방식은 없습니다. 예를 들어, 주로 웹 브라우징을 위해서 사용되는 컴퓨터의 조각화 빈도와 범위는 파일서버로서 사용되는 컴퓨터와 다릅니다.
• 의미가 있는 디스크에 관련하는 지표 선택, 예를 들면, 부팅 및 첫 응용 프로그램을 실행한 후의 부팅.
• 통계적으로 관련되어 있을 가능성이 있는 반복된 측정

조각화 범위를 사용자를 이해할 수 있는 성능과 직접 관련지을 때의 복잡함을 보여주는데 도움이 되는 예를 보고 갑시다.

Windows XP에서는 여러개의 조각에 분할된 파일은 모두, 조각화되어 보여집니다. Windows Vista에서는 조각(fragment)이 충분히 큰 경우, 조각화되어 있다고 보여지지 않습니다. 최적화 알고리즘이 64 MB 보다 큰 파일 조각을 무시하도록, (Windows XP에서) 변경되었기 때문에입니다. 그 결과, XP 최적화와 Vista 최적화에서는 동일 볼륨상의 조각화 양이 다르게 보고됩니다. 그렇다면, 어느 쪽이 맞는 것 일까요? 이 질문에 답하기 전에 우리는 Vista 에서 최적화가 변경된 이유를 이해해야 합니다. Vista 에서 우리는 최적화의 영향을 분석한 결과, 다음과 같은 것을 알게 되었습니다. 즉, 최적화에 의해서 가장 큰 성능 향상을 얻을 수 있는 것은 파일의 여러개 조각이 "충분히 큰 데이터 정리" 로 일체화했을 경우로, 디스크 검색 대기 시간의 영향은 연속된 파일을 읽기와 관련된 대기시간과 의미있는 관련은 없다고 판단했습니다. 이것은 임계점을 넘으면, 조각화된 여러개의 파일을 조합하는 것은 눈에 띄는 이점이 없어지는 것을 의미합니다. 실제, 그렇게 하여 부정적인 결과가 얻어지고 있습니다. 예를 들어, 최적화에 의해 64 MB 이상의 조각(fragment)를 조합하는 경우, 다량의 디스크 I/O 를 필요로 합니다. 이것은 위에서 설명한 I/O 를 최소화한다는 원칙에 반해 (사용자가 시작한 I/O 용으로 사용 가능한 합계의 디스크 대역폭이 줄이기 위해) 시스템에 대해서 비어 있는 영역이 큰 인접한 차단을 찾아낸다는 큰 압력을 가하게 됩니다. 여기에 특정 양의 데이터 조각화가 정확히 좋다는 시나리오가 있습니다. 즉, 이 조각화를 감소시키기 위해서는 아무것도 하지 않는 것이 올바른 방법이라고 판명되었습니다!

조각화의 양과 그 영향과 같은 비교적 이해하기 쉬운 개념은 실제로는 매우 복잡하고, 그 진짜 영향은 정확하게 대응해야 할 시스템 전체의 종합적인 평가를 요청하는 것에 주의해 주세요. Windows XP 와 Vista 가 다른 설계상의 결정 사항에는 사용자가 사용하는 일반적인 하드웨어와 소프트웨어 환경에 관한 이 평가가 반영됩니다. 마지막으로 최적화에서 시스템응답은 기존의 조각(fragment)의 단순한 수 이상으로, 고려해야 할것들이 많다는 것을 이해하는 것이 중요합니다.

Windows 7 의 최적화 엔진 및 경험은 시스템응답 성에 대한 영향의 연속 한 전체적인 분석에 근거해 개선 되었습니다.

Windows Vista에서는 우리는 세부 사항최적화 상태를 표시하는 UI 를 모두 삭제했습니다. 우리는 이 결정이 마음에 들지 않는다는 피드백을 받았습니다. 여기서, 우리는 다양한 절충에 대해 조사를 하여 평가하고, 최적화를 위한 새로운 GUI를 구축했습니다. 그 결과, Windows 7에서는 상태를 보다 용이하고 직관적으로 감시할 수 있습니다. 또한 최적화는 프로세스 내에서 언제라도, 모든 볼륨으로 (필요하면) 매우 간단하게, 안전하게 종료시킬 수 있습니다. 아래와 같은 스크린 샷은 감시의 용이함을 나타내고 있습니다.

 

 

 

Windows XP에서는 최적화는 사용자가 시작하는 (수동) 조작이 아니면 안됩니다. 즉, 그것을 스케줄 할 수 없었습니다 Windows Vista 는 최적화를 스케줄 하기 위해서 기능을 추가했습니다. 다만, 최적화할 수 있는 볼륨은 항상 1 만이었습니다. Windows 7에서는 이 제한을 없앴습니다. 현재는 여러 개의 볼륨을 병렬하여 최적화할 수 있습니다. 볼륨의 최적화가 완료할 때까지, 다른 볼륨상에서 같은 조작을 시작하기를 기다릴 필요가 없어졌습니다. 아래와 같은 스크린 샷은 여러개의 볼륨에 대해서, 어떻게 동시에 최적화를 스케줄 하는지를 보여줍니다.

 

 

그외 Windows 7에서 달라진 변경에는 아래와 같습니다.

• Windows 7 의 최적화는 보다 포괄적입니다. Windows Vista 또는 이전 버전에서다시 배포할 수 없었던 많은 파일은 이제 최적으로 다시 배포 할 수 있습니다. 특히, 다양한 NTFS 메타데이터 파일을 이동 가능하게 하기 위해서, 많은 작업을 했습니다. NTFS 메타데이터 파일을 다시 배포 하는 이 기능은 볼륨의 축소를 촉진합니다. 왜냐하면, 시스템에 의해, 모든 파일과 파일시스템 메타데이터가 보다 긴밀히 압축되어 「마지막 부분」을 필요한 때에 다시 사용할 수 있습니다.
• 반도체 미디어가 검색 되었을 경우, Windows 는 그 디스크에 대한 최적화를 무효로 합니다. 반도체 미디어는 그 물리적인 특성에 의해, 최적화를 할 필요 없고, 실제 특정 경우에서는 미디어 전체 수명동안 감소할 수 있습니다.
• 기본값에서는 최적화는 Windows Server 2008 R2 (Windows 7 서버 출시)에서는 무효가 되어 있습니다. 서버 작업 부담량의 격차를 고려하면, 이러한 작업의 부담량을 파악하고 있는 관리자가 최적화를 유효하게 하기 위해 스케줄링 해야합니다.

Windows 7  최적화를 사용하는 방법은 간단입니다. 아무것도 할 필요는 없습니다! 최적화는 자동적으로, 정기적으로 백그라운드에서 실행되도록 스케줄하여,  전경 액티비티에 영향은 최소한으로 억제됩니다. 이것에 의해, 하드 디스크드라이브 위의 데이터가 효율적으로 배포 되어 시스템이 최적으로 반흥할 수 있도록 하였습니다.

Rajeev 와 Matt

Published Tuesday, February 17, 2009 1:09 AM by e7blog

Filed under: Storage

Windows 7의 「Windows 경험 인덱스」엔지니어링

 

 

전세계에서 Windows 7 베타를 다운로드 및 설치해 주신 많은 분들에게서 많은 보고가  들어와 처리에 분주합니다. 사용하기 시작한 여러분의 흥분이 전달되어 저희들도 매우 기뻐하고 있습니다. 베타에 참여하시는 고 있는 분들의 상당수는 자신이 사용하고 있는 하드웨어에 정통하고 조정도 가능하여, Windows 7 의 Windows 경험 인덱스 (Windows Experience Index = WEI) 나, Windows 7에서  WEI 가 어떻게 변경 또는 개선 되었는지에 대한 질문은 많지 않습니다. 이 글에서는 Michael Fortin 이 WEI 엔지니어링의 세부 사항에 대해 말씀 드리겠습니다.

WEI 는  PC 의 주요 하드웨어 구성요소 성능을 상대적으로 측정하기 위한 방법으로, Windows Vista에서 도입되었습니다. 벤치마크의 인덱스와 같이 상대적인 평가로 사용되는 것으로, 수치가 다른 수치들과 비교되는 것은 아닙니다. 다른 측정과는 달리, WEI는 단지 구성요소의 성능을 측정하는 것입니다. 또, WEI 는 단시간만 실행되어, 소프트웨어 실행 중에 구성요소의 interaction를 측정하는 것이 아니고, 하드웨어 특징을 측정하는 것입니다. 따라서 시스템이 자신만의 사용법에 의해서 어떻게 동작하는지 측정하지 않고, 측정 할 수 없습니다. 즉, WEI 는 시스템 성능을 측정하는 것이 아니라, 단지 Windows 7 실행 시,하드웨어의 상대적인 성능을 측정하는 것입니다.

특정 개인에게 필요한 「절대적인」 WEI 를 일반화하려는 분들은 주의가 필요하다는 말씀을 드립니다. 우리는 PC 성능에 대해서 각각 다른 허용범위나 기대를 가지고 있기 때문에,  WEI 값이 같아도 다른 사람에게는 완전히 다른 의미를 가지는 경우가 있습니다. 저의 경우, 업무의 약 90%는 WEI 가  2.0 인 (게임용 그래픽 구성요소의 점수가 비교적 낮다) 매우 싼 노트북 PC 에서 합니다. PC 에서 Outlook (2GB 정도의 전자 메일 교환 포함), Internet Explorer (10이상의 탭을 연 상태), Excel (개발 팀 멤버의 긴 목록을 연 상태),PowerPoint, 메신저 (비디오 첨부), 또 .NET 에서 쓰여진 기간 업무 (LOB) 응용 프로그램을 실행하기도 합니다. 이 정도의 작업부하와 Windows 7이 실행되는  PC 에서는 지금도 「병목 상태」는 자기 자신의 뇌와 손가락의 WEI 는 아닐까 생각합니다. 그 극단에 있는 것이 제가 크리스마스 선물로 산 25 인치 일체형 머신으로,WEI 는 5.1 입니다 (서브 스코어는 7.2, 7.2, 6.2, 5.1, 5.9 , 역시 게임용 그래픽이지만).이 머신에서는 64 비트판 Windows 7 이여서, 언제나 윈도우에서 MediaCenter 를 실행하여, 데스크톱에는 개지트가 가득하고, 프린트 서버로 사용하고 있음에도 불구하고, 쾌적하게 동작하고 있습니다 (탑재된 RAM 의 약 25% 를 사용하여,CPU 사용율은 10% 를 넘지 않습니다. )

--Steven

Windows 경험 인덱스 (WEI)의 기본 점수는 5 개의 최상위 WEI 항목별 점수 가운데, 가장 낮은 항목별 점수에 의해서 결정됩니다. 각각의 항목별 점수는 규칙이나 일련의 시스템 평가 테스트를 사용하여 계산됩니다. Windows 7에서 채점되는 것은 Vista 와 같은 다음 5개 영역입니다:

• 프로세서
• 메모리 (RAM)
• 그래픽 (일반적인 데스크톱)
• 게임용 그래픽 (주로 3D)
• 프라이머리 하드 디스크

채점 영역은 같지만, 채점 폭이 바뀌었습니다. Vista에서는 WEI 점수는 1.0에서 5.9 의 범위였지만, Windows 7에서는 상한이 7.9 로 올라갔습니다. 장치 채점의 규칙도 Vista 와 바뀌었고, 세심하게 등급 설정된 장치와 실제 사용의 다른 품질을 비교한 경험과 피드백을 반영시켰습니다 (즉, 등급설정을 보다 실제 사용할 때의 환경을 보여줍니다). 베타 버전을 설치하고, 시스템이 있는 구성요소 점수가 (Vista 와 비교해서) 바뀐 것을  알고 계신 분도 계실지 모르지만, 다음과 같은 이유 때문입니다. 

점수 범위는 특정 PC 에 요구되는 경험을 상대적으로 이해하기 위한 일반적인 가이드 라인이 되도록 기대하고 있습니다. Vista 시대에서 계속되는 시스템에 대한 1.0에서 5.0 까지의 일반적인 가이드 라인은 Windows 7에 대해서도 적용됩니다. 그러나, 앞에서 말한 것처럼, Windows 7에서는 수준 6.0에서 7.0 이 추가되었습니다. 즉, 7.9 가 최고 점수가 됩니다. 새로운 수준은 반도체 디스크나 멀티 코어 프로세서, 고급 지향 그래픽 어댑터로 대표되는 주요한 기술의 대폭적인 향상을 반영하기 위해서 설계되었습니다. 또한 시스템 메모리 탑재량도 결정적 수단이 됩니다.

새롭게 추가된 수준에 가이드 라인을 설정할 수 있도록 작업 중입니다. 예를 들어, 게임 사용자는 게임용 그래픽 점수가 6.0에서 6.9 사이이면, DX10 를 지원하고, 일반적인 해상도보다 뛰어난 frame rate를 구현하는 시스템 (1280x1024 로 40-50 fps 등) 입니다. 그리고, 점수가 7.0에서 7.9 의 사이에서는 보다 고해상도의 화면에서 보다 뛰어난 frame rate를 요구합니다. 당연, 각 게임 스펙은 이것들과 밀접한 관계가 있으므로, 게임 개발자들도 WEI 점수가 특정 시스템에서 어느 정도의 경험을 가져올 지가 기준이 될 수 있도록 하기 위해서 입니다. 그래픽은 하드웨어 중에서 가장 점수의 폭이 넓고, 또, 사용자의 기대 값의 폭도 가장 넓은 것입니다. CAD, HD 비디오, 사진, 그래픽에 중점을 두는 게이머가 요구하는 최고급품과 평균적인 비즈니스 사용자나 (업무보다는 취미로서 이것들을 실시한다) 일반 사용자가 요구하는 것에서는 상당한 차이가 있습니다.

물론, 새로운 수준의 추가는 왜 Vista 에서는 4.0 이상의 점수이지만, 지금은 2.9 밖에 안 되는  것에 대한 설명이 되지는 않습니다. 많은 경우에서는 점수가 큰폭으로 내리는 것은 흥미로운 실제 학습과 하드웨어 상황의 큰 변화를 볼 수 있던 새로운 디스크 테스트가 Windows 7에서 추가되었기 때문에입니다.

디스크 점수에 대해, 최근 Windows 성능에 관한 글에서 이야기한 것처럼,  오래 전부터 포괄적인 성능을 피드백하는 루프를 개발해 왔습니다. 이 루프에 의해, 컴퓨터의 현재 사용자가 응용 프로그램 또는 Windows 의 중대한 응답 문제에 직면하는 것을 나타낸 시간대를 커버하는 몇천개의 세부 사항 트레이스를 캡 처할 수 있었습니다. 이러한 트레이스를 분석한 결과, 디스크 I/O 와의 관계를 찾아내 표준적인 4KB  디스크가 로드하는데 생각했던 것보다도 긴 시간, 실제로는 훨씬 길게 (10배~30배) 걸린 다는 것을 알 수 있었습니다. 개개의 디스크가 로드하는데, 완료까지 수십 밀리초 대신, 수백 밀리초 걸리는 시퀀를 많이 볼 수 있습니다. 이러한 시퀀스가 쌓이면, 높은 수준의 응용 프로그램의 응답은 현저하게 영향을 받게 됩니다.

인식된 문제에 의해, 많은 I/O 시퀀스를 합성하여, 반도체 드라이브를 포함한 많은 디스크 드라이브에 대한 대규모 연구를 했습니다. 그 결과, 많은 뛰어난 디스크를 발견했지만, 유감스럽지만 로드에 있어 중대한 과제가 있는 것도 많이 찾아냈습니다. 특히, 반도체 드라이브의 제일 세대는 잘 볼 수 있는 클라이언트 I/O 의 시퀀스에 직면할때, 대체로 과제가 있는 것을 알았습니다.

일례로서 문제가 있는 시퀀스는 하나 이상의 플러시가 섞인 일련의 순차적 및 랜덤 I/O에서 완성되어 있습니다. 이러한 시퀀스중에서 많은 랜덤 기입은 현실과 동떨어진 짧은 시간 (예를 들어 500 밀리초)에 완료합니다. 매우 단시간의 I/O 완료는 캐싱을 시사하는 것으로, 실제 회전하는 미디어나 플러시 셀에 비트를 이동시키는 작업은 뒷전이 됩니다. 성공이 매우 빠르게 되돌아 온 후, 연기된 작업의 백로그가 쌓여서 갑니다. 다음에 무엇이 일어날지는 드라이브에 따라서 다릅니다. 드라이브는 먼저 발행 또는 연기된 것이 아무리 기입이나 플러시를 실시하려고, 기대 대로 항상 로드 응답을 계속합니다. 그리고, 좋은 성능을 덕분에 PC 를 사용하는 사람이 문제를 느낄 것은 없습니다. 그런데 있는 드라이브에서는 작업의 백로그를 삭제하려고 하여, 매우 오랜 시간 재고되어 그 결과 지각할 수 있는 「블로킹」상태 또는 거의 「잠근 시스템」이 되어 버립니다. 이것을 검증 하기 위해,  시스템에서 성능이 나쁜 디스크를 기존의 좋은 디스크와 바꿔 넣어 관찰했는데, 성능의 극적인 향상을 볼 수 있었습니다. 몇가지의 경우에서는 드라이브의 컴퓨터 데이터 보존부분을 업데이트하는 것만으로 응답을 현저하게 향상시키는데 충분했습니다.

실제로  학습을 반영시키기 위해, Windows 7 의 베타 버전의 코드에서는 (채점 중에) 문제가 있는 동작을 보이는 드라이브에 대해서 점수의 상한을 정하고 이러한 결과를 한층 더 평가하기 위해서 피드백 시스템을 사용하여 정보를 우리에게 되돌리도록 했습니다. 점수가 1.9, 2.0, 2.9 및 3.0 의 시스템 디스크는 이 새로운 상한 규칙에 의할 가능성이 큽니다. 베타 디스크 사정이나 지금까지 관찰한 데이터에 근거하는 이러한 상한에 대해, 우리는 내부적으로 자신을 가지고 있습니다. 물론, 한층 더 광범위한 베타 참여자에서의 데이터나 피드백, 드라이브 배급업체와의 교환에서 배워 갈 것입니다.

디스크 점수가 낮아도 성능에 불만이 없으면, 아무것도 할 필요는 없습니다 (물론 WEI 는 하드웨어 변경을 권장하는 도구가 아닙니다).일반적인 작업 부하나 응용 프로그램용으로 발행된 I/O 의 시퀀스가 지금까지 말한 것 같은 문제에 조우한다고는 할 수 없습니다. 반복이지만,  WEI 는 측정 기준이지만, 사용자 본인만이 자신의 PC 요구에 맞추어 적용할 수 있는 측정 기준입니다.

먼저, 새로운 수준의 6에서 7 은 새로운 하드웨어, 특히 SSD, 그래픽 어댑터, 멀티 코어 프로세서 등에 의해 향상한 경험을 측정하기 위해서 추가되었다고 언급했습니다. SSD 에 관해서는 새로운 테스트는 랜덤 I/O 비율과 먼저 말한 긴 대기 시간의 문제의 회피에 초점을 맞히고 있습니다. 다만, 테스트는 접속되고 있는 저장소 장치가 SSD 일지 어떨지는 특히 체크하지 않습니다. 테스트는 장치의 종류에 관계없이 실행되어 매우 높은 랜덤 I/O 비율에 견딜 수 있는 장치는 점수가 높아집니다.

그래픽 어댑터는DX9 와 DX10 을 평가 대상으로 했습니다. Vista에서는 테스트는 DX9에 대해서만 했습니다. 6 에서 7 점대의 점수를 내려면, 그래픽 어댑터가 뛰어난 성능의 점수를 내고, DX10 를 지원하여, 드라이버가 WDDM 1.1 대응의 드라이버(Windows 7 의 베타로, 그것이 다운로드 되도록 한 것을 알아차리셨을지도 모르지만)일 필요가 있습니다. WDDM 1.0 드라이버의 경우, DX9 평가만 실행되어 전체 점수의 상한이 5.9 가 됩니다.

멀티 코어 프로세서에 관해서는 싱글 스레드 및 멀티 스레드의  두가지 시나리오로 실행됩니다. 수준 6 및 7에서는 시스템의 CPU 는 너무 일반 용도 대상 대신, 가혹한 프로세스나 멀티 태스킹에 적절하다는 것을 의미하는 것을 목적으로 합니다. 예를 들어, 쿼드 코어 프로세서의 상당수는 6 점대 후반에서 7 점대 전반의 점수로, 8 코어 시스템은 7.9 가까운 점수가 나온다고 전망합니다. 채점에서는 최신 마이크로프로세서도 고려합니다.

주요한 하드웨어 파트너에 대해서도, 변경에 관한 세부 사항이나 이유에 대해 설명했습니다. 앞으로도 피드백을 적절히 도입하기 위해 적극적으로 협업해 갈 것입니다.

--Michael Fortin

Published Monday, February 09, 2009 3:27 AM by e7blog

Filed under: Perf

Windows 7 장치 지원과 테스트 기본

 

 

많은 분들은 베타 버전을 입수하여, Windows 7 을 설치하여 사용하기 시작하고 계시겠지요. 여기서, 어떻게 테스트를 통해 장치를 지원하고 있는지, 또,  PC 에코시스템의 관점에서 어떠한 대처를 하고 있는지 이야기하고자 합니다. 베타 버전 출시와 그에 대한 피드백 분석은 대작업으로, 매우 중요시하고 있습니다. 그리고 PDC에서 이야기한 것처럼, Windows 7 의 엔지니어링에 적용하고 싶은 것을 배운 분야 이기도 합니다. 이것은 Windows 조직 전체에 걸친 장대한 노력이지만,  이 글의 집필은 Windows Experience 테스트 팀 담당의 부사장인  Grant George 가 주도하고 있습니다.  --Steven

Windows 장치와 드라이버

Windows 출시에 있어서 중요한 책임 중 하나는 사용자가 가지고 있는 모든 장치와 그 드라이버에 대한 지원과 호환성을 들 수 있습니다. Windows 의 소프트웨어와 하드웨어를 잇는 추상화 층은 OS 의 지극히 중요한 부분입니다. 그 층은 다양한 측면을 가지는 하드웨어 에코시스템에 두고, 모든 파트너와의 인터페이스 역할을 이루어 있는 드라이버모델을 개입되어 연결됩니다. Windows 는 오늘 광범위하게 걸친 장치를 지원하고 있습니다. 예를 들어, 오디오 장치 (스피커나 헤드 집합 등), 디스플레이 장치 (모니터 등), 프린터, FAX 나 스캔 장치, 모든 형식, 사이즈 및 기능의 디지털 카메라나 휴대용 미디어와의 접속 등입니다. Windows 는 이러한 장치를 개발하여 시장이나 사용자에 출시하는 전세계의 회사에서 개방적인 플랫폼입니다. 그리고, 우리의 일은 이러한 에코시스템이나 선택사항을 잘 이해하여, 장치나 드라이버가 우리의 고객을 위해서 올바르게 동작하는 것을 확실히 하는 것입니다. 거기에는 Windows 7 의 개발 기간을 통해, 장치 제공자와의 제휴가 꼭 필요입니다.

드라이버는 장치와 Windows OS 와의 인터페이스 역할을 완수합니다. 그리고, WDM (Windows Driver Model)에 속합니다. WDM 는 처음에 Windows 용의 드라이버를 간단하게 쓸 수 있도록 하기 위한 , 커널 모드 드라이버의 중간층으로서 만들어졌습니다. 드라이버에는 다양한 종류가 있습니다. 클래스 드라이버(비슷한 하드웨어 클래스의 장치를 지원하는 하드웨어 장치 드라이버로, OS 와의 교환을 위해서 배급업체는 자신의 제품을 표준프로토콜 호환으로 할 필요가 있습니다)와 장치 개별의 드라이버(장치 배급업체에 의해서 제공되는 고유의 장치나 장치가 있는 버전 용무의 드라이버)가 주요 두가지 입니다.

파트너 지원

하드웨어 파트너에 대한 지원은 Windows Driver Kit (WDK)과 인증용 Windows Logo Kit (WLK) 형태가 있습니다. WDK 는 장치 드라이버를 개발할 수 있도록 하는 것으로, Vista 이후 이전의 Windows Driver Development Kit (DDK) 를  대신했습니다. WDK 에는 DDK 구성요소를 모두 추가하여 Windows Driver Foundation (WDF)와 설치 가능 파일시스템 (IFS) 킷이 포함되어 있습니다. Driver Test Manager (DTM)도 있지만, 이것은 WDK 와는 다른 물건입니다. WLK 는 Windows 용으로 장치를 인증하는 도움이 됩니다 (자동화된 테스트나 테스트 용무의 런타임 프레임워크가 포함되어 있습니다). 장치에서 Microsoft의 “Designed for Windows?”로고를 사용하려면, 하드웨어 제조업체는 이러한 테스트를 실행하여 패스할 필요가 있습니다. 이 인증 프로세스는 장치가 Windows OS 와 서로 작용할 때에 일정 수준의 품질과 호환성을 확보하는 도움이 됩니다. WLK 의 테스트에 합격한 하드웨어와 드라이버는 Windows 로고나 Windows Update에서 드라이버를 배포하는 자격을 획득,  온라인 Windows Marketplace에서 참조할 수 있게 됩니다.

유효성 검사와 테스트

Windows 7은 드라이버모델 유효성 검사, 새로운 장치나 레거시 장치의 테스트 및 드라이버의 테스트를 개선했습니다. Vista 와 비교해서, 제품의 엔지니어링 주기 전반을 통해서 드라이버플랫폼의 확인과 레거시 장치와 그 부수 드라이버의 유효성 검사에 의해 한층 중점을 두고 있습니다. 각 장치의 설치 기반에 근거한 데이터는 테스트에 꼭 필요한 요소를 나타내지만, 우리는 이 데이터를 매상 데이터나 하드웨어 제조업체의 계획표, 자발적으로 선택한 익명의 원격 측정 등 다양한 정보원에서 모으고 있습니다. 우리는 문제나 버그의 발견이 과거의 출시보다 훨씬 빠른 단계에서도 제품의 이 분야 테스트 검사 방법의 구조를 집중화·표준화 시켰습니다. 또, 플랫폼이나 인터페이스의 변경을  외부의 하드웨어 파트너에게 신속히 전달해 그들의 테스트 주기가 우리의 스케줄과 보조를 맞추도록 대처를 강화했습니다. 또한 최근 트랜드를 포함한 실제 사용 데이터, 각 장치의 명성 및 테스트 룸에서 실시하고 있는 우선 순위의 보다 강고한 상관관계를 이끌어냈습니다. 이것은 일반용으로 Windows 7 을 출시하기 직전 직후에 마켓에 등장하는 신규  장치의 경우, 특히 중요합니다.

Windows 7 사용자에 대해서 장치나 드라이버의 접속성 및 기능성에 대해 고품질 경험을 가져오는 또 하나의 중요한 요소는 Windows 7 의 전체적인 엔지니어링 프로세스를 단계적으로 하는 것입니다. 이번 출시를 위해, 모든 엔지니어링의 팀은 잘 구성된 단계화 된 개발 프로세스에 따라 왔습니다. Windows 7 의 새로운 기능이나 성능의 개발/프로그래밍을 세가지 다른 단계(이정표)에 분할하여, 각각의 단계 마지막에 통합 및 안정화 시간을 마련했습니다. Windows 7 개발 전체에 대해 코드베이스가 지극히 안정되어 있는 것을 확인했습니다. 그리고, 장치 및 드라이버의 유효성 검사 테스트는 각 이정표로 언제나 가고 있었습니다.  프로그래밍의 기간 중, 프로그램 관리자, 개발자 및 테스터는 매우 긴밀히 일했습니다. 외부의 파트너, 특히 장치 배급업체의 파트너와도 Windows 7 의 변화에 대한 포럼을 빠른 시기에 개최하는 등 관계 강화에 노력하여 유효성 검사에 대해도 밀접하게 대응하고 있습니다. 계획과 실행을 가장 중요시 했습니다. 즉, 일을 계획하고, 계획에 근거하여 일을 하는 것입니다. 왜냐하면, 이것은 기능 내용 및 스케줄 전체의 스냅샷의 양쪽 모두에 대해 Windows 7 의 새로운 기능의 개발이나 출시가 훨씬 예측하기 쉬워진다고 믿기 때문입니다. 이것에 의해, 「우리는 이렇게 합니다」라고 했을 때, 계획의 진척 상황에 관해서 외부의 파트너의 우리를 보는 눈이 어려워진 것은 인식하고 있습니다. 그러나 동시에 Windows 7 의 개발 기간 중, 장치 경험에 두어 외부의 파트너가 우리와 어떻게 협동하면 좋은가 확신이 깊어졌다고 기대하고 있습니다.

어느 장치를 테스트할지 결정

사내의 프로그램 매니지먼트 팀이 장치의 시장 점유율 분석을 도와 주고 있습니다. 데이터의 상당수는 Customer Experience Improvement Program (고객 경험 개선 프로그램)에서 고객 기반의 실제로 사용되고 있는 하드웨어 데이터를 알 수 있습니다. 예를 들어, 디스플레이 장치 단독으로 16,000 이상의 고유 하드웨어 ID 가 있습니다. 많은 일과 같이 우리는 하나의 장치가 올바르게 기능하지 않는 것뿐으로, Windows 전체의 경험이나 업그레이드의 평판을 떨어뜨린다는 것을 알고 있습니다. 그리고, 이 공유된 이해를 꼭 강화하고 싶습니다.

새로운 장치는 일반적으로, 사용자 수는 적지만, 드라이버는 가장 새로운 코드인 (또는 코드베이스가 처음으로 새로운 장치를 만날) 경우가 많습니다. 그리고 장치가 주류가 되는 것에 따라, 시장 점유율은 성장하고 많은 배급업체는 드라이버를 개발 및 계속 개선합니다. 이것은 사용자를 위한 것이기도 하고,  우리를 위한 테스트 때문에이기도 하지만, 항상 있는 장치에 대해 최신 드라이버를 사용하는 것이 중요합니다.

장치의 수명이 다할 때까지, 우리는 외부의 장치 파트너와 긴밀히 일해, 우리의 테스트 룸에서는 오래된 장치도 새로운 장치도 Windows 상에서 올바르게 동작해 계속 될 수 있도록 하기 위해 충실히 우선 순위 정합니다. 모든 장치 클래스에 대해서 시장에서의 트랜드에 세심의 주위를 기울이는 것으로, 다음 분야에서 지침이 될 결정을 내릴 수 있습니다:

• 추가 설정 없이 지원해야 할 중요한 장치
• Windows Update 에서 어느 드라이버를 입수 가능 여부
• 우리의 테스트에서 어느 장치와 드라이버에 초점을 맞출지 여부

시장동향을 주의 깊게 지켜보는 것의 장점 중 하나는 장치 패밀리의 동등한 기반의 견해 생성입니다.

동등한 클래스(equivalence class)

우리는 동등한 클래스의 개념을 하드웨어 (장치) 테스트의 매트릭스를 정의 및 우선 순위를 정하는데 사용합니다. 동등한 클래스의 생성에는 것을 관련한 장치로 동등한 속성에 근거하여 그룹을 나눕니다. 예를 들어, 화학 약품 회사에서 근무하고, 자동차용 왁스 첨가물을 실제 차량에[서 테스트 하는 것이 일이라고 상상해 주세요. 한정된 테스트 예산에서, 제품을 테스트하는 배급업체나 모델의 수는 최대로 하고 싶다고 생각하겠지요. 우선, 현재의 시장 공간을 분석하는 것으로, 테스트 매트릭스를 위한 최선의 선택을 할 수 있습니다.

먼저 분석한 테스트 차량은 청색의 2003년형 포드 마스탕으로 합시다. 같은 청색의 도료가 포드의 2003년과 2004년의 모든 모델로 사용 되어, 마츠다의 2005년의 모든 모델에서도 사용되고 있는 것을 알 수 있고 있습니다. 즉, 최초의 테스트 차량은 같은 값에 근거한 표에 대하고, 몇가지의 항목을 대표하게 됩니다:

Test ID	Make	Model	Color	Year
1	Ford	Mustang	Blue	2003
2	Ford	*	Blue	2004
3	Mazda	*	Blue	2005

그런데, 메르세데스 C240 의 2001 년형 실버를 봅시다. 메르세데스와 크라이슬러는 제휴하여 조사했는데, 크라이슬러의 2006년에서 2009년의 모델에 같은 실버의 도료가 사용되었던 것이 판명되었습니다. 즉, 테스트 매트릭스에 근거한 동등한 클래스는 다음과 같이 됩니다:

Test ID	Make	Model	Color	Year
1	Ford	Mustang	Blue	2003
2	Ford	*	Blue	2004
3	Mazda	*	Blue	2005
4	Mercedes	C240	Silver	2001
5	Chrysler	*	Silver	2006
6	Chrysler	*	Silver	2007
7	Chrysler	*	Silver	2008
8	Chrysler	*	Silver	2009

실제 각 차량을 주의 깊게 분석하고, 잠재적인 테스트 범위를 최대화하기 위해서 활용할 수 있는 등가관계를 구축했습니다. 하나의 배급업체/모델을 테스트 하는 것은 이론상, 다수를 테스트 하는 것과 동등합니다. 물론, 실제로 다른 회사는 다른 기법으로 도료를 도포할 것입니다. 이것은 하나의 변수가 되기에 테스트 목적에 따라 적절히 특성을 분류하기 위한 추가 정보가 필요합니다.

컴퓨터 장치의 테스트도 많이 비슷합니다. 시장에는 몇 천 개의 다른 장치가 있지만, 대부분은 주요 구성요소를 공유하고 있거나 과거 버전의 재성형이거나 메모리나 클락 속도, 화소 수, 커넥터, 또는 단지 히트 싱크 종류만의 차이이기도 합니다. 디스플레이 장치를 예를 듭시다. 시장에는 16,000 이상의 디스플레이 장치가 존재합니다. 그러나, 같은 값의 관점에서 분류하면, 마켓의 90% 는 약 60 종류의 GPU 에 상당합니다. 같은 값에 근거해 꼼꼼하게 구축된 테스트 매트릭스에 좀 더 추가하는 것으로써, 전 GPU 의 99% 이상을 커버할 수 있습니다. 드라이버의 개발자는 드라이버의 대상을 일련의 하드웨어로 하는 것으로, 같은 값을 활용할 수 있습니다. 드라이버 설치 패키지는 하드웨어 ID 에 의해서 지원하는 장치를 구별합니다.

최신 컴퓨터 장치는 모두, 장치 배급업체, 종류 및 클래스에 근거한 개별의 하드웨어 ID 가 할당되어 있습니다. 많은 ID (PCI, PC 카드, USB, IEEE 1394 장치)는 각각 장치 종류 업계표준 단체에 의해서 나뉩니다.

제 디스플레이 어댑터의 장치 ID 를 봅시다:

PCI\VEN_10DE&DEV_0611&SUBSYS_C8013842&REV_A2

PCI-SIG (전 PCI 장치의 ID 매핑을 실시하고 있는 표준 단체) 사이트로 가서 10진법으로 검색해 보면, 이것은 NVidia PCI 의 ID 인 것을 알 수 있었습니다. 저의 시스템을 좀 더 보면,

C:\Windows\System32\DriverStore\FileRepository

에 NVidia 의 드라이버를 찾아냈습니다 (“nv_lh”로 시작되는 폴더).드라이버 INF 파일의 하나를 열어 보면, 다음과 같은 시사적인 행을 찾을 수 있습니다:

NVIDIA_G92.DEV_0611.1 = "NVIDIA GeForce 8800 GT”

드라이버의 INF 파일을 한층 더 자세하게 보면, 같은 G92 GPU 가 다음 장치 모두에서 사용되는 것을 알 수 있었습니다:

• NVIDIA GeForce 8800 GTS 512
• NVIDIA GeForce 8800 GT
• NVIDIA GeForce 9800 GX2
• NVIDIA GeForce 8800 GS
• NVIDIA GeForce 9600 GSO
• NVIDIA GeForce 8800 GT
• NVIDIA GeForce 9800 GTX
• NVIDIA Quadro FX 3700

넷에서 조금 조사해 보면, 흥미로운 정보가 있습니다. 「코드명 G92 의 8800 GT 는 2007 년 10 월 29 일에 출시 되었다. 이 카드는 처음으로 65 nm 프로세스에 마이그레이션하여, PCI-Express 2.0 [13] 에 대응.2 슬롯이었던 8800 GTS 나 GTX 와는 대조적으로, 싱글스 로트의 쿨러를 탑재하고 있다. 또, 65 nm 프로세스에 의해, GTS 나 GTX 보다 전력 절약화 되고 있다. 」-WikiPedia

즉 이론상은 만약 스스로 디스플레이 어댑터의 테스트를 실행했다면, 다른 관련 장치에서도 같은 결과가 될 가능성이 충분히 있습니다.

Windows 7에서의 드라이버 목표

Windows 7에서의 주요한 목표의 하나는 Vista 로 인정된 모든 드라이버와의 호환성으로, 사람들이 심레스에 업그레이드 할 수 있도록 하는 것입니다. 이것은 어떻게 테스트할지에 대한 지침이 되는 몇가지 요건으로 분류할 수 있습니다. :

• 기본적인 기능의 드라이버는 in-box 로 한다. (in-box 란, Windows  설치의 일부로서 이용 가능하게 한다는 의미입니다. ) 주류의 저장소, 네트워크, 입력 및 디스플레이 장치 용무의 드라이버가 이것에 해당합니다. 즉, OS 를 설치 할 수 있고 사용자가 온라인에 액세스 할 수 있는 상태로 합니다. 그리고 필요하면 추가 드라이버는 Windows Update에서 입수할 수 있도록 합니다.
• 드라이버의 업데이트 또는 설치를 최소한의 노력으로 완성되도록 한다.
• 드라이버가 업데이트 되었을 때, 새로운 드라이버로 문제가 발생하지 않게 한다.
• 드라이버는 안정성이 있는 것으로 한다.

많이 하는 질문중에 드라이버 입수 가능성이 있습니다. 사람들이 드라이버를 찾는 데는 주요 이유가 3개 있습니다.: Windows 를 클린 설치 하기 위해, 새로운 컴퓨터에 장치를 접속하기 위해, 업데이트 된 드라이버가 필요하기 때문입니다. 이 블로그의 독자들이 열열한 사용자라고 해도, 회사, 친구 및 가족의 지원 /IT 인프라 담당자로서도 드라이버를 입수하여 확실히 머신을 업데이트 하는 것은 싫어 할 수 없는 「취미」와 같은 것임은 강하게 인식하고 있습니다. 우리는 모두 최신이면서 최고의 것을 갖고 싶은 것뿐으로, 그 이상에서도 그것 이하이기도 하지 않습니다.

클린 설치는 Windows 7 의 베타 단계에서 우리 모두가 높게 평가하고 있는 것입니다. 클린 설치는 많은 사람에서 중요한 것과 동시에 몇번이나 반복해지는/주요한 경험은 아니라고 할 것을 밝혀 둡니다. 그런데도 덧붙여 in-box 드라이버와 Windows Update에서 입수 가능한 드라이버의 편성은 매우 폭넓은 PC 의 도움이 되겠지요 (예를 들어, 새로운 Atom 기반의 머신에서 클린 설치를 하면, 대부분의 드라이버가 설치되어 있는 것을 알 수 있습니다.) 한편, 일부 PC 용 드라이버는 PC 배급업체에서만  입수할 수 있고, 다양한 이유로 Windows Update 나 장치 배급업체의 사이트에서도 다운로드 할 수 없는 경우가 있습니다. 예를 들어, 모바일 그래픽 드라이버는 일반적으로 PC 배급업체에서만 입수 가능하고, 그래픽 컴포넌트의 배급업체에서는 입수할 수 없습니다. 이것은 각 PC 배급업체에의 칩 세트의 출시 방법에 의해 결정된 것입니다.

분명히 기존 장치를 새로운 PC 에 접속하는 것은 자주 있는 것입니다. 이 경우에서는 옛날 장치를 뒤따르고 있던 CD/DVD 를 분실하여, ( 「먼저 설치 프로그램을 실행해 주세요」라고 하는 경고를 무시) 단지 넣어버렸을지도 모릅니다. 반복 말씀 드리지만, 우리의 목표는 이것들을 Windows Update에서 제공하는 것입니다. 하드웨어 제조업체는 여러 가지 이유에 의해 빈번히 업데이트 하거나 매우 큰 사이즈의 다운로드 프로그램을 제공하지만,  그것은 Windows Update에서의 배포에 적절하지 않습니다. 그러한 경우에서는 장치의 배급업체에서 드라이버를 찾도록 경고를 합니다 (많은 경우, 링크도 함께 표시합니다).

드라이버를 업데이트 하는 행위는 우리 모두에서 친숙한 일입니다. 왜냐하면, 문제를 해결하기 위해서는 「최신 드라이버를 입수해 주세요」라고 하는 메시지가 자주 표시되기 때문입니다. 이것은 특히, 새로운 드라이버가 전체의 향상에 추가된 성능을 향상시키거나 보다 많은 기능을 제공하는 경우에 열심인 게이머의 사이에 볼 수 있습니다. 업데이트 드라이버를 입수하는 제일 좋은 방법은 Windows Update 추가 선택에서가 일반적이지만, 역시 많은 경우 최신이며 최고의 것은 하드웨어 제조업체의 사이트에서 직접 다운로드 하게 됩니다.

우리의 목표는 명백하고, 다양한 장치에 대한 드라이버가 입수 가능하고, 높은 품질이 되도록 하는 것입니다. PC 나 관련 장치의 출시에 공헌하고 있는 파트너가 많이 있지만, 광범위한 사용자에 대해서 고품질 소프트웨어와 지원을 제공할 수 있도록 힘을 쓰고 있습니다.

Windows 7  장치와 드라이버의 테스트 척도

아래와 같은 표는 지금까지의 Windows 7 의 개발로 우리가 직접 테스트 했던 것이 명백한 장치의 예입니다. 이것은 단지 직접 테스트의 추출 견본에서 여기에 목록 되지 않은 장치도 많이 직접 테스트 또는 동등한 클래스로 커버됩니다.

<표>

Manufacturer	Description	Family
Altec Lansing	T515	Audio
AMD (ATI)	Radeon 9200	Display
AMD (ATI)	FireGL 3100	Display
AMD (ATI)	Radeon X300/X550/X1050 Series	Display
AMD (ATI)	Radeon 9800 Pro	Display
AMD (ATI)	FireGL V3100	Display
AMD (ATI)	Radeon Xpress Series	Display
AMD (ATI)	Radeon Xpress Series	Display
AMD (ATI)	Radeon Xpress 1200	Display
AMD (ATI)	Radeon X700 PRO	Display
AMD (ATI)	Radeon X1200	Display
AMD (ATI)	Radeon X800 CrossFire Edition	Display
AMD (ATI)	Mobility Radeon X300	Display
AMD (ATI)	Radeon X850 CrossFire Edition	Display
AMD (ATI)	Radeon X1550	Display
AMD (ATI)	Radeon X1950 Series	Display
AMD (ATI)	Mobility Radeon X1300	Display
AMD (ATI)	Mobility Radeon X1400	Display
AMD (ATI)	Mobility Radeon HD3200	Display
AMD (ATI)	Radeon HD 2600 XT	Display
AMD (ATI)	Radeon HD 3850	Display
AMD (ATI)	Radeon HD 3870	Display
AMD (ATI)	Radeon HD 3200	Display
AMD (ATI)	Radeon HD 2400	Display
AMD (ATI)	FireGL 6000	Display
AMD (ATI)	FireGL 8200	Display
AMD (ATI)	Radeon HD 2900 XT	Display
AMD (ATI)	Radeon HD 2600	Display
AMD (ATI)	Radeon HD 4850	Display
AMD (ATI)	Radeon HD4670	Display
AMD (ATI)	ATI Technologies, Inc. RAGE XL PCI	Display
AMD (ATI)	RADEON 7000 Series	Display
Analog Devices	AD1884	Audio
Analog Devices	AD1984	Audio
Analog Devices	AD1981	Audio
Analog Devices	ADI1986A	Audio
Analog Devices	ADI1988B	Audio
Analog Devices Inc.	ADI AC97	Audio
Apple	iPhone headset	Audio
Apple	iSight 640x480 Firewire	VidCap
Archos	Archos605(WiFi)	Portable Device
ATI	ATI HDMI	Audio
BlueAnt	X5 Stereo BT Headset	Audio
Brother	HL-5140	Print / Scan
Brother	HL-2070	Print / Scan
Brother	MFC-8440	Print / Scan
Brother	MFC-5840c	Print / Scan
Brother	HL-5150	Print / Scan
Brother	MFC-8840	Print / Scan
Brother	HL-6050D	Print / Scan
Brother	IntelliFax-5750e	Print / Scan
Brother	IntelliFax-5750	Print / Scan
Canon	Canon A720IS	Portable Device
Canon	Digital Rebel XT	Portable Device
Canon	A420\410	Portable Device
Canon	SD430	Portable Device
Canon	Pixma MP140	Print / Scan
Canon	Pixma iP1800	Print / Scan
Canon	Pixma iP1700	Print / Scan
Canon	Pixma iP2500	Print / Scan
Canon	Pixma MP210	Print / Scan
Canon	Pixma MP160	Print / Scan
Canon	Pixma iP1500	Print / Scan
Canon	Pixma iP1600	Print / Scan
Canon	Pixma iP4200	Print / Scan
Canon	Pixma iP3500	Print / Scan
Canon	Pixma iP4500	Print / Scan
Canon	Pixma MP180	Print / Scan
Canon	Pixma iP2000	Print / Scan
Canon	i475D	Print / Scan
Canon	Pixma MP150	Print / Scan
Canon	i250	Print / Scan
Canon	Pixma MP520	Print / Scan
Canon	S450	Print / Scan
Canon	MultiPass MP390	Print / Scan
Canon	Pixma MP500	Print / Scan
Canon	Pixma MX300	Print / Scan
Canon	Pixma iP1000	Print / Scan
Canon	Pixma MP610	Print / Scan
Canon	MultiPass MP190	Print / Scan
Canon	Pixma iP6210D	Print / Scan
Canon	Pixma iP5200	Print / Scan
Canon	Pixma iP3300	Print / Scan
Canon	Pixma iP3000	Print / Scan
Canon	Pixma MP510	Print / Scan
Canon	Pixma iP90	Print / Scan
Canon	i350	Print / Scan
Canon	Pixma iP6600D	Print / Scan
Canon	Pixma MP830	Print / Scan
Canon	BJC-6000	Print / Scan
Canon	i550	Print / Scan
Canon	Pixma MP170	Print / Scan
Canon	Pixma MP460	Print / Scan
Canon	Pixma MP600	Print / Scan
Canon	Pixma iP4300	Print / Scan
Canon	i860	Print / Scan
Canon	Pixma MP110	Print / Scan
Canon	i320	Print / Scan
Canon	Pixma iP6220D	Print / Scan
Canon	Pixma MP130	Print / Scan
Canon	Pixma iP6310D	Print / Scan
Canon	i960/i965	Print / Scan
Canon	Pixma MP950	Print / Scan
Canon	Selphy Series	Print / Scan
Canon	i560	Print / Scan
Canon	Pixma iP8500	Print / Scan
Canon	MultiPass MP370	Print / Scan
Canon	Pixma iP4000	Print / Scan
Canon	i9900	Print / Scan
Canon	Pixma iX4000	Print / Scan
Canon	i865	Print / Scan
Canon	Pixma mini260	Print / Scan
Canon	Pixma iX5000	Print / Scan
Canon	i850	Print / Scan
Canon	S530D	Print / Scan
Canon	Pixma MP800R	Print / Scan
Canon	Pixma iP5200R	Print / Scan
Canon	i470D Photo Printer	Print / Scan
Canon	S600	Print / Scan
Canon	BJC-85	Print / Scan
Canon	Pixma iP6000	Print / Scan
Canon	S9000	Print / Scan
Canon	Pixma MP750	Print / Scan
Canon	Pixma MP780	Print / Scan
Canon	S630	Print / Scan
Canon	MultiPass MP1000	Print / Scan
Canon	S520	Print / Scan
Canon	Pixma MP810	Print / Scan
Canon	Pixma iP5000	Print / Scan
Canon	Pixma iP6700D	Print / Scan
Canon	Pixma iP80	Print / Scan
Canon	SD600	Portable Device
Canon Inc.	PowerShot A720 IS	Portable Device
CASIO COMPUTER CO.,LTD.	EX-Z1200	Portable Device
Chrontel	Chrontel HDMI	Audio
Conexant	Venice	Audio
Creative	MP3+ (SB0270)	Audio
Creative	Xmod	Audio
Creative	Live! Cam Optia AF	VidCap
Creative	WebCam Live! USB	VidCap
Creative	Webcam NoteBook 640x480 USB	VidCap
Creative	WebCam Instant 352x288 USB	VidCap
Creative	WebCam NX Pro 640x480 USB	VidCap
Creative	WEBCAM NX	VidCap
Creative	Live! Cam Notebook Pro 640K USB 2.0	VidCap
Creative	Live! Cam Video IM Pro VGA USB 2.0	VidCap
Creative	Webcam Live Ultra 640x480 USB 2.0 Manual Focus Ring	VidCap
Creative Labs, Inc.	Live! Series	Audio
Creative Labs, Inc.	Audigy Series	Audio
Creative Labs, Inc.	X-Fi Series	Audio
Creative Technology Ltd	Nano Plus	Portable Device
Creative Technology Ltd	NOMAD MuVo TX	Portable Device
Creative Technology Ltd	Zen Vision M	Portable Device
Creative Technology Ltd	Vision W	Portable Device
Creative Technology Ltd	Sleek	Portable Device
Creative Technology Ltd	PMC v2	Portable Device
Dell	Axim X51v	Portable Device
Dell	AiO 810	Print / Scan
Dell	A924	Print / Scan
Dell	J740	Print / Scan
Dell	1600n	Print / Scan
Dell	A922	Print / Scan
Dell	A940	Print / Scan
Dell	LP 1720dn	Print / Scan
Dell	3100cn	Print / Scan
Dell	W5300N	Print / Scan
Denon	S-52	Media Sharing
Dixim	media server	Media Sharing
Dlink	DSM-210	Media Sharing
Dlink	DSM - 520	Media Sharing
Dlink	DSM - 510	Media Sharing
Drobo	Drobo NAS	Media Sharing
Epson	Stylus Color C88+	Print / Scan
Epson	Stylus Color C84/C85	Print / Scan
Epson	Stylus Color C86/C87	Print / Scan
Epson	Stylus Color C64	Print / Scan
Epson	Stylus Photo R265	Print / Scan
Epson	LQ-570/670	Print / Scan
Epson	FX-880	Print / Scan
Epson	Stylus Photo R220	Print / Scan
Epson	LQ-300	Print / Scan
Epson	Stylus Photo R320	Print / Scan
Epson	Stylus CX6600/6500/6900	Print / Scan
Epson	Stylus CX5400	Print / Scan
Epson	Stylus Photo 1270	Print / Scan
Epson	LQ-1070+	Print / Scan
Epson	Stylus Photo R200	Print / Scan
Epson	Stylus Photo 1280/1290	Print / Scan
Epson	Stylus Color 900/N	Print / Scan
Epson	Stylus Color C62	Print / Scan
Epson	ActionPrinter 5000+	Print / Scan
Epson	Stylus Photo 820	Print / Scan
Epson	Stylus Color 660	Print / Scan
Epson	Stylus Color 640	Print / Scan
Epson	AcuLaser 2600N	Print / Scan
Epson	FX-2170	Print / Scan
Epson	FX-2190	Print / Scan
FujiFilm	F30	Portable Device
General Electric	EasyCam USB PC Camera 640x480	VidCap
GN\Jabra	GN9330	Audio
GN\Jabra	GN9350	Audio
GN\Jabra	GN2000USB	Audio
HP	HD TV	Media Sharing
HP	Photosmart R717	Portable Device
HP	Deskjet D1400 series	Print / Scan
HP	Deskjet F380	Print / Scan
HP	Deskjet F4100	Print / Scan
HP	LaserJet 1018	Print / Scan
HP	LaserJet 1020	Print / Scan
HP	Photosmart C3180	Print / Scan
HP	Deskjet D2400 Series	Print / Scan
HP	LaserJet P2015	Print / Scan
HP	Officejet K550	Print / Scan
HP	PSC 1410	Print / Scan
HP	Deskjet F2100 series	Print / Scan
HP	PSC 1315	Print / Scan
HP	Deskjet 5440	Print / Scan
HP	Color LaserJet 2600	Print / Scan
HP	Officejet 5700	Print / Scan
HP	PSC 1510	Print / Scan
HP	Photosmart C4200	Print / Scan
HP	Deskjet 5150	Print / Scan
HP	Deskjet 930C/935C	Print / Scan
HP	Deskjet 5940	Print / Scan
HP	Photosmart C4180	Print / Scan
HP	Deskjet D2330	Print / Scan
HP	LaserJet 1022	Print / Scan
HP	Deskjet 3745	Print / Scan
HP	Deskjet 5550	Print / Scan
HP	Photosmart C5200	Print / Scan
HP	Officejet 5610	Print / Scan
HP	Deskjet D2360	Print / Scan
HP	Deskjet 3900 Series	Print / Scan
HP	Photosmart C5180	Print / Scan
HP	Deskjet 5740	Print / Scan
HP	Deskjet D4200 Series	Print / Scan
HP	Deskjet 6122	Print / Scan
HP	Deskjet 950C	Print / Scan
HP	Deskjet 940C	Print / Scan
HP	PSC 1610	Print / Scan
HP	Photosmart D5160	Print / Scan
HP	Officejet 6200 Series	Print / Scan
HP	Deskjet 3845	Print / Scan
HP	Deskjet 3650	Print / Scan
HP	PSC 2355	Print / Scan
HP	Officejet 6300 Series	Print / Scan
HP	LaserJet P2014	Print / Scan
HP	LaserJet 1300	Print / Scan
HP	Officejet Pro L7500	Print / Scan
HP	Officejet Pro L7600	Print / Scan
HP	PSC 1350	Print / Scan
HP	Deskjet 9800	Print / Scan
HP	Photosmart 2575	Print / Scan
HP	Deskjet 450ci	Print / Scan
HP	Officejet 4215	Print / Scan
HP	LaserJet 1160	Print / Scan
HP	Deskjet 5650	Print / Scan
HP	Officejet 7400 Series	Print / Scan
HP	Deskjet 3740	Print / Scan
HP	Officejet 5510 Series	Print / Scan
HP	Photosmart 3210	Print / Scan
HP	Officejet 7300 Series	Print / Scan
HP	Photosmart 7850	Print / Scan
HP	Deskjet 832C	Print / Scan
HP	Deskjet 1220C	Print / Scan
HP	LaserJet 3030 MFP	Print / Scan
HP	Photosmart A616	Print / Scan
HP	LaserJet 3055	Print / Scan
HP	Deskjet 720C	Print / Scan
HP	Photosmart 7260	Print / Scan
HP	Deskjet 3320	Print / Scan
HP	Deskjet 970C	Print / Scan
HP	Photosmart A440	Print / Scan
HP	Deskjet 695C/697C	Print / Scan
HP	Photosmart A516	Print / Scan
HP	Deskjet 6540	Print / Scan
HP	Deskjet 6940	Print / Scan
HP	PSC 2510	Print / Scan
HP	Officejet 6100 Series	Print / Scan
HP	Deskjet 6840	Print / Scan
HP	Photosmart A430	Print / Scan
HP	Photosmart 7450	Print / Scan
HP	Deskjet 812C/815C	Print / Scan
HP	Photosmart 375	Print / Scan
HP	Officejet V40 Series	Print / Scan
HP	Deskjet 840/843/845	Print / Scan
HP	Photosmart D7400 Series	Print / Scan
HP	PSC 950 Series	Print / Scan
HP	Officejet G Series	Print / Scan
HP	LaserJet 1015	Print / Scan
HP	Photosmart 7960	Print / Scan
HP	Deskjet 895C	Print / Scan
HP	Photosmart 8450	Print / Scan
HP	Photosmart Pro B8350	Print / Scan
HP	Deskjet 1180c	Print / Scan
HP	LaserJet 4345 MFP	Print / Scan
HP	LaserJet 4250	Print / Scan
HP	LaserJet P3005	Print / Scan
HP	LaserJet 5200	Print / Scan
HP	LaserJet 4350n	Print / Scan
HP	Color LaserJet 4700	Print / Scan
HP	LaserJet 2300	Print / Scan
HP	LaserJet 4000	Print / Scan
HP	Color LaserJet 5550	Print / Scan
HP	Color LaserJet 3800	Print / Scan
HP	LaserJet 4050	Print / Scan
HP	Color LaserJet 3600	Print / Scan
HP	LaserJet 9050	Print / Scan
HP	LaserJet 2100	Print / Scan
HP	LaserJet 4240	Print / Scan
HP	LaserJet 2200	Print / Scan
HP	Color LaserJet 3000	Print / Scan
HP	LaserJet 4100	Print / Scan
HP	LaserJet 5000	Print / Scan
HP	Business Inkjet 1200D	Print / Scan
HP	Color LaserJet 4550	Print / Scan
HP	Color LaserJet 4600	Print / Scan
HP	Color LaserJet CP4005	Print / Scan
HP	Color LaserJet 3700	Print / Scan
HP	Color LaserJet 3500	Print / Scan
HP	LaserJet 9000 MFP	Print / Scan
HP	LaserJet 4 Plus	Print / Scan
HP	LaserJet III	Print / Scan
HP	LaserJet 6MP	Print / Scan
HP	Color LaserJet 1500L	Print / Scan
HP	PSC 1315	Print / Scan
HP	Officejet 5610	Print / Scan
HP	PSC 1350	Print / Scan
HP	LaserJet 4345 MFP	Print / Scan
HTC	TyTN II	Portable Device
IDT	STAC9220(9223)7680	Audio
IDT	STAC9220(9223)7681	Audio
IDT	STAC9227X(D)7618	Audio
IDT	STAC9227X(D)7619	Audio
IDT	STAC9225(Sony)7662	Audio
IDT	STAC9225(Sony)7664	Audio
IDT	STAC9225(Sony)7661	Audio
IDT	STAC9200	Audio
IDT	STAC9228	Audio
IDT	STAC9205	Audio
IDT	STAC9250	Audio
Insignia	NS-BTHDP	Audio
Insignia	NS-DV4G	Portable Device
Insignia	NS-DA2G	Portable Device
Intel	Intel HDMI	Audio
Intel	i965GX/G35	Display
Intel	G3x	Display
Intel	i4G	Display
Intel	i45GM	Display
Intel	i915GM	Display
Intel	i915G	Display
Intel	i945G	Display
Intel	i945GM	Display
Intel	Q3x	Display
Intel	i965G	Display
Intel	i965GM	Display
Iriver	ClixGen2	Portable Device
Iriver	IriverClix2_FWv1.14	Portable Device
Iriver	U10 Series	Portable Device
Iriver	Clix	Portable Device
Jabra	BT620S	Audio
Jabra	BT8010	Audio
Jabra	BT3030	Audio
Jasco	Minicam Pro	VidCap
Kodak	Easyshare LS420	Portable Device
Konica Minolta	magicolor 5450	Print / Scan
Kyocera Mita	FS-6900	Print / Scan
LABTEC	LABTEC WEBCAM PRO 961358	VidCap
LABTEC	Web Cam Plus 352x288 USB 2.0 Manual Focus Motion Detection	VidCap
Lexmark	Z845	Print / Scan
Lexmark	Z1300	Print / Scan
Lexmark	X2550	Print / Scan
Lexmark	X1270	Print / Scan
Lexmark	X2470	Print / Scan
Lexmark	Z735	Print / Scan
Lexmark	E120n	Print / Scan
Lexmark	X3550	Print / Scan
Lexmark	Z715	Print / Scan
Lexmark	Z42 Color JetPrinter	Print / Scan
Lexmark	X5470	Print / Scan
Lexmark	Z816	Print / Scan
Lexmark	Z615	Print / Scan
Lexmark	X2250	Print / Scan
Lexmark	P915	Print / Scan
Lexmark	X7170	Print / Scan
Lexmark	X4550	Print / Scan
Lexmark	X6170	Print / Scan
Lexmark	X6150	Print / Scan
Lexmark	E232	Print / Scan
Lexmark	2490	Print / Scan
Lexmark	P3150	Print / Scan
Lexmark	X5150	Print / Scan
Lexmark	E323	Print / Scan
Lexmark	P315	Print / Scan
Lexmark	Z25 Color JetPrinter	Print / Scan
Lexmark	2491	Print / Scan
Lexmark	X215	Print / Scan
Lexmark	X4250	Print / Scan
Lexmark	E321	Print / Scan
Lexmark	Z45 Color JetPrinter	Print / Scan
Lexmark	X83	Print / Scan
Lexmark	C524	Print / Scan
Lexmark	E450D	Print / Scan
Lexmark	T640	Print / Scan
Lexmark	X634	Print / Scan
Lexmark	W840	Print / Scan
Lexmark	X632	Print / Scan
Lexmark	X620	Print / Scan
Lexmark	X630	Print / Scan
Lexmark	T642	Print / Scan
Lexmark	W812	Print / Scan
Lexmark	X1270	Print / Scan
LG	HBS-200	Audio
Logitech	QuickCam Pro 9000	Audio
Logitech	QuickCam Pro 9000	VidCap
Logitech	Quickcam Communicate STX VGA Fixed Focus USB 2.0	VidCap
Logitech	QuickCam Chat VGA w/Image Capture USB 2.0	VidCap
Logitech	961400-0403 QuickCam Notebook Deluxe 1.3MP MF USB 2.0	VidCap
Logitech	QuickCam Pro 4000 640x480 USB 2.0	VidCap
Logitech	QuickCam Pro 5000 640x480 USB 2.0	VidCap
Logitech	Quickcam Vision Pro1	VidCap
Logitech	Quickcam Vision Pro2	VidCap
Logitech	961403 QuickCam Fusion 1.3MP USB 2.0	VidCap
Logitech	QuickCam Messenger 640x480 USB	VidCap
Logitech	QuickCam Messenger Refresh 640x480 USB	VidCap
Logitech	QuickCam Notebooks Pro 1.3MP USB 2.0	VidCap
Logitech	QuickCam Zoom 640x480 USB	VidCap
Logitech	QuickCam Communicate 640x480 USB 2.0	VidCap
Logitech	QuickCam Orbit MP 1.3MP USB 2.0	VidCap
Logitech	QUICKCAMFORNB	VidCap
Logitech	QuickCam Orbit 640x480 USB 2.0	VidCap
Logitech	QuickCam for Notebooks Pro	VidCap
Lubix	UBHS-LC1	Audio
Matrox	M9120	Display
Microsoft	NX-3000	Audio
Microsoft	VX-7000	Audio
Microsoft	NX-6000	Audio
Microsoft	VX-6000	Audio
Microsoft	VX-3000	Audio
Microsoft	VX-1000	Audio
Microsoft	LX-3000	Audio
Microsoft	ZX-6000	Audio
Microsoft	Mic Array	Audio
Microsoft	XBox 360	Media Sharing
Microsoft	LifeCam VX-1000 VGA USB 2.0	VidCap
Microsoft	Lifecam NX-6000	VidCap
Microsoft	LifeCam VX-6000 1.3MP USB 2.0	VidCap
Microsoft	LifeCam VX-3000 1.3MP USB 2.0	VidCap
Microsoft	Xbox Live Vision (Xbox 360)	VidCap
Microsoft	Lifecam VX-7000	VidCap
Microsoft	Lifecam NX-3000	VidCap
Momento	Wireless Picture Frame	Media Sharing
Motorola	S9	Audio
Motorola	HT820	Audio
Motorola	H670	Audio
Motorola	HS850	Audio
Motorola	H500	Audio
Motorola	DJ S805	Audio
NEC	UTR-UC-1	Audio
Nero8 Home Media	media server	Media Sharing
Nikon	CoolPix S1	Portable Device
Nokia	BH800	Audio
Nokia	N95	Media Sharing
Nokia	N95	Portable Device
Nokia	5300	Portable Device
nVidia	nVidia HDMI	Audio
Nvidia	GeForce 7600GT	Display
Nvidia	GeForce 7800GT	Display
Nvidia	Geforce 8200	Display
Nvidia	GeForce 7400 Go	Display
Nvidia	Geforce 7950 GX2	Display
Nvidia	Geforce 8800GTS	Display
Nvidia	Geforce 8800GTX	Display
Nvidia	Geforce 8400 GS	Display
Nvidia	GeForce 8400M GS	Display
Nvidia	Geforce 8600 GT	Display
Nvidia	Quador NVS 130m	Display
Nvidia	Quadro 570	Display
Nvidia	Quadro 570m	Display
Nvidia	GeForce 9600 GT	Display
Nvidia	GeForce 8800 GT	Display
Nvidia	Geforce 8400GS (G98)	Display
Nvidia	Geforce 9800 X2	Display
Nvidia	Geforce GTX 260	Display
Nvidia	GeForce4 MX 420	Display
Nvidia	GeForce FX 5200	Display
Nvidia	Geforce FX 5900	Display
Nvidia	GeForce 6150	Display
Nvidia	GeForce 6100	Display
Nvidia	GeForce 6200	Display
Nvidia	GeForce 7050	Display
Nvidia	GeForce 6800	Display
Nvidia	GeForce Go 6150	Display
Oki	Microline 320/Turbo	Print / Scan
Oki	Microline 184 Turbo	Print / Scan
Oki	Microline 391/Turbo	Print / Scan
Oki	Microline 321/Turbo	Print / Scan
Oki	Microline 590	Print / Scan
Panasonic	KX-P2130	Print / Scan
Panasonic	KX-P2023	Print / Scan
Parrot	Boombox	Audio
Philips	Stereo Mic	Audio
Philips	GoGear 30GB	Portable Device
Plantronics	Pulsar 590A/E	Audio
Plantronics	Pulsar 260	Audio
Plantronics	Discovery 655 or 665	Audio
Plantronics	SupraPluc DA45	Audio
Polycom	CX400	Audio
Realtek	Realtek 262 HD Audio codec	Audio
Realtek	Realtek 268 HD Audio codec	Audio
Realtek	Realtek 660 HD Audio codec	Audio
Realtek	Realtek 862 HD Audio codec	Audio
Realtek	Realtek 883 HD Audio codec	Audio
Realtek	Realtek 888 HD Audio codec	Audio
Realtek	Realtek 885 HD Audio codec	Audio
Realtek	Realtek 882 HD Audio codec	Audio
Realtek	Realtek 861 HD Audio codec	Audio
Realtek	Realtek 662 HD Audio codec	Audio
Realtek Semiconductor Corp	Realtek AC97	Audio
Rhapsody	music Jukebox	Media Sharing
RIO	Rio Carbon	Portable Device
Roku	Radio Soundbridge	Media Sharing
Roku	SoundbridgeM1000	Media Sharing
S3	GammaChrome G700	Display
S3	GammaChrome G700	Display
S3	S3 Graphics Chrome 440/430 Series	Display
S3	S3 Graphics Chrome 440/430 Series	Display
Samsung	WEP-210	Audio
Samsung	YP-Z5	Portable Device
Samsung	ML-1610	Print / Scan
Samsung	SF-5100	Print / Scan
Samsung	ML-1710	Print / Scan
SanDisk Corporation	Sansa E260	Portable Device
SanDisk Corporation	Sansa View Mp3 Player	Portable Device
SanDisk Corporation	Sansa m250	Portable Device
SI	1392 HDMI	Audio
SigmaTel, Inc.	Sigmatel AC97	Audio
SiS	Xabre	Display
SiS	Mirage3	Display
Sonos	Zone player ZP80	Media Sharing
Sony	DR-BT22	Audio
Sony	PS3	Media Sharing
Sony	DSC-T200	Portable Device
Sony Corporation	WALKMAN NWZ-A816	Portable Device
Sony Ericsson	W910i	Portable Device
Toshiba	Gigabeat	Portable Device
Toshiba	Gigabeat V2 PMC	Portable Device
Turtle Beach	Audio Advantage Micro	Audio
Tversity Inc	media server	Media Sharing
Twonky Media	media server	Media Sharing
Via	DeltaChrome G700	Display
Western Digital	External harddrive	Media Sharing
Xerox	Phaser 6120	Print / Scan
Xerox	Phaser 4510	Print / Scan

Windows 7 에너지효율

 

 

이 글에서는 전원 관리에 대한 기본적인 내용을 말씀 드리고자 합니다. 전원 관리 (즉, 에너지 효율) 는  PC 에코시스템에서  중요한 문제로, PC 실행시의 에너지효율은 가장 에너지효율이 낮은 구성요소에 의해 제약을 받습니다. Windows 7 설계 시에는 실행 시스템의 에너지 사용 패턴을 중시하는 것이 명확하게 하여 앞으로도 지속적으로 하드웨어나 소프트웨어 제조사와 협력하여 노력할 것입니다. 모든 영역의 요구에 대한 균형을 유지하려고 할  때, 에너지 소비가 가장 눈에 띄어 알기 쉬울 것이라고 생각됩니다. 시스템을 시험적으로 실행할 경우에는 시스템을 전원에 접속함으로, 그에 따른 테스트 실행시의 수적인 변화를 분명히 알 수 있습니다 (영화 아폴로 13 에서  매핑이라는 전원을 유효하게 사용하기 위한 격투 모습 (미션 크리티컬한 문제이지만) 을 보신 분도 계시겠지만, ).이 글은 커널(Kernel) 팀을 통괄하는 프로그램관리 팀의 Dean DeWhitt 에 쓴 글입니다. 
--Steven

에너지효율은 현대 컴퓨팅에서 자주 언급되는 주제의 하나입니다. 그 증거로, 프로세서나 칩 세트의 공급업체는 제품에 대해, 단순한 프로세서의 클록 주파수나 벤치마크 성능 대신, 와트 당 성능" 을 팔고 있습니다.  "그린 컴퓨팅" (컴퓨팅 전력 소비와 환경에 미치는 영향 절감)에 관심을 가진 분들은 아실지 모르겠지만, 최종적으로 배터리 수명은 항상 모바일 PC 의 구매와 사용성에 영향을 주는 주요한 요인입니다. 이러한, PC 업계의 에너지효율에 관한 대처는 Windows 전원 관리 방법에 대한 지속적인 관심을 불러일으킵니다.

Windows 7 설계시 우리의 목표는 이전 출시 버전보다 전력 소비를 줄여서, 사용자가 Windows PC 에 원하는 성능과  기능을 제공하는 것이었습니다. Windows에서는 이미 풍부한 에너지 절약 기능이 제공됩니다. 예를 들어, 사용자가 컴퓨터를 사용하지 않을 때에는 디스플레이 전원을 끊고, 시스템을 자동적으로 절전 상태로 할 수 있습니다. Windows 7에서는 이러한 영역에 투자를 거듭하여 기존 기능을 확장하여, 시스템이 유휴 상태 일 때의 전력 소비를 줄이는 것을 중시했습니다. Windows에서는 프로세서, 하드 드라이브나 디스플레이 등이 다양한 장치의 전원 상태를 관리해야 하지만, 컴퓨터에서 실행되는 그 이외의 장치나 소프트웨어도 전력 소비와 배터리 수명에 대해 (그 이상이라고는 아닐지라도) 동일한 정도의 영향을 미칩니다.

우리는 에너지효율과 전력 소비에 대해 이야기를 할 경우에 과제가 되는 영역을 다음 세가지로 분류하고 있습니다.

• 기본 하드웨어 플랫폼 : 프로세서, 칩 세트 및 메모리. 모바일 플랫폼의 경우에는 배터리 용량도 포함됩니다. 기본 하드웨어 플랫폼은 플랫폼의 전력 소비에 큰 영향을 미칠 가능성이 있습니다. 최대 프로세서 속도, 코어 수 (프로세서가 모바일 장치용으로 설계된 경우), RAM 용량 등은 모두, 전력 소비에 영향을 미치는 요인이 됩니다.
• Windows : PC 운영 체제에서는 시스템의 다양한 장치를 관리하여,  이용 상황에 근거한 성능과 전력 소비 절충을 고려하여, 최종 사용자가 전원 계획과 설정을 통해서 전원 관리 방침을 세울 수 있도록 해야 합니다. 이 영역에서의 과제는 장치 전원을 적절히 관리하고, Windows 의 새로운 기능에 대하여 시스템 리소스 (CPU, 메모리와 디스크)가 가능한 효율적으로 사용하는 것입니다.
• 확장기능 : 확장기능은 다른 장치, 드라이버, 서비스와 응용 프로그램 등을 포함한 일반적인 카테고리입니다. 장치, 드라이버 및 그 외의 소프트웨어는 전력 소비에 중요한 영향을 미칠 가능성이 있고, 응용 프로그램 하나에 의해서 배터리 수명이 20% 이상 차이가 나기도 합니다.

Windows PC에서 에너지효율을 크게 향상하기 위해서는 이러한 각 영역에서의 대처가 필요합니다. 어느 쪽이든 한가지 영역의 한가지 구성요소에 관한 문제가 전력 소비에 큰 영향을 미칠 가능성도 있습니다. 따라서 플랫폼 관점에서 에너지효율의 문제에 입각해, 플랫폼의 각 구성요소에 대한 특별한 주위를 기울여야 합니다.

기본 하드웨어 플랫폼

기본 하드웨어 플랫폼은 실제로는 시스템 제조사에 따라서 다릅니다. 고객은 시스템을 구입할 때, 궁극의 선택을 하게 됩니다. 즉, 매우 효율적인 하드웨어 구성요소를 갖춘 시스템을 구입하는 것도, 전력 소비보다 성능이 우선된 구성요소를 갖춘 시스템을 구입할 수도 있습니다. 데스크톱 PC 나 모바일 PC 에는 다양한 폼 요소(form factor), 능력이나 전력 소비 수준이 다른 것이 있습니다. 모바일 PC 에는 표준적인 3 셀 또는 6 셀 배터리를 갖추고 있는 것도, 확장 9 셀 배터리 또는 컴퓨터에 추가 가능한 다른 외부 배터리를 가지는 것도 있습니다. Windows 의 과제는 Windows 에코시스템이 광범위하게 포함하는 하드웨어 에너지효율을 얼마나 향상시키는가 입니다. 최신의 랩톱 전원은 다음과 같은 경향이 있습니다.

 

데스크톱은 와트 수가 높지만, 전원의 배분은 비슷해 집니다. 데스크톱 PC 를 사용하는 경우에도, 디스플레이에서는 대량의 에너지가 소비됩니다.

운영 시스템

Windows 운영 체제는 플랫폼상의 다른 구성요소와 같은 정도 크기의 영향을 줄 가능성이 있습니다. Windows 7 설계의 목표는운영 체제서 전원 정책의 설정을 비롯, 뛰어난 기반 및 전력 절약을 구현할 수 있는 기회를 Windows 에서 제공할 수 있도록 하는 것입니다.

Windows  전원 관리에서 대부분의 사용자가 가장 먼저 사용하는 것은 [컨트롤 패널] 의 [전원 옵션] 또는 모바일 PC 의 배터리 미터입니다. Windows 에는 전원 설정이나 전원 계획이라고 하는 전원 관리 기능이 있습니다. 전원 계획에서는 필요에 따라서, 전원 설정 집합에서 다른 집합을 간단하게 변경할 수 있습니다.

 

전원 계획에서는 다양한 Windows 전력 절약 기능을 변경할 수 있습니다. 예를 들어, 비활성화 타이머를 사용하면, 디스플레이를 오프 하는 것도, 시스템을 자동적으로 절전 상태로 하거나 시스템을 원하는 데로 설정하기 위한 새로운 사용자 지정 전원 계획을 새롭게 생성할 수도 있습니다. 디스플레이의 전원 오프 기능과 절전 기능이나 유휴 기능은 전력 절약을 구현하여, 배터리 수명을 늘리기 위해서 매우 중요합니다. 위에 나타낸 것처럼, 디스플레이는 일반적인 모바일 PC 의 경우에는 할당된 전원의 40% 를 소비하고, 데스크톱 PC 의 경우에는 30 ~ 100 초의 와트 수를 소비할 가능성이 있습니다.

PC 의 OEM (특히 랩톱 제조사)는 특정 모델에서 사용 가능한 차별화된 하드웨어나 고유의 소프트웨어를 활용하기 위한 사용자 지정 전원 기능집합을 개발하는 경우가 자주 있습니다. PC 의 OEM 의 이름이 붙은 전원 기능을 보는 일도 자주 있겠지요. 이것들은 에너지효율의 향상에 임하는 OEM 에 의해서 개발된 것입니다.

간단한 힌트 : 데스크톱 PC 전력을 절약하는 가장 간단한 방법은 디스플레이의 유휴 타임아웃을 과감히 짧게 하는 (예를 들어, 2 분 또는 5 분으로 한다) 것입니다. 화면 보호기가 유효하게 되어 있는 경우는 무효로 하고, 디스플레이를 오프로 할 수 있도록 해 주세요. 모바일 PC에서  배터리 수명을 늘리는 가장 간단한 방법은 디스플레이의 밝기를 줄이는 것입니다. 또, 새로운 올인원 컴퓨터의 상당수는 랩톱 구성요소를 사용하고 있어, 전원 관리의 관점에서는 랩톱과 같이라고 보여지는 것에 주의해 주세요.

Windows에서는 필요에 따라서 성능을 향상시켜, 현재의 작업 부담량에 근거하여 전력을 절약하기 위해서, 프로세서의 성능을 관리하고, 현재의 이용 상황에 근거하여 동적으로 변경합니다. 예를 들어, 제가 이 블로그에 글을 쓸 때 등, 시스템이 거의 유휴 상태 때에는 최대의 동작 모드로 프로세서를 동작시킬 필요가 없기 때문에 프로세서의 전압과 주파수의 값을 낮게 하여 전력을 절약할 수 있습니다. 같이 하드 디스크드라이브나 그 외의 다양한 장치에서는 사용하지 않을 때에는 저출력 모드로 하거나 완전히 전원을 끊고, 전력을 절약할 수 있습니다.

Windows 7에서는 전원 관리를 위한 사용자 경험이 향상되어, 유휴 상태로의 전력 소비의 삭감과 새로운 장치 전원 모드의 지원이 중시 됩니다.

시스템이 유휴 상태 때의 전력 소비를 최적화 하는 데는 두 가지 이유가 있습니다. 첫 번째 이유는 PC 는 하루에도 다양한 때에 유휴 상태가 되기 때문에, 시스템이 유휴 상태가 되어 있는 시간이 증가하는 만큼 소비하는 전력이 줄어 들기 때문입니다. 두 번째 이유는 유휴 상태 때의 전력 소비가 "기본" 이 되어, 다른 모든 작업 부담량의 전력 소비가 추가되기 때문입니다. 예를 들어, 유휴 상태에서 15 W 소비하는 시스템에서는 다른 작업의 부담량을 처리하고 있을 때의 전력 소비가 추가됩니다. 유휴 상태 때의 플랫폼에서의 전력 소비를 줄이면, 다른 대부분의 시나리오로의 향상도 도모할 수 있습니다.

유휴 상태 때의 전력 소비를 줄이기 위한 제일 중요한 것은  프로세서, 메모리 및 디스크 사용을 최적화하는 것입니다. 프로세서는 광범위하게 전력을 소비하기 때문에, 프로세서의 사용을 줄이는 것은 가장 중요합니다. 완전한 유휴 상태 때에는 프로세서가 소비하는 전력은 100 ~ 300 mW 로 낮음입니다. 그러나, 완전히 가동할 때의 프로세서는 최고 35 W를 소비하는경우도 있습니다. 이와 같이 소비하는 전력에 상당한 폭이 있는 것은 프로세서가 비록 단시간만 동작해도 전력 소비와 배터리 수명에 큰 영향을 미칠 가능성이 있다는 것을 의미합니다. Windows 7에서는 프로세서의 사용을 줄이기 위해서 도움이 되는 몇가지 영역에 투자하여, 프로세서가 최소 절전 모드가 되는 시간이 보다 길어집니다. 이러한 투자 중 하나는 플랫폼상에서 실행되는 서비스 영역으로 이런 서비스가 필요한 때에게만 실행하도록 하는 "트리거 실행" 이라 불리는 것입니다. 이런 서비스는 효율적이고 서비스 자체가 미치는 영향은 최소한으로 억제되지만, 효과가 있는 몇가지 서비스를 추가할 수도 있습니다. 우리는 Windows 에서 이것들 양쪽 모두의 서비스를 관리하면서도 이 영역에 대한 투자를 인프라를 활용하기 위한 서비스를 생성하는 사람들을 위해서 확장하기 위한 방법을 찾고 있습니다 (이것들은 부팅 시간의 향상에 공헌하는 기능이기도 합니다).

유휴 상태 때의 전력 소비를 한층 더 줄이기 위해 우리는 코어 프로세서의 전원 관리 향상을 중시하고 있습니다. Windows에서는 현재의 이용 상황에 근거하여 프로세서의 성능이 조정되어 반드시 필요한 때에게만 프로세서 성능을 향상시키도록 하여, 전력 소비가 큰폭으로 줄어듭니다.

우리는 USB 장치 클래스의 확장 등, 장치의 전원 관리 영역에 투자하여, 오디오, 바이오 메트릭스, 스캐너, 스마트 카드 등이 광범위하게 건너는 장치로의 선택적인 중단 (selective suspend)을 가능하게 했습니다. 이러한 Windows 7에서 사용 가능한 기능에 의해서, 보다 에너지효율이 뛰어난 PC 설계가 가능하게 되었습니다. 또, 우리는 유/무선의 네트워크 장치의 전원 관리의 향상을 도모하기 위한 투자도 실시했습니다.

코어 인프라에 많은 투자를 하여, 몇가지 시나리오에서 에너지효율이 향상됐지만, Windows 7에서는 몇가지 주요한 고객 시나리오에서, 리소스 사용률 개선을 도모할 수 있는 영역을 특정하고, 모바일 플랫폼에서의 배터리 수명을 늘릴 수 있도록 하는 것을 중시했습니다. 그래서 특정된 시나리오가 미디어 재생이었습니다. DVD 재생을 최적화하려면, 프로세서와 그래픽 사용률 감소, 오디오 향상, 옵티컬 디스크드라이브 확장이 필요합니다. 이러한 향상을 도모하는 것에 대하여는 이미 성과를 올려 WinHEC 컨퍼런스에서 설명했던 대로, 광범위한 모바일 플랫폼에서의 배터리 수명을 큰폭으로 늘릴 수 있었습니다.

확장기능

그래픽 장치, USB 장치, 장치 드라이버, 백그라운드 서비스 및 설치 된 응용 프로그램은 모두 Windows 의 확장기능입니다. 전력 소비와 에너지효율의 대폭적인 향상을 도모하는 것은 플랫폼 확장기능의 효율을 향상시키는 것에 의해서 구현할 수 있습니다.

예를 들어, 하나의 USB 장치가 선택 중지를 지원하지 않는 경우를 생각해 보세요. 그 USB 장치 자체는 매우 적은 전력 밖에 소비하지 않을지도 모르지만, (지문 리더 등) 그 장치가 중지 상태가 될 때까지, 프로세서와 칩 세트는 매우 빈번히 장치를 폴링하고, 새로운 데이터가 있는지 확인할 필요가 있습니다. 그러한 폴링에 의해, 프로세서가 최소 절전의 유휴 상태가 되는 것이 방해할 수 있고, 일반적인 비즈니스 클래스의 노트북의 경우는 배터리 수명이 20 ~ 25% 짧아집니다.

에너지효율의 대폭적인 향상이 요청되는 영역은 장치 이외로도 있습니다. 응용 프로그램과 서비스 소프트웨어도, 전력 소비에 큰 영향을 미칠 가능성이 있습니다. 예를 들어, timeBeginPeriod API 를 사용하여 플랫폼 타이머의 정밀도를 향상시키는 응용 프로그램에 대해 생각해 봅시다. 그 경우, 플랫폼의 타이머 틱(timer tick) 정밀도가 향상되어, 프로세서가 최소 절전의 유휴 모드를 효율적으로 사용할 수 없어집니다.  하나의 응용 프로그램에서 타이머 정밀도가 1ms 까지 향상된 상태가 유지되면, 일반적인 노트북 PC 의 경우는 배터리 수명에 최대 10% 의 영향이 미치는 것이 관찰되었습니다.

우리는 파트너와 밀접하게 제휴하고, Windows 플랫폼의 확장기능의 에너지효율의 향상에 노력하고 있습니다. 우리가 채용하는 방법은 하드웨어와 소프트웨어의 에너지효율 문제를 특정하기 위한 풍부한 도구를 제공하는 것입니다. Windows 7에서는 에너지효율의 문제에 관한 HTML 형식의 리포트를 제공하는 새로운 인 박스(in-box) 유틸리티 (전원 문제에 관한 "톱 10" 체크리스트)를 추가했습니다. Windows 7에서 시험해 보고 싶은 경우는 관리자 특권으로 명령 프롬프트에서 powercfg /energy 를 실행해 주세요. Powercfg 를 실행할 경우에는 열려 있는 응용 프로그램과 문서를 모두 닫아야 합니다. 이 유틸리티는 시스템이 유휴 상태 때의 에너지효율 문제를 검색하도록 설계되었습니다. energy 매개 변수를 지정해 powercfg 를 실행하면, 중단없이 USB 장치와 플랫폼 타이머의 정밀도가 향상한 응용 프로그램을 검색 할 수 있습니다.

보다 심층 분석을 실시하기 위해서, Windows Performance Toolkit 도 제공됩니다. 소프트웨어 개발자는 Performance Toolkit (http://www.microsoft.com/japan/whdc/system/sysperf/perftools.mspx)을 사용하면, 응용 프로그램의 리소스 사용률 관찰, 성능 병목 상태 해결 및 에너지효율에 영향을 주는 문제의 특정을 매우 간단하게 실시할 수 있습니다.

PC를 끌 때 경우 전력 절약

지금까지는 PC 가 켜져 있을 때의 전력 절약에 대해 설명해 왔습니다. 그러나, PC 가 사용되지 않을 때에 최소 절전 모드가 되도록 하면 전력을 절약할 수 있습니다. 많은 사용자는 컴퓨터를 사용하지 않을 때에 종료하지만,  모바일 PC 가 절전 상태 (경우에 따라서는 최대 절전 모드 상태)가 되도록 하는 사용자도 있습니다. 사용자가 시스템을 사용하는데 적절한 모드를 선택할 수 있도록 하기 위해, Windows 에는 두가지 전력 절약 모드가 있습니다.

• 절전 상태 : 열려 있는 프로그램, 문서 및 파일이 시스템의 RAM 에 저장되어 시스템 그 이외 부분의 전원이 끊어집니다. 절전 상태에서는 메모리에만 전원이 공급되므로, 전력 소비가 매우 적어집니다 (일반적으로 모바일 PC에서는 1 W 미만, 데스크톱 PC에서는 3 W미만).절전 상태의 주요 이점은 매우 단시간에 시스템을 재개할 수 있는 것입니다. 대부분의 시스템에서는 2 초 미만으로 절전 상태에서 재개할 수 있습니다.
• 최대 절전 모드 상태 ： 열려 있는 프로그램, 문서와 파일이 모두, 시스템의 RAM에서 하드 드라이브에 복사됩니다. 생성된 파일은 절전 모드 설정 파일로 불립니다. RAM 가 절전 모드 설정 파일에 복사된 다음에 모든 PC 의 전원이 끊어집니다. 최대 절전 모드 상태는 모바일 PC 에서 자주 사용됩니다. 왜냐하면, 대부분의 랩톱에서는 소비 전력이 0 W 에 가까워, 배터리를 다 쓴 후에도 열려 있는 모든 프로그램과 문서가 절전 모드 설정 파일에 복사되기 때문입니다. RAM 사이즈가 계속 증가해도, PC 에 따라서는 저장소에 한계가 있기 때문에 최대 절전 모드 상태는 일반 사용자에서 최적인 옵션이라고 말할 수 있습니다 (간단한 힌트로서는 디스크 클린업 마법사 또는 powercfg –hibernate off 에 의해서, 최대 절전 모드 상태를 위해서 미리 할당된 디스크 영역을 삭제할 수 있습니다).
• 종료 : 일반적인 Windows  종료입니다. 메모리나 디스크에는 아무것도 저장 되지 않습니다. 다음 시스템 전원이 켜질 때 시스템은 다시 부팅됩니다.

우리는 샘플 데스크톱 PC 를 사용하여, 절전 상태, 최대 절전 모드 상태, 종료 상태 및 기본적인 온 상태 (데스크톱만이 표시되어 아무것도 프로그램이 열리지 않은 상태)의 전력 소비를 측정했습니다. 또, 재시동의 지연 (시스템이 온상태에 돌아오기까지 걸리는 시간)에 대해도 측정했습니다.

 

이 그림에서도 절전 상태에서의 안정성과 성능을 중시하여, 대부분의 사람들에게 컴퓨터를 사용하지 않을 때에는 절전 상태로 하는 것을 권장하는 이유가 명백해집니다. 절전 상태에서는 종료 상태와 거의 같은 전력이 소비되지만, 시스템이 부팅 프로세스 없이 2 초 미만으로 재개됩니다. 부팅 때에는 대량의 전력이 소비되므로, 컴퓨터 전원을 꺼서 전력을 절약하거나 컴퓨터를 저전력 상태로 할지를 검토할 때는 컴퓨터를 사용하지 않는 시간이 어느 정도 있는지를 생각해야 합니다.  그렇지만, 이전의 블로그에서 설명한 것과 같이 부팅 ( 및 종료)이 Windows 7 을 설계하는데, 성능을 향상시키는데 매우 중요한 요인이 되는 것은 분명합니다.

다음 단계

우리는 Windows PC 의 에너지효율을 지속적으로 향상시키기 위해  노력하고 있습니다. 또, 전원이 어디서 소비되고 있는지를 식별하기 위한 도구와 Windows 7 의 코어 플랫폼 전원 관리의 대폭적인 향상을 도모했습니다. 앞으로 해야 할 일들이 아직 많이 있지만, 베타 버전 출시를 기대하며, CEIP에서 에너지효율과 전원 관리에 관한 피드백을 기다리고 있습니다. 물론, 지속적으로 에코시스템 외 멤버와 밀접하게 제휴하여, 전원이 하나가 되고, PC, 소프트웨어 및 주변기기의 제조, 사용 및 수명 주기의 종료에 이르기까지의 에너지 효율 향상에 크게 공헌하기 위해 노력할 것입니다.

--Dean

Published Sunday, February 01, 2009 12:16 AM by e7blog

Filed under: Perf

사용자 계정 컨트롤 (UAC) 업데이트

 

 

어떻게 우리가 사용자 계정 컨트롤 (user account control = UAC)를 개선했는지를 대해서, 매우 많은 반향이 전해졌습니다. 여기서, 여러분에 대해서 간단하게 정보를 업데이트 해드리고 싶습니다. 많은 분들은 자신에게 맞게 설정된 것 같다는 피드백을 주셔서 기쁘게 생각합니다. 여기에서는 기본 선택에 대해 자세하게 보고합니다. --Steven

이전 글에서 UAC 의 「왜」와 UAC 의 Windows, 에코시스템 및 사용자에 대한 의미에 대해 말씀 드렸습니다. 또, 전해진 데이터나 피드백에 대처해 보다 좋은 것과 하기 위해, 우리에게 필요한 것은 무엇인가 말하는 일도 이야기했습니다.

UAC 의 목적을 지지해 주신 여러분에서의 주석은 유익하고 중요한 것입니다. UAC 는 사용자가 시스템을 관리하에 두고, 장기간의 보유 비용을 줄이고, 소프트웨어 에코시스템을 개선할 수 있도록 하기 위해 생성되었습니다. 또한 전체적인 경험을 향상시키기 위해서, 보내주신 피드백을 고려하려 원격 측정에 근거하여 개발할 것입니다.

빌드 6801 을 사용하시는 분은 프롬프트 삭감과 개선된 새로운 대화상자 메시지가 장점이라고 합니다. 또, 사용자가 자신의 시스템에 대해서 보다 강력한 제어권을 얻기 위해 새로운 UAC 컨트롤 패널도 있습니다. 관리자는 UAC에서 받는 통지의 수준을 보다 상세하게 컨트롤 할 수 있게 되었습니다. UAC 컨트롤 패널은 시작 메뉴의 검색, 액션 센터, 소개 및 UAC 프롬프트에서도 열 수 있으므로 찾아 보세요. 물론, Vista에서와 같이 익숙한 방법으로 액세스 가능합니다.

 

그림 1: UAC 컨트롤 패널

 

UAC 컨트롤 패널에서는 4 종류의 설정에서 선택할 수 있습니다:

1. 모든 시스템변경에 대해 항상 통지. 이것은 Vista 에서의 동작입니다 - 시스템 레벨 변경 (Windows 설정, 소프트웨어 설치 등)이 있으면, UAC 프롬프트가 표시됩니다.
2. 프로그램이 컴퓨터에 대해서 변경을 하려고 할 때만 통지한다. 이 설정은 자신이 컨트롤 패널이나 관리 작업이라는 Windows 설정을 변경할 때 프롬프트는 표시되지 않습니다.
3. 프로그램이 컴퓨터에 대해서 변경을 하려고 할 때만 통지한다. 다만 보안으로 보호된 데스크톱은 사용하지 않는다. 이것은 2번째와 같지만, UAC 프롬프트는 보안으로 보호된 데스크톱 대신 일반적으로의 데스크톱에 표시됩니다.
4. 통지하지 않는다. 이것은 UAC 를 완전하게 오프로 합니다.
   

보내준 피드백에서, 고객은 컨트롤이라고 표시되는 통지 건수보다 좋은 밸런스를 원한다는 것을 알게 되었습니다. 이전 글에서도 말한 것처럼, 많은 관리자 (또는 개발자)의 고객이 이 밸런스를 요구하고 있습니다. 우리의 데이터에 의하면, 대부분의 머신 (75%)은 관리자 특권을 완전히 갖춘 단일 계정으로 실행됩니다.

 

그림 2. 2008 년 1 월에서 2008 년 6 월까지의 하나 이상의 사용자 계정이 있는 머신 비율 (서버 제외)

 

제품 기본은 이러한 고객에게 초점을 맞춰 두번째의 「프로그램이 컴퓨터에 대해서 변경할 때만 통지한다. 」를 선택했습니다. 이 설정은 자신이 컨트롤 패널 등 Windows 설정을 변경할 때 프롬프트는 표시되지 않습니다. 대신에 Windows 이외의 응용 프로그램에 의해서 요청된 관리자 수준 변경 (새로운 소프트웨어의 설치 등)에 초점을 맞출 수 있도록 합니다. 추가적인 통지 없이 Windows 설정을 자주 변경하는데 보다 강한 제어권을 원하는 사람들에게 이 설정은 전체적인 프롬프트의 수를 줄여주고, 나머지 중요한 통지에 집중할 수 있습니다.

이 기본 설정은 다양한 고객의 원하는 적당한 통지 변경을 가져옵니다. 동시에 새로운 컨트롤 패널 ( 및 정책)에 의해서, 관리자가 받는 통지 수의 설정을 조정하는 것이 간단하여 바로 발견되도록 했습니다. 모든 기본 선택에 대해, 베타 기간 중 계속 최종제품을 위해서 결정할 때까지,  보내주시는 피드백과 데이터를 주의 깊게 모니터 계속할 것 입니다. 

--UAC, 커널 및 보안의 프로그램 관리자

 

 

Published Monday, February 02, 2009 8:32 AM by e7blog

Filed under: Security

성능 논의 지속

 

 

이 블로그에서  성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를 읽고 계신 여러분들도 매우 흥미로울 것이라고 생각합니다. 성능에 대해 어떻게 생각하고 개발을 하는지 여러 가지 에피소드에 대해 좀 더 많은 정보를 제공을 드리고자 합니다. 물론, 저도 최근까지 매우 낮은 사양의 머신을 사용했기 때문에 성능은 개인적으로도 중요한 문제입니다. 다만, 현재 이 블로그는 크리스마스 선물로 본인에게 선물한 것을 집에서 사용하고 있습니다. 64 비트의 일체형 데스크톱으로, CPU 는 Quad Core, discrete graphic, 메모리 8GB,RAID 가 탑재되어, 초기설정을 끝내자마자 업그레이드된  새로운 Windows 7 빌드가 운영됩니다. 이 글은 Michael Fortin 과 함께 썼습니다. --Steven

베타는 아직 완성되지 않았지만, 벌써 많은 분들이 벤치마크를 시작하여 시험을 하고 있습니다. 만약을 위해 말씀 드리지만, 출시 이전 빌드의 벤치마크 테스트는 좀 더 기다려 주시기를 바랍니다. 이렇게 말씀 드려도 많은 사람이 여러가지 판단을 내려야 한다는 것을 알고 있습니다. 동시에 출시전의 코드 상황인 것을 사람들에게 알려 주기 위해, 시간을 들여주신 분들에게 감사 드립니다. 무엇보다도, 현재 많은 분들이 좋은 결과를  볼 수 있다는 것을 기쁘게 생각합니다. Windows 7 의 모든 기초적 능력이나 사람들이 기대하는 새로운 기능이 제품이 완성했을 때는 한층 더 큰 기쁨이 될 것이라고 믿고 있습니다.

이 블로그에서 성능에 대해 쓰는 것은 그것을 측정한다라는 것처럼 미묘한 일입니다. 방향성을 보여주는 의지 표명이 우리의 의도 이상으로 받아 들여지는 것을 보았습니다. 또 동시에 성능 측정 방법은 한편으로 무한대라고 생각될 만큼 많고, 같은 데이터의 파악방법도 다양합니다. 결국, 성능은 각개인이 느끼는 것이라고 말할 수 있는 것이 아닐까 생각했습니다. 적절한지 우수한지는 시나리오나 개인에 따라서 변합니다. 지금까지 받은 메일 중에서 성능에 대해 명백한 것이 있었습니다. :

 

• 모든 응용 프로그램 (열어서 로드하는 응용 프로그램) 를  매우 빠르고 실행하고.특히, 많은 것을 동시에!!!!! 따라서 모두에게 대규모 멀티 코어 (quad-octa core CPU) 와 GPGPU 를!!!!!!!!!!!!
• 지금이 그 때입니다. 사용자는 스피드를 원하고 우리는 스피드를 줄 수 있습니다.
• 1.5GHz 의 Intel Atom CPU (싱글 코어) 와 메모리 1GB 를 탑재한 Acer의 NetBook 「Aspire One」에서 Windows 7 을 매우 빠르게 움직이면서, 그래픽도 제대로 된 한 것을 보고 싶다.
• Windows 7 에서는 GUI 와 심장부의 향상 (대규모 멀티 코어 + 64 비트 + Direct 11…최고의 성능 등)을 포함하여, 플립 3D 기능을 개조해 주었으면 한다!!!!! 플립 3D 기능을 Windows 7 에서 효과적 이며 실용적인 것으로 했으면 좋겠다.
• 성능에 대한 것으로 많은 폰트를 설치 할 때  불편함을 줄여주는 방법을 찾아내 주세요.
• 성능, 실행, 검색 스피드 및 UI 경험에서 Windows 차기 버전에서는 새롭운 혁신적인 무엇인가를 가져왔으면 좋겠습니다. HP Touch Smart PC 의 새로운 UI 을 사용해 보았지만, 그들은 터치 인터페이스 컨트롤은 훌륭합니다.
• Windows Vista 보다 성능이 월등히 향상되기를 바랍니다.
• 많은 사람들이 바라는  최대 기능은 성능입니다.

이러한 주석에서 성능은 사람에 따라서 각각 다른 의미를 가진다는 것을 알 수 있습니다. 사용자 인터페이스 담당자는 잘 알고 있지만, 지각된 성능과 실제 성능은 자주 다들 때가 있습니다. 제(Steven)가 Windows UI 의 일부를 Visual C++를 쓰고 있고, Borland C++ 와 벤치마크를 비교 했을 때, 우리는 확실히 빨랐지만(초 단위 측정), 비교 문서에서는 항상 Borland 가 빠르고, 컴파일로 처리된 행수의 형식에서 결과를 표시한다고 합니다. 그래서 저는 컴파일 중에 몇 번이나 점멸하는 행수를 표시하는 코드를 넣었습니다 (문자 그대로 반짝반짝 점멸하여, 이제 안 된다고 말하는 것처럼 보였습니다).시계 시간으로는 실제로 그 처리에 시간을 소비하여, 그 만큼 「늦어진다」는 것이지만, 반대로 이번은 우리가 빠르다는 칭찬을 받았습니다. 즉, 이 경우에서는 늦게 볼 수 있던 것이 실제로는 빨랐던 것입니다.

또, 이것과 반대의 이야기가 과거에 있었습니다. Microsoft Word for DOS 스크롤 속도에 대한 것으로(Excel for Windows에서도 같습니다)  초기 무렵, Bill Gates 는 언제나 눈에 보이는 성능 강화를 추진했지만, 스크롤 속도는 언제나 충분한 스피드에 이르지 않는 한가지였습니다. 머리 좋은 사람들이 모여 이 문제에 열심히 고민한 결과, 이번은 스크롤이 너무 빠르게 되었습니다. 문자 그대로, 감속하지 않으면 안 될 정도 입니다. 그렇지 않으면 [Page Down] 키를 누르는 것만으로, 항상 문서의 첫번째 페이지에서 마지막으로 갔습니다. 빠른 것이 좋은 일이지만, 가끔 「너무 빠른」경우도 있습니다.

 

보다 좋은 성능을 위해서, 무엇을 오프로 하거나 조정하거나 하는 것이 좋은지 피드백을 받았던 적이 있습니다. 또, 성능이 생각했던 것보다도 좋지 않은 원인을 찾고 싶다는 분들도 있습니다. 최근 저는 새로운 노트 PC 의 성능 문제를 밝히고자 하는 분과 전자 메일을 교환했습니다. 이야기를 들을 때에 그 노트 PC 는 매우 「클린」 (프로세스는 40까지, 탑재 메모리 1GB 의 반은 프리, 유휴 상태로 CPU 사용율은 5% 미만)한 상태 라는 것을 알 수 있었습니다. 그리고, 한층 더 알아본 결과, 인터넷 접속 (전화 접속)이 그 시스템에서의 가장 큰 병목 상태였다는 것이 판명되었습니다. 많은 사람이 애니메이션이나 그래픽, 또 색조차도 오프로 하는 것을 추천합니다. 그것은 이것들이 성능의 근원이라고 믿을 수 있기 때문입니다. 레지스트리, 디스크 영역 활용, 색의 깊이에 대해 사람들이 성능 문제의 가능성이 있다고 생각하는 주제를 다뤘습니다.

성능은 본질적으로 시간과 공간의 절충 (SF 대신, 컴퓨터 과학적으로)으로, 노트 PC에서는 한층 더 전력 소비 (또는 CPU 활용)의 측면이 있습니다. 메모리가 무한하다고 가정하면, 물론 많은 알고리즘은 지금 있는 것과는 완전히 다를 것입니다. 유한한 메모리에서는 성능이 전체적인 일련의 시나리오에 크게 영향을 받습니다. 때문에 많은 경우에서는 성능에 대해 이야기할 때는 시계 시간에 대해 이야기하는 것과 같은 정도, 메모리의 소비량 삭감과 관련됩니다. OS 일부는 메모리 사용량의 관점에서는 훨씬 더 조절 가능하게 되어 있어 그 결과, 시스템 전체의 성능이 향상합니다 (적은 페이지로 해결되기 위해).시스템 외 부분은 실행되는 명령의 수가 관계합니다 (거의 모든 오퍼레이션은 코드 경로를 통과하기 위해).우리는 두 가지 모두 상당한 작업량을 할애하고 있습니다!

성능 측정 및 향상의 현실은 Windows 7 에서 우리가 몇가지 「수준」에 집중하고 있는 것입니다. 그것들은 마이크로 벤치마크, 특정 시나리오, 시스템 튜닝에서 Windows 7 을 어떻게 설계할지에 대해 각각 중대한 역할을 이루어 있습니다. 어느 것이나 측정 가능하지만, 어떤 것이나 하나의 측정에서 시스템 성능을 간단하게 결론짓는 것은 사실과 다릅니다.

 

마이크로 벤치마크(Micro-benchmark).마이크로 벤치마크는 테스트의 일종으로, 특정 하위 시스템에 대하여 극한 수준까지 스트레스를 줍니다. 이것은 자주, 매우 고속으로 전체 실행시의 일부 시간밖에 차지하지 않는 듯한, 사용시의 성능을 보는 것이 곤란한 코드 영역입니다. 테스트는 시스템의 일부에 스트레스를 추가하는 것과 같이 설계됩니다. 시스템이 많은 파트는 마이크로 벤치마크의 대상입니다. 예를 들어, 파일시스템, 네트워크, 메모리 관리, 2D 및 3D 그래픽 등입니다. 좋은 예로서 고속 파일 복사를 가능하게 하는 작업이 있습니다. 파일을 복사할 때는 (상당한 ) 수많은 조건의 요인이 되는 하위 코드가 다수 존재합니다. 그리고, 이 코드는 커멘드 윈도우 (또는 API)로 XCOPY 를 개입시켜 가장 직접적으로 실행됩니다. 물론, 복사 작업의 대부분은 탐색기에서 행해져 진행상황 표시, 취소할 수 있도록 하기 위한 작업, 복사 중에 바이트 수 계산 등도 함께 행해집니다. 이러한 모두에는 어느 정도의 비용을 지불하지 않으면 안됩니다 동시에 거기에 따라 이익도 있습니다. 마이크로 벤치마크의 목적은 최선의 경우를 잘 이해하여, 가장 사용에 적절한 경우와 비교하는 것입니다. 고급 사용자는 보다 권한이나 컨트롤, 유연성을 얻기 위해서, 언제나 명령줄을 사용합니다. 마이크로 벤치마크의 결과 향상에 의해, 시스템 성능을 측정하기 쉽습니다. 그러나, 몇 번이나 반복하지만, 특정 사용 방법은 훨씬 광범위한 코드 경로에 이르러, 시간도 다양한 장소에서 소비되므로 이것은 부적절하다는 것을 압니다. Internet Explorer 8 에서 스크립트 성능에 관련한 이런 종류의 문제를 논했던 성능에 대한 글을 썼습니다. 한편 그 반대로, 하위 시스템에서는 마이크로 벤치마크에 의해서 성능을 측정할 때, 주의 깊게 해야 하는 것인 것을 우리는 잘 이해하고 있습니다. 예를 들어, DirectX 그래픽 성능은 게이머를 목표로 하는 분야입니다. 또, 많은 마이크로 벤치마크는 Windows OS, 하드웨어, 특정 드라이버 편성에 의존하는 것도 주목할 만합니다.

 

특정 시나리오. 대부분의 사람은 부팅, 대기/다시 시작, 일반적인 응용 프로그램 실행이라는 높은 수준의 동작을 개입시켜 PC 성능을 실감합니다. 이것들은 과거에도 채택했던 주제입니다. Windows 7 설계에서는 각 팀이 개선하고 싶은 특정 시나리오에 초점을 맞추었습니다. 이런 종류의 작업은 꼼꼼한 설치나 추가 도구를 필요로 하지 않고 검증할 수 있는 것입니다. 이 작업에는 실행되는 수많은 명령의 코드 경로를 튜닝하거나 자주 있는 경우를 위해서 배포된 데이터를 보거나 모든 OS 의 API (예를 들어, 레지스트리 검색 등)를 이해하는 것이 포함됩니다. 예로서 USB 장치를 다시 넣는 시간을 줄이기 위해서 계속하는 작업이 있습니다. 이것은 특히 UFD (USB 플러시 장치)나 메모리카드에 대해서 현저합니다. Windows 는 전체의 하위 시스템이 특정 카드 리더나 UFD 용의 고유 드라이버에 의해서 정밀 조사 되는 것을 허가합니다. 비록 대부분의 경우 같아도, 우리는 에코시스템의 다양성에 대해 책임을 지지 않으면 안됩니다. 프로젝트를 시작할 때, UFD 가 삽입될 때에 실행되는 코드의 완전한 프로파일을 확인하여 이 시나리오에 구석에서 구석까지 살펴보았습니다. 그 후, 체계적으로 각각의 「핫 스폿」을 극복해 나갔습니다. 또, 이 선에 따른 다른 예로서 저장소 하위 시스템 뿐만이 아니고 그래픽서브시스템도 관계하는 DVD 영화의 재생을 들 수 있습니다. 이 시나리오의 좋은 점은 전력 소비에 영향을 주는 CPU 이용에 대해도 최적화하고 싶어지는 것입니다.

 

시스템 튜닝.상당한 양의 성능 작업이 시스템 튜닝과 관련됩니다. 이 분야에서 실시하고 있는 작업을 확인하기 위해, 우리는 정기적으로 시스템의 전체적인 성능을 이전 빌드나 이전에 출시한 Windows 와 같은 테스트와 비교합니다. 그리고, 많은 시간·영역·전력을 소비하는 오퍼레이션이나, 이러한 차원의 어느 쪽이든 「성장」이 있는 오퍼레이션을 없애기 가능한 것을 찾고 있습니다. 또, 빌드별로 테스트를 실시해서, 기능이 저하되지 않은지 확인하는 것과 동시에 각 개발자는 자신의 담당 영역이 좋아지도록 책임을 지고 있습니다. 우리는 개선을 위해서 할 수 있는 것이 없는지, 모든 수단을 동원하여 조사하고 있습니다. Pre-Beta 또는 베타 버전의 Windows 7 을 사용해 보고 많은 사람이 곧바로 깨닫는 것의 하나에 데스크톱 윈도우 관리자의 메모리 사용량 (작업 관리자로 측정되므로, 그것 자신의 측정값은 오해 받을지도 모릅니다)이 있습니다. Windows 7에서는 방대한  아키텍처 작업이 하위 시스템에 의해서 소비되는 메모리량을 줄이기 위해서 투입되었습니다. 이 작업은 Windows Vista 용 드라이버와의 호환성을 유지하면서 실행되었습니다. 같은 작업을 데스크톱 검색 엔진에 대해서도 가서, 메모리 뿐만이 아니라 I/O 의 발자국(리소스 소요량)도 줄였습니다. 무엇보다 복잡했던 작업의 하나로 작업 표시와 시작 메뉴가 개선되었습니다. 이 개선에는 중대한 부분 (코드의 「저해」영역)이나 레지스트리 I/O, 전체 코드 경로에 대한 상당한 작업이 발생했기 때문입니다. 이 작업의 목적은 UI  요소가 항상 이용 가능하고 잘 움직이도록 하는 것이었습니다.

응용 프로그램의 선택 사용자 인터페이스를 추진하는 포괄적인 성능의 측정 방법도 있습니다. 그것들은 다른 기초적인 하드웨어 또는 드라이버를 같을 버전의 Windows 에서 비교하는데 가장 적합합니다. 그 이유는 자동화 그 자체가 자주 버전에 의존하기 때문에 자동화는 자연스럽지 않은 방법으로 행해져, 실제로 느껴지는 성능 변화 대신, 이 차이를 측정하는 경향에 있습니다. 전형적인 예로서 드롭 다운 메뉴를 드로잉하기 위한 코드 경로가 있습니다. 더 액세스 하기 쉽게 하거나 매력적으로 하기 위해 메뉴에 명령을 추가하면, 훨씬 빠른 스피드로 메뉴 구동하는 자동화된 시스템에서는 「성능」 변화를 알 수 있을지도 모릅니다. 만약을 위해 말씀 드리지만, 이런 종류의 상황에서는 마이크로 벤치마크 효과는 실제 사용 패턴 과는 모순된 형태로 증대 됩니다.

다양한 측정 방법으로 초점을 맞추고 생각하면, Windows 7 에 대한 종합적인 목적은 사용자의 여러분이 기대에 따른 시스템을 체험하는 것은 중요합니다. 성능의 사고 방식은 특정 벤치마크의 결과와 같은 정도 중요합니다. 그리고, 성능의 전체상 배치를 근거로 해서 작업하고 있는 것을 확실한 것으로 하기 위해, 앞에서 한 얘기와 같이 폭넓은 도구에 대해서 주의해야 합니다.

폭넓은 전략에 덧붙여 우리가 도입하고 있는 특수한 도구가 있습니다. 그 하나가 PerfTrack 라는 도구로, 성능에 관해서 데이터 역할을 다음의 수준에 가지고 가므로, 베타로 중요한 역할을 완수합니다.

 

• 몇 천 가지 다양한 경우를 측정하기 위한 일련의 테스트 코드를 생성하여 보수해 왔습니다. 이것을 개발자가 체크인 하기전에 실행하여, 빌드를 스스로가 설치하여 사용할 수 있는 수준으로  성능이나 반응을 유지합니다. 이러한 게이트는 매일매일의 빌드 성능과 반응이 몇천명이  장기간 Windows 7 을 메인 시스템으로 실행하고 일상업무를 실시하는데 필요 충분한 수준으로 유지합니다.
• 서비스 비용을 줄이고, 주요한 코드 경로의 효율을 높여 확장성을 향상하기 위해서 리팩터링하여, I/O 의 효율을 높이고 그 외에도 여러 가지 왔습니다. 원격 측정에 의해서 일반적이라고 판명된 현실세계의 실행 패스에 근거한 시나리오 주도형입니다.
• 주요한 PC 배급업체, 소프트웨어 배급업체, 하드웨어 제조업체와 긴밀한 파트너 관계를 만들어 왔습니다. 우리의 도구를 일반적으로 공개하여 다수의 트레이닝 세션을 마련했습니다. 그리고, 사용자 여러분이 어려운 설정을 필요로 하지 않고, 배터리 지속 시간도 오래되고 훌륭한 능력의 시스템을 입수하는 것을 목적으로 시스템을 출시하는 것에 중점을 두었습니다.
• Windows 개발 팀에서는 단순한 트레이스 캡처 도구를 전원 데스크톱에 설치했습니다. 이 데스크톱 도구는 성능의 트레이스를 유효하게 하여 24 x 7 (1일 24시간, 주 7일) 실행할 수 있습니다. 만약 무언가가 늦어지거나 하면, 마지막 행동을 기록하여 자동 분석에 데이터를 보내기. 또한 팀의 사람들은 새로운 문제나 자동화 테스트에서 아직 판명되지 않는 문제가 없는지, 직접 트레이스 결과를 점검합니다. 트레이스 결과는 정보량이 매우 풍부하고, 거의 항상 중대한 문제의 근원을 찾아내는데 도움이 됩니다.
• 모든 Pre-Beta, Beta 및 RTM 판의 사용자의 여러분을 위해서, 우리는 새로운 유형의 계기를 개발하여, 운영 체제와 미리 설치된 있는 응용 프로그램의 500이상의 장소를 측정하는데 사용했습니다. 새로운 계기는 컨셉은 단순하지만, 결과는 획기적입니다. 이 도구가 PerfTrack 로, 클라이언트의 벤치마크 테스트는 실제 사용자의 반응 문제에 대해 그다지 참고되지 않는다는 신념을 증명하는데 도움이 되었습니다.

 

Perftrack 는 매우 유연하고, 적은 오버헤드로 동적으로 설정 가능한 원격 시스템입니다. Windows 7 을 통한 주요한 시나리오로, 시나리오를 하나로 통합하는 시작」과「정지」의 이벤트가 있습니다. 시나리오는 어떤 것이든 가능합니다. 예를 들어, 파일을 여는 웹 페이지를 열람하는 컨트롤 패널을 여는 문서를 검색하는 컴퓨터를 실행 하는 일반적인 일도 있습니다. 반복이지만, Windows 7 의 베타에서는 500 이상의 시나리오가 측정되었습니다.

분명하게, 정지와 시작 이벤트간의 시간은 시나리오의 반응을 나타내고 있어 분석을 위해서 이 지표를 우리의 곳까지 보내기 되돌리는데, 원격 측정의 인프라를 사용하고 있습니다. Perftrack 의 독자성은 단지 무엇을 측정할까 뿐만이 아니고, 문제가 있는 응답 시간의 발생을 단지 관찰하는 이상이 할 수 있는 점에 있습니다. Perftrack 는 트레이스의 형태로 보다 많은 정보를 「전화 접속」요청 할 수 있습니다.

아래와 같은 분포를 생각해 봅시다. 그리고 시나리오는 XYZ 를 여는 것으로 합니다. 선택한 목표에 대해서, 초록은 허용범위 안의 시간을 나타내, 황색은 빠듯이 OK 로 간주하는 시간을 나타내고, 빨강은 낮은 성능을 의미합니다. 시간은 밀리초 단위로, X 축으로 따라 표시됩니다. Y 축은 히트 카운트를 나타냅니다.

 

보시면 알 수 있듯이 시나리오가 완료하기까지 5초 이상 걸리는 경우가 많이 있습니다. 이런 종류의 분포에서는 성능 팀은 과거에 시간이 걸리는 「열다」커멘드를 체험한 것이 있는 시스템에서의 100 이상의 트레이스를 「전화 접속」하여 요청 하는 것을 추천합니다. 「전화 접속」리퀘스트에서는 우리가 흥미롭게 생각하는 「반응을 일으키는 최소 물리량」의 시간을 설정합니다. 또한 일정량의 메모리를 탑재하고 있는 특정 클래스의 프로세서를 탑재하는 특정 드라이버가 존재하는 등의 조건으로 머신에 필터를 걸기도 합니다. 그리고, 조건을 만족하는 클라이언트는 「시작」이벤트에 이른 시점에서, 빠르게 트레이스 할 수 있도록 설정되어 만약 「정지」이벤트가 설정한 「반응을 일으키는 최소 물리량」의 시간 이후 발생하면, 우리에게 반환될 가능성이 있습니다.

상상대로, 상당양의 엔지니어링 작업은 원격 측정과 피드백의 시스템이 기능하는 것을 위해서 소비됩니다. 모든 Windows 개발 팀은 이 시스템을 구현하기 위해서 공헌하여, 이미 기본적인 부분은 완성되어 앞으로 지금보다는 적은 노력으로 가능할 것 입니다. 

트레이스와 거기에 따라 밝혀진 지극히 현실적인 문제의 수정에 중점적으로 임한 결과, 실제 반응으로 놀라우 개선을 볼 수 있어 Windows 7 에 대한 수많은 칭찬을 얻었습니다. 추가적으로 트레이스는 우리가 오랫동안 그렇다고 믿어 온 것을 증명하는데도 도움이 된 것을 지적하고 싶습니다.

이 글에서는 성능에 대한 우리의 생각을 소개하고, Windows 7 의 엔지니어링을 통해 어떻게 측정할지 세부 사항에 대해 소개했습니다. 베타 기간 중, 우리는 목표를 달성하기 위해 보다 좋은 원격 측정을 계속 실행할 예정입니다. Windows 7 에서 사용자의 여러분에게 기대에 부응하는 성능을 체험하실 수 있을 것이라고 믿고 있습니다.

앞으로 많은 사람이 스톱 워치나 마이크로 벤치마크를 계속 사용하여 자동검사를 계속 실행할 것입니다. 이것들은 각각, 자기 자신으로 실시하는 분석이나 우리의 엔지니어링에서 적합한 장소입니다. 여러분의 흥미를 근거로 하면서, 우리가 어떻게 사물을 측정하여, 어떻게 제품을 개발할지에 대해 한층 더 이야기할 수 있기를 바랍니다. 

--Steven and Michael

Published Thursday, January 22, 2009 7:03 PM by e7blog

Filed under: Perf

Follow up: Windows 7 필요 옵션

 

이 주제에 대해 사용자 인터페이스 플랫폼 팀의 팀원 생각을 전합니다. Brett 는 Windows 7 의 필요 옵션 테스트를 담당하는 시니어 테스트 리드입니다. --Steven

안녕하세요. 저는 Windows 7 필요 옵션 팀에서 테스트 리드를 하고있는 Brett 입니다. 작년 11 월에 동료 Michael 가 Windows 7 에 대한 우리의 팀의 일에 대해 블로그를 썼지만, 그 이후 새로운 스크린 돋보기에 대한 최신 정보를 제공하고 싶습니다. 덧붙여서 개인적인 일이지만, 저는 저시력으로, 우리 팀에서 개발하고 있는 기술이 제가 하는 일에도 꼭 필요합니다. 

최근 수개월, 매일 매일 Windows 7 을 사용해 왔습니다. 자사의 아직 베타 버전에도 못 미치는 개발중의 제품을 사용하는 것을 「dogfooding」라고 부릅니다. Windows 7 을 첫번째 OS 로서 사용하고 있는데, 새로운 돋보기는 저에서 많은 도움이 되고 있습니다.

그런데, 돋보기는 상상대로 Windows 에는 많은 기능이 있지만, 매력 포인트는 사람에 따라서 다릅니다. 이것에 대해, 우리는 수억 명의 사람에게 피자를 만드는 것이라고 말합니다. Windows 7 의 베타를 출시 한 이래, 돋보기에 대해 많은 코멘트를 읽었습니다. 있는 것은 새로운 것에 의해서 정말로 혜택을 받고 있는 사람부터 제안과 현안 사항에 대해 보내주셨습니다. 이러한 피드백은 어떠한 내용이든 고마운 것이고, 감사하든다는 말씀을 드립니다. 혜택을 받은 사람의 상당수는 기본적인 돋보기가 필요한 사람으로, 줌인 이나 줌 아웃을 간단하게 할 수 있는 것을 평가합니다. 저도 그 한 사람입니다. 돋보기와 함께 사용자가 지정한 색, 고대비, 또는 스크린 리더를 사용하고 있는 사람에서는 아마 새로운 돋보기는 별로 도움이 되지 않은 것이 아닐까 생각됩니다. 그러한 사람을 위해서, Vista 의 돋보기가 계속 동작하는 것을 확인했습니다. Windows 7에서 우리가 한 것을 좀 더 설명하겠습니다..

구현에 대해 자세하게 이야기하는 전에 Windows 그래픽 시스템에서 시작하고 싶습니다. 과거 수년간 GPU 기술이 큰 폭으로 향상되어, Vista에서는 마침내 최신 하드웨어의 accelerated graphics system이 크게 발전했습니다. 그것은 Aero 로 불리고 있는 것으로, GPU 를 활용하고 있습니다. Aero 라는 말은 투명성이나 그라데이션 등 Windows 비주얼의 특정 요소를 가리키는 것으로서 자주 사용됩니다. 그러나, 실제로는 그 이상으로, 최신 그래픽 렌더링 (기술적으로는 DirectX API 와 데스크톱 윈도우메니저)은 단지 미학이기 때문에 뿐만이 아니고, 최신의 하드웨어에 의해서 보조된 그래픽과 강화된 API 를 사용하고 있는 텍스트, 2 D, 3D 등 모든 형태의 렌더링을 위해서 있습니다. 그렇지만, 다양한 에코시스템이 새로운 기술을 도입하려면 시간이 걸립니다. 또, Windows, 소프트웨어 개발자 및 하드웨어 제조업체에서도 새로운 기술을 도입하려면 시간이 걸려, 당분간의 신구 모두 진행하여 지원할 필요가 있습니다. 예를 들어, 스크린 리더는 옛 Windows 그래픽 시스템 (GDI)을 경유한 데이터를 캡쳐하여, 화면에 표시되지 않는 UI 모델을 구축하는 것은 잘 할 수 있습니다. 그러나 새로운 UI 렌더링을 오프로 할 필요가 있습니다. 한편, 새로운 돋보기는 데스크톱 윈도우메니저 (「Aero」)와 밀접하게 통합되어, 그래픽 처리 능력을 활용하여, 전체 화면 모드에서 멀티 모니터 대응의 부드러운 확대를 구현합니다.

이것이 보여주는 것과 같이 진화시켜 가는 방법은 단순하지는 않지만, Windows 7에서는 새로운 투자를 실시하는 것과 동시에 Vista 로의 기능이나 호환성이 유지되도록  했습니다. 돋보기는 이 일례로, GPU의 힘을 활용하여 폭넓은 사용자에 대해서 새로울 가능성을 가져오는 한편으로, 스크린 리더, 고대비 또는 그 외의 이유로 Aero 를 오프로 하지 않으면 안 되는 경우에는 제품의 기존 성능을 유지합니다. 그리고,  최대한 호환성을 유지하여, 지금 의지하고 있는 도구의 대부분이 Windows 7에서도 잘 동작한다고 생각합니다.

그럼, 돋보기는 모든 사람에서 좋아졌는지요? 유감스럽지만, 모든 사람에게 도움을 주는 것은 아니지만,  확실히 많은 사람에서 혜택을 줍니다.  그러나 그 이상으로, Windows 7에서는 모든 사람에서의 필요 옵션이 진보했다고 솔직하게 말할 수 있습니다. Michael 도 쓴적이 있지만, 우리는 몇가지 분야에 투자를 실시했습니다. 그것은 돋보기와 스크린 키보드 만이 아니고, 기초를 이루는 필요 옵션 API에 대해서도 상당한 작업을 실시했습니다. 또, 커뮤니티를 적극적으로 지원하여 최근에는 NPO 의 NV Access에 대해, 그들의 오픈 소스의 스크린 리더가 Windows 7 이나 Internet Explorer 8 의 지원을 향상할 수 있도록 조성했습니다.

마지막까지 읽어 주셔 감사합니다. 또, 댓글도 감사합니다.

-Brett

Published Monday, February 09, 2009 3:18 AM by e7blog

Filed under: Design

Follow-up：Windows 윈도우의 관리

윈도우 정렬에 관한 글에서, 다양한 논의가 있었습니다. 이것은 이러한 세세한 부분이 사용자에게 얼마나 중요한 것인지 잘 보여줍니다. 응용 프로그램을 화면상에 표시하는 방법을 조정할 수 있을지는 대부분의 작업과 관계하기 때문에, 생산성 향상의 열쇠가 됩니다. 또한 그것은 한사람 한사람 다양한 다른 문제입니다. 사용자는 자신의 작업환경을 컨트롤하여, 자신에게 쾌적한 상태로 설정하고 싶어 합니다. 

여기서, 분명히 해 두지 않으면 안 되는 사실이 있습니다. 그것은 사용자가 요구하는 다양한 작업 형태, 다양한 도구나 제안된 방법이 모두를 만족시킬 수 있는 솔루션을 제공하는 것은 불가능합니다. 모든 요구 사항을 아우르는 옵션과 UI 를 구현하는 매우 어려운 일이라는 것을 알고 있을 것이라고  생각합니다. 처음은 별로 마음이 내키지 않는 일이었지만, 사용자가 Windows PC 를 자신만의 PC로 하기 위해 사용하고 있는 (또한 스스로 개발하고 있다!) 다양한 도구나 유틸리티에 대해 묻는 것을 기대하고 있습니다. 우리의 목표는 데스크톱을 관리하는데 생각할 수 있는 온갖 방법으로 대응한 솔루션을 제공하는 것이 아닙니다. 오히려, 사용자 지정 기능과 개인 설정 기능을 사용해 데스크톱을 관리하는 수단을 제공하여, 사용자가 독특하고 참신한 방법으로 데스크톱을 한층 더 진화시킬수 있는 도구를 개발할 수 있는 플랫폼을 제공하는 것입니다.  아무리 노력해도 무한의 사용자 지정 기능을 제공하는 것은  기술적으로 불가능합니다. 다만, 이 방법에는 무한하지는 않다고 해도 상당한 유연성이 있기 위해, 개발자는 새로운 도구를 제공하고, 컴퓨터-배급업체는 자사의 PC 를 차별화할 수 있습니다. 또, 이러한 요소를 원하는 대로 조합하는 것으로, UI 를 자신 전용에 조정해, 생산성이 오르는 쾌적한 환경으로 할 수 있습니다.

다른 한가지 말해야 할 것은  정말로 많은 댓글의 내용이 윈도우 포커스의 이동, 레지스트리, Z오더 윈도우 관리 등, Windows 에서  논의되어 온 요소에 관한 것 이었습니다. 이러한 Windows API 에 관한 역사 및 명언은 Raymond Chen 의 블로그에서 태어났습니다. Raymond 는 Windows 팀에 오랜 세월 속하고 있는 개발자인 것과 동시에 「Old New Thing, The Practical Development Throughout the Evolution of Windows 」의 저자이기도 합니다. 이것은 Windows 가 실시하는 부분과 응용 프로그램 개발자가 실시할 수 있는 부분 ( 및 사용자 지정 할 수 있는 부분)의 경계가 어디에 있는지를 이해하기 위해서 최적인 백서입니다.

댓글 전체에 걸쳐서 중복되는 피드백이 있었습니다. 피드백의 내용에서는 (자세한 것은 다음을 참조), 이러한 점에 대한 다양한 생각이 있습니다.

• 윈도우의 크기는 중요. 그러나, 윈도우의 크기 변경은 귀찮고, 번거로운 일이다. 
• 윈도우의 행선지를 스스로 지정하게 해주면 좋겠다. 윈도우를 어디에 배포하면 좋은지 잘 알고 있는 것은 자기 자신이다.
• 대상 윈도우 (또는 데스크톱)가 가득차 있을 경우가 많아서, 파일 드래그가 귀찮다.
• 바뀐 윈도우가 어떤 것인지 찾을 때, 실행중의 윈도우를 더 간단하게 분별할 수 있도록 해 주었으면 한다.
• 컨텐츠가 윈도우가 들어가도록, 예측할 수 있는 방법을 원한다 (반드시 최대화될 필요는 없다).
• 윈도우가 최대화 된 경우에서도 나의 개인용으로 설정된 배색을 유지하고 싶다.

이러한 요구에 대해는 다른 제품의 기능에 대해서, 그리고 완전히 새로운 접근 방식에 대해서, 잠재적인 해결책이 논의되고 있습니다. 이러한 댓글에서 분명한 것은 개선을 요구하는 소리가 많다는 것으로, 이 주제에 대해 오랫동안 생각하고 충분히 구체적인 추천 기능을 생각하고 있는 사용자가 있다는 것입니다. 다음은 현재 댓글란에서 교환되고 있는 내용의 일부를 발췌합니다.

원하는 장소에 윈도우를 배포 한다

기존의 기능에 대해, 적절히 기능하는 경우와 그렇지 않은 경우를 사용자가 논의하는 상태를 보고, 매우 흥미롭다고 느꼈습니다.

예를 들어, @d_e씨는 작업 표시의 정렬 표시 옵션을 좋아합니다. 

분할 윈도우와 같은 형태로의 윈도우 정렬은 실제는 매우 간단하다. 작업 표시에서 복수의 윈도우를 Ctrl 키를 누르면서 선택한다. 다음에 오른쪽 클릭 하고, 정렬 표시 옵션의 한쪽을 선택한다.

그러나, 이 방법에서는 @Xepol를 만족시켜주지 못합니다.

작업 표시의 위의 윈도우 정렬 버튼에 관해서는 Win95 이후, 존재는 알고 있지만, 나는 사용한 적이 없다. 목적 대로에 표시되지 않기 때문이다. 목적의 정렬 방법에 가까웠다고 해도 순서가 잘못되어 있다. 결국 스스로 드래그 해야 하기 때문에 최초에서 스스로 목적의 장소에 배포 하는 것이 간단하다.

@Aengeln씨는 더 사용하기 쉽게 하기 위해서, 윈도우를 정렬 표시한다는 기본적인 생각을 한층 더 높은 수준으로 끌어올리는 것을 제안됩니다.

정말로 편리한 기능이란, 특히 큰 화면의 경우는 데스크톱을 다른 부분으로서 분리하는 기능일 것이다. 예를 들어, 데스크톱의 우측 일부분에서 Messenger 윈도우를 최대화하면서, 나머지의 영역에서도 다른 윈도우를 최대화할 수 있다는 기능이다. 최대화되어 있지 않은 윈도우는 데스크톱 양쪽의 영역에서 임의의 위치에 배포 할 수 있다.

윈도우가 배포되는 장소를 제어할 수 있어, 평소 사용하는것 처럼 간단하고 빠르게 실시할 수 있다면, 여러개의 윈도우 화면 영역을 최적화하는 기능은 매우 사용하기 쉬운 것 같습니다. 현재의 작업 표시가 정렬 표시 기능은 편리할지도 모르겠지만, 일상적으로 사용하는 만큼 간단한 것은 아닌 것 같습니다.

적절한 크기로 열린다

윈도우의 「기본값 크기」에 대한 댓글이나 기본값 크기가 어떻게 결정될지에 대한 질문이 다수 있었습니다. 열 때의 크기를 응용 프로그램에서 선택할 수도 있지만, 일반적으로는 먼저 닫았을 때의 윈도우의 크기가 사용됩니다 (또는 이 설정을 사용하지 않게 지정할 수도 있습니다). 사용자를 실망시킬 가능성이 있는 경우의 하나로서 IE 가 작은 윈도우를 여는 경우가 있습니다 (Web 사이트에서는 가끔 있습니다). 일단 닫으면, 그것이 새로운 「 이전 크기」가 되어 버리기 때문입니다.

@magicalclick씨에서 다음과 같은 해결책이 제안되었습니다.

캡션 버튼 ( 「고정크기」)이 하나 더 있으면 좋다. 실제로는 체크 박스가 체크된 경우  이 응용 프로그램에서 윈도우 상태가 보관 유지된다. 나중에 크기를 바꾸거나 이동하거나 할 수 있다. 윈도우를 닫은 후도 나중에 한 변경은 저장 되지 않는다.

@steven_sinofsky에서 작업 효율을 향상시키기 위해서 사용할 수 있는 다음과 같은 고급 사용법이 소개되었습니다.

@magicalclick님,  저는 거기에는 반대입니다. 버튼이나 클릭을  추가하는 것이 아니라, 「파워 사용자」방식으로 원클릭으로 완성되도록 합니다. 즉, 언제 작은 윈도우로 열렸을 경우에 그것을 닫지 말고, 응용 프로그램의 다른 카피를 「일반적」크기의 윈도우로 열고 난후 , 작은 윈도우를 닫고, 일반적크기의 윈도우를 닫습니다.
물론, 이 방법은  힘든 일이고, 해결책을 찾아내는 것은 불가능에 가까울지도 모르지만, 제목 표시줄 위에 4 번째의 UI 를 추가하는 것 보다는 좋은 방법이라고 생각합니다.
–steven

올바른 윈도우를 찾는다

자주 화제가 되는 것은 (MacOS의) 「Expose」입니다.

@Joey_j님: Windows 에는 「Expose」와 같은 기능이 필요하다. 나는 모든 윈도우를 동시에 보고 싶다.

@Dan.F님:  「expose」.복사 해 주었으면 한다.

@GRiNSER님: Expose에는 장점과 결점이 있다. macbook 프로의 1400x1050 화면에서 30 개의 윈도우를 취급할 수 있다고 해도 실제는 그만큼 도움이 되지 않는다. 다만, 플립 3D 보다는 편리하다. Expose는 키보드를 사용한 윈도우 검색보다 사용하기 쉬운일 것이다.

이름과 관계없이, 검색하고 있는 윈도우를 시각적으로 찾는 기능에 대한 요구가 있습니다. 시계열적인 방법의 Alt + Tab 나 플립 3D 보다, 랜덤 액세스 방법으로, 축소 표시에서 윈도우를 시각적으로 선택할 수 있는 방법입니다. 이것은 많은 윈도우를 여는 영역이 있는 경우는 바꿀때에는 매우 편리하지만, 몇가지 현재의 접근 방식에서는 확대 축소 기능이 불충분합니다. 확대 축소를 실시했을 경우, 사용자가 한층 더 많은 프로그램을 실행하면 보다 곤란한 문제로 발전할 가능성이 있습니다.

파일 드래그

윈도우 사이에서의 드래그를 보다 간단히 하는 방법에 대해, 여러 가지  댓글 ( 및 제안)이 있었습니다.

@Manicmarc님:  저는 Mac OS 의 Springloaded 폴더와 같은 기능이 있으면 좋다고 생각합니다. 폴더 위에 드래그 하고, 폴더를 포인트 하면, 폴더가 표시되어 다음의 폴더가 열리면 거기에 드래그 하는 것입니다.

@Juan Antonio님: 개체를 드래그 할 경우에 윈도우의 목록 또는 썸네일을 열고, 개체의 드롭 할 곳에 사용하는 윈도우를 (오른쪽 클릭등에서) 선택할 수 있으면, 편리하다.

이 주제에 대해 무언가 가능한 것으로, 적절하다고 생각된 것은 @Kosher 님의 댓글 이었습니다. 

UI 를 아주 조금 확장하는 것으로, 작업을 아주 간단하게 실행할 수 있습니다. 어느 정도 간단한가 라는 것만이 아니라, 공통의 UI 워크플로와 작업 사이의 사용자 전환이 어느 정도 원활한지도 관계하고 있습니다. 이것은 Ferrari 를 한번도 운전했던 적이 없고, 향후도 Ferrari 를 탈 기회가 있다고는 생각되지 않는 사람에게, Ferrari 와 Toyota 의 차이점을 설명하는데 비슷하다.

Windows 7 설계에서 우리는 이러한 댓글들을 현실화 하기 위해 진지하게 고민했습니다. Windows 7 을 시승 (테스트)할 수 있게 되었을 때, Windows 7 이 어느 차와 비교 되는지, 지금부터 기대하고 있습니다.

- Dave

Follow-up: 시작, 실행 및 전환 기능

작업 표시줄과 관련된 사용자 인터페이스에 관해서 많은 댓글을 받았습니다. Chaitanya 가 댓글애 대한 몇가지 피드백과 생각을 요약하였습니다. --Steven

댓글과 전자 메일에 등장한 화제를 다루고 싶습니다. 이 포스팅에서는 일관되게  볼 수 있는 피드백에 대한 고찰 및 명백해진 과제 몇가지를 엔지니어링과 설계 관점에서 다룹니다.

우선 몇가지를 언급해 두겠습니다.

• 많은 사용자가 알림 영역은 보다 컨트롤과 사용자 지정이 가능할 필요가 있다는 의견에 동의합니다.
• 작업 표시 버튼의 재배포에 대한 몇가지의 코멘트를 받아들였습니다. 작업 표시의 각 버튼은 예상 가능한 장소에 표시되어야 할 필요가 있다는 의견과 작업 표시를 더 컨트롤하고 싶다는 의견이 있습니다.
• 퀵 실행은 매우 도움이 되지만, 보다 뛰어난 실행용 서페이스 (기본으로 보다 크게 표시하거나, 장소를 확장하는 등)을 할 수 있도록 하는 것에 여러가지  의견이 있습니다.
• 축소 표시는 많은 사용자에서 도움이 되고 있습니다. 그러나, 디스플레이 크기는 해당 윈도우를 찾아낼 때에 도움이 되지 않는 경우도 있습니다. 항상 적절한 정보량을 제공하는 보다 뛰어난 윈도우 식별 방법에 대한 관심을 볼 수 있었습니다.
• 윈도우 보다 뛰어난 크기 조정 방법에 대한 논의가 있었습니다. 작업 표시를 많은 윈도우용으로 최적화하는 것 또는 복수의 디스플레이상에 늘리는 것 등이 논의됩니다.

데이터

수집한 데이터에서 이끌어낸 결론과 데이터 처리 방법에 대한 몇가지  질문이 있었습니다.

@Computermensch의 포스팅입니다. 「이 「분석」 (데이터가 있다면 보고 싶습니다) 에서의 문제는 단지 작업 표시줄 주변의 현재의 액티비티를 관리하려는 점에있습니다. 즉, 「작업 표시줄의 발전」에 관해서 말하면, 여러분은 현재 사용중인 프레임워크 안에서 개발하려는 것 뿐입니다. 그러나, 진정한 개발 또는 발전이란, 작업 표시줄 컨셉의 개발이어야 합니다. 」

@Bluvg의 포스팅입니다. 「사용자가 6-9 개 이상의 윈도우를 동작시키지 않았던 이유가 UI자체에 있었다면 어떻게 될까요? 바꾸어 말하면, 이 UI에서 좀 더 많은 윈도우가 효율적으로 표시할 수 있으면, 결과는 어떻게 될까요? 그렇다고 하면,  6-9개의 시나리오에 우선 순위를 붙인다는 것은 데이터에서 잘못된 결과를 이끌어내게 되는 것은 아닐까요. 데이터는 UI 자체의 의한 명령으로 사용자 필요에  의한 것은 아닐지도 모릅니다. 」

수집한 데이터와 그 사용 방법에 관해서는 지금까지의 포스팅에서 벌써 언급했습니다. 그러한 데이터는 기능설계에 직접적으로는 반영되지 않지만 문제해결에 참고가 됩니다. 고객 인터뷰나 온라인에서 자동적으로 모아진 정보는 제품이 현재 어떻게 사용되는지에 대한 이해를 현실적이고 정확하게 보여줍니다. 그러나, 반드시,단지 현상에 맞춰 설계하는 것 자체가 목적은 아닙니다. 새로운 설계가 사용자의 현재 목적과 동작을 만족시키지 않는 경우, 저항을 하게 될  우려가 있다는 것을 알아둬야 합니다. 이것은 목표를 새롭게 하거나 변경해선 안 된다고 것이 아니고, 목표를 바꾸는 경우는 사용자의 궁극의 목적을 존중해야 한다는 것입니다. 문제에 대해서 새로운 솔루션을 제공하는 것은 중요합니다. 확인 해야 할 필요가 있는 것은 적절한 문제를 해결하고 있는 것, 그리고, 사용자가 있는 현재의 장소에서 보다 뛰어난 솔루션이 있다고 생각되는 장소 경로가 존재하는 것입니다. 앞에서 말한 것처럼, 우리는 디자인프로세스에 두고, 작업 표시를 보다 많은 윈도우를 위해서 보다 효율적으로 크기 조정 하는 필요성을 인식하고 있기 때문에 안심해 주십시오. 이것에 의해, 6-9 개의 윈도우의 경우와 같이 「함정에 빠졌다」라고 느끼고 있을지도 모르는 사용자가 필요하면, 마음 편하게 과감히 다른 윈도우를 여는 것이 가능하게 됩니다. 또한 90% 의 경우에서는 현재 더 많은 윈도우를 열고 있는 사용자에도 이익을 가져올 것입니다.

알림 영역

알림 영역에 관한 문제를 이전의 포스팅에서 알려드렸지만, 여러분의 의견으로 이러한 문제의 중요도가 더 높아졌습니다.

@ Jalf의 포스팅입니다. 「20개의 아이콘과 30초의 풍선 통지가 「항상」혼잡한 작업 표시 공간이 한층 더 좁아져 버립니다. 확실히, 그 정보를 필요로 하는 경우는 거기에 있었으면 좋겠습니다. 그러나, 액티브하게 그 정보를 찾지 않은 경우는 그 정보를 필요로 하지 않기 때문이라고 생각할 수 없을까요.

Jalf씨의 댓글은 통지에 관해서 찬반 양쪽 모두의 의견을 말하고 있어 매우 흥미롭다고 생각합니다. 통지는 확실히 도움이 되는 경우도 있습니다만, 많은 사용자가 지적하듯이, 매우 쉽게 사용자를 압도해 버리는 경우도 있습니다. 따라서, 필요한 정보는 알게 되면서도 사용자가 연속해서 컨트롤 할 수 있는 상태에 있도록 하려면, 주의 깊은 밸런스가 필요합니다. 정보가 필요할지는 상대적인 것입니다만, 컨트롤의 필요성은 기본 사항입니다. 우리는 이 문제를 눈치채고 있어 매우 진지하게 임하고 있기 때문에 안심해 주십시오.

멀티 모니터 지원

작업 표시의 멀티 모니터 지원을 논의하기 위해서, 여러분들로 부터 댓글을 받은 것은 놀랄 만한 일이 아닙니다. 그것은 선구적 사용자 ( 및 우리 개발자)에서 일반적인 요망으로, 조사 영역으로서 오리지날의 포스팅으로 알렸습니다.

@Justausr의 댓글은 매우 직접적입니다. 「멀티 모니터 지원을 하지 않는 것은 거의 범죄는 아닐까요.나는 Bill Gate 의 오피스와 그가 사용하는 3개의 모니터 사진을 본 적이 있습니다. 대부분의 개발자는 요즘 2개의 모니터를 가지고 있습니다. 왜, 작업 표시줄의 멀티 모니터 지원은 없습니까? 반복하지만, 이것은 Windows 팀의 컴파트먼트화 및 설계와 구현에 있어 사용자 지향이 결여되어  있다는 일례입니다. 이것은 「가능」인데 「당연 실행합니다」라는 단계가 아니라는 사실은 여러분이 이 문제를「 아직」이해하고 있지  않다는 것을 보여줍니다.

적어도 이런 특정 경우에는 우리가 「이해하고 있다」고 생각합니다. 다만, 멀티 모니터 지원 설계는 보이는 것처럼  단순하지 않다고 생각합니다. 많은 기능을 사용하므로, 이것을 실행하려면 여러가지 방법이 있습니다. 예를 들어 각 디스플레이 위에 존재하는 고유의 작업 표시를 제안하는 사람도 있으면, 복수의 디스플레이에 늘어나는 작업 표시를 제안하는 사람도 있습니다. 이러한 접근 방식 모두를 살펴 봅시다. 다른 크기, 방향 및 배포의 모니터를 가지는 복잡함을 명심해 둬 주세요.

각 디스플레이위에 각각 작업 표시를 구현하여, 각 작업 표시에 각각의 데스크톱 부분에 존재하는 윈도우만을 포함하면, 몇가지 문제가 발생합니다. 막대가 항상 스크린의 최하단에 있기 위해, 일부 사용자에서는 마우스의 이동거리가 줄어들어 편리해집니다. 그러나, 그러한 설계는 윈도우가 존재하는 장소를 추적하는 부담을 사용자에 강요하게 됩니다. 브라우저 창을 복수의 장소에서 찾는 것을 상상해 주세요. 필요한 아이템을 찾아내기 위해서, 복수의 작업 표시를 봐야 합니다. 최악의 상황은 윈도우가 디스플레이 에서 다른 디스플레이로 이동하는 경우, 그 윈도우를 찾기 위한 새로운 장소를 기억해둬야 합니다. 사용자가 각 버튼에 대해 기억 해야 한다는 것은 작업 표시 버튼을 재배포 한다고 하는 요망과 상반된다고도 생각할 수 있습니다. 텔레비전용으로 동적으로 다른 기능을 가지는 2 대의 리모콘이 있습니다. 거의 모든 가상 데스크탑 구현으로, 현재 사용하고 있는 데스크톱과는  관계없는 것으로 작업 표시를 고정해 두는 것은 그 이유의 하나입니다.

또 하나의 인기 있는 접근 방식은 복수의 데스크톱에 늘어나는 작업 표시입니다. Windows 작업 표시로 이 기능을 에뮬레이트하는 몇가지의 타사 도구가 있습니다. 이 접근 방식의 가장 분명한 이점은 이중의 작업 표시와 같이, 실행, 바꾸기 그리고 조용하게 알리기 위해서 사용하는 공간이 넓어지는 것입니다. 분명히 복수의 디스플레이를 가진 사용자는 동시에 많은 윈도우를 여는 공간이 있어, 따라서, 작업 표시에 의해 넓은 공간이 필요하게 됩니다. 앞서가는 사용자 중에는 작업 표시의 높이를 확대하여 복수의 행을 표시하여 이 문제에 대처하는 사람도 있습니다. 작업 표시를 늘리는 것을 바라는 사람도 있습니다. 알아 두어야 할 중요한 것은 문제는 반드시 작업 표시를 늘릴 수 없다고 하는 것은 아니고, 윈도우의 상세 정보를 표시하기 위해서, 더 공간이 필요하다고 하는 것입니다. 사용자가 몇가지 디스플레이를 가지고 있을지에 관계없이, 이 문제의 최선의 솔루션을 찾아낼 필요가 있는 것은 그때문입니다.

이 설계의 문제에 대해는 상당한 시간을 소비했으므로, 이 해결에 관한 각론에 대해 간결하게 설명해 두는 것은 좋을 것이라 생각했습니다. 월등히 향상된다고 알고 있는 경우에게만 사물을 변경하고, 얻으려는 이익이상의  복잡함은 도입하지 않는다는 것이, 성공을 위한 한걸음 일지 모릅니다.

보내주신 댓글에 대해 깊이 감사드립니다.

- Chaitanya

Windows 7 필요 옵션 (사용자 보조)