Sankim's Blog : Windows

Windows 최대 지원 Processor

sankim — Wed, 18 Nov 2009 08:42:49 GMT

오늘은 이번에 출시된 Windows Server 2008 R2가 지원 하는 최대 CPU(Processor) 수에 대한 이야기 입니다.

Windows Server 2008 R2각 Edition별 지원 최대 Processor

Edition	*지원 소켓(Socket) 수**
Windows Server 2008 Web R2	4 (x64)
Windows Server 2008 Standard R2	4 (x64)
Windows Server 2008 Enterprise R2	8 (x64)
Windows Server 2008 Datacenter R2	64 (x64)
Windows Server 2008 *Itanium R2	64 (IA64)
Windows Server 2008 Foundation R2	1 (x64)
Windows Server 2008 HPC R2	4 (x64)

위에 보이는 지원 소켓(Socket)이란 메인보드(Mainboard) CPU 소켓(Socket)에 장착한 CPU를 의미 합니다.

[그림] Socket 하나.

Processor가 부팅이 되면 듀얼이냐 쿼드냐에 따라 작업 관리자의 ‘CPU 사용 현황’텝에 2개나 4개로 나타나는데, 이것이 바로 Logical Processor입니다. 현재 Windows는 최대 256개의 Logical Processor를 지원 합니다.

[그림] 하나의 Socket에 장착한 Dual Core CPU로 Logical Processor 두개

정리하자면 Windows 최대 Processor 지원은 Windows Edition별 Socket 지원에 256 Logical Processors가 제한 입니다.

Socket과 Logical Processor라는 의미를 혼돈 하시어 가끔 “Windows Server 2008 Standard Edition에는 퀴드 코어는 하나 밖에 장착하지 못하는가?”는 식의 궁금증을 가지시는 경우가 있는데요 아래 그림을 보시면 Windows Server 2008 R2 Standard Edition에 Hyper thread(*2)를 지원하는 2(*2)개의 퀴드코어(*4) 프로세서를 장착하면 총 16개의 Logical Processor가 정상적으로 동작하는 것을 보실 수 있습니다.

추가로.. :^^

[그림] Windows Server 2008(Version 6.0)까지는 최대 지원 Logical Processor가 64개였습니다. 이걸 처음 본게 5년 전인데 보고 참 많이 놀랐는데요..

[그림] Windows Server 2008 R2(Version 6.1), 256 Logical Processors, 와우~!

Windows 7, W2K8 Server R2(Version 6.1) & 32bit와 64bit 최대 메모리

sankim — Wed, 04 Nov 2009 06:56:00 GMT

안녕하세요? Sankim 입니다.

오늘은 Windows 7, Windows Server 2008 R2 그리고 32bit/64bit 최대 지원 메모리(RAM)에 대해서 간단히 정리해 보기로 하겠습니다.

Windows 7과 W2K8 Server R2(Version 6.1) 최대 메모리

[Windows 7 최대 물리 메모리]

: Windows 7 클라이언트 버전에서 32Bit는 최대 4GB 메모리, 64bit는 192GB 메모리까지 사용 가능합니다. Starter Edition은 기본적으로 2GB이하 메모리를 가진 H/W를 위한 Edition이므로 2GB로 제한 되었습니다.

에디션(SKU)	32Bit 최대 메모리	64bit 최대 메모리
Windows 7 Ultimate	4 GB	192 GB
Windows 7 Enterprise	4 GB	192 GB
Windows 7 Professional	4 GB	192 GB
Windows 7 Home Premium	4 GB	16 GB
*Windows 7 Home Basic	4 GB	8 GB
Windows 7 Starter	2 GB	2 GB

[Windows Server 2008 R2 최대 물리 메모리]

: Windows Server 2008 R2 서버 버전에서는 최대 2TB까지 가능합니다.

*에디션(SKU)	64bit 최대 메모리
Windows Server 2008 R2 Datacenter	2 TB
Windows Server 2008 R2 Enterprise	2 TB
Windows Server 2008 R2 for Itanium Based	2 TB
Windows Server 2008 R2 Foundation	8 GB
Windows Server 2008 R2 Standard	32 GB
Windows HPC 2008 R2	128 GB
Windows Web Server 2008 R2	32 GB

* Windows Server R2에서는 32bit 버전은 출시되지 않았습니다.

이전 Windows 버전에 대한 메모리 정보는 ‘Windows 최대 메모리 크기(Size)’를 참조 하여 주십시오.

32/64Bit 최대 메모리

[Windows 32bit 최대 메모리]

32bit CPU에서는 서버 버전에 한해서 최대 64GB까지 가능합니다. 클라이언트트 4GB로 제한 되어 있습니다.

SKU	Edition	최대 메모리
*Server 버전	Windows Server 2008 Enterprise & Datacenter 32bit	64GB
Client 버전	Windows 7 Ultimate & Enterprise 32bit	4GB

*Windows Server 2008 R2는 32bit이 존재하지 않으므로 서버 버전에서는 제외 했습니다.

**32bit Windows Client의 최대 지원 메모리에 대한 내용은 ‘4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트’를 참조하여 주십시오.

[Windows 64bit 최대 메모리]

SKU

Edition

최대 메모리

Server 버전

Windows Server 2008 R2 Enterprise & Datacenter 64bit

2TB

Client 버전

Windows 7 Ultimate & Enterprise 64 bit

192GB

(* Windows Vista는 128GB)

그리고 Memory FAQ 2가지..

1. 'Windows 최대 메모리 크기(Size)'라는 글을 보면 서비스팩 별로 지원 되는 최대 메모리가 단계적으로 올라가는데 왜 그런가요?

: 윈도우가 처음부터 32bit 198GB, 64bit 2TB까지 지원 가능한 구조였을까요? 물론 이론적으로 가능하지만 처음부터 Windows가 그런 대용량의 메모리를 지원할 수는 없었습니다. 왜냐하면 그 사양의 메모리가 있어야 그것에 맞게 설계하고 테스트 할 수 있어야 하는데 구현하기 위한 H/W가 없는데 윈도우 혼자서 만들 수는 없기 때문입니다. 그래서 H/W의 장착 가능한 Memory 용량이 단계적으로 발전할 때 마다 동시에 Windows가 서비스 팩 시점에 맞춰 최대 메모리를 확장 해왔다고 보시면 좋을 것 같습니다.

2. 64bit Windows를 사용하면 프로그램도 64Bit처럼 사용할 수 있나요?

: 아닙니다. 64bit CPU에 64bit OS가 설치되어야 64bit Computing을 하기 위한 환경이 구성되고 여기에 64bit 메모리 환경을 활용할 수 있는 64bit 프로그램(대용량 메모리를 사용할 수 있도록 설계된)을 구동해야 진정한 64bit Computing이라 할 수 있습니다. 즉 ‘x64 CPU + 64bit Windows + x64 응용프로그램’이어야 진정한 64bit Computing을 하는 것입니다. 자세한 내용은 'Windows 64bit Computing’에 대한 오해 혹은 잘못된 상식'을 참고 하십시오.

p.s. Address Space Limitation 항목도 그림과 함께 만들어 보려고 낑낑 댓는데, 이거 영~ 조잡해서 안되겠군요.. 그림 잘 만들어지면 다음 블로그에 올리도록 하겠습니다. 혹시 그림판(mspaint.exe)으로 그림 좀 멋지게 만드는 방법 아시는분 ? … ㅜㅜ

윈도우 7 메모리 덤프 생성 과정 변경

sankim — Tue, 27 Oct 2009 08:29:00 GMT

안녕하세요? Sankim입니다, 오늘은 제목이 좀 건조 합니다.

이번 포스팅에서는 Windows 7에서 변경된 메모리 덤프(Memory dump) 생성 프로세스에 대해서 말씀 드릴까 합니다. 다 읽으시고 나서는 Windows 7을 기점으로 지금까지 생각지도 못한 세밀한 부분들까지 새로운 PC환경을 위해 능동적으로 변화하고 있다고 느끼(?) 실지도 모르겠습니다.

[블루스크린] 블루스크린이 왜 파란색인지 궁금하시면 여기를 클릭하세요.

Windows 사용자라면 애석하게도 블루스크린을 한번씩 경험해 보셨을 거라 믿습니다. 블루 스크린이란 윈도우의 커널 모드에서 문제(Crash)가 발생하면 화면상에 Crash가 발생했음을 알리는 블루스크린을 띄우면서 시스템 드라이브(보통 C 드라이브 루트 폴더)에 있는 페이지파일(pagefile.sys) 파일에 메모리 내용을 쓰게 됩니다, 그 뒤에 부팅하면서 덤프가 저장된 이전 pagefile.sys로 C:\Windows 폴더에 메모리 덤프 파일인 memory.dmp를 생성합니다. Dump(덤프)라는 의미가 어떤 매체의 데이타를 다른 종류의 매체로 옮긴다는 의미를 가지고 있는데, 블루스크린이 발생하면 숫자가 1%에서 100%까지 옮겨 가는 것을 볼 수 있죠? 이것이 바로 메모리에 있는 데이터를 하드디스크에 있는 Pagefile.sys에 옮기는 과정을 나타내는 것 입니다.

[메모리에서 Memory.dmp로 가는 과정]

윈도우에서 어떤 작업을 하기 위해서는 실행 데이터가 메모리에 올라와 있어야 하는데 이 때문에 memory.dmp에는 당시 윈도우가 문제 시점에 어떤 일들이 벌어 지고 있는지를 확인할 수 있는 아주 중요한 단서를 가지고 있습니다. 그래서 이 memory.dmp 파일을 분석하여 문제(Crash)가 발생한 원인을 찾아 해결 합니다.

[WinDBG를 이용해 디버깅 중(?)..]

