Archive

Archive for July, 2007

가고 싶은 직장 1위 구글?…떠나는 직원들

July 12th, 2007

출처 : 전자뉴스 -07-06

부러움의 대상이었던 구글 직원들이 회사를 떠나고 있다.

 1년에 수백만통의 이력서가 쇄도하고 ‘엔지니어들이 선호하는 직장 1위’로 꼽히는 구글이 실리콘밸리 신생업체들에 인재를 빼앗기고 있는 것.

 5일 월스트리트저널(WSJ)은 실리콘밸리 구직자 사이에서 구글의 인기가 차츰 사그라지고 있다고 보도했다. 그 이유로 직원 1만2000명의 어엿한 대기업으로 성장한 구글이 벤처 시절의 자유롭고 창의적인 업무 환경과 막대한 스톡옵션 등 매력을 더이상 발산하지 못한다는 점을 들었다. 이 때문에 심지어 구글 직원들까지도 우르르 퇴사, 미래 가능성이 더 큰 벤처로 이탈하고 있다. 과거 구글을 선택한 이유가 아이러니하게도 구글을 등지는 이유가 됐다.

  ◇비대해진 구글 앞에서 작아지는 직원들, ‘떠나자’=구글의 직원 수는 1분기 말 기준 1만2000명으로 3년 전인 2004년 1분기보다 6배 이상 증가했다. 
 
 
단기간에 몸집이 커지면서 어쩔 수 없이 의사결정 속도도 느려지고 개개인이 회사에 기여하고 있다는 자부심도 줄어든 것이 직원 이탈의 주 원인이라고 WSJ는 분석했다.

 또다른 요인은 직원들을 돈방석에 올려놓은 스톡옵션. 구글의 팽창기인 2003∼2004년 대거 입사했던 수천명의 직원들이 받은 스톡옵션 행사 기한 만료가 다가오자 하나둘 주식을 처분해 회사를 떠나고 있는 것이다. 당시 그들이 배당받은 스톡옵션 가격은 1주당 평균 49센트. 3일(현지시각) 종가기준 구글 주가는 534달러니 1000배가 넘는다. 구글맵을 개발한 브렛 테일러(26)는 2003년 3월 구글에 입사했다가 최근 창업을 준비하면서 스톡옵션을 처분, 세금을 내고도 1000만달러 가까운 재산을 보유하게 된 경우다.

 부와 경력을 거머쥔 구글 출신들은 회사를 차리거나 또다른 스톡옵션 기회를 찾아 유망 신생벤처의 문을 두드리고 있다.

 ◇페이스북, 구글 개발자 출신 몰려=구글에 등을 돌린 구직자가 가장 많이 몰리는 업체 중 하나는 소셜네트워크서비스 업체 ‘페이스북’이다. 더스틴 모스코비츠 페이스북 부사장은 “올해 들어 실시한 신규 채용에서 11명이 구글로부터도 동시에 입사 제안을 받았는데 이 중 1명을 제외한 10명이 우리 회사를 선택했다”고 밝혔다.

 구글에서 웹사이트 구축 서비스 ‘구글 페이지 크리에이터(GPC)’ 핵심 개발자로 활동한 저스틴 로젠스타인(24)도 지난 5월 페이스북 수석소프트웨어엔지니어로 자리를 옮겼다. “중요한 업무를 맡을 기회가 더 많고 업무처리가 신속한 곳에서 일하고 싶다”는 것이 이유였다. 그는 페이스북을 가리켜 “어제의 구글 그리고 오래 전의 마이크로소프트와 닮았다”며 “구글을 여전히 사랑하지만 페이스북의 성장 잠재력에 더 끌렸다”고 말했다.

◇구글, ‘인재만이 살길, 초심으로 돌아가자!’=구글은 WSJ의 지적에 대해 착시현상일 뿐이라고 반박하고 있다. 최근 2∼3년간 이직률이 5% 아래에서 유지되고 있으며 채용에 응하는 비율도 90% 이상으로 여전히 높다는 것. 비율은 그대로인데 직원 규모가 커지면서 입사하고 퇴사하는 사람이 많다 보니 마치 대규모 이탈이 이뤄지는 것처럼 보일 뿐이라는 주장이다. 그러나 좋은 인재를 계속 유치하지 못한다면 회사의 경쟁력이 쇠퇴할 것이라는 위기의식을 구글도 느끼고 있다. 구글은 최근 ‘스컹크웍스’라는 별동대를 만들어 첨단 제품 개발을 전담시키고 있으며 일부 사업 조직을 마치 벤처처럼 분리해 자율성을 부여하는 등 스피드 경영에 갖은 노력을 기울이고 있다.
 

