ISO 파일이 CD/DVD 이미지의 대표 형식인 것 처럼, VHD 파일은 가상 하드디스크 이미지 파일이다. 즉 VHD 파일은 그 안에 하드디스크를 포함하고 있는 이미지 파일이며, 운영체제의 부팅도 가능하다. Windows 7과 Windows Server 2008 R2에서는 VHD 파일에 포함된 운영체제로부터 바로 부팅 가능하다. 따라서 사용 중인 운영 체제를 VHD 파일로 만들어 USB 저장 장치나 외장 하드에 넣어 들고 다니다가, Windows 7이 설치된 다른 시스템에서 얼마든지 부팅 가능하다.
자세한 방법은 다음 3개의 링크 참조
Windows 7 설치에 사용되는 WinPE image인 Boot.wim(또는 WinPE.wim, WinRE.wim 등)을 Windows 7 부팅 메뉴에 추가하는 방법입니다.
다음 예는 Windows 7이 C: 드라이브에 설치되어 있고, D: 드라이브에 Boot.wim 파일과 Boot.sdi 파일을 위치 시켰을 경우의 예입니다.
1. 먼저 준비한 Boot.wim과 Boot.sdi 파일을 D: 드라이브의 Root 디렉토리로 복사한다.
2. 다음 내용의 script를 CMD 파일로 만든다.
@echo off
pushd %~dp0
bcdedit /create {ramdiskoptions}
bcdedit /deletevalue {ramdiskoptions} description
bcdedit /set {ramdiskoptions} ramdisksdidevice partition=D:
bcdedit /set {ramdiskoptions} ramdisksdipath \boot.sdi
bcdedit /create /d "WinPE Boot" /application OSLOADER > GUIDTEMP.TXT
for /F "tokens=1" %%B in ('findstr { GUIDTEMP.TXT') do (
bcdedit /set %%B device ramdisk=[D:]\boot.wim,{ramdiskoptions}
bcdedit /set %%B osdevice ramdisk=[D:]\boot.wim,{ramdiskoptions}
bcdedit /set %%B path \windows\system32\winload.exe
bcdedit /set %%B systemroot \windows
bcdedit /set %%B winpe yes
bcdedit /set %%B detecthal yes
bcdedit /set %%B ems yes
bcdedit /displayorder %%B /addlast
bcdedit /timeout 2
del GUIDTEMP.TXT
)
3. 명령 프롬프트(Command Prompt) 창을 관리자 권한으로 실행한 후, 위 2단계에서 만든 CMD 스크립트를 실행한다.
Windows® 7용 Windows® 자동 설치 키트(AIK)가 있으면 Microsoft Windows® 7 및 Windows Server® 2008 R2 운영 체제 제품군을 쉽게 설치, 사용자 정의 및 배포할 수 있다.
Windows® 자동 설치 키트(Windows AIK)는 Windows® 운영 체제의 구성과 배포를 도와주는 일련의 도구와 문서로 이루어져 있다. Windows AIK를 사용하면 Windows 설치를 자동화하고, ImageX를 통해 Windows 이미지를 캡처하고, 배포 이미지 서비스 및 관리(DISM)를 사용하여 이미지를 구성 및 수정하고, Windows PE 이미지를 만들고, 사용자 환경 마이그레이션 도구(USMT)를 통해 사용자 프로필과 데이터를 마이그레이션할 수 있다.
Windows AIK를 설치하려면 먼저 ISO를 다운로드하고, DVD 버닝 도구를 사용해 ISO 파일을 DVD에 기록한 다음 이 DVD를 사용하여 Windows AIK를 설치해야 한다.
앞서 게재한 <CopyProfile> 문제와 관련이 있기에, Microsoft KB947243에 올라와 있는 내용을 다음과 같이 참조합니다.
[문제 설명]
Windows Vista 또는 Windows Server 2008 감사 모드에서 휴대용 컴퓨터에서 실행 중인 경우 Num Lock 키는 항상 켜져 있습니다.
다음 시나리오 중 하나에서 이 문제가 발생합니다.
감사 모드에서 Windows Vista 또는 Windows Server 2008 시작되는 무인 설치를 수행할 수 있습니다.
Windows Vista 또는 Windows Server 2008에서 부족 상자 환경 (OOBE) 마법사를 실행할 때 눌러 감사 모드로 시도하려면 Ctrl + Shift + F3을 누릅니다.
참고 숫자 패드로 문자 키가 표시되어 있기 때문에 이 문제가 발생합니다.
[원인]
InitialKeyboardIndicators 레지스트리 항목의 값이 2로 설정되어 있기 때문에 이 문제가 발생합니다. Num Lock 기능이 켜져 있는지 2 값을 나타냅니다. 이 값은 감사 모드에서 사용되는 관리자 프로필이 저장됩니다. 기본 프로필 및 사용자 계정을 관리자 프로필을 true로 설정된 태그 CopyProfile 값을 복사할 경우. 따라서 "문제 설명" 절에서 설명한 문제가 발생합니다.
[시나리오 1에 대한 해결 방법]
Unattend.xml 파일을 열고, 찾고 있는 <settings pass="auditUser"> 태그와 설정한 다음 해당다음 명령을 실행하여 RunSynchronous 명령:
Unattend.xml 파일 RunSynchronous 명령을 실행하면 다음과 유사한.
<settings pass="auditUser">
<component name="Microsoft-Windows-Deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="<http://schemas.microsoft.com/WMIConfig/2002/State>" xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>">
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Order>1</Order>
<Path>cmd /c reg copy "HKEY_USERS\.DEFAULT\Control Panel\Keyboard" "HKEY_CURRENT_USER\Control Panel\Keyboard" /s /f</Path>
<Description>Numlock Workaround</Description>
</RunSynchronousCommand>
</RunSynchronous>
</component>......이 해결 방법은 올바른 값을 초기 관리자 프로필을 기본 사용자 프로필을 복사합니다. 이러한 값은 InitialKeyboardIndicators 레지스트리 항목은 설정합니다. 이 레지스트리 항목은 키보드 동작을 제어합니다.
[시나리오 2에 대한 해결 방법]
이 문제를 해결하려면 자동으로 해결 링크를 누르십시오. 그런 다음 실행파일 다운로드 대화 상자에서 클릭하고 이 마법사의 단계를 따릅니다.
Microsoft Fix it 50111
중요한 이 섹션에서는, 메서드 또는 작업이 레지스트리 수정 방법을 알려 주는 단계가 포함되어 있습니다. 그러나 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수 있습니다. 따라서 다음 이 단계를 주의 깊게 따라야 합니다. 추가 보호 기능을 수정하기 전에 레지스트리를 백업해야. 그런 다음 문제가 발생할 경우 레지스트리를 복원할 수 있습니다. 백업 및 복원하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
이 문제를 해결하려면 다음과 같이 하십시오.
Windows Deployment 방법으로 Windows Vista부터는, Unattend.txt 포맷에서 Unattend.xml 포맷의 설치 방법으로 변경되었다. 또한 Unattend.txt 보다 더 많은 설정 옵션들이 추가되었다. 그 중에서 <CopyProfile> 옵션에 대한 중요한 정보를 이 글을 보시는 분들께 알려드리고자 한다.
<CopyProfile> 옵션의 사용 용도는 여기에 자세히 설명되어 있다. Deployment 대상 대표 모델에서 Deployment Master 설치본을 만든 후, 동일 모델의 복제(clone) 시스템들에 대해 Master 설치본을 복사한 이후, 개별 사용자에 대한 각 개인의 고유 설정을 마무리함으로써 최종 Windows 설치를 마무리하게 된다.
Master 설치본 제작 시에 Administrator라는 최상위 관리자 계정으로 Windows 로그온 한 뒤, 각종 장치 드라이버 설치, 각종 공통 사용 프로그램 설치 및 각종 설정 값을 최적화하는 작업을 진행하게 된다. 동일 모델의 clone 시스템들이 최종 사용자에게 배달되면, 최종 사용자는 개인 고유의 Windows 사용 정보를 설정하게 되고(대표적인 것이 사용자 계정과 네트워크 그룹 내의 PC 이름 등을 설정하게 됨), 자신이 직접 입력한 사용자 이름으로 새로운 사용자 계정을 만들어 Windows를 사용하게 된다.
<CopyProfile> 옵션의 사용 목적은 Master 설치본 제작 시 로그온 한 Administrator 계정에서 설정한 모든 설정 값들을, 새로운 사용자 계정 생성 시 사용자가 직접 입력하는 정보 이외의 기타 Windows 설정 값을 Administrator 계정에서 변경한 설정한 값과 동일하게 복사할 목적으로 사용한다.
이 <CopyProfile> 옵션 사용 시 Microsoft가 인정하는 않는 다음과 같은 제약 사항이 있다.
절대 Autounattend.xml 파일 안에 <CopyProfile> 옵션을 사용해서는 안 된다. 본인의 테스트에서 2가지 심각한 버그가 발견되었는데, 그 중 1가지는 Windows 설치 후 로그 온 시, 한글 키보드에서 무조건 [Num Lock] 키가 ON 된다. 특히 노트북 사용자에게는 아주 치명적이다. 둘째, CD/DVD 드라이브에 미디어를 넣었다가 꺼낸 후, [컴퓨터 관리]의 [디스크 관리]를 접근하면 CD/DVD 드라이브에서 꺼낸 미디어를 넣으라는 오류 메시지가 지속적으로 나오고, 미디어를 다시 넣을 때까지는 이 상황을 빠져나갈 수 없다.
<CopyProfile>을 올바른 목적으로 사용하기 위해서는, Autounattend.xml로 Windows 설치를 모두 완료한 후, <CopyProfile>만 포함된 개별 Unattend.xml 파일을 만들어 놓은 후 필요한 각종 설정 값들을 모두 변경한 후, 다음과 같은 방법으로 개별 Sysprep 명령을 실행해 주어야 한다. 이 때 Sysprep(시스템 준비 도구) 창이 이미 실행되어 있는 상황에서는 Sysprep 명령어가 작동하지 않으므로, 반드시 Sysprep 창을 닫고 다음 방법을 적용해야 한다.
CopyProfile to true in the Unattend.xml file that you will use with Sysprep in the next step.Microsoft-Windows-Shell-Setup | CopyProfile
sysprep /generalize /unattend:unattend.xml to copy the customized user profile settings over the default user profile.XML Example
<CopyProfile>true</CopyProfile>
[주의 사항]
1. Windows 7을 Administrator 계정으로 자동 설치하는 Autounattend.xml 설정 중에
<Themes> 설정은 포함되지 않아야 함.
2. <CopyProfile> 설정을 Autounattend.xml 안에는 절대 사용하지 말 것.
<CopyProfile> 옵션 사용 시, 첨부 xml 파일을 참조 바랍니다. (32비트 Windows 7용임)
|
Windows 7을 기반으로 새로운 프로그램을 개발할 때 참고해야 할 개발자 가이드입니다.
|
Windows Server 2008 최대 사용 가능 메모리
32-bit의 경우 PAE를 Enable 했을 때 최대 메모리
|
Version |
32-bit |
64-bit |
|
Windows Server 2008 Datacenter |
64 GB |
2 TB |
|
Windows Server 2008 Datacenter (Server Core) |
64 GB |
2 TB |
|
Windows Server 2008 Enterprise |
64 GB |
2 TB |
|
Windows Server 2008 HPC Edition |
N/A |
128 GB |
|
Windows Server 2008 Standard |
4 GB |
32 GB |
|
Windows Server 2008 for Itanium-Based |
N/A |
2 TB |
|
Windows Web Server 2008 |
4 GB |
32 GB |
Windows Vista 최대 사용 가능 메모리
|
Version |
32-bit |
64-bit |
|
Windows Vista Ultimate |
4 GB |
128 GB |
|
Windows Vista Enterprise |
4 GB |
128 GB |
|
Windows Vista Business |
4 GB |
128 GB |
|
Windows Vista Home Premium |
4 GB |
16 GB |
|
Windows Vista Home Basic |
4 GB |
8 GB |
|
Windows Vista Starter |
1 GB |
N/A |
Windows Home Server 최대 사용 가능 메모리
Windows Home Server 는 32-bit edition만 있으며, 4GB가 최대 사용 가능 메모리
Windows XP 최대 사용 가능 메모리
|
Version |
32-bit |
64-bit |
|
Windows XP |
4 GB |
128 GB |
|
Windows XP Starter Edition |
512 MB |
N/A |
Windows 2000 최대 사용 가능 메모리
|
Version |
32-bit |
|
Windows 2000 Professional |
4 GB |
|
Windows 2000 Server |
4 GB |
|
Windows 2000 Advanced Server |
8 GB |
|
Windows 2000 Datacenter Server |
32 GB |
*Windows 2000은 64-bit 버전이 없다.
‘시스템 속성 > 성능 > 설정 > 성능 옵션 > 고급 > 프로세서 사용 계획’에 ‘프로그램’과 ‘백그라운드 서비스’ 옵션 두 가지 중 하나를 사용자가 선택할 수 있다. [아래 그림 참조]
대부분 이 옵션에 대해서 아래와 같이 잘못 이해하고 있다.
{‘프로그램’은 실제 사용자가 실행하는 응용 프로그램이고 ‘백그라운드 서비스’는 ‘서비스 관리자(services.msc)’에서 실행되는 서비스를 의미한다. 그래서 설정에 의해 사용량을 할당 조정한다.}
하지만 이는 잘못된 해석이다.(또한 다이얼로그 창의 표시 문구가 충분히 오해를 불러올 수 있다?)
이 옵션을 이해하기 위해서는 먼저 스레드(Thread)와 컨텍스트 스위치(Context Switch) 두 가지 개념을 이해해야 한다.
프로그램이란 것은 실행 파일이 프로세스(Process)로 만들어 진 후 스레드(Thread)에서 명령이 실행되는 구조이다. 스레드란 명령어가 CPU를 사용하여 실행되는 단위로 정의 할 수 있다.
컴퓨터를 사용할 때 네트워크 처리, HDD 처리, 커널에서의 작업, 응용프로그램 처리 등등 너무나도 많은 작업들이 동시 다발적으로 이뤄지고 있다. 다른 예로, 사용자가 인터넷에서 파일을 다운로드 하면서 Word와 WMP를 함께 사용하는 경우도 생각해 볼 수 있다. 이러한 것들은 모두 스레드 단위로 작업이 이뤄지며 작업에 따라 스레드 처리 시간이 길수도 짧을 수도 있다.
일상 생활에서도 금방 끝나는 일이 있고 오래 걸리는 일들이 있듯이 스레드도 처리 하는데 시간이 긴 작업과 짧은 작업들이 섞여 있는데, 만약 아래 그림처럼 CPU에서 하나의 스레드가 끝날 때까지 다른 스레드들은 기다려야 한다면, 스레드 A가 끝날 때 까지는 스레드 B, C는 기다리고만 있어야 한다.
좀더 효율적으로 동시 작업이 가능 하도록 하나의 스레드가 시작해서 끝날 때까지 무작정 CPU를 사용하는 것이 아니고 아래 그림 처럼 스레드의 실행 시간을 짧은 시간 단위로 잘라낸 뒤 순서대로 세워 놓고 실행하다가, 자신에게 할당된 시간이 끝나면 하던 일을 멈추고 다음 스레드에게 CPU를 사용할 수 있도록 한 뒤 다시 자기 차례가 돌아오면 자신의 일을 다시 시작한다. 스레드가 CPU를 얼마 동안 사용할지를 정의한 시간 단위를 바로 퀀텀(Quantum)이라고 합니다. 그러면 스레드 B는 다음 순번에서 바로 작업을 끝낼 수 있다.
이 퀀텀을 사용자가 길게도 혹은 짧게도 설정 할 수 있는데 이것이 바로 ‘프로세스 사용 계획 옵션’이다. ‘프로그램’으로 설정하면 모든 스레드의 퀀텀을 짧게(6, 대략 2 Click) 설정하고, 반대로 ‘백그라운드 서비스’로 설정하면 길게(36, 대략 12 Click) 설정한다.
2가지의 차이와 장단 점을 이해하려면, Context Switch를 먼저 이해해야 한다.
위 그림과 같이 퀀텀에 정의된 시간이 끝나 CPU를 떠나야 하는 스레드 A는 CPU를 떠나기 전에 자신이 어디까지 작업을 했는지를 저장한다. 그래야 다음 차례에 다시 A가 실행될 때 앞에서 마지막으로 진행했던 부분부터 다시 시작 할 수 있기 때문이다. 또한 B는 자신이 앞에서 실행 했던 부분부터 다시 시작 하기 위해 앞에서 저장했던 실행정보를 불러오는데, 바로 이런 일련의 작업을 컨텍스트 스위치(Context Switch)라 한다.
이 Context Switch 자체는 미약하지만 전체적으로 보면 성능에 영향을 줄 수 있는 작업입니다. 그래서 만약 다른 작업은 거의 없고 CPU에서 스레드를 처리하는데 긴 시간이 필요한 단일 응용프로그램(SQL Server 혹은 그래픽 랜더링 작업 같은)만 실행하는 환경이라면, ‘백그라운드 서비스’로 설정해 Context Swith를 최소화하고 해당 프로그램의 스레드가 긴 시간 CPU를 사용 할 수 있도록 하는 것이 효과적이다.
반대로 일반 사용자의 컴퓨터 사용 패턴은 아주 소소한 아이콘 클릭 같은 작업을 포함해 IE같은 웹 브라우저 사용과 함께 음악을 듣는 것과 같이 동시에 여러 프로그램을 실행하는 패턴을 보이는데, 이런 경우 스레드에 긴 시간을 주면 스레드가 끝나기를 기다리는 시간이 오래 걸리기 때문에 다른 작업으로 넘어가는데 시간이 걸려 반응속도를 늦출 수 있다. 따라서 일정한 시간 내에 여러 스레드들이 실행 될 수 있도록 잦은 Context Switch 시간의 부하를 감수하더라도 퀀텀을 작게 설정하여, 사용자 측면에서 반응속도를 높일 수 있다.
그래서 두 옵션은 아래와 같이 정의 할 수 있습니다
프로그램: 여러 작업을 동시에 수행하는 일반 사용자 환경에서 반응 속도를 높여준다.
백그라운드 서비스: 계속해서 한가지 작업을 하는 응용프로그램을 실행 하는 경우. 처리 효율을 높인다.
[출처: Sankim's Blog ]
시간이 갈수록 WinSxS 폴더의 크기가 커지는 이유와 그 해결 방법에 관한 내용이다.
Servicing이란?
Windows Vista 이전에는 보안 업데이트나 BugFix를 위해 시스템을 업데이트를 하면, exe나 dll 같은 시스템 파일이나 레지스트리 값들을 각 파일 단위로 업데이트 하였다. 그러나 Vista부터는 Servicing이라는 새로운 Component 관리 메커니즘을 통해 파일, 레지스트리 값, 서비스, Generic Command, Dependencies, Category를 묶어 하나의 Component 단위로 관리한다. 그리고 이런 여러 Component들을 하나로 묶은 것을 Deployment라고 하며, 또 이 여러 Deployment들을 하나로 묶은 것을 Package라고 한다. 윈도우 업데이트가 이뤄질 때 각각의 Component 단위로 이뤄지는 것이 아니라 Package 단위로 이뤄진다. 그리고 WinSxS 폴더는 이 Component를 모아 저장해둔 공간이므로 Component Store라고 부른다.
Servicing이 적용된 Vista 이후부터는 Windows가 처음 설치 될 때 윈도우 설치 미디어에 들어 있는 모든 시스템 파일들을 Component Store(WinSxS 폴더)에 넣고 설치 작업을 진행한다. 그래서 새로운 기능을 설치 하거나 SFC(System File Checker)를 실행 할 때, 이전 버전 같이 윈도우 설치 CD를 넣으라는 메시지 박스가 나타나지 않는다. 처음 Windows를 설치 할 때나 혹은 시스템 업데이트를 할 때, WinSxS 폴더에서 필요한 Component를 Windows 시스템 폴더(예. C:\Windows)에 연결되도록 하드링크를 만들어, 시스템이나 사용자가 액세스 가능한 상태를 Projection이라고 하며, 반대로 파일이 WinSxS 폴더에 저장되어 있지만 사용하지 않는(하드링크가 되어 있지 않는) 상태를 Stage라고 한다.
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 폴더의 크기는 끊임 없이 커져만 가는 걸까?
WinSxS 폴더에 있는 파일에 Windows 폴더에서 액세스 가능한 하드링크가 생성된 것이며 WinSxS 폴더에 있는 파일이 Windows 폴더에 있는 파일들과 중복되는 것이 아니며 WinSxS폴더에 있는 하나의 파일이 Windows 폴더의 파일로 1:1로 매치 된다는 의미 인데, 아래 그림을 보면 Win32k.sys의 경우 여러 버전 별로 각각 존재하는 것을 볼 수 있다.
Servicing은 새로운 Update가 있으면 새로운 업데이트를 다운로드 한 뒤 이전 버전의 Component는 그대로 Component Store(WinSxS 폴더)에 남겨둔 채 다운로드 받은 새로운 Component를 사용(Projection)한다. 아래 그림에서 보는 것처럼 만약 동일한 Component로 새로운 Update가 나오면 새 Update가 나올 때 마다 WinSxS에 Component들이 쌓이게 된다.
게다가 배포되는 Package안에는 각 서비스팩 버전 별로 각기 다른 버전의 Component가 들어 있어 그 크기는 더욱 커져 간다. 예를 들어 A라는 업데이트가 하나 있다면, Package 안에는 Windows Vista RTM 버전, SP1 버전, SP2 버전에 맞는 업데이트 세가지를 모두 담고 있다. 즉 업데이트 A를 설치 하면 WinSxS에 RTM, SP1, SP2버전의 파일들을 모두 WinSxS 폴더에 저장해 두고 현재 윈도우 서비스팩 버전에 맞는 Component를 Projection 시키고 나머지 파일들은 Stage한다. 그래서 새로운 업데이트가 나올수록 WinSxS 폴더의 크기는 커져가는 것이다.
그럼 왜 이런 구조가 필요한가?
Servicing이 지난 버전 혹은 상위 서비스팩 버전의 Component 들까지 저장하고 있는 구조는 언뜻 보면 불합리해 보일 수도 있지만 이러한 메커니즘은 가능한 최신의 Component를 유지하게 한다. 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를 실행 하는 것이다. 이 2가지 명령은 현재 컴퓨터에 설치된 서비스팩 이전의 Component들을 WinSxS 폴더에서 안정적으로 삭제한다. 즉 현재 컴퓨터에 설치된 서비스팩 이전 버전의 Stage된 파일들을 제거해 디스크 공간 확보할 수 있는 방법이다. 단 이 명령을 실행하면 서비스 팩을 제거 할 수 있는 옵션도 사라지고 해당 서비스팩 이전 상태로는 돌아 갈 수 없다.
[출처: Sankim's Blog ]
WinSxS 폴더를 열어서 확인해 보면 안에 있는 파일들이 모두 Windows(일반적으로 C:\windows)폴더에 있는 파일과 동일한 파일인 것을 확인 할 수 있다. 이것은 Windows 폴더에 있는 시스템 파일들이 원래는 WinSxS에 기본 경로가 있었고 윈도우가 설치 되면서 Windows 폴더에다 하드링크를 생성한 것이다. 그래서 시스템이나 사용자는 Windows\system32에 연결된 하드링크 된 파일을 이용하는 것이다.
아래 그림에서처럼 “fsutil hardlink list”로 확인하면 세가지 파일 모두 Windows/system32와 WinSxS에 하드링크 되어 있는 것을 확인 할 수 있다.
Windows 폴더가 원본 파일인 것 같지만 사실은 원래Windows\WinSxS에 처음 하드링크된 파일들이고 Windows에 있는 파일들은 WinSxS에 있는 파일들을 하드링크를 생성해 사용하는 것이다.
WinSxS 폴더는 시간이 지날수록 WinSxS의 크기는 점점 커져만 가는데, 그것은 Windows Vista 및 Server 2008에서부터 새로 적용된 Servicing 이라는 OS Component를 관리하는 매커니즘 때문이다.
[출처: Sankim's Blog ]
정의: 파일의 디렉토리 엔트리(Directory entry)를 가리키며, 실제 파일은 1개 이상의 하드 링크를 가진다.
이를 풀어서 설명하면, 디스크 상의 모든 파일은 액세스 하기 위한 경로(폴더 경로 + 파일 명) 정보인 Directory Entry를 가지는데, 이를 하드 링크라 한다.
그런데 디스크 상에서 존재하는 실제 파일은 1개 이상의 하드 링크를 가질 수가 있는데,
예를 들어, 파일 A는 C:\temp1\1.txt와 C:\temp2\2.txt라는 2개의 하드 링크를 가질 수 있다.
이 때 사용자가 C:\temp1\1.txt 파일을 변경하고 저장하면, C:\temp2\2.txt 파일을 열었을 때,
C:\temp1\1.txt 파일에서 변경한 내용이 그대로 반영된다.
그리고 C:\temp2\2.txt 파일을 삭제할 경우 하드 링크인 C:\temp2\2.txt 디렉토리 엔트리만 지워지고,
파일 A는 C:\temp1\1.txt 하드 링크가 남아 있기 때문에 그대로 계속 존재하게 된다.
사용자가 하드 링크를 만들려면, Mklink.exe 도구를 사용한다.
C:\temp1\1.txt로 부터 새로운 C:\temp3\3.txt 하드 링크를 생성하려면 다음과 같이 실행한다.
Mklink C:\temp3\3.txt C:\temp1\1.txt /H
여기서 /H는 하드 링크를 생성하기 위한 옵션이다.
[출처: Sankim's Blog ]
Yochay Kiriaty gives a Windows libraries overview, focusing on the things you need to remember as developers since libraries may sometimes break your application.
Windows 7 library presentation
Windows 7 library presentation Video
Code Demo
Yochay Kiriaty gives a Windows 7 Sensor and Location Platform overview.
Watch the presentation
Download his slides
Jaime Rodriguez gives a great talk about the Windows 7 Taskbar, showing multiple ways (native and managed, using Window API Code Pack and WPF 4) to add great Taskbar functionality to your application.
Watch Jamie’s presentation recording
Jaime Rodriguez discusses Windows 7 Multitouch
Landy Wang, a Distinguished Engineer in the Kernel team. Landy really drilled into the changes to Windows 7 Memory Management, and the amazing work done by the team to reduce the memory footprint, making the entire operating system run fast (real fast).
Watch Landy’s presentation recording
Download his slides.
Mark Russinovich, Technical Fellow and the man behind SysInternals and many of the improvements in Windows 7, opens with a short introduction to the work done by the Kernel team and as a setup for the following two sessions.
Watch Mark’s presentation recording
Download his slides.
Arun Kishan, a Principal Architect for the process management components, described his work around the thread and process allocation that frees the kernel from its thread dispatcher locks and gives Windows 7 the ability to scale seamlessly to many (256) cores.
Watch Arun’s presentation recording
Download his slides.
|
Michael Oneppo explained the changes in the Windows 7 graphics stack. Michael's presentation is very interesting, as it describes some of the DirectX API that was down-ported to Windows 7 as a part of the Platform Update for Windows Vista and the Platform Update for Windows Server 2008. |
Some free Windows 7 resources that might be interesting to you.
CP.xml
Windows_7_Developer_Guide_v1.5.xps
Windows7_Tips_1stEd.pdf