덤프에는 메모리에 있던 모든 내용을 모두 dump하는 전체덤프(Complete dump), 메모리에서 커널(Kernel) 관련 내용만 dump하는 커널덤프(Kernel dump)가 있고 덤프에 대한 간략한 정보만을 담은 작은 메모리 덤프(Mini dump)가 있습니다. 만약 메모리가 2GB를 넘어가면 아래 그림에서처럼 전체덤프 옵션을 사라지고 커널덤프와 미니덤프만 남습니다, 그러나 사용자가 필요하다면 레지스트리 변경으로 전체덤프 생성이 가능합니다. 시스템 Crash(블루스크린이 나타난 경우 보통 이렇게 부릅니다)이 발생한 경우 대부분 커널덤프로 분석하지만(당연히 Kernel에서 문제니까) 경우에 따라서 Application Mode가 커널모드(Kernel Mode)에 영향을 주어 시스템 Crash를 야기하는 경우가 있어 드물지만 전체 덤프가 필요한 경우가 있습니다. 몇 년 전만해도 대용량의 전체덤프가 필요할 때 때 이것을 어떻게 받아내서(마치 산고를 거쳐 한 생명을 받아내듯이..) 그걸 어떻게 원격에 가져가 분석할지에 대해서 고민한적이 있었는데요.. **요즘이야 워낙 하드디스크가 커져서리..

[디버깅 정보 쓰기] ‘덤프 유형 확인은 제어판 > 시스템 > 고급 시스템 설정 > 시작 및 복구’에서 확인 가능합니다.

덤프의 유형이 ‘전체 덤프’로 설정 되어 있으면 ‘실제 페이지 파일(Pagefile.sys) 크기 + 300MB’의 크기의 memory.dmp 파일이 생성 되는데. 요즘 대부분의 PC나 노트북의 경우 2GB 정도의 메모리가 기본으로 장착 되어 있기 때문에 2GB의 메모리가 있다면 2.3GB 정도의 memory.dmp 파일이 생성 됩니다, 혹은 커널 덤프라고 해도 수백 메가바이트가 되기도 합니다. 아무리 요즘 하드디스크가 대용량화 되었다고 해도 이런 크기는 무시 못할 것입니다, 게다가 넷북과 같은 경우 PC만큼 넉넉한(?) 용량을 가지고 있지 못하기 때문에 큰 부담이 될 수 있습니다. 이에 Windows 7에서부터는 하드디스크에서 부담을 줄이고자 메모리 전체 덤프와 커널덤프 파일 생성 여부를 아래와 같이 변경 하였습니다.

[메모리 덤프 생성 여부 순서도]

결론부터 말씀 드리면 위 순서도의 결론은 4GB 이상의 여유 공간이 존재 하지 않는 한 메모리 덤프를 생성하지 않는다는 것입니다. 이것은 하드디스크의 공간이 충분하지 않은 상태에 Memory.dmp 파일이 생성되어 시스템 리소스를 차지 하는 것을 막겠다는 의도 입니다.

위 표를 정리 해보죠.

① 먼저 레지스트리 AlwaysKeepMemorydump값이 1로 되어 있으면 무조건 메모리 덤프 파일을 생성합니다. 아래 덤프를 만들기 위한 조건에 관계하지 않고 무조건 메모리 덤프를 생성 합니다. 경로는 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl 입니다, 기본적으로는 없는 값이므로 필요하면 만드셔야 합니다.

② 만약 Windows가 Windows Server 2008 R2 이상이면 무조건 메모리 덤프 파일을 생성합니다. 기업에서 서버로 사용하는 제품에 문제가 생겼는데 덤프 분석이 필요할 가능성이 높겠죠? 그래서 더 볼 것 없이 W2K8 R2에서는 무조건 덤프를 생성 합니다. 이전에 말씀 드렸듯이 Windows 7과 Windows Server 2008 R2는 동일한 커널을 가지고 있으며 이번에 새로 적용된 룰은 이 둘에게만 해당 됩니다.

③ 만약 Windows 7 이상 클라이언트가 도메인에 Join 되어 있다면 무조건 메모리 덤프 파일을 생성한다. 도메인에 Join되어 있다는 의미는 기업 고객일 가능성이 높고, 고객 기업이라면 덤프 발생시 클라이언트라도 덤프 분석이 필요한 가능성이 높기 때문입니다.

④ 도메인에 조인 되어 있지 않다면 하드디스크의 여유 공간이 4GB 이상인지 확인 한다, 만약 4GB 이상이면 메모리 덤프 파일을 생성 하지만, 그렇지 않다면 생성하지 않습니다.

자~ 그럼 전체덤프와 커널덤프 말고 미니덤프(Minidump)는 어떨까요? 이전에는 시스템 Crash가발생할 때마다 Minidump폴더(보통 C:\Windows\Minidump)에 MiniMMDDYY-nn.dmp 파일(MMDDYY는 월/일/연도) 이름 형식으로 미니덤프가 쌓였었습니다, 미니덤프와 다른 덤프의 차이점은 크기가 작다는 점 이외에 다른 전체/커널덤프들은 만약 덤프가 발생하면 이전에 있던 memory.dmp위에 덮어 씁므로써(Overwrite) 복수의 덤프 파일이 생성되지 않지만 미니 덤프파일의 경우 계속해서 발생일 표시인 MMDDYY과 뒤에 nn의 이름을 바꿔가며 생성됩니다. 그래서 Windows 7에서 부터는 레지스트리 MinidumpsCount 값으로 최대로 만들어 질 수 있는 미니덤프 값을 조정 할 수 게 되었습니다. MinidumpsCount는 레지스트리 경로 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl에서 볼 수 있으며 기본 50개로 설정 되어 있습니다.

Windows 7에서는 지금까지 말씀 드린 덤프 파일과 같이 디스크 크기(Disk Footprint)를 줄이기 위한 노력 이외에도 정말 여러 방면에서 OS를 가볍게 해서 빠른 Performance를 내기 위한 눈물겨운(?) 노력을 기울였는데요, 앞으로 계속해서 소개하도록 하겠습니다.

**생각해 보니 HDD는 커졌지만 메모리도 너무 많이 커져서.. 램이 512GB인데 이걸 전체 덤프로 받으려면..

그럼 모두 가을을 만끽 하시길 빌며 저는 이만~ :^^

Thanks talee

p.s. 아~ 역시 전 미적 작업에 있어서는 감각이 떨어지나 봅니다.. 위에 간단해 보이는 순서도 하나 만드는 것이 글 쓰는 시간이랑 비슷했어요.. ㅜㅜ

Good News!(Great News!) Windows 7

sankim — Thu, 22 Oct 2009 05:48:55 GMT

오늘 드디어 Windows 7이 정식 출시 됩니다.

저 Sankim 이제부터 지금까지 숨겨(?) 왔던 Windows 7 이야기들을 여러분들께 천천히 꺼내 놓도록 하겠습니다.. 흐흐흐.. ( ㅡㅡ; ;ㅡㅡ 이 웃음은?)

컴잉순!

누구 레드 스크린(Red Screen) 보신 분 안계세요???

sankim — Mon, 21 Sep 2009 05:19:00 GMT

이전에 '윈도우의 블루스크린은 왜 파란색일까?'라는 포스팅에서 블루스크린이 파란색(Blue)이 된 사연을 설명 드린 적이 있었습니다. 그런데 이후에 댓글로 블루스크린 뿐만 아니라 레드 스크린(Red Screen)을 보셨다는 제보가 있어 사실 유무를 확인 해 보았습니다.

사실 Windows 기술 지원을 꽤 오래 해왔음에도 레드스크린 이라는 것을 한번도 본적이 없던 터라 반신 반의 했었는데 Research 중 'Sorting it all Out' 블로그에서 실제 Red Screen을 캡쳐한 화면을 볼 수 있었고 그 이외에도 검색을 해 보면 레드스크린 관련된 KB 문서와 실제로 사진으로 찍은 화면까지 볼 수 있었습니다.

!!! 진짜 레드 스크린이...!!!

확인 결과 컴퓨터를 부팅할 때 부팅을 관리 하는 부트 매니저(Boot Manager)단에서 유효한 엔트리(Valid Entry)를 찾지 못할 경우 Windows는 레드스크린 함께 에러 메시지(Valid Error Message)를 보여 줍니다. 일반적인 사례들을 보면 원인의 대부분이 BIOS나 디스크와 관련이 있지만 다행히 재부팅으로 문제가 해결됩니다. 혹시 재부팅 해도 문제가 해결 안되고 레드스크린에서 디스크 관련 문제라는 메시지를 뿌려 주면 한번 복구콘솔에서 ‘chkdsk /p /r’를 실행해 보시기 바랍니다, 해결 가능성이 있습니다..

그럼 오늘도 좋은 하루 되시고요 앞으로 다가올 가을의 향취를 만끽하시길 바랍니다~ :)

*10월5일 업데이트: 이번 추석에 windows 7에서 몇가지 테스트를 하다 Boot Manager 단에서 Crash를 발생 시켜보았는데, Windows 7에서는 레드 스크린이 나타나지 않고 마친 콘솔처럼 검은색 바탕에 하얀 글씨로 Windows Vista와 동일한 모습의 메시지가 나타났습니다.

p.s. 개인적으로 바뻐서 블로깅이 뜸합니다.. ^^;;

Servicing Stack (2) 부제: 커져만 가는 WinSxS 폴더 사이즈를 줄여보자!

sankim — Mon, 17 Aug 2009 07:59:47 GMT

이번 포스팅은 Servicing과 WinSxS 두 번째 이야기 입니다. 이번 포스팅에서는 Servicing에 대해서 설명 드리고 시간이 갈수록 WinSxS 폴더의 크기가 커지는 이유와 그 해결 방법을 말씀 드리겠습니다.

Servicing이란?

Windows Vista 이전에는 보안 업데이트나 BugFix를 위해 시스템을 업데이트를 하면 INF 기반으로 exe나 dll 같은 시스템 파일 이나 레지스트리 값들을 각 파일 단위로 업데이트 하였습니다, 그러나 Vista에서 부터는 Servicing이라는 새로운 Component 관리 메커니즘을 통해 파일, 레지스트리 값, 서비스, Generic Command, Dependencies, Category를 묶어 하나의 Component 단위로 관리합니다, 그리고 이런 여러 Component들을 하나로 묶은 것을 Deployment라고 하며, 또 이 여러 Deployment들을 하나로 묶은 것을 Package라고 합니다. 윈도우 업데이트가 이뤄질 때는 각각의 Component 단위로 이뤄지는 것이 아니라 Package 단위로 이뤄집니다. 그리고 WinSxS 폴더는 이 Component를 모아 저장해둔 공간이므로 Component Store라고 부릅니다.