News

LCD 패널 비교 요약

July 7th, 2007

나름 개인적으로 느끼는 바로는.. LCD 구매시, 추후에 중고차 팔듯, 중고로 팔 경우까지 생각하면 소위 대기업 제품을 사용하는게 좋을것 같기는 한데.. 총알 문제도 있고..  최근에는 국내 중소기업들의 LCD 제품들이 눈에 띄게 좋아져서.. 대부분 아래의 패널을 사용하고 있는데.. 아래의 장단점을 비교해서 본인의 작업용도에 맞는 제품을 고르면 될거 같다.. 내가 내린 결론은, 동일한 패널을 사용하고.. A/S 정책.. 그리고 무엇보다 디자인이 중요한듯.. 대부분 스피커 내장인데, 스피커 없는 제품중에 입맛이 맞는게 좋을것 같은데..

 

삼성: S-PVA(Patterned Vertical Alignment) -> VA 방식
LG: S-IPS(Super-IPS) -> IPS 방식
CMO: e-wv -> TN 방식

*패널의 가격순 -> IPS>VA>TN
*패널의 시야각 -> IPS>VA>TN
*패널의 명암비 -> VA>TN>IPS
*패널의 응답속도 -> TN>IPS>VA

IPS의 장점 -> 광 시야각 최고, 잔상 거의 없음, 
 단점 -> 명암비가 낮음

VA의 장점 -> 좋은 시야각, 색감과 명암비 높음
 단점 -> 잔상이 있음.

TN의 장점 -> 잔상 못느낌, 가격이 낮음
 단점 -> 시야각이 떨어짐

S-IPS는 기존 IPS의 약점인 대비비와 응답속도를 보완한 모드..
S-PVA는 기존 VA의 약점인 시야각에 따라 색깔이 달라보이는 문제점을 개선한 모드..
e-wv는 기존 TN의 약점인 시야각을 향상시킨 모드

*LG는 IPS와 TN, 삼성은 PVA와 TN을 사용.
*최근의 VA는 IPS와 서로 비슷함.

System

Vista Note 4 - IE protected mode and API

July 4th, 2007

출처 : 김명신의 즐거운 하루 블로그 