Servicing이 적용된 Vista 이후는 Windows가 처음 설치 될 때 윈도우 설치 CD에 들어 있는 모든 시스템 파일들을 Component Store(WinSxS 폴더)에 넣고 설치 작업을 진행합니다, 그래서 새로운 기능을 설치 하거나 SFC(System File Checker)를 실행 할 때 이전 버전 같이 윈도우 설치 CD를 넣으라는 메시지 박스가 나타나지 않습니다. 처음 Windows를 설치 할 때나 혹은 시스템 업데이트를 할 때 WinSxS 폴더에서 필요한 Component를 Windows 시스템 폴더(예. C:\Windows)에 연결되도록 하드링크를 만들어 시스템이나 사용자가 액세스 가능한 상태를 Projection이라고 하며 반대로 파일이 WinSxS 폴더에 저장되어 있기는 하지만 사용하지 않는(하드링크가 되어 있지 않는) 상태를 Stage라고 합니다. 이런 식으로 OS Component를 관리하는 메커니즘을 Servicing 이라고 합니다.

Servicing은 아래와 같은 구조를 가지고 있습니다.

[그림 1] Servicing 구조. (이 외에도 여러 구성들이 있지만 이해를 돕기 위해 단순화 하였습니다)

Windows Update 통해서나 MSU와 같은 업데이트 파일을 이용해 시스템을 업데이트 할 때 CBS(Component Based Servicing)는 우선 해당 Package가 현재 Windows에 설치되어야 할 Package인 지를 판단 합니다. 만약 CBS가 설치되어야 할 Package라고 판단하면 아래 CSI(Component Servicing Infrastructure)에게 넘겨 CSI에 의해 Package가 설치 됩니다.

*윈도우 서비스 관리자에서 보이는 Windows Module Installer 혹은 작업 관리자에서 볼 수 있는trustedinstaller.exe 프로세스가 CBS의 역할을 합니다.

왜 WinSxS 폴더의 크기는 끊임 없이 커져만 가는 걸까요?

앞 1탄에서 WinSxS 폴더에 있는 파일에 Windows 폴더에서 액세스 가능한 하드링크가 생성된 것이며 WinSxS 폴더에 있는 파일이 Windows 폴더에 있는 파일들과 중복되는 것이 아니라고 말씀 드렸습니다. 그렇다면 WinSxS폴더에 있는 하나의 파일이 Windows 폴더의 파일로 1:1로 매치 된다는 의미 인데 아래 그림 2를 보시면 Win32k.sys의 경우 여러 버전 별로 각각 존재하는 것을 볼 수 있습니다.

Servicing은 새로운 Update가 있으면 새로운 업데이트를 다운로드 한 뒤 이전 버전의 Component는 그대로 Component Store(WinSxS 폴더)에 남겨둔 채 다운로드 받은 새로운 Component를 사용(Projection)합니다. 아래 그림2 에서 보시는 것과 같이 만약 동일한 Component로 새로운 Update가 나오면 새 Update가 나올 때 마다 WinSxS에 Component들이 쌓이게 됩니다.

게다가 배포되는 Package안에는 각 서비스팩 버전 별로 각기 다른 버전의 Component가 들어 있어 그 크기는 더욱 커져만 갑니다. 예를 들어 A라는 업데이트가 하나 있다면, Package 안에는 Windows Vista RTM 버전, SP1 버전, SP2 버전에 맞는 업데이트 세가지를 모두 담고 있습니다. 즉 업데이트 A를 설치 하면 WinSxS에 RTM, SP1, SP2버전의 파일들을 모두 WinSxS 폴더에 저장해 두고 현재 윈도우 서비스팩 버전에 맞는 Component를 Projection 시키고 나머지 파일들은 Stage 합니다. 그래서 새로운 업데이트가 나올수록 WinSxS 폴더의 크기는 커져가는 것입니다.

[그림 2] WinSxS 폴더에 있는 여러 버전의 Win32k.sys

그럼 왜 이런 구조가 필요한 걸 까요?

Servicing이 지난 버전 혹은 상위 서비스팩 버전의 Component 들까지 저장하고 있는 구조는 언뜻 보면 불합리해 보일 수도 있습니다만 이러한 메커니즘은 어떠한 상황에서도 시스템이 최신의 Component를 유지 할 수 있도록 할 수 있습니다.

예를 들어 만약 Windows XP에서 설치 되어 있는 업데이트 B를 제거 한다면 해당 업데이트가 설치 되기 이전의 상태로만 돌아 갈 것 입니다, 그러나 이전으로 돌아간 상태가 최신 상태라는 보장은 없습니다(왜냐 하면 현 버전과 이전 버전 중간에 무수히 많은 버전들이 나왔을 수 있으므로). 그러나 Servicing 구조는 지금까지 모든 Component에 대한 업데이트를 각 버전 별로 모두 가지고 있으므로 현재 상태에서 Stage되어 있는 최신의 Component만 Projection 시키면 됩니다. 또 다른 예로 Windows Vista SP1인 상태에서 만약 SP1을 제거한다면 이전 같으면 RTM 상태에서 또다시 Windows Update를 통해 최신의 버전으로 무수히 많은 업데이트를 해야 했겠지만 Servicing에서는 자신이 Component Store(WinSxS폴더)에 저장된 RTM Component중에 가장 최신의 Component로 Projection 시키게 됩니다.

그렇다면 시간이 갈수록 커질 수 밖에 없는 WinSxS 폴더의 공간을 줄일 수 있는 방법은 무엇이 있을까요?

웹을 검색해보면 WinSxS를 통째로 삭제하는 방법들을 볼 수 있습니다, 물론 삭제 한다고 지금 당장은 시스템에 문제가 생기지 않겠지만 Windows의 신뢰성에 문제를 일으킬 수 있는 문제이므로 WinSxS를 직접 삭제하시는 것은 피해주시기 바랍니다.

여러분들께서 WinSxS 폴더의 크기를 줄이는 가장 안전하고 효과적인 방법은 VSP1CLN.exe혹은 COMPCLN.exe를 실행 하는 것 입니다. 이 두 명령은 현재 컴퓨터에 설치된 서비스팩 이전의 Component들을 WinSxS 폴더에서 안정적으로 삭제합니다. 즉 현재 컴퓨터에 설치된 서비스팩 이전 버전의 Stage된 파일들을 제거해 디스크 공간 확보할 수 있는 방법입니다. 단 이 명령을 실행하면 서비스 팩을 제거 할 수 있는 옵션도 사라지고 해당 서비스팩 이전 상태로는 돌아 갈 수 없습니다.

* Windows Vista Service Pack 1이 설치된 컴퓨터에서는 VSP1CLN.exe를 실행 합니다. (Windows Server 2008의 경우는 기본적으로 SP1을 포함하므로 VSP1CLN.exe는 사용하지 않습니다)

*Windows Vista Service Pack 2, Windows Server 2008이 설치된 컴퓨터에서는 COMPCLN.exe를 실행 합니다.

그럼 VSP1CLN.exe의 실행 예를 보도록 하겠습니다. 아래 그림은 “My Notes to Myself and Others...”에서 가져 왔습니다.

실행 전)

VSP1CLN.exe 실행)

실행 후)

하드디스크의 여유 공간이 약 800MB가 늘어난 것을 볼 수 있습니다. J

오늘 포스팅은 여기까지 입니다, 글로 설명 드리기에는 참 복잡(?)한 내용이라 얼마나 이해하시는데 도움을 드렸는지 모르겠습니다.

그럼 더운 여름 건강히 보내시고 다음 포스팅에서 뵙도록 하겠습니다~

Servicing Stack (1) 부제: WinSxS 폴더를 이해하다

sankim — Mon, 27 Jul 2009 05:30:00 GMT

인터넷을 떠돌다가 우연히 Windows Vista와 Windows 7의 WinSxS(C:\Windows\WinSxS) 폴더에 대한 글들을 보았습니다, 대부분의 질문이 “하드 디스크가 부족해서 확인해 보니까 WinSxS 폴더가 엄청 디스크를 차지 하더라고요, 이걸 어떻게 지우죠?” 라는 질문으로 시작해서 답변으로는 WinSxS 폴더의 삭제 방법을 알려주는 글들이 많았습니다.

디스크 용량에 상당히 민감할 수 밖에 없는 일반 데스크톱 사용자의 윈도우 탐색기를 통해 보이는 WinSxS 폴더의 GB급 크기는 큰 부담일 것 입니다만 뭔지도 모르고 무턱대고 삭제하는건 상당히 위험하겠죠? 그래서 이번 포스팅에서는 WinSxS 폴더의 정체를 밝히고 실질적으로 WinSxS 폴더를 관리하는 ‘Servicing Stack’이라는 개념을 알아보고 WinSxS의 사이즈를 안정적으로 줄 일 수 있는 방법도 소개 하도록 하겠습니다.

오늘은 첫 번째 시간으로 WinSxS를 이해하기 위한 핵심인 하드 링크(Hard link)에 대해서 설명 드리겠습니다. 우선은 WinSxS는 머리에서 잠시 내려 놓으시고 먼저 하드 링크를 이해하는데 힘써주십시오. (그리 어렵지 않습니다..)

하드링크(Hard Link)란?

정의: 파일의 디렉토리 엔트리(Directory entry)를 칭하며 모든 파일은 하나 이상의 하드링크를 가진다.

흠.. 좀 이해하기 어렵죠? 조금 풀어서 설명 드리면 디스크 상의 모든 파일은 사용자 혹은 시스템이 액세스 하기 위한 경로(폴더와 파일명) 정보인 디렉토리 엔트리(Directory entire)를 가지는데 이를 하드링크라고 부릅니다. 예를 들어 디스크 위에 A라는 파일이 있는데 이것에 접근 하려면 C:\temp\01.txt라는 경로가 필요한데 이 경로정보를 하드링크라고 부릅니다. 하나의 파일은 한 개 이상의 하드링크를 가지며 A 라는 파일이 있을 때 C:\temp\01.txt와 C:\sankim\02.txt라는 하드링크 두개를 가질 수 있습니다. 이 두 개는 경로나 파일 이름은 다르지만 결국은 하나의 같은 파일 A가 되는 것입니다.

그래도 아직 설명이 드라이(Dry)한 게 가슴에 와 닿지 않죠? 아래 예제와 함께 하드링크를 설명 드리겠습니다.

디스크 상에 A라는 파일이 있고 경로는 C:\temp\01.txt 입니다, 즉 사용자(혹은 시스템이나 응용프로그램)는 C:\temp\01.txt라는 경로(Path)를 통해서 파일 A에 액세스 할 수 있습니다. C:\temp\01.txt라는 디렉토리 엔트리는 파일 A에 액세스 하기 위한 일종의 링크로 생각 할 수 있고 그래서 하드링크라고 부릅니다. *보통 우리가 파일을 휴지통에서 삭제(Delete)하는 것은 이 하드링크를 제거하는 것입니다.

*중요: 위 갈색 네모에 있는 C:\temp\01.txt는 파일이 아닙니다, 실제 파일은 ‘파일 A’이고 갈색 네모 박스는 사용자나 시스템이 ‘파일 A’에 액세스 할 수 있도록 해주는 경로 정보입니다*

여기서 만약 사용자 혹은 시스템이 파일 A에 접근하기 위한 경로를 C:\temp\01.txt 뿐만 아니라 다른 이름으로도 액세스해야 할 필요가 있다면 또 다른 하드링크를 생성해 하나의 파일에 두 개 이상의 경로를 만들 수 있습니다. 파일 A에 하드 링크로 또 다른 경로 C:\sankim\02.txt를 추가 한다면 아래와 같은 구조를 가지게 됩니다.

이러면 사용자(시스템 혹은 응용프로그램 포함)는 C:\temp\01.txt이건 C:\sankim\02.txt이건 동일하게 파일 A에 액세스 할 수 있습니다. 다시 한번 강조하지만 여기서 중요한 건 두 개의 파일이 생성되는 것이 아니라 디스크 위에 파일은 그대로고 그 파일에 액세스 할 수 있는 경로 정보인 디렉토리 엔트리가 하나 더 추가 되었다는 것입니다.

만약 여기서 C:\temp\01.txt를 삭제하면 어떻게 될까요? 그래도 사용자는 아래 그림과 같이 C:\sankim\02.txt를 통해 파일 A에 액세스 할 수 있습니다. 왜냐 하면 파일 A에 액세스 할 수 있는 C:\temp\01.txt라는 경로 없어진 것뿐이고 다른 경로는 남아 있기 때문입니다.

사용자가 하드링크를 만들려면 Mklink.exe라는 도구를 할 수 있는데요, 그럼 다중 하드링크를 제 Windows 7 컴퓨터에서 만들어 보도록 하겠습니다. 하드링크 생성을 위해 아래와 같이 “mklink.exe /H”를 이용해 C:\sankim이라는 폴더에 02.txt라는 Hard link를 만듭니다. *여기서 /H 옵션을 빼면 심볼릭 링크 (Symbolic link)가 만들어 집니다, 심볼릭 링크는 나중에 설명 드리겠습니다.

위와 같이 하드링크를 만든 뒤 01.txt에서 아무 텍스트를 넣고 02.txt를 열어 보면 01.txt와 동일한 내용임을 확인 할 수 있습니다, 또 반대로 02.txt에서 텍스트를 변경해도 01.txt에서도 동일하게 텍스트가 변경된 것을 확인 할 수 있습니다. 이것은 두 경로가 경로 정보만 다를 뿐 동일한 파일이라는 증거가 됩니다.

그럼 01.txt를 삭제했을 때 어떤 현상이 나타나는지 확인해 보도록 하겠습니다.

C:\temp\01.txt를 삭제 했지만 여전히 C:\sankim\02.txt를 통해서 파일에 액세스가 가능함을 확인 할 수 있습니다. 이제 하드링크가 이해가 되시죠?

지금까지 열심히 하드링크를 설명 드렸는데 하드링크하고 WinSxS가 무슨 관계냐고요? WinSxS 폴더를 열어서 확인해 보면 안에 있는 파일들이 모두 Windows(일반적으로 C:\windows)폴더에 있는 파일과 동일한 파일인 것을 확인 할 수 있습니다. 이것은 최초 시스템 파일들(Windows 폴더에 있는 파일들)은 원래는 WinSxS에 기본 경로가 있었고 윈도우가 설치 되면서 Windows 폴더에 하드링크를 생성한 것 입니다. 그래서 시스템이나 사용자는 Windows\system32에 연결된 하드링크 된 파일을 이용하는 것입니다. 아래 그림에서처럼 같이 “fsutil hardlink list”로 확인하면 세가지 파일 모두 Windows/system32와 WinSxs에 하드링크 되어 있는 것을 확인 할 수 있습니다.

아래 ‘WinSxS 하드링크 예’그림에서와 같이 Windows 폴더가 원본 파일인 것 같지만 사실은 원래Windows\WinSxS에 처음 하드링크된 파일들이고 Windows에 있는 파일들은 WinSxS에 있는 파일들을 하드링크를 생성해 사용하는 것입니다.

그러므로 어차피 경로가 다르게 보일 뿐이지 동일한 하나의 파일이므로 WinSxS가 있다고 해서 중복된 파일인해 디스크 공간을 더 차지하는 것은 아닙니다.

자~ 그럼 WinSxS가 있다고 해서 디스크 공간을 소비하는 것은 아니라는 것을 하드링크를 통해 이해하게 되었습니다. 하지만 그와 별개로 시간이 지날수록 WinSxS의 크기는 점점 커져만 가는데요.. 왜 그런 걸까요? 그것은 Windows Vista, Server 2008에서부터 새로 적용된 Servicing 이라는 OS Component를 관리하는 매커니즘 때문입니다. 다음 시간에는 새로운 Servicing에 대해서 말씀드리도록 하도록 하겠습니다.

Windows Internals 5'th를 받았습니다

sankim — Thu, 09 Jul 2009 11:15:00 GMT

최근 지나친 노동으로 인해 목에 담이 드는 바람에 침 맞으러 한의원에 다녀왔더니 자리에 웬 두꺼운 책 하나가 떡 허니 놓여 있더군요, 제목을 보니 'Windows Internals 5'th'였습니다. 누가 가져다 놓았나 했더니 꼬알라님께서 첫 샘플로 입수한 첫 책을 제자리에 선물로 놓고 가셨더군요, 이 자리를 빌어 다시 한번 감사의 말을 전합니다. ^^

잽싸게 책을 들고가 이 책의 Master Reviewer로 작업을 하신 김관현 부장님께 싸인을 받았습니다. 좀 멋지게 몇 마디라도 쓰실 줄 알았더니 달랑 싸인만..

맨 앞 표지에는 'To Jim Alchin, our OS and rock star'이라고 적혀 있네요. Jim Alchin이 바로 ‘[단상] 브라보 마이 라이프’라는 포스팅에서 소개해 드린 ‘Windows의 아버지’로 불리며 Platforms & Services Division 부사장으로 일하다 2007년 Windows Vista의 출시와 함께 은퇴해 지금은 뮤지션으로 활동하고 있는 분입니다. 참고로 이전 Edition에서는 맨 앞 표지에 ‘To Dave cutler, Father of the Windows Kernel’ 이였습니다.

이전 4’th Edition보다 250페이지 가량 Windows Vista와 Server 2008에서 변경된 혹은 새로 선보인 내용이 추가 되었습니다. Windows Vista와 지금 나와있는 Windows 7의 Kernel은 95%가량 동일하므로 Windows 7에서 새로 추가되거나 Enhancement된 부분을 제외하면 Windows 7의 Kernel의 상당 부분을 커버 합니다.

아래 동영상은 이 책의 저자인 Mark Russinovich와 David Solomon의 의 인터뷰 입니다.

Windows에 관심이 많고 Kernel과 개발에 대한 지식을 갖추신 분들이시라면 관심가지실 것을 권장합니다만 아니시라면 해석 불가능한 외계어만 보시다 마실 가능성이 높으므로 권장하지 않습니다. ^^;

Windows Vista 출시 이후 비스타나 윈도우 7의 내부 구조를 상세히 설명한 자료가 없어서 항상 Blackbox를 대하는 기분이었는데 이제 좀 속 시원히 안(?)을 들여다 볼 수 있을 것으로 기대 됩니다. 이 책이 생겼다고 바로 그 안의 지식이 당장 내 것이 되는 건 아닐 텐데도 기분이 좋아지네요. ^^

모두 Happy Reading~

p.s. 글 쓰는 중간에 Talee군이 와서 자기도 하나 달라며 니킥 한방 날리고 갔습니다.. :P

Windows Vista 서비스 팩(Service Pack) 2 FAQ

sankim — Tue, 07 Jul 2009 06:33:52 GMT

이번 포스팅에서는 Windows Vista 서비스 팩(Service Pack) 2에 대해서 SP2자체 보다는 추가적으로 궁금 하실 만한 사항에 대해서 FAQ 형식으로 꾸며 보았습니다.

Q: 서비스 팩(이하 SP)이란 무엇입니까?

A: 보안 업데이트(Security update)나 버그픽스(Bugfix)와 같은 업데이트들의 모음(collection of updates)입니다. 그래서 사용자는 일일이 업데이트 파일을 찾아 설치 하지 않아도 SP 하나 설치로 모든 업데이트 설치가 가능합니다.