사실 Vista 는 정식출시 이전부터 ActvieX Control의 보안문제로 도마에 올랐었습니다.혹자는 “ActiveX Control을 쓰지말라는 이야기냐?” 라고 까지 물어보지만  조금 더 세심하게 살펴볼 필요가 있습니다.특히나 많은 분들은 IE7에서의 변경사항과 Vista에서의 IE7을 혼돈하여 이야기 하는 경우가 많기 때문에 이에 대해서도 조금 자세히 알아볼 필요가 있습니다.
IE 7의 새로운 기능에 대해서는 microsoft 사이트를 통해서 쉽게 확인하실 수 있습니다.
이렇게 처음으로 IE7의 새로운 기능을 이야기하는 이유는 앞으로의 내용이 IE7의 새로운 기능에 대해서 이야기를 할 것이 아니기 때문입니다.
Windows 2003 혹은 Windows XP 사용자를 위한 ActiveX Component를 개발하는 측면에서는 크게 달라진 것이 없습니다. 물론 세세하게 들어가면 몇몇 warning 창이 새로 생기고, 수행여부를 사용자에게 물어보기도 하고, ActiveX Component을 사용하지 못하도록 할 수도 있고 등등 이것저것 많습니다만 이건 순전히 사용자 측면이고 개발자들은 기존의 규칙을 잘 따르기만 하면 큰 문제는 생기지 않습니다. 이러한 환경에서는 여전히 ActiveX Component의 관리자의 권한을 얻을 수 있습니다.
이제는 Vista로 가볼 차례입니다. 가장 먼저 변경된 사항은 Vista IE 7에만 존재하는 보호모드(protected mode) 입니다. UAC와 관련된 내용을 일부 확인하셨다면 Administrators 그룹에 포함된 사용자라 하더라도 권한상승창을 통하지 않고는 관리자 권한으로 프로세스를 수행할 수 없다는 것 즈음을 아시고 계시리라 생각합니다. 그런데 보호모드란 녀석은 UAC보다 더 지독합니다. 왠만하면 아무것도 못하게 합니다.
이전의 OS에서는 아무런 제약없이 했던 파일쓰기나 레지스트리 추가/수정, 다른 서버로 연결하기 등은 모두 제한됩니다. 그래서 만일 관리자 권한이 필요한 작업을 수행하려면, ActiveX Component를 2개 만들어서 하나는 보호모드로 수행중인 iexplore.exe 프로세스 안에서 수행되게 놔두고 나머지 한녀석은 dllhost.exe라는 surrogate process가 hosting하도록 구성해야 합니다. 물론 이 과정에서 dllhost.exe는 관리자 권한을 가지고 수행될 수 있도록 조치를 해 두어야 합니다. 이 내용은 다음에 알아보기로 합시다. 사실 이러한 내용들은 모두 기존의 ActiveX 가 Vista에서도 정상적으로 동작하려면 어떻게 해야하는가에 대한 호환성과 관련된 내용입니다.
오늘 확인할 내용은 IE7에서 새로이 제공하는 함수인데 다 접어두고 구체적인 내용을 가지고 접근해 봅시다. 먼저 ActiveX Component내에서 IE가 현재 보호모드에서 수행중인지의 여부를 어떻게 확인하면 좋을까요? msdn에 새로 추가된 Internet Explorer 7 관련 API 목록을 살펴보면 바로 그 내용을 확인할 수 있습니다.
HRESULT IEIsProtectedModeProcess(BOOL *pbResult);
위 함수를 이용하면 ActiveX를 hosting하고 있는 현재의 IE process가 보호모드에서 돌고 있는지의 여부를 확인할 수 있습니다. 이 함수가 만일 FALSE를 반환하면 우리는 매우 happy합니다. 왜냐하면 위에서 말씀드린바와 같이 별 제약없이 모든 기능을 수행할 수 있을테니까요.
두번째로 알아볼 내용은, 저장가능한 Folder위치나 레지스트리 위치를 찾아내는 함수들입니다. 앞서 보호모드에서는 파일쓰기, 레지스트리 추가/수정 등이 제한된다고 했습니다만 다행히도 완전히 이런 기능이 불가능한 것만은 아닙니다. 앞으로 알아볼 특별한 위치에 대해서는 IE7이 보호모드에서 수행되고 있고, IE 프로세스 내부로 로딩된 ActiveX라 하더라도 쓰기가 가능합니다. (사실 IE7이 보호모드에서 수행된다 하더라도 여전히 temporary internet files 폴더 등에 파일을 저장하고 있지 않습니까?)
먼저 레지스트리상에 쓰기 가능 영역은 어떻게 얻어올 수 있을까요?
HRESULT IEGetWriteableHKCU(HKEY *phKey );
위 함수가 도움이 됩니다. 레지스트리상에 쓰기 가능영역은 HKEY_CURRENT_USER 이하에 위치하게 되고, 이곳의 위치를 알기 위해서는 위 함수를 반드시 이용해야 합니다 HKEY를 가져오게 되면, 그 다음은 레지스트리 관련 함수를 그대로 이용하면 되겠지요. 물론 이 함수에 의해서 획득된 HKEY에 대해서도 반드시 RegCloseKey() 함수로 close해주어야 함은 물론입니다.
다음은 로컬파일시스템 상에 쓸 수 있는 영역을 획득하는 방법에 대해서 알아봅시다. 위의 레지스트리의 예와 그다지 틀리지 않습니다.
HRESULT IEGetWriteableFolderPath(GUID clsidFolderID, LPWSTR *lppwstrPath );
첫번째 인자로 줄 수 있는 내용은, KnownFolders.h 파일에 정의된 내용중 하나가 올 수 있습니다만, 반환값을 확인하여 실제 접근이 가능한지 확인하여야 합니다. FOLDERID_InternetCache, FOLDERID_Cookies, FOLDERID_History, FOLDERID_LocalAppDataLow 을 지정할 수 있습니다. 주의할 것은 두번째 인자로 반환된 LPWSTR * 값은 추후 CoTaksMemFree()로 해제되어야 한다는 것입니다.
그외에도 몇가지 추가적인 함수들이 있는데, 목록만을 써보면 다음과 같습니다.
IECancelSaveFile
IEGetWriteableFolderPath : 앞서 알아본 함수
IEGetWriteableHKCU : 앞서 알아본 함수
IEIsProtectedModeProcess : 앞서알아본함수
IEIsProtectedModeURL
IELaunchURL
IESaveFile
IEShowSaveFileDialog
이에 대한 사용 예제는 Introduction to the Protected Mode API 를 통해 sample도 확인해 보시기 바랍니다.
결론적으로 Vista IE7 이 보호모드로 수행된다 하더라도, 제한적이긴 하지만 여전히 파일쓰기와 레지스트리 I/O 가능합니다. 따라서 ActiveX Component를 작성하실 때, 파일 I/O나 레지스트리 I/O가 필요하다고 해서 무조건 관리자 권한으로의 권한상승을 시도할 것이 아니라, 허용된 범위 내에서 동작하도록 ActiveX Component를 개발할 수 있는지의 여부를 먼저 확인하시기 바랍니다.

 