Q: Windows Vista와 Windows Server 2008에서 이야기 하는 단일 서비스 모델(Single Service Model)은 무슨 의미 입니까?

A: 네, 단일 서비스는 Windows Vista와 Windows Server 2008이 동일한 SP을 공유한다는 의미입니다. Windows Vista와 Windows Server 2008은 동일한 코드베이스를 가지므로 서비스가 통일되어 있습니다. 따라서 시스템 관리자는 두 플랫폼에 대해 하나의 SP만 테스트하고 배포하면 됩니다.

그래서 실제 하나의 SP 2를 다운로드 해도 Windows Vista와 Windows Server 2008 모두에 적용 가능 합니다. SP2 다운로드를 원하시면 여기를 클릭하세요

Q: SP2에는 SP1이 포함되어 있습니까?

A: 아니요, 이번 SP 2 이전까지는 최신 SP에는 이전 SP이 포함되어 있었습니다, 그래서 Windows XP SP2를 설치 한다면 SP1이 포함되어 있었기 때문에 SP1을 먼저 설치할 필요가 없었습니다, 그러나 Windows Vista에서는 SP의 크기가 너무 커지는 것을 방지하고 단일 서비스 모델을 지원하기 위해서 입니다.

SP1이 설치 되어 있지 않은 Windows Vista에 SP2를 설치 하기 위해서는 아래를 참조 하여 주십시오. 참고로 Windows Server 2008은 기본 RTM에 이미 SP1이 포함 되어 있으므로 SP1을 설치할 필요가 없습니다.

Q: SP을 다운받아 설치하는 것과 Windows Update를 통해 설치하는 것은 어떤 차이가 있나요?

A: SP을 다운받는 것을 Standalone Package라고 하는데 이는 인터넷 연결이 되지 않거나 기업 환경에서 관리자가 별도로 설치를 원할 때 사용합니다, Standalone Package의 경우 SP의 용량이 큰편인데 X64의 경우 Standalone Package는 다운 받으면 대략 660MB까지 되는데 이는 32개의 언어가 모두 포함되어 있기 때문입니다. Windows Update는 관리자가 별도로 없는 기업이나 홈 유저를 위한 서비스로 인터넷에 연결되어 있으면 사용이 가능합니다. Windows Update를 이용하면 SP를 43MB정도만 다운로드 받아 설치 하는데 이는 변경된 그리고 필요한 구성만 다운로드 받아 설치 하기 때문입니다.

-참고로 IA64는 Windows Update를 통한 SP 설치가 지원되지 않습니다.

Q: 컴퓨터가 여러 대인데 Windows Update를 보면 한 두대 컴퓨터에 SP2 설치가 나타나지 않아요, 왜 그렇지요?

A: Windows Update를 통해 SP2를 배포 할 때는 한번에 모든 컴퓨터에게 SP2를 배포하는 것이 아니라 약간의 시차를 두고 순차적으로 배포하는 매커니즘을 가집니다. 만약 SP2 설치가 급하신 분이시라면 직접 다운로드 받아 설치하시기 바랍니다. J

Q: SP2에 IE8인 포함되어 있나요?

A: 아니요, SP2에는 IE8이 포함 되어 있지 않습니다.

Q: SP2는 R2가 아닌 컴퓨터를 Windows Server 2008 R2 SP2 컴퓨터로 변경합니까?

A: 아니요, SP2는 Windows Server 2008을 Windows Server 2008 R2로 업그레이드하지 않습니다. Windows Server 2008 R2는 Windows Server의 후속 릴리스이고 SP2는 현재 버전의 Windows 2008 Server에 대한 SP입니다.

Thx 찌Na

그럼 다음 포스팅에서 만나요~

Windows 성능 옵션(프로그램 vs 백그라운드 서비스)을 이해하다

sankim — Wed, 10 Jun 2009 06:45:00 GMT

Windows NT부터 Windows 7에서 까지 ‘시스템 속성 > 성능 > 설정 > 성능 옵션 > 고급 > 프로세서 사용 계획’에 ‘프로그램’과 ‘백그라운드 서비스’ 옵션 두 가지 중 하나를 사용자가 선택할 수 있습니다. 이 두 개의 옵션에 대해서 여러 의견(?)들이 난무하는데요, 이번 포스팅에서는 이 두 가지 옵션이 어떤 의미를 가지는지 그리고 여러분은 어떤 상황에서 두 옵션 중 하나를 선택할 것인지를 설명 드릴까 합니다.

[그림 1. Windows 7, 프로세서 사용 계획]

잘못된 오해
많은 분들께서 이 옵션에 대해서 아래와 같이 잘못 이해하고 계십니다.

{‘프로그램’은 실제 사용자가 실행하는 응용 프로그램이고 ‘백그라운드 서비스’는 ‘서비스 관리자(services.msc)’에서 실행되는 서비스를 의미한다. 그래서 프로세서 사용계획의 설정에 의해 ‘프로그램’을 선택하면 사용자 프로그램에 더 많은 CPU 사용량을 할당하고 ‘백그라운드 서비스’를 선택하면 서비스(Service)에 더 많은 CPU 사용량을 할당한다} => NO, NO, NO 이렇게 이해하고 계시면 안됩니다.

진실을 말씀 드리겠습니다.
(이 옵션을 이해하기 위해서는 먼저 스레드와 컨텍스트 스위치 두가지 개념을 이해하셔야 합니다 그래서 이 단어의 정의를 설명드리면서 옵션을 이해하도록 하겠습니다)
우리가 사용하는 프로그램이란 것은 알고 보면 실행 파일이 프로세스(Process)로 만들어 진 후 스레드(Thread)에서 명령이 실행되는 것 입니다, 여기서 스레드란 명령어가 CPU를 사용하여 실행되는 단위로 정의 할 수 있습니다. (그밖에 많은 복잡한 이야기들이 있지만 여기서는 이정도 까지만 이해하시면 되겠습니다)

우리가 컴퓨터를 사용할 때 우리는 모르지만 네트워크 처리, HDD 처리, 커널에서의 작업, 응용프로그램 처리 등등 너무나도 많은 작업들이 동시 다발적으로 이뤄지고 있습니다. 다른 예로, 사용자가 인터넷에서 파일을 다운로드 하면서 Word와 WMP를 함께 사용하는 경우도 생각해 볼 수 있습니다. 이러한 것들은 모두 스레드 단위로 작업이 이뤄지며 작업에 따라 스레드 처리 시간이 길수도 짧을 수도 있습니다.

일상 생활에서도 금방 끝나는 일이 있고 오래 걸리는 일들이 있듯이 스레드도 처리 하는데 시간이 긴 작업과 짧은 작업들이 섞여 있는데 만약 그림처럼 CPU에서 하나의 스레드가 끝날 때까지 다른 스레드들은 기다려야 한다면 스레드 A가 끝날 때 까지는 스레드 B, C는 기다리고만 있어야 할 것 입니다.

[그림 2]

위 그림 2처럼 하나의 스레드가 자신의 명령이 끝날 때가지 계속 CPU 독점해서 사용한다고 하면 오랜 시간 동안 다른 스레드들(프로그램)이 실행되지 못할 것입니다, 그렇게 되면 다른 프로그램의 성능에 영향을 주겠죠? 특히 스레드 B의 입장에서는 잠시 CPU를 사용하면 금방 끝날 일인데 앞에서 스레드 A의 작업이 끝나기를 기다려야 하니 답답한 노릇일 것입니다.

그래서 좀더 효율적으로 동시 작업이 가능 하도록 하나의 스레드가 시작해서 끝날 때까지 무작정 CPU를 사용하는 것이 아니고 그림 3. 처럼 스레드의 실행 시간을 짧은 시간 단위로 잘라낸 뒤 순서대로 세워 놓고 실행하다 자신에게 할당된 시간이 끝나면 하던 일을 멈추고 다음 스레드에게 CPU를 사용할 수 있도록 한 뒤 다시 자기 차례가 돌아오면 자신의 일을 다시 합니다. 스레드가 CPU를 얼마 동안 사용할지를 정의한 시간 단위를 바로 퀀텀(Quantum)이라고 합니다. 그러면 그림에서처럼 스레드 B는 다음 순번에서 바로 작업을 끝낼 수 있습니다. (그림 3의 ‘A B C A B C A C A C A A A’ 순서를 보시면 이해가 좀 쉬우실 것입니다)

[그림 3]

이 퀀텀을 사용자가 길게도 혹은 짧게도 설정 할 수 있는데 이것이 바로 ‘프로세스 사용 계획 옵션’입니다. 그래서 ‘프로그램’으로 설정하면 모든 스레드의 퀀텀을 짧게(6, 대략 2 Click) 설정하고 반대로 ‘백그라운드 서비스’로 설정하면 길게(36, 대략 12 Click) 설정 합니다.

그렇다면 퀀텀(스레드 실행 시간)을 짧게 혹은 길게 설정 하는 것은 어떤 차이가 있을까요?

차이와 그에 따른 장단 점을 이해 하시려면 Context Switch라는 의미를 이해 해야 합니다.

[그림 4, Context Switch]

그림 4.와 같이 퀀텀에 정의된 시간이 끝나 CPU를 떠나야 하는 스레드 A는 CPU를 떠나기 전에 자신이 어디까지 작업을 했는지를 저장합니다, 그래야 다음 차례에 다시 A가 실행될 때 앞에서 마지막으로 진행했던 부분부터 다시 시작 할 수 있기 때문입니다, 또한 B는 자신이 앞에서 실행 했던 부분부터 다시 시작 하기 위해 앞에서 저장했던 실행정보를 불러옵니다, 바로 이런 일련의 작업을 컨텍스트 스위치(Context Switch)라고 합니다.

이 Context Switch 자체는 미약(?)하기는 하지만 전체적으로 보면 성능에 영향을 줄 수 있는 작업입니다. 그래서 만약 다른 작업은 거의 없고 CPU에서 스레드를 처리하는데 긴 시간이 필요한 단일 응용프로그램(SQL Server 혹은 그래픽 랜더링 작업 같은)만 실행하는 환경이라면 ‘백그라운드 서비스’로 설정해 Context Swith를 최소화하고 해당 프로그램의 스레드가 긴 시간 CPU를 사용 할 수 있도록 하는 것이 효과적일 것입니다.

반대로 일반 사용자의 컴퓨터 사용 패턴은 아주 소소한 아이콘 클릭 같은 작업을 포함해 IE같은 웹 브라우저 사용과 함께 음악을 듣는 것과 같이 동시에 여러 프로그램을 실행하는 패턴을 보입니다. 이런 경우 스레드에 긴 시간을 주면 스레드가 끝나기를 기다리는 시간이 오래 걸리기 때문에 다른 작업으로 넘어가는데 시간이 걸려 반응속도를 늦출 수 있지만, 일정한 시간 내에 여러 스레드들이 실행 될 수 있도록 퀀텀을 작게 설정하면 사용자 측면에서 반응속도를 높일 수 있습니다..

두 옵션은 아래와 같이 정의 할 수 있습니다
프로그램: 여러 작업을 동시에 수행하는 일반 사용자 환경에서 쾌적한(?) 반응 속도를 보여준다.
백그라운드 서비스: 계속해서 한가지 작업을 실행하는 응용프로그램을 실행 하는 경우 높은 처리 효율을 가진다.
* 이 두 옵션을 그 반대의 환경에 설정하였다면 반드시 나쁘다고는 말할 수 없겠지만 성능 효율면에서는 떨어질 것입니다.

그래서 기본적으로 Windows 2000 Professional, XP, Vista그리고 Windows 7과 같이 일반 사용자를 위한 Windows 클라이언트에서는 ‘프로그램’으로 설정 되어 있으며 Windows Server 2000, 2003, 2008에서는 ‘백그라운드 서비스’로 설정 되어 있습니다. 만약 윈도우 클라이언트지만 그래픽 랜더링 작업 같이 CPU를 많이 사용하는 하나의 작업을 주로 사용하는 환경이라면 ‘백그라운드 서비스’를 선택 할 수 있을 것이고 반대로 윈도우 서버지만 클라이언트 환경같이 사용한다면 ‘프로그램’ 옵션을 선택하면 성능에 효과적일 것입니다.

조금 자세한 추가 설명
‘프로그램’으로 설정 되어 있으면 스레드는 2 Clock interval 기간 동안 실행이 가능하며 ‘백그라운드 서비스’는 12 Clock interval 기간 동안 실행할 수 있습니다.

퀀텀에서는 Clock interval의 3배수로 설정됩니다, 그래서 ‘프로그램’으로 설정 되어 있으면 Short 값인 6(‘실제 Clock 2개’ x 3배수)을 가지고, ‘백그라운드 서비스’로 설정 되어 있으면 퀀텀 Long 값인 36(‘실제 Clock 12개’ x 3배수)을 가집니다. 그래서 클럭인터럽트가 걸릴 때마다 퀀텀 값을 3단위로 줄여가 결국 0이 되면 일단 그 스레드가 이번에 실행될 시간은 모두 끝내고 기다리고 있던 다음 스레드가 실행 되도록 합니다.

이해를 돕고자 상당 부분 단순화 썼습니다. 좀더 자세한 정보가 필요하신 분들께서는 아래 Windows Internals의 Thread 부분을 참고 하시기 바랍니다.

[참고문서]
Windows Internals 4’th, Chapter 6, Controlling the Quantum

윈도우 7 출시 예정일 발표!

sankim — Wed, 03 Jun 2009 07:25:23 GMT

Windows 7 Team 블로그에서 Windows 7과 Windows Server 2008 R2이 7월 둘째 중에 RTM될 것이며, 10월 22일 GA(어디서나 어떤 형태로든 구입 가능한) 될 것이라고 발표 되었습니다.

Obviously, Release To Manufacturing (RTM) is an important milestone on the path to GA. We anticipate that we’ll be able to make the RTM code for Windows 7 available to our partners sometime in the 2nd half of July. We also expect to be able to make RTM code for Windows Server 2008 R2 available to our partners in this time frame as well.

두 제품은 동일 커널(6.1) 라인으로 만들어 지고 있고 여러 새로운 기능들이 두 제품 안에서 구동되므로 동일한 RTM과 출시일을 가지게 됩니다.

이제 Windows 7과 Windows Server 2008 R2의 탄생이 가까이 왔습니다!

Easy Transfer를 이용한 XP에서 Windows 7으로 마이그레이션

sankim — Mon, 01 Jun 2009 10:15:00 GMT

이전 ‘윈도우 XP, Vista에서 윈도우7으로 업그레이드’에서 말씀 드린바 대로 오늘은 Easy Transfer를 이용해 XP에서 Windows 7으로 마이그레이션 하는 방법을 설명 드리겠습니다.

마이그레이션이란 이전 윈도우(XP, Vista)에 있던 설정이나 데이타를 새로운 H/W 혹은 운영체제(Windows 7)로 옮기는 작업이라고 말씀 드렸는데요, Easy Transfer을 이용하면 기본 윈도우 설정 정보는 물론이고 이전 컴퓨터에서 사용하던 데이타를 옮길 수 있습니다. 그러나 설치 되어 있는 응용프로그램은 옮길 수 없으므로 마이그레이션 전에 새로 설치 해야 합니다.

Easy Transfer에서 전송 가능한 파일과 설정

파일 및 폴더
전자 메일 설정
연락처 및 메시지
프로그램 설정
사용자 계정 및 설정
인터넷 설정 및 즐겨찾기
음악
그림 및 비디오

Easy Transfer는 컨셉은 간단합니다, Easy Transfer를 이용해 윈도우 XP의 설정과 하드디스크의 데이터를 전용 USB 케이블을 이용해 바로 새로운 컴퓨터로 옮기거나 아니면 설정과 데이타를 하나의 .MIG 파일로 만들어 USB 같은 하드디스크에 저장한 뒤 그 MIG 파일을 새 컴퓨터에 옮겨 Easy Transfer를 이용해 풀어 놓는 방법입니다. 단순하게 보면 백업&복구와 유사한 컨셉으로 볼 수 있지만 윈도우 설정이나 프로파일까지 그대로 옮길 수 있다는 것이 다릅니다.

Easy Transfer로 데이터를 옮기는 방법 3가지

Easy Transfer USB cable을 이용한 방법

: Old 컴퓨터(XP, Vista)와 New 컴퓨터(윈도우 7) 사이에 Easy Transfer USB cable을 연결해서 마이그레이션을 하는 방법입니다. 별도의 Easy Transfer USB cable이 있어야 하는 방법입니다.

[그림 1] Easy Transfer USB cable

Network를 이용한 방법

: Old 컴퓨터와 New 컴퓨터 사이 마이그레이션 할 데이타를 네트워크를 통해 전송하는 방법 입니다. Old 컴퓨터와 New 컴퓨터 모두 네트워크에 공존하고 있다면 간단하게 사용할 수 있는 방법입니다. 그러나 네트워크에 영향을 줄 수 있으므로

외장 하드디스크를 이용한 방법

: USB 메모리 혹은 디스크나 네트워크 공유를 이용해 직접 마이그레이션 할 파일을 저장했다가 새로 설치된 Windows 7에서 저장된 데이타를 풀어 놓는 방식 입니다.

[1] Windows XP에서 Easy Transfer 마이그레이션 실행 (외장 하드디스크를 이용한 방법)

*Easy Transfer를 실행하기 위해서는 Windows 7 설치 CD에 있는 Support\Migwiz 폴더에 가시면 migwiz.exe를 실행 합니다.

[그림 2, 왼쪽] migwiz.exe를 실행한 모습 [그림 3, 오른쪽] 마이그레이션 할 방법을 선택 할 수 있습니다. 여기서는 ‘외부 하드 디스크 또는 USB 플래시 드라이브’를 선택해 진행하도록 하겠습니다.

[그림 4, 오른쪽] 전송할 항목을 확인 합니다.

[그림 5, 오른쪽, 그림 6, 왼쪽] 아래 그림에서처럼 고급을 클릭하시면 필요한 파일폴더를 추가로 마이그레이션 항목에 추가할 수 있습니다.

[그림 7, 오른쪽] 보안을 위해 MIG파일을 이용하기 위한 암호를 설정 합니다. [그림 8, 왼쪽] 파일을 저장하고 나면 ‘파일 전송’이 완료 됩니다.

[2] Windows 7으로 마이그레이션

[그림 9, 오른쪽] 새로운 컴퓨터에서 마이그레이션 ‘This is my new computer’를 선택합니다. [그림 10, 왼쪽] 저장된 MIG 파일로 마이그레이션 작업을 ‘Yes’를 선택합니다.

[그림 11, 오른쪽] 새 컴퓨터에 옮길 계정과 파일들을 선택합니다 [그림 12, 왼쪽] 마이그레이션 중

[그림 13] 마이그레이션이 끝난 뒤 리포트를 볼 수 있습니다.

[그림 14] 로그 오프하고 나니 XP에 있던 계정들이 나타났습니다.

*그리고 작업 전에는 중요한 데이타 백업은 빼먹지 않는 센스~ :)

[참고문서]
Step-by-Step: Windows 7 Upgrade and Migration
http://technet.microsoft.com/en-us/library/dd446674.aspx

4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트

sankim — Thu, 21 May 2009 04:29:00 GMT

지난 ‘Windows 메모리 FAQ’에서 Windows 메모리에 대한 이야기를 드렸는데요, 특히 Windows 클라이언트의 4GB 제한에 대해서 여러분들의 아주 뜨거운(?) 반응이 있었습니다. 그래서 지난 번에 약속 드린 ‘Easy Transfer를 이용한 마이그레이션’은 다음 포스팅으로 미루고 오늘은 ‘4GB 제한의 진실, 32비트 Windows 클라이언트‘라는 주제로 Q&A 형식으로 이야기를 나누도록 하겠습니다.

Q1) 왜 Windows 클라이언트는 4GB까지만 지원하나요?