Development

Vista Note 3 - 권한상승을 위해 실행파일에 Manifest 추가

July 4th, 2007

출처 : 김명신의 즐거운 하루 블로그 

Administrators 권한이 있는 경우에만 정상적으로 수행될 수 있는 어플리케이션을 만들기 위해서는 manifest를 이용하여 ‘이 프로그램을 수행하기 위해서는 반드시 권한상승이 필요하다’는 정보를 실행파일에 포함시킬 필요가 있습니다.
물론, 오른마우스를 클릭해서 “관리자 권한으로 실행” 으로 어플리케이션을 수행하거나, ‘속성’에서 ‘관리자 권한으로 이 프로그램 실행’을 선택할 수도 있겠지만, 사용자에게 이렇게 어플리케이션을 수행할 것을 강요하는 것은 매우 어려운 일이기 때문에, 실행파일 자체에 ‘이 어플리케이션은 반드시 Administrators permission이 필요하다’ 라는 정보를 추가하여, 자동적으로 권한상승 창이 뜰 수 있도록 하는 것은 매우 중요합니다. 그런데 Visual Studio 2005 조차도 이러한 정보를 단숨에 실행파일에 추가하는 손쉬운 방법을 제공하지는 않습니다. (1. 아래 내용을 보면 아시겠지만 그렇다고 매우 복잡한것도 아닙니다. 2. 한편으로 보면 이는 매우 당연합니다. Visual Studio 2005가 Vista보다 미리 출시되었을 뿐더러 이러한 manifest를 추가하는 것은 단순히 특수한 type의 resource를 추가하는 것 이상의 동작이 아니기 때문입니다.) 게다가 managed code를 개발하느냐 혹은 C/C++와 같이 native code를 개발하느냐에 따라 그 방법이 서로 상이하기 때문에 조금은 혼돈스러울 수 있습니다.
앞서 말한 이러한 제약사항(본 어플리케이션은 반드시 Administrators 권한이 필요하다와 같은)은 manifest 라는 파일에 기록되게 되며, manifest 파일들은 실행파일에 추가(embedding)될 수 있습니다. manifest 파일의 일반적인 구조는 다음과 같습니다. 이 파일은 ‘실행파일명.exe.manifest’ 라는 파일로 저장하는 것이 좋습니다. ‘MyApp.exe’가 실행파일명이라면 ‘MyApp.exe.manifest’로 저장하시면 됩니다.

 image007.jpg

이제 실질적인 3가지 절차를 알아 봅시다. 
 
1. ‘Step by Step’ 방법
 
먼저 ‘실행파일명.rc’ 라는 이름의 빈파일을 만듭니다. ‘MyApp.rc’와 같이 만들면 됩니다. 아래와
같은 내용을 적습니다. 

#define RT_MANIFEST 24
#define APP_MANIFEST 1
APP_MANIFEST RT_MANIFEST MyApp.exe.manifest