1. Windows XP가 처음 출시된 초기만 해도 4 기가 바이트(GB) 메모리라는 게 서버에서도 거의 사용되지 않는 고사양의 메모리였으므로 4GB를 이상 지원을 고려할 필요가 없었습니다. (당시는 일반적으로 사용하는 서버의 메모리가 512MB 혹은 그 이하였던 시절 이였습니다, 64MB 서버도… ^^)

2. Windows XP SP2가 출시될 시점에 윈도우 클라이언트도 4GB 메모리 필요성의 조짐이 보였습니다, 그래서 당시 Windows 개발팀에서는 윈도우 클라이언트에서 4GB 이상 메모리 지원을 검토하였습니다.

3. 그런데 윈도우 클라이언트에서 4GB 이상의 메모리를 관리(Memory Management)하면 블루스크린(Crash), 시스템 행(System Hang), 부팅이 되지 않거나 혹은 비디오 카드 같은 장치의 드라이버 문제로 장치를 인식하지 못하는 문제가 빈번하게 발생하는 것을 볼 수 있었습니다. (대부분 Memory corruption)

4. 원인은 윈도우 클라이언트를 위해 만들어진 3'rd Party 디바이스 장치 드라이버(Driver)가 4GB 이상 메모리 환경을 고려하지 않고 만들어졌기 때문에 발생한 문제였습니다.

5. 이런 장치 드라이버 호환성 문제를 피하기 위해 윈도우 클라이언트(XP, Vista, 7)에서는 4GB까지만 메모리 관리(Memory Management)를 할 수 있도록 한 것 입니다.

Q2) 4GB메모리가 전부 보이지(인식)되지 않고 3(.xx)GB 정도로 보여요, 왜 그런가요?

아래 그림은 제 Windows 7에서 시스템 정보(msinfo32.exe)를 실행시켜 얻을 결과입니다, 실제 설치된 메모리는 4GB지만 윈도우가 이용할 수 있는 실제 메모리는 3GB로 인식하고 있습니다.

하나 더 아래 그림은 작업 관리자에서 나타난 값입니다, 마찬가지로 실제 메모리를 3GB 정도만 인식하고 있는 것을 볼 수 있습니다.

결론부터 말씀 드리면 이 현상의 원인은 컴퓨터의 칩셋(Chipset)과 연결된 장치(비디오 카드, Lan 카드 같은)가 가지고 있는 메모리 때문에 실제 장착된 메모리보다 적게 나타나는 것입니다. 윈도우는 '실제 메모리'에 나타난 '전체' 크기 만큼의 메모리만 사용할 수 있므며(즉 위와 같은 경우에는 전체 4GB를 사용하지 못합니다) 이는 하드웨어 이슈 입니다. 이와 연관있는 디바이스 요소로는 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory 등이 있습니다.

[이유는 아래와 같습니다]

어려운 이야기가 될 수 있으니 쉬운 이해를 위해 먼저 아래 그림을 보시죠. 시스템이 시작할 때 Physical Address Map(이하 PAM)이라는 걸 만듭니다, PAM은 RAM과 각 장치들이 가지고 있는 메모리의 주소 정보로 일종의 '순서' 혹은 '차례'를 만들어 Windows에게 넘겨줍니다, 그러면 Windows는 PAM 범위의 메모리만 사용(Access) 할 수 있습니다.

그런데 PAM이 만들어 질때 메모리(RAM)만 가지고 만드는 것이 아니고 모든 종류의 장치가 가진 디바이스 메모리(비디오 카드, Lan 카드가 가지고 잇는 메모리를 칭함)까지 포함합니다, 처음에는 RAM만 가지고 PAM을 만들어 가다는 중간에 디바이스 메모리가 끼어들게 됩니다, 그러면 PAM 중간에 디바이스 메모리가 포함되고 다시 PAM에 추가되다만 나머지 RAM이 PAM에 추가 되는데 이때 추가된 RAM이 4GB 범위 밖에서 만들어집니다. x86 Standard Memory management Mode를 사용하는 32-bit Windows는 4GB 메모리 영역까지만 사용(Access) 할 수 있는데 디바이스 메모리 때문에 RAM이 4GB 범위 밖으로 밀려나 해당 범위의 메모리가 보이지 않게 되는 것입니다.

위 그림은 총 4GB메모리 환경에서 디바이스 메모리가 총 500MB이기 때문에 사용할 수 있는 총 메모리가 3.5GB로 줄어든 예입니다. 밀려난 500MB는 윈도우가 Access 할 수 없는 영역이기 때문에 사용할 수 없습니다. 이 이슈는 하드웨어에서 해결해야 할 이슈입니다. (이전에 사용한 '문제'라는 표현은 오해를 가져 올수 있어 '이슈'로 변경하였습니다, 여기서 하드웨어란 칩셋을 의미합니다 )

*참고로 32비트 Windows 서버 관련한 4GB 제한에 대한 이야기는 이전에 ‘누가 내 메모리를 훔쳤나?’라는 글로 포스팅한 적이 있습니다, 서버에 관심 있으신 분들은 참고로 읽어 보시기 바랍니다.

Q3) 정말 디바이스 장치들이 메모리 중간에 끼어 들어 메모리가 밀려났는지를 어떻게 해야 볼 수 있죠?

이전에 어떻게 해야 볼 수 있을까 고민 많이 했는데(디버거 봐야 하나.. 등등 ^^;) 의외로 장치 관리자(devmgmt.msc)에서 간단하게 보실 수 있었습니다. 아래 내용은 32비트 클라이언트뿐만 아니라 64비트와의 비교를 보여드리기 위해 제 테스트 머신에 듀얼 부팅으로 Windows Vista 32비트와 64비트를 설치해 테스트를 진행하였습니다.

32 비트 Windows 클라이언트

아래 그림은 32비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB를 장착했지만 전체가 3.3GB정도가 나옵니다.

그렇다면 ‘작업 관리자’가 말하는 Windows가 실제 인식한 Physical Memory 범위는 어떤 모습일까요? 아래 그림은 Meminfo.exe를 이용하여 Windows가 실제 인식하는 Physical Memory 범위를 출력한 결과입니다. (meminfo는 전에 소개해 드렸던 Windows Internals 5’th Edition을 쓴 Alex Ionescu가 만들었습니다)

메모리를 표기할 때 16진수로 표현하고 이를 00000000~FFFFFFFF로(0MB에서 4GB)로 표현합니다. 위 결과를 보시면 Physical Memory 범위가 ‘00001000~0009F000’과 ‘00100000~CFDFF000’ 두 범위로 나눠져 있으며 대략 3.4GB 정도의 크기 입니다.

그럼 두 범위에 중간에 빠진 ‘0009F000~00100000’과’CFDFF000~FFFFFFFF’ 사이 영역은 왜 Windows에서 인식하지 못한 것 일까요? 앞에서 말씀 드렸듯이 디바이스가 해당 영역을 점유해 윈도우가 사용(Access)할 수 있는 메모리가 아니기 때문입니다.

디바이스가 점유한 모습은 ‘장치 관리자(devmgmt.msc)’를 통해 확인 하실 수 있습니다, ‘장치 관리자(devmgmt.msn) > 보기 > 리소스(연결별) > 메모리’를 선택합니다, 그러면 아래 그림과 같이 비디오 카드 Radeon X13000이 ‘D0000000~DFFFFFFF’(대략 268MB)과 ‘FE900000~FEAFFFFF’(대략 2MB) 영역, 즉 Physical Memory 범위에서 제외되었던 곳에 자리 잡고 있음을 확인 할 수 있습니다.

32비트에서는 4GB에서 밀려난 메모리를 볼 수 없습니다, 그럼 밀려난 나머지를 보기 위해 우리 64비트를 살펴보도록 하죠~

64비트 Windows 클라이언트

아래는 64비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB 모두 보입니다.

Meminfo로 본 Physical Memory 범위입니다, 64비트라 Address 범위부터가 다르죠? Memory Address가 4GB를 넘고 메모리 또한 4GB 범위 모두 나타납니다.

장치 관리자에서 본 모습입니다.

32비트에서 본 것과 마찬가지로 위 빨간 박스의 부분은 268MB정도 되고 아래가 2MB정도가 됩니다. 중간에 비디오 카드가 끼어 들었지만 4GB 이후 주소인 '0000000100000000~000000012C000000(실제 메모리 5GB 쯤의 자리)'에서 나머지 720896KB(대략 720MB)를 인식한 것을 볼 수 있습니다. 즉 디바이스가 메모리를 4GB 영역 밖으로 밀어냈다고 해도 128GB까지 인식하는 64bit Addressing 때문에 문제없이 모든 Physical Memory가 보입니다.

처음에 드렸던 예로 이런 상황에서 64비트를 그림으로 표현 하면 아래와 같습니다.

Q4) 그럼 32비트 클라이언트가 4GB 이상을 사용(Access, Addressing)하려면 어떻게 해야 할까요?

정답은 32비트 클라이언트는 4GB 이상을 사용할 수 있는 방법이 없습니다, 4GB 이상 메모리의 사용이 필요하다면 64-bit Windows 클라이언트를 사용하십시오.

현재는 32-bit 환경에서 64-bit 환경으로 넘어가기 위해서는 우선 64비트로의 인식전환이 필요할 것입니다. 다음으로 64비트 전용 응용프로그램들이 많이 나와야 할 것 입니다, 32비트 응용프로그램을 에뮬레이션 하기 위한 WOW 64 Subsystem이 있기는 하지만 모든 응용프로그램에 호환성을 보장하지 않고 32비트 응용프로그램 구조상 64비트 Windows에서 실핼 할 때 64비트가 제공하는 무한(?)한 메모리를 이용할 수 없는 제한이 있습니다.

*64비트 윈도우와 응용프로그램에 대한 이야기는 예전에 포스팅 한 글이 있습니다, 읽어 보시고 추가적인 이해에 도움이 되셨으면 합니다.

Windows 64bit Computing에 대한 오해 혹은 잘못된 상식
http://blogs.technet.com/sankim/archive/2007/12/28/windows-64bit-computing.aspx

Q5) Windows XP를 보면 PAE를 지원하는데 이는 XP도 PAE를 사용하면 4GB 이상을 사용할 수 있다는 의미 아닌가요?

Windows XP SP2 부터 나온 DEP(Data Execution Prevention)를 사용하기 위해서는 기본적으로 PAE가 활성화(Enable)되어 있어야 합니다, 그래서 PAE 기능을 활성화 할 수 있도록 한 것입니다. 이는 Windows Kernel에서 32bit에서는 존재하지 않는 64bit PTE table의 field를 이용하기 때문입니다.

To use these processor features, the processor must be running in Physical Address Extension (PAE) mode. However, Windows will automatically enable PAE mode to support DEP. *해당 문서를 보시려면 여기를 클릭하세요.

참고로 PAE를 활성화 하는 경우와 반대의 경우 윈도우가 시작 시 로드하는 커널 파일은 아래와 같습니다.

CPU 수에 따른 환경	기본	PAE 활성
Uniprocess(단일 CPU)	Ntoskrnl.exe	Ntkrnlpa.exe
Multiprocess(다중 or 코어 CPU)	Ntkrnlmp.exe	Ntkrpamp.exe

Q6) 번 외 질문인데요, 도구마다 메모리 측정 결과가 각기 조금씩 다른 경우가 있어요 왜 그렇죠?

위 그림에서 작업관리자는 3.3인데 왜 meminfo는 3.4냐고 반문하실 수도 있습니다 또한 제가 종종 받는 질문 중 하나가 작업 관리자에서 ‘사용가능’ 항목과 성능 모니터에서 ‘Available %메모리%’의 값이 다르다는 것입니다. 이는 각 도구마다 메모리를 계산하기 위한 항목 수집 기준이 조금씩 달라서입니다, 크게 차이가 나는 것이 아니므로 이번 포스팅에서는 무시하셔도 좋습니다. 언제 작업 관리자에 나온 항목에 대한 자세한 설명을 드리겠습니다. (약속만 드리고 지키지 못하는 것들이 많지만 이번 약속은 꼭!!)

그럼 여러분 좋은 하루 되세요~

* 이전에 댓글에 추가로 명시 했습니다만 '장치 메모리', 혹은 'MMIO'라고만 명시 한것에 대해서 모호하다는 의견이 있어 본문 내용과 하단 부분에 함께 추가 합니다. ^^ 4GB 전체 사용하지 못하는 이슈에 영향을 끼치는 디바이스 요인으로 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory *등(헥헥헥..)이 있습니다. 그러나 말씀안드려도 이들 모두 '장치 메모리'의 범주 임을 알 수 있는 센스~!

[참고자료]
Pushing the Limits of Windows: Physical Memory, Written by Mark Russinovich *이번 포스팅의 대부분의 아이디어가 이 글에서 나왔습니다, 꼭 한번 읽어 보시기 바랍니다.
Windows Internals, Chapter 7 Memory Management
Intel 64 and IA-32 Architectures Software Developer’s Manual, Intel 64 and IA-32 Architectures

윈도우 XP, Vista에서 윈도우7으로 업그레이드

sankim — Sun, 17 May 2009 18:45:00 GMT

안녕하세요? sankim입니다, 오늘은 XP, Vista에서 윈도우7으로 업그레이드에 대한 말씀을 드리겠습니다.

[버전별 업그레이드&마이그레이션]

버전	업그레이드	마이그레이션
Windows XP	지원안함(X)	지원(O)
Windows Vista	지원안함(X)	지원(O)
Windows Vista SP1 이상	지원(O)	지원(O)
Windows 7 Beta	지원안함(X)	지원(O)

위 표에서 업그레이드와 마이그레이션의 의미는 아래와 같습니다

업그레이드(Upgrade): Vista에서 Windows 7 설치 CD를 넣고 ‘업그레이드’를 클릭해서 Windows 7을 설치하는 과정, 이전에 설치되어 있던 응용프로그램이나 파일 그리고 설정이 그대로 남아 있다.

마이그레이션(Migration): 이전 버전의 컴퓨터에 있던 데이타와 설정을 별도로 제공되는 도구를 이용해 Windows 7 컴퓨터에 옮기는 작업.

[1] Windows Vista에서 Windows 7으로 업그레이드

Windows Vista에서는 업그레이드가 지원되지 않습니다, Windows Vista에 서비스팩 1이상이 설치된 환경에서 직접 업그레이드를 지원합니다. 그러므로 현재 사용하는 Vista에서 Windows 7 설치 CD를 넣고 설치 과정 중 '업그레이드’를 클릭하시면 바로 Windows 7으로 업그레이드가 됩니다.

* 업그레이드는 반듯이 동일 Edition 사이에서만 가능합니다, 예를 들면 Windows Vista Ultimate였다면 동일한 Windows 7 Ultimate으로만 가능합니다.

[2] Windows XP에서 Windows 7으로 업그레이드

Windows XP에서 바로 Windows 7으로 직접 업그레이드하는 방법은 지원하지 않습니다, Windows 7 설치 CD를 넣고 업그레이드를 선택하시면 아래 그림 같이 윈도우 XP에서 윈도우 7으로 바로 업그레이드(Directly Upgrade)할 수 없다는 메시지와 함께 작업이 종료 됩니다.

XP에서 Windows 7 업그레이드를 위해 아래와 같은 두 가지 방법이 있습니다.

1. 이전 데이타를 Easy Transfer 혹은 USMT 4.0를 이용해 마이그레이션 하는 방법

2. 현재 사용하는 XP를 Vista로 업그레이드 한 뒤 Windows 7으로 업그레이드.

[3] Windows 7 Beta에서 Windows 7으로 업그레이드

XP와 동일하게 직접 업그레이드를 지원하지 않습니다, 7 Beta는 RC나 정식 RTM으로 새로 설치 하셔야 합니다.

다음 포스팅에서는 Easy Transfer를 이용해 윈도우 XP, 7 Beta에서 Windows 7으로 마이그레이션 하는 방법을 설명 드리도록 하겠습니다.

드디어 Windows Internals 5’th 출간!

sankim — Wed, 13 May 2009 14:19:50 GMT

오늘 talee 군이 먼저 찾아내어 포스팅 한 것을 낼름 배껴(:P) 소개 합니다.

드디어 Windows Internals 5’th Edition이 나왔습니다. Windows Internlas는 Windows Kernel에 관심이 있는 분들에게는 바이블과 같은 책으로써 Windows의 내부 구조에 대해서 가장 정확하게 설명 했습니다. 아직 판매는 되지는 않고 있으나 곧 판매될 예정입니다.

오늘은 그래서 지금까지 나온 Windows Internals 시리즈를 둘러보겠습니다.

Inside Windows NT: 1993년에 Inside Windows NT라는 이름으로 Helen Custer가 집필 했습니다. (바쁜 개발자들에게 내부 구조에 대한 정보를 얻느라 많이 힘들었던 듯 합니다)

Inside Windows NT 2’th: 윈도우의 아버지 Dave Cutler는 그의 DEC 시절 그의 제자(?) 였던 David Solomon에게 Windows Source Code를 Access할 수 있도록 ‘허’하였고 이렇게 해서 Solomon이 단독으로 쓴 Inside Windows NT 두번째판이 1998년에 출간 되었습니다. Windows NT에 대해서 주로 다뤘고 곧 나올 예정이던 Windows 2000에 대한 내용이 Windows NT 5.0이라는 Chapter로 추가 되었었습니다. 멋도 모르고 제가 처음 샀던 책인데 그때는 책을 읽고 이해했다기 보다는 글씨가 몇개인지 세는 수준이였습니다.

Inside Windows 2000 3’th: 2001년에 출간 되었고 새로 출시 되었던 Windows 2000을 중심으로 다뤘습니다. 이번에는 David Solomon이 그의 제자(?)였던 Mark Russinovich와 책을 썼습니다. 이때 Solomon이 코드를 보고 책을 쓰면 Mark는 그것을 다시 한번 확인 하는 과정을 거쳤다고 합니다. 현재 Mark Russinovich는 마이크로소프트에서 Technical Fellow라는 직책으로 일하고 있습니다. 2년 전 직접 Mark와 Solomon을 만나서 이야기도 나눠본 경험이 있습니다. 그런데 이때 표지에 나와있는 Mark의 사진을 보면 Solomon 못지 않은 살집이 보입니다, 사진이 잘못 나왔거나 다이어트를 한 것이 아닌가라는 생각이..

Windows Internals 4’th: 2005년에 출간된 네번째 판부터는 Windows Internals라는 이름으로 변경되어 출간 됩니다. Windows 2003과 XP에 대한 내용이 추가 되었습니다. 개인적으로 가장 열심히 본 책이기도 합니다. (이전에 잃어 버려서 다시 구매할 때 눈물을 흘렸던 기억이…)

Windows Internals 5’th: 이번 5’th에서는 Windows Server 2008과 Vista에서의 기술을 설명하였습니다, 그리고 이번 판에서는 새로운 인물이 보입니다, Alex Ionescu라고 하는 젊은 친구입니다, 2년 전에 시애틀에서 만난 본사 개발자가 요즘 Solomon이 데리고 다니면서 키우는 19살 짜리 친구가 있는데 얼마 전 본사 개발자들을 상대로 강의를 했다’는 이야기를 들었는데 그 친구가 바로 Alex더 군요, 천재란게 있기는 한가 봅니다.. 참고로 Solomon은 이미16살 때 DEC에서 Dave의 VMS팀에서 일 했습니다, 진짜 천재.

이번 5’th에서는 오타 혹은 내용의 모호성을 철저히 차단하고자 수많은 Reviewer들이 참여해 높은 Quality의 책을 만들어냈습니다.

여기를 누르시면 발간에 대한 ‘감사의 말’을 보실 수 있습니다. Reviewer 명단에 저의 Master의 이름이 보이네요 ^^ khK 수고 많으셨습니다!