위 의미는 RT_MANIFEST 형 resource로 APP_MANIFEST 라는 이름의 identifier를 “MyApp.exe.manifest” 라는 내용을 정의한다라는 의미입니다.(manifest 형 resource 구분자의 값은 항상 1로 정의하는 것이 좋습니다.
(참고적으로 파일내에 RT_MANIFEST 를 정의하는 대신 #include 를 포함시키는 것도 좋은 방법입니다. 하지만 이 경우 winuser.h 파일의 위치를 정의하기 위하여 추가적인 명령들을 설정해야할 수 있습니다. 또한 MyApp.exe.manifest 파일을 rc 파일과 분리된 파일로 두지 않고 rc 파일내에 쓸 수도 있습니다.)
이제 rc 파일을 컴파일하여 res 파일을 만듭니다. 컴파일 하는 방법은 다음과 같은 두가지 방법 중 한가지를 사용하면 됩니다.
command line prompt 에서 rc.exe /r MyApp.rc 를 입력합니다.
Visual Studio 2005 내에서 project properties를 선택하고 Build Event Tab의 Pre-Build event에 다음을 입력합니다.
“$(DevEnvDir)..\..\SDK\v2.0\bin\rc.exe” /r “$(ProjectDir)$(TargetName).rc”
(rc.exe 파일의 위치는 적절히 수정되어야할 수 있습니다.)
이제 컴파일된 resource를 실행파일에 추가하기 위한 절차를 수행합니다. 다음과 같은 2가지 방법이 있을 수 있습니다.
Visual Studio 2005나 MsBuild를 이용하는 방법
MyApp.csproj 파일을 열어서 볼드체로 표시된 내용을 다음과 같이 추가합니다.


MyApp.res

command line을 이용하여 컴파일 하는 방법
csc /win32res:MyApp.res MyApp.cs
vjc /win32res:MyApp.res MyApp.jsl
vbc /win32resource:MyApp.res MyApp.vb
 
2. mt.exe를 활용하는 방법
 
mt.exe 를 이용하면 이미 생성된 실행파일에 manifest 파일을 embedding할 수 있습니다. mt.exe를 활용하는 방법에도 2가지 방법이 있을 수 있습니다.
command prompt를 이용하여 다음과 같이 입력합니다.
mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;#1
여기서 #1 은 manfest 파일에 대한 resource identifier를 1로 정의한다는 의미입니다.
Visual Studio 2005 내에서 project properties를 선택하고 Build Event Tab의 Post-Build event에 다음을 입력합니다.
“$(DevEnvDir)..\..\VC\bin\mt.exe” -manifest “$(ProjectDir)$(TargetName).exe.manifest”  -outputresource:”$(TargetDir)$(TargetFileName)”;#1
 
3. Manifest Tool을 이용하는 방법
 
Visual Studio 2005를 이용하여 C++ 어플리케이션을 개발하고 있다면, 좀 더 손쉽게 manifest 파일을 embedding할 수 있습니다.
project properties를 선택하고 Configuration Properties->Manifest Tool을 선택한 후, Input and Output을 선택합니다. Additional Manifest Files 에 ‘MyApp.exe.manifest’ 와 같이 manifest 파일명을 입력하면 됩니다.
 
결론
이러한 3가지 방법중에 각각 선호하는 방법을 선택하면 되겠습니다만, 2번 방법을 이용하는 것이 가장 간단하면서도, managed/native의 구분없이 사용할 수 있으므로 가장 적절하지 않을까 생각됩니다.
 
다음 Link를 참고하십시오.
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment
.Net Security Blog : Adding a UAC Manifest to Managed Code
The Moth: Vista: User Account Control
How To: Tell Vista’s UAC What Privelege Level Your App Requires 

Development

Vista Note 2 - Virtualization

July 4th, 2007

출처 : 김명신의 즐거운 하루 블로그

Vista 에서 수행되는 어플리케이션은 기본적으로 표준사용자 권한으로 수행됩니다.
설사 사용자가 Administrators 그룹에 포함된 계정을 이용하여 로그인을 수행하였더라도, 프로그램은 표준 사용자 권한을 가지고 수행되게 됩니다.((이와 관련된 자세한 사항은 다음에 이야기 하겠습니다) 이러한 특성 때문에 예전에는 제한없이 사용가능 했던 리소스들에 대해서 접근이 불가능하거나 그 동작 방식이 변경된 경우가 있습니다.

구체적으로 예를 들어보면,
C:\windows 나 c:\windows\system32 폴더의 권한 설정을 보면 표준사용저는 write 권한이 없습니다. 이것은 Program Files 폴더에 대해서도 마찬가지 입니다. 레지스트리는 어떨까요? HKEY_LOCAL_MACHINE 에도 내용을 읽을 수는 있지만 수정, 삭제, 추가 등의 동작은 제한됩니다. 앞서 Vista Note -1 에서 환경설정 파일을 어디에 저장할 것인가에 대한 내용을 다루었던 것을 기억하시나요? 만일 여러분이 Program Files 밑에 프로그램을 배포하고, 그 위치에 환경설정 파일을 저장하도록 작성해 두면 어떨까요? 이 경우에는 수정이나 저장 권한이 없으므로 실패해야 합니다.

하지만 Vista가 단순히 그렇게만 출시되었다면 어떤일이 일어날까요? 아마도 엄청나게 많은 프로그램들이 제대로 수행되지 않을 것입니다. 우리는 흔히 Program Files 밑에 프로그램을 설치하고 프로그램과 동일한 폴더에 환경설정 파일을 저장하죠. 또한 HKEY_LOCAL_MACHINE 아래에 프로그램 수행에 필요한 정보를 저장하기 합니다.

그래서 Vista에서는 이전 version의 윈도우에서 정상적으로 동작하던 어플리케이션이, Vista에서도 잘 동작할 수 있도록 몇가지 장치들을 강구해 두었습니다. 그 중에 하나가 Virtualization 입니다.
Virtualization이란, 여러분이 Program Files 이하에 파일을 저장하려고 시도하면, 실제 물리적으로 Program Files 이하에 파일을 저장하지 않고, c:\users\< 사용자이름>\AppData\Local\VirtualStore\Program Files 로 redirection 시켜 버립니다.
이는 Windows 폴더에 대해서도 마찬가지 입니다. 프로그램에서 Windows 폴더에 무엇인가를 저장하려고 시도하면, c:\users\< 사용자이름>\AppData\Local\VirtualStore\Window에 파일을 저장하게 됩니다.
아래와 같이 TextBox control 1개와 Button Control 2개를 form에 배치하고 각각의 이벤트 핸들러를 다음과 같이 정의해 봅시다. 
 image001.png

private
void SaveBtn_Click(object sender, EventArgs e)
{
SaveFileDialog saveDlg = new
SaveFileDialog();
saveDlg.Filter = “txt files (*.txt)|*.txt|All files (*.*)|*.*”;
saveDlg.FilterIndex = 2;
if (saveDlg.ShowDialog() == DialogResult.OK)
{
using (StreamWriter sw = new
StreamWriter(saveDlg.FileName))
{
sw.Write(textBox1.Text);
}
}
}

 

private
void LoadBtn_Click(object sender, EventArgs e)
{
OpenFileDialog openDlg = new
OpenFileDialog();
openDlg.Filter = “txt files (*.txt)|*.txt|All files (*.*)|*.*”;
openDlg.FilterIndex = 2;
if (openDlg.ShowDialog() == DialogResult.OK)
{
using (StreamReader sr = new
StreamReader(openDlg.FileName))
{
string readLine;
textBox1.Clear();
while ((readLine = sr.ReadLine()) != null)
{
textBox1.Text += readLine;
}
}
}
}

TextBox control에 “test”를 입력하고, Save 버튼을 클릭한 후, “C:\Program Files” 이하에 test.txt 라는 이름으로 파일을 저장해 봅시다. 그런 다음 command prompt를 열고 c:\program files 이하를 살펴보면,

c:\Program Files>dir test.txt
C 드라이브의 볼륨에는 이름이 없습니다.
볼륨 일련 번호: 0DC0-D7A5
c:\Program Files 디렉터리
파일을 찾을 수 없습니다.

이제 virtualization folder로 이동해서 program files 이하를 살펴봅시다.
C:\Users\myungkim.FAREAST\AppData\Local\VirtualStore\Program Files>dir
C 드라이브의 볼륨에는 이름이 없습니다.
볼륨 일련 번호: 0DC0-D7A5
C:\Users\myungkim.FAREAST\AppData\Local\VirtualStore\Program Files 디렉터리
2006-12-19 오후 04:06

 

.
2006-12-19 오후 04:06
..
2006-12-13 오후 07:19
Microsoft SDKs
2006-12-19 오후 04:20 4 test.txt
1개 파일 4 바이트
3개 디렉터리 7,047,626,752 바이트 남음  

위 결과를 보면, test.txt가 c:\Program Files가 아닌 VirtualStore 이하의 Program Files 이하에 저장된 것을 확인할 수 있습니다.
이제는 TextBox의 내용을 지우고, Load 버튼을 클릭한 후, c:\Program Files 로 이동해 봅시다. 그러면 VirtualStore 이하에 있던 text.txt 파일이 존재함을 알 수 있습니다. 물론 파일을 선택하여 열어보면, 저장한 내용이 포함되어 있습니다.
몇가지 더 test를 수행해 볼 수 있습니다. 만일 물리적으로 C:\Program Files 이하에 동일 이름의 파일이 존재한다면, File Dialog에 나타난 파일은 어느 파일일까요? VirtualStore 이하에 있는 test.txt 파일일까요 ? C:\Program Files 이하에 있는 파일 일까요? 이러한 동작을 확인해 보기 위해서 CMD shell을 관리자 권한으로 수행한 후, c:\Program Files로 이동해서 다음과 같이 입력해 봅시다.
c:\Program Files>copy con test.txt
test2
^Z
1개 파일이 복사되었습니다.

이제 프로그램에서 Load를 선택하여 C:\Program Files를 이동한 후, tet.txt를 선택하여 그 내용을 확인해 봅시다. “test” 인가요 “test2″ 인가요? 답은 VirtualStore에 있는 파일이 열립니다. 한가지 더 test해보고 싶으시죠? VirtualStore 이하에 파일이 존재하지 않는다면 어떻게 될까요?
C:\Users\myungkim.FAREAST\AppData\Local\VirtualStore\Program Files>del test.txt

이렇게 되면 c:\Program Files 이하에 존재하는 test.txt 파일이 열립니다. 즉 test2 라는 내용이 표시되겠죠. 정리하면 다음과 같습니다.
VirtualStore\Program Files         C:\Program Files         어느쪽 파일이 열릴까?
               X                                       X                                 파일 없음
               O                                       X                       VirtualStore\Program Files
               X                                       O                           C:\Program Files
               O                                       O                       VirtualStore\Program Files

즉, 항상 VirtualStore가 우선적으로 검토되고, 만일 적절한 파일을 발견하지 못한 경우에 한해서만, 물리적인 저장 위치인 C:\Program Files 를 access한다고 정리하시면 됩니다.
Registry의 경우는 어떨까요? 핵심적인 메커니즘은 파일과 유사합니다. Registry Virtualization은 HKEY_LOCAL_MACHINE\Software 이하만을 가상화 합니다. 즉 HKEY_LOCAL_MACHINE\Software\AppKey1 에 접근을 시도하면 실제로는 HKEY_USERS\_Classes\VirtualStore\Machine\Software\AppKey1 에 접근하게 됩니다.
Registry Virtualization에 대한 보다 자세한 내용은 Registry Virtualization 를 참고하십시오.
마지막으로 이러한 virtualization 기능은 다음 version의 windows 출시나 혹은 그 이전에라도 제거될 수 있다는 것입니다. 실제로 64bit Vista에서는 이러한 virtualization 기능이 전혀 동작하지 않습니다. 따라서 virtualization 기능에 대해서 전혀 기억하지 못하더라도 다음 한가지만은 기억해야 합니다.
Program Files나 windows 혹은 windows/system 폴더 그리고 HKEY_LOCAL_MACHINE\Software 등에는 파일 혹은 정보를 수정,삭제,저장할 수 없으므로 프로그램을 수정해서 다른 위치에 이러한 정보를 저장하도록 고쳐야 한다는 것입니다.
이 것이 제가 Vista Note -1 에서 환경설정 파일에 대한 내용을 미리 말씀 드린 이유이기도 합니다

 

  

Development