WinInet(The Microsoft Win32 Internet functions) 클래스는 Win32반의 WinInet API들을 캡슐화하고 있는 클래스의 모임을 말하며 클라이언트 쪽에서 인터넷의 표준 프로토콜인 HTTP, Gopher, FTP 등을 지원하기 위한 클래스이다. MFC에서 제공하는 WinInet 관련 클래스들은 네트워크상에서 발생하는 여러 가지 복잡한 처리 작업을 내부적으로 수행하고 상당히 안정적인 코드를 제공한다. 이러한 프로토콜을 사용한 전송을 쉽게 할 수 있도록 운영체제 확장의 일부로 wininet.dll을 제공한다. MFC 응용 프로그램에서 wininet.dll은 CInternetSession 개체에 의해 표현된다. CInternetSession은 작업자가 인터넷에 정확히 어떻게 연결하려고 했는지 wininet.dll에게 알리도록 한다.

CInternetSession(LPCTSTR pstrAgent = NULL, DWORD dwContext = 1, DWORD dwAccessType = RNET_OPEN_TYPE_PRECONFIG, LPCTSTR pstrProxyName = NULL, LPCTSTR pstrProxyBypass = NULL, DWORD dwFlags = 0);

첫 번째 인자는 클라이언트 쪽 소프트웨어 이름을 가리키는 포인터이다. 디폴트값 NULL은 생성자가 AfxGetAppName() 호출을 통해 응용프로그램의 이름을 찾게 할 것이다. dwAccessType 인자는 WinInet에게 인터넷을 어떻게 연결할 계획인지 알려준다. 디폴트 값인 INTER_OPEN_TYPE_PRECONFIG는 레지스트리에서 인터넷 연결에 관하여 이전에 입력된 정보를 찾는다. 인트라넷을 사용하고 있거나 컴퓨터가 인터넷에 직접 연결되어 있다면 INTERNET_OPEN_TYPE_DIRECT를 지정할 수 있다. 방화벽을 통한 연결은 GATEWAY_INTERNET_ACCESS, 프록시를 통해 인터넷에 요청을 전달하려고 하려면 INTERNET_OPEN_TYPE_PROXY를 지정한다. 이것을 지정하지 않으면 pstrProxyName과 pstrProxyBypass 인자를 NULL로 지정할 수 있다. 그리고 dwFlags 인자를 사용하여 다른 방법으로 연결에 영항을 줄 수 있다. 비동기 동작을 지원하는 INTERNET_FLAG_ASYNC 플래그와 세션을 통해 기존 연결을 재사용하려는 INTER_FLAG_EXITING_CONNECT 플래그가 OR 연산자를 사용하여 결합된다.

dwContext라는 인자가 있는데 인터넷에 있는 다른 컴퓨터와 대화하는 것은 오랜 시간이 걸릴 수 있다. 일부 프로토콜 등은 많은 오버헤드를 발생시키고, 인터넷 응용 프로그램의 사용자들은 종종 느린 링크를 통해서 연결된다. 따라서 윈도우 인터넷 API는 언제, 어떤 것이 진행되었는지 응용프로그램이 알 수 있게 하는 콜백을 제공한다. dwContext 인자는 단순히 응용 프로그램이 실행하고 있는 각 동작들을 구분할 수 있게 해준다. MFC는 콜백 함수처럼 복잡한 것들에 대해 염려하지 않아도 되게 해준다. CInternetSession으로부터 클래스를 유도하고 OnStatusCallback() 함수를 오버라이드할 수 있다.

또 CInternetSession 듀도 개체에 EnableStatusCallback() 함수를 호출하여 상태 콜백을 받고 싶어한다는 것을 시스템에게 알릴 필요가 있다. 이 인자가 TRUE(디폴트)이면 함수가 콜백을 활성화시킬 것이고, FALSE이면 인자가 콜백을 비활성화시킬 것이다. CInternetSession을 열고 FTP 프로토콜을 이용하여 파일을 전송할 경우 GetFtpConnection() 멤버를 호출함으로써 FtpConnection 개체를 생성할 수 있다. GetFtpConnection()은 이 새 CFtpConnection을 가리키는 포인터를 반환한다.

CFtpConnection* GetFtpConnection( LPCTSTR pstrServer, LPCTSTR pstrUserName = NULL, LPCTSTR pstrPassword = NULL, INTERNET_PORT nPort = INTERNET_INVALID_PORT_NUMBER, BOOL bPassive = FALSE );

첫 번째 인자는 연결하고자 하는 서버의 이름이고 두 번째 인자와 세 번째 인자는 연결에 사용될 사용자 이름과 암호를 나타낸다. 디폴트 값인 NULL을 전달하면 익명(anonynous)으로 접속요청을 하게 된다. nPort 인자는 포트 번호를 나타내는데 디폴트 값인 INTERNET_INVALID_PORT_NUMBER을 사용하면 이 프로토콜의 디폴트 TCP/IP 포트 번호(HTTP:80, FTP:21, Gopher:70, HTTPS:443)를 사용한다. 이를 이용한 FTP 서버 접속은 리스트 3과 같다.

리스트 3 : FTP 서버 접속
------------------------------------------------------------

CInternetSession m_Session;

CFtpConnection *m_pConnection = NULL;
try
{
//Anonymous 로 로그인
m_pConnection = m_Session.GetFtpConnection(ftp.pserang.co.kr);
// 사용자명과 패스워드 로그인
/* m_pConnnection = m_Session.GetFtpConnection(ftp.pserang.co.kr","User_Name","Password); */
//연결시 작업
m_pConnection->Close();
}
catch (CInternetException *m_pEx)
{
m_pEx->ReportError(MB_ICONEXCLAMATION);
m_pConnection = NULL;
m_pEx->Delete();
}
delete m_pConnection;
------------------------------------------------------------
CInternetException은 운영체제로부터 문제를 기술하는 에러 텍스트를 얻어내는 에외처리 클래스이다. 연결이 이루어 졌을 때 GetCurrentDirectory()를 호출하여 FTP 컴퓨터의 현재 디렉토리를 얻을 수 있고 SetCurrentDirectory()로 상대편 디렉토리를 설정할 수 있다. 그리고 GetFile()로 파일을 다운로드 할 수 있고 PutFile()로 파일을 업로드 할 수 있다. 사용자에게 권한이 주어지면 CreateDirectory()/RemoveDirectory() 및 Remove()/Rename()를 호출하여 디렉토리를 생성/추가할 수 있고 파일을 제거/이름변경을 할 수 있다. 예를 들어 파일을 다운로드 할 때의 코드는 다음과 같다.
 

m_pConnection->GetFile("RemoteFile", "localFile", FALSE, FILE_ATTRIBUTE_NORMAL, FTP_TRANSFER_TYPE_BINARY | INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE);

네 번째 인자(DWORD dwAttributes)는 파일 복사 후 로컬 컴퓨터에 생성되는 파일의 속성을 나타낸다. 읽기 전용은 FILE_ATTRIBUTE_READONLY로 지정할 수 있다. 다섯 번째 인자(DWORD dwFlags)는 원시 이진 파일들을 처리할 수 없는 연결을 통해 올바로 데이터를 전달하기 위해 FTP 프로토콜에 사용되는 의미를 바꾼다. CFtpFileFind란 클래스가 있는데 FTP 서버를 검색하는 기능을 수행한다. 이 클래스는 CFileFind 클래스에서 파생되었다. CFtpFileFind 클래스는 두 개의 인자가 있는데 첫 번째 인자는 검색할 서버를 위한 CFtpConnectiondmf 가리키는 포인터이고 두 번째 인자는 dwContext 값을 나타낸다.

CFtpFileFind *m_pFileFind = NULL;
m_pFileFind = new CFtpFileFind(m_pConnection);
BOOL bContinue = TRUE;
CString m_file_name;
m_pFileFind->FindFile("RemoteDir");
while(bContinue)
{
bContinue = m_pFileFind->FindNextFile();
m_file_name = m_pFileFind->GetFileName();
if(m_pFileFind->IsDirectory())
{
//디렉토리일 경우 루틴
}
// 파일인 경우
else
{
//파일일 경우 루틴
}
}

FTP 서버로 연결이 되면 CFtpFileFind 클래스를 이용하여 지정된 경로의 파일을 계속 찾는 구문이다. HTTP 서버 즉, 일반적으로 말하는 웹 서버에 접속하기 위해서 MFC 계층에서 CFtpConnection과 비슷한 위치를 차지하는 CHttpConnection를 사용해 연결할 수 있다. CInternetSession의 GetHtpConnection() 멤버를 사용하여 CHttpConnection을 열 수 있다.

CHttpConnection* GetHttpConnection( LPCTSTR pstrServer, INTERNET_PORT nPort = NTERNET_INVALID_PORT_NUMBER, LPCTSTR pstrUserName = NULL, LPCTSTR pstrPassword = NULL );

각 인자는 GetFtpConnection()과 거의 동일하다. 웹서버에 접속하는 코드는 다음과 같다.

CInternetSession m_Session;
CHttpConnection *m_pHttpConnection = NULL;
CHttpFile *m_pFile = NULL;
try
{
m_pHttpConnection = m_Session.GetHttpConnection(www.pserang.co.kr);
m_pFile = m_pHttpconnection->OpenRequest(CHttpConnection::HTTP_VERB_GET,"/");
m_pFile -> AddRequestHeaders("Accept:text/*\r\nAccept-Language:kr\r\n");
m_pFile ->SendRequest();
//...
}
catch(CInternetException *m_pEx)
{
m_pEx->ReprotError();
m_pEx->Delete();
}
delete m_pFile;
delete m_pHttpConnection;

CHttpFile이라는 것이 있는데 CInternetFile로부터 유도되었고 CInternetFile은 CStdioFile로부터 유도되었다. CHttpFile의 특징은 자신만의 파일 데이터 버퍼링을 수행한다. SetReadBufferSize()를 호출하여 버퍼 크기를 설정할 수 있고, 버퍼를 설정하지 않고서 ReadString()을 사용하면 자동으로 버퍼가 설정된다. 위 코드 중 서버에게 요청하는 OpenRequest()의 첫 번째 인자는 CHttpConnection 내부의 enum에서 정의된 기호이다. 이 인자는 요청에서 사용하고자 하는 메소드를 지정한다. HTTP_VERB_GET이라는 메소드는 서버에 있는 개체의 전체 내용을 요청하는데 쓰인다. 그 외 특정 개체와 연결된 개체를 전달하고자 할 때는 HTTP_VERB_POST 인자가 쓰이고 마지막 인자인 POST 대신 HEAD, PUT, LINK, DELETE, UNLINK 등이 사용된다.  요청은 CHttpFile::SendRequest() 호출과 함께 전달된다. 요청을 전달하기 전에 헤더를 추가하고 싶으면 CHttpFile::AddHeaders()를 호출할 수 있다. 서버가 요청에 대한 개체를 갖고 있지만 클라이언트의 Accept: 헤더에서 지정된 형식 요청을 충족시킬 수 없으면 일반 "404 Not Found"(HTTP_STATUS_NOT_FUOND: 404)" 에러와

"HTTP_STATUS_NONE_ACCEPTABLE: 406" 에러를 반환할 것이다. 요청이 전달되고 반응이 성공적으로 수신되었으면 SendRequest()가 TRUE를 반환한다. 그렇지 않으면 예외가 발생할 것이다. 이것은 내부 서버 에러가 있다는 것을 의미한다. CHttpFile::QueryInfoStatusCode()를 호출함으로써 CHttpFile 개체로 들어온 정보로부터 반환 코드를 커낼 수 있다.

m_pFile->SendRequest();
DWORD m_dwStatusCode;
m_pFile->QueryInfoStatusCode(m_dwStatusCode);

m_dwStatusCode는 요청 결과에 반영하는 정수를 갖고 있다. 예를 들어 200은 HTTP_STATUS_OK를 나타내며 요청이 게이트웨이로 갔지만 게이트웨이와 서버와의 통신이 타임아웃일 경우는 504(HTTP_STATUS_GATEWAY_TIMEOUT)를 나타낸다
리스트 4는 프록시를 통하여 HTTP 파일을 다운로드 하는 코드이다.

[MSC 명령어]

certmgr.msc : 인증서 관리
ciadv.msc : 인덱싱 서비스
compmgmt.msc : 컴퓨터 관리
devmgmt.msc : 장치관리자
dfrg.msc : 디스크 조각 모음
diskmgmt.msc : 디스크 관리
eventvwr.msc : 이벤트 뷰어 (이벤트 로그)
fsmgmt.msc : 공유 폴더 (공유 폴더 관리)
gpedit.msc : 그룹 정책
lusrmgr.msc : 로컬 사용자 및 그룹
ntmsmgr.msc : Removable Storage
ntmsoprq.msc : 이동식 저장소 운영자 요청
perfmon.msc : 성능
rsop.msc : 정책의 결과 집합
secpol.msc : 로컬 보안 설정
services.msc : 서비스
wmimgmt.msc : WMI 서비스 구성
comexp.msc : comexp 구성 요소 서비스
control userpasswords2 : 사용자 계정 

Matthew A. Stoecker
Microsoft Corporation

2004년 5월

적용 대상:

   Visual Studio 2005

요약: Visual Studio Class Designer를 사용하면 클래스 구조와 관계를 시각화하고 시각 디자인 환경에서 새 클래스를 만들고 클래스를 쉽게 refactor할 수 있습니다. 이 백서에서는 이러한 작업에 대해 설명합니다(7페이지/인쇄 페이지 기준).

참고 이 문서는 해당 제품 릴리스의 제조 이전에 개발되었으므로 여기에 포함된 정보가 출시 제품의 내용과 완전히 일치함을 보증하지는 못합니다. 여기서 제공되는 정보는 이 문서가 작성된 당시의 제품 정보를 기준으로 하며 계획 목적으로만 사용해야 합니다. 정보는 언제든지 사전 예고 없이 변경될 수 있습니다. Microsoft가 이 설명서 본안에 관련된 특허권, 상표권, 저작권 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등에 대한 어떠한 사용권도 허여하지 않습니다.

목차

소개
시각 클래스 디자이너를 사용해야 하는 이유
Visual Studio Class Designer
Visual Studio와의 통합
결론

소개

Visual Studio Class Designer는 CLR(공용 언어 런타임)을 위한 완전한 기능을 갖춘 시각 디자인 환경입니다. Visual Studio Class Designer를 사용하면 클래스 및 기타 유형의 구조를 시각화하고 이 시각 표현을 통해 소스 코드를 편집할 수 있습니다. 클래스 다이어그램의 변경 내용은 즉시 코드에 반영되며 코드의 변경 내용은 즉시 디자이너의 모양에 영향을 줍니다. 디자이너와 코드 간의 이러한 동기 관계를 통해 복잡한 CLR 유형을 시각적으로 쉽게 만들고 구성할 수 있습니다.

Class Designer에는 코드를 refactor하고 식별자 이름을 쉽게 바꾸고 메서드를 다시 정의할 수 있는 특수 기능이 들어 있습니다. 클래스와 구조도 자동으로 생성할 수 있으며 스텁을 자동으로 생성하여 인터페이스를 구현할 수 있습니다.

마지막으로, Class Designer는 코드 베이스 영역을 동료에게 쉽게 전달할 수 있는 통신 도구로 사용할 수도 있습니다. 클래스 다이어그램을 인쇄하거나 이미지로 저장하여 HTML 페이지나 PowerPoint 프레젠테이션으로 표시할 수 있습니다.

그림 1. Class Designer

시각 클래스 디자이너를 사용해야 하는 이유

소프트웨어를 디자인하는 작업은 매우 어렵고 복잡합니다. 초기 디자인 단계에서 코드 검토, 최종 제품 문서화에 이르기까지 개발 주기 동안 모든 시점에서 문제가 발생합니다. 시각 클래스 디자이너는 전체 개발 주기에서 유용하며 다음과 같은 시나리오를 예로 들 수 있습니다.

• 기존 코드 이해: 기존 코드 베이스는 복잡하고 혼란스러울 수 있습니다. 시각 클래스 디자이너를 사용하면 기존 클래스 계층 구조를 그래픽으로 탐색하고 각 클래스 간의 관계를 파악할 수 있습니다.
• 클래스 디자인: 시각 클래스 디자이너를 사용하여 소프트웨어를 그래픽으로 훌륭하게 디자인하고 구현할 수 있습니다.
• 코드 검토 및 refactoring: 시각 클래스 디자이너는 코드 검토 및 refactoring을 위한 강력한 도구입니다. 기존 코드 다이어그램에 검토용 주석을 추가할 수 있으며 디자이너로 코드를 refactor하여 시간을 절약할 수 있습니다.
• 문서화를 위한 클래스 다이어그램: 클래스 다이어그램을 사용하여 상속 트리를 그래픽으로 표시함으로써 기존 클래스 계층 구조를 문서화할 수 있습니다. 또한 클래스 다이어그램은 전자 메일이나 시각적 프레젠테이션을 통해 동료와 아이디어를 교환하는 경우에도 유용합니다.

Visual Studio Class Designer

Visual Studio Class Designer는 .NET Framework용 통합 디자인 기능을 갖춘 시각적 코드 디자인 도구입니다. Class Designer의 시각적 기능은 CLR과 밀접하게 관련되어 있습니다. 클래스, 구조, 인터페이스 등의 CLR 모양은 각각의 특성을 나타내는 모양으로 시각적으로 구별되도록 표현됩니다. 더욱이 다이어그램의 용어는 특정 언어와 관련이 있습니다. 예를 들어 Visual Basic에서는 Public, Private 및 Friend 액세스 수준으로 작업할 수 있습니다. 반면 C#에서는 public, private 및 internal로 표시됩니다. Class Designer와 CLR의 견고한 통합을 통해 Class Designer는 .NET Framework를 사용하여 클래스를 만들 수 있는 이상적인 도구가 되었습니다.

Visual Studio Class Designer는 위에서 언급한 모든 주요 시나리오를 위한 기능을 제공하므로 전체 개발 주기에 걸쳐 적절히 사용할 수 있습니다. 예를 들면 다음과 같습니다.

• 기존의 코드 이해: Visual Studio Class Designer를 사용하여 클래스 간의 관계를 쉽고 빠르게 확인할 수 있습니다. 시각적으로 확인하고 기존 유형에 친숙해질 수 있게 함으로써 기존 코드의 상속 계층 구조를 확인할 수 있을 뿐 아니라 참조된 유형 및 .NET 어셈블리도 확인할 수 있습니다.
• 클래스 디자인: Visual Studio Class Designer를 사용하여 클래스 및 클래스 계층 구조를 빠르게 디자인할 수 있습니다. 자주 사용하는 끌어서 놓기 기능을 사용하여 코드 편집기와의 동기화를 유지하면서 클래스 다이어그램을 만들 수 있습니다. 클래스 다이어그램을 변경하면 코드에 바로 반영되며 반대의 경우도 마찬가지입니다. 클래스 다이어그램은 항상 코드의 현재 상황을 표시합니다.
• 코드 검토 및 refactoring: Visual Studio Class Designer는 코드 검토 및 refactoring을 위한 강력한 도구입니다. 이후의 작업을 위해 기존 코드 다이어그램에 주석을 추가할 수 있으며 기본으로 제공되는 refactoring 기능을 사용하여 기호 이름 바꾸기, 속성 필드 캡슐화 등의 일반 작업을 빠르고 편리하게 수행할 수 있습니다.
• 문서화를 위한 클래스 다이어그램: 기존 클래스 다이어그램을 인쇄하거나 이미지로 저장하여 HTML 페이지나 Microsoft PowerPoint 프레젠테이션으로 표시하는 등 다양한 방법으로 표시할 수 있습니다.

Class Designer를 사용하여 클래스 만들기

프로젝트에서 Class Designer를 사용하여 클래스를 쉽게 만들고 구성할 수 있습니다. 클래스 다이어그램은 실제로 코드의 현재 상황을 표시합니다. 다이어그램의 변경 내용은 코드와 자동으로 동기화되며 반대의 경우도 마찬가지입니다. 도구 상자에서 Class Design 표면으로 클래스를 끌어서 놓는 방법으로 간단한 클래스를 만들 수 있습니다. 프로젝트에 클래스를 만든 후에는 코드 편집기를 열고 코드를 직접 새 클래스에 추가할 수 있습니다. 변경한 내용은 클래스 다이어그램에 반영됩니다.

클래스를 만든 후 Class Details 창을 사용하여 구성원을 추가할 수 있습니다. 예를 들어 메서드를 추가하려면 Class Details 창에서 <add method>를 클릭하고 메서드 이름을 입력합니다. 그런 다음 반환 유형, 액세스 수준을 지정하고 메서드에 대한 주석을 추가할 수 있습니다. 메서드를 만든 후에는 매개 변수 이름을 지정하고 유형, 한정자 및 주석을 지정하여 메서드를 먼저 추가하는 것과 비슷한 방법으로 메서드 이름에 매개 변수를 추가할 수 있습니다. 메서드가 추가되는 것과 같은 방식으로 속성, 필드 및 이벤트가 추가됩니다. 트리 컨트롤을 사용하여 메서드를 편집하는 작업은 코드 편집기에서 입력하는 것과 매우 유사합니다. 동일한 키 입력으로 셀을 탐색할 수 있으며 IntelliSense 도움말을 사용할 수 있습니다.

인터페이스 구현

Class Designer를 사용하여 클래스에서 인터페이스를 쉽게 구현할 수 있습니다. 사실, 인터페이스가 Class Designer 표면에 표시된 경우 클래스에서 인터페이스로 상속 선을 그려서, 클래스를 상속할 때 사용하는 절차를 똑같이 사용하여 구현할 수 있습니다. 그러나 인터페이스가 Class Designer에 표시되지 않은 경우에도 쉽게 구현할 수 있습니다. 클래스 보기에서 구현할 클래스로 인터페이스를 끌어서 놓으면 됩니다. 인터페이스에 정의된 메서드에 대해 메서드 스텁이 자동으로 생성됩니다. 일단 구현된 후에는 코드 편집기에서 특정 구현 코드를 추가할 수 있습니다.

상속 계층 구조 시각화

Class Designer를 사용하여 프로젝트에서 상속 계층 구조를 시각화할 수 있습니다. 상속된 클래스의 기본 클래스를 표시하려면 클래스의 헤더 영역을 마우스 오른쪽 단추로 클릭하고 Show Base Class를 클릭합니다. 그러면 다이어그램에 기본 클래스가 나타납니다.

기존 클래스에서 상속되는 클래스를 표시하려면 클래스의 헤더 영역을 마우스 오른쪽 단추로 클릭하고 Show Derived Types를 선택합니다. 파생된 클래스가 상속 선으로 클래스에 연결되어 다이어그램에 나타납니다.

Visual Studio와의 통합

Class Designer는 Visual Studio 2005 Team System과 완벽하게 통합됩니다. 일반 Visual Studio 도구를 사용할 때와 같은 공간에서 같은 방법으로 친숙하게 Class Designer로 작업할 수 있습니다. Class Designer에서 작업할 경우 친숙한 끌어서 놓기 작업을 통해 액세스할 수 있는 Class Designer 도구가 도구 상자에 포함되어 있으면 Class Details 및 Properties 창에서 유형 구성원에 액세스할 수 있습니다. Solution Explorer, Class View 등의 표준 Visual Studio 도구 창에서도 끌어서 놓기 기능을 사용할 수 있습니다. Class Designer에서 변경한 내용은 모두 해당 코드 파일과 즉시 동기화됩니다. 그런 다음 Visual Studio 코드 편집기를 사용하여 정상적으로 이 코드 파일을 열어서 편집할 수 있습니다.

클래스 다이어그램

클래스 다이어그램은 변경을 통해 계속 업데이트되는 현재 코드 보기입니다. 클래스 다이어그램에는 기존 프로젝트의 클래스가 표시됩니다. 클래스 다이어그램을 사용하여 프로젝트에서 클래스 간의 관계를 시각화하고 개별 클래스에 구성원을 추가 및 편집할 수 있습니다. 클래스 다이어그램 파일은 프로젝트의 일부로서 계속 남아 있으므로 코드를 그래픽으로 볼 때 항상 사용할 수 있습니다.

Project 메뉴에서 New Item을 선택하고 클래스 다이어그램을 선택하여 기존 프로젝트에 새 클래스 다이어그램을 추가할 수 있습니다. 클래스 다이어그램은 프로젝트의 일부라기보다는 클래스를 만들고 편집하는 과정을 돕는 도구입니다. 클래스를 만든 후에는 Class View에서 클래스 디자인 표면으로 끌어서 놓는 방법으로 Class Designer에 기존 클래스를 추가할 수 있습니다. 또한 도구 상자에서 Class Designer로 끌어서 놓는 방법으로 새 클래스 및 기타 유형을 추가할 수 있습니다.

Class Designer에 추가한 후 클래스 및 기타 유형은 선택하고 처리할 수 있는 도형으로 표시됩니다. Class Designer에서 임의의 도형을 선택하면 상세 정보가 Class Details 창에 표시됩니다. 클래스 다이어그램 자체에는 시각적 정보만 저장되며 코드 내용에 대한 정보는 포함되지 않습니다. 클래스 다이어그램 파일을 삭제해도 코드는 손실되지 않습니다.

그림 2. 클래스 다이어그램

도구 상자

클래스 다이어그램이 표시되면 도구 상자에서 새 구성원을 클래스 다이어그램에 추가할 수 있습니다. 도구 상자에는 클래스 다이어그램에 추가할 수 있는 클래스, 구조, 대리자, enum 및 기타 유형이 포함되어 있습니다. 도구 상자에서 유형이 추가되면 해당 코드 및 코드 파일이 프로젝트에 추가됩니다.

그림 3. 도구 상자

Class Details 창

Class Details 창에는 Class Designer에 표시되는 유형이 가진 메서드, 속성, 필드 및 이벤트가 표시됩니다. Class Details 창을 사용하여 Class Designer에 있는 클래스 구성원이나 구조를 신속하게 편집할 수 있습니다. 예를 들어 메서드의 반환 유형을 변경하거나 매개 변수를 추가하거나 액세스 수준을 변경할 수 있습니다. Class Details 창에서 변경한 내용은 모두 코드에 즉시 반영됩니다.

그림 4. Class Details 창

결론

Class Designer는 Visual Studio 2005를 위한 새 도구로서, 프로젝트에서 클래스 및 인터페이스를 신속하게 만들고 구성할 수 있게 합니다. 이 백서에서는 기존 코드 이해, 클래스 디자인, 코드 검토 및 refactoring, 문서화를 위한 다이어그램 사용 등 Class Designer를 사용할 수 있는 가장 기본적인 시나리오에 대해 설명했습니다. Class Designer의 기능에 대해 더 자세히 배워서 이 새 도구를 활용하면 소프트웨어를 개발할 때 유용할 것입니다.

출처 : http://www.microsoft.com/korea/msdn/library/ko-kr/dev/vstudio/clssdsgnr.aspx ]]> * Skill http://dokim.egloos.com/551231#comments Fri, 04 Jul 2008 03:46:40 GMT 오키 http://dokim.egloos.com/393222 http://dokim.egloos.com/393222 MPEG-2(엠펙 투)는 MPEG(Moving Picture Expert Group)이 정한 오디오와 비디오 인코딩(부호화)에 관한 일련의 표준을 말하며, ISO 표준 13818(13818-1은 시스템, 13818-2는 비디오 부호화, 13818-3은 오디오...)로 공표되었다. MPEG-2는 일반적으로 디지털 위성방송, 디지털 유선방송 등의 디지털 방송을 위한 오디오와 비디오 정보 전송을 위해 쓰이고 있다. 또, MPEG-2의 표준을 약간 변형한 인코딩 포맷은 상업 DVD의 표준으로 돌비 디지털, DTS와 함께 사용되고 있다.

MPEG-2는 MPEG-1과 비슷하지만, 텔레비전 방송에서 사용하는 비월주사 방식의 영상을 지원한다. MPEG-2 비디오는 저속 비트율(1 Mbit/s) 환경에는 부적합하지만, 초당 3 메가비트 이상을 요구하는 MPEG-1보다는 향상된 압축률을 보이고 있다. MPEG-2의 MPEG-1과 구별되는 특징으로는 데이터 유실이 많은 전송 환경에도 적합한 트랜스포트 스트림이 정의되어 있다는 점을 들 수 있으며, 이는 현재 디지털 방송에 사용되고 있다. MPEG-2는 원래 MPEG-3로 개발하려던 HDTV(고선명 텔레비젼) 전송의 표준 또한 포함한다. 또한 MPEG-1과도 호환성도 보장되어 표준을 따르는 MPEG-2 디코더는 MPEG-1 스트림도 재생할 수 있다.

MPEG-2 13818-3 오디오 표준은 MPEG-1 오디오 표준에서 발전되어 채널의 확장을 하는 MC (다중 채널)과 낮은 표본화 주파수를 제공하는 LSF (낮은 샘플링 주파수:Low Sampling Frequency)(24 kHz, 22.05 kHz, 16 kHz)로 구성되어 있다. 또한 두가지 모두 MPEG-1 오디오를 복호화할 수 있는 하위 호환성의 특성을 가지고 있다. 알고리즘 측면에서는 추가된 내용이 없기 때문에 이론적으로 MPEG-1과 동일한 압축율을 가진다고 봐도 무방하다.

하지만 MPEG-2에서는 압축율을 높이는 대신, 하위 호환성을 지원하지 않는 AAC (고급 오디오 코딩)를 13818-3이 표준화 된 후 13818-7로 표준화하고 있다. AAC에는 기존 MPEG 오디오에서 사용되지 않던, LTP, TNS, 예측 도구가 추가되었으며 레이어로 구분하던 MPEG-1,2와는 달리 도구의 집합인 프로파일로 구분하여 정의하고 있다. (덜 복잡함, 조절할 수 있는 샘플 속도)

[편집] MPEG-2 표준

DVD / DVB 에서 사용되는 변경된 표준을 제외한 MPEG-2 비디오와 MPEG-2 오디오에 대한 일반 정보.

MPEG-2 시스템 스트림은 보통 다음과 같은 두 가지 요소로 구성된다.

• 영상 데이터 + 타임 스탬프(시각 정보)
• 소리 데이터 + 타임 스탬프

[편집] 간략한 MPEG-2 비디오 인코딩 절차

MPEG-2는 오디오 신호를 비롯한 동영상의 일반적인 인코딩(부호화)을 위한 규약이다. 부호화된 비디오 스트림은 인트라(Intra), 전방 예측(Predictive), 양방향 예측(Bidirectional)의 세가지 프레임들이 GOP(Group of Pictures) 구조라는 특별한 구조를 이루어 만들어 진다. 일반적으로 부호화할 원본은 소리가 포함된 일정한 해상도의 영상이 초당 25(CCIR규정) 프레임 또는 초당 29.97(FCC규정) 프레임의 속도로 바뀌는 동영상이다.

MPEG-2는 비월주사(interlaced scan)와 순차주사(progressive scan) 두 가지 방식의 비디오 스트림을 모두 지원한다. 순차주사 방식에선 부호화의 기본 유닛이 프레임(한 장의 영상)이 되고, 비월주사 방식에선 필드(한 장의 영상의 홀수줄, 혹은 짝수줄만으로 이루어짐)이다. 아래 설명에서 "픽처" 혹은 "정지 영상"이라고 말한 것은 각각의 기본 유닛(즉 필드나 프레임)을 가리킨다.

MPEG-2 스트림은 단일 영상을 부호화한 데이터 프레임의 연속이다. 각 정지영상을 부호화하는 방법엔 인트라(I), 전방 예측(P), 양방향 예측(B) 세 가지가 있다.

각 비디오 이미지는 루미넌스(명도) 성분 Y 와 두 개의 크로미넌스(색차) U, V 채널로 우선 나뉘어진다. 각각에 대해 공간적으로 "매크로 블럭(macroblock)"이라 불리는 16x16 크기의 격자로 나뉘며, 이 매크로 블럭이 부호화의 기본적인 조각이 된다. 매크로 블럭은 8x8 크기의 "블럭" 4개가 합쳐진 것이다. 원본 이미지의 크로미넌스 포맷에 따라 한 매크로 블럭이 8x8 크기의 크로미넌스 블럭을 갖을지, 아니면 16x16을 갖을지가 결정된다. 예를 들어, 일반적으로 쓰이는 4:2:0 포맷에서는, 한 색상이 매크로 블럭 하나(16x16)당 한 개의 크로미넌스 블록(8x8)만을 갖게 되어, 하나의 매크로 블럭은 4개의 루미넌스 블럭, 1개의 U블럭, 1개의 V블럭으로 총 6개의 블럭을 갖게 된다.

I 픽처의 경우 이미지 데이터는 다음 문단에서 설명하는 인코딩 절차를 바로 거치게 되며, P (혹은 B) 픽처의 경우엔 우선 "움직임 보상"(motion compensation)이라 불리는 과정을 거쳐 이전 영상(B의 경우엔 이전과 이후의 영상)과의 관련성을 검색하여 이용한 후 다음 인코딩을 진행하게 된다. 움직임 보상에선 P (혹은 B) 픽처로 만들어질 영상의 각 매크로 블럭이 이전(B의 경우엔 이후도 포함) 영상의 어느 부분과 가장 관련성이 높은가를 알아내어 그 부분과의 공간상의 변위인 "움직임 벡터"(motion vector)와 두 영상간의 차이가 다음과 같이 부호화 되어 전송되게 된다.

각 블럭은 8x8 이산 코사인 변환(descrete cosine transformaton)의 과정을 거치게 된다. 변환으로 얻어진 각 계수들은 미리 정해진 값들로 나누어 양자화 되고, 지그재그로 재배열 된 후 영에 대한 RLC을 하게 된다. 마지막으로 허프만 코딩으로 부호화를 마친다.

I 픽쳐 인코딩은 공간적인 반복성에 대한 것이고, P 와 B 픽처는 시간적인 반복성에 대한 것이다. 다시 말해, 동영상을 이루는 이어지는 두개의 정지영상은 서로 상당히 비슷하며, 그래서 P 픽처는 보통 I 픽처의 10%, B 픽처는 2%의 크기로 부호화된다.

이 세 가지 프레임으로 이루어지는 일련의 프레임들은 GOP(Group of Pictures)라 불리는 구조를 이룬다. 다양한 구조의 GOP가 가능하지만 많이 쓰이는 것은 I_BB_P_BB_P_BB_P_BB_P_BB_ 의 순서로 15개의 프레임이 하나의 GOP를 구성하는 것이다. 이와 유사하게 12개의 프레임으로 만들어진 GOP구조도 자주 쓰인다. GOP 구조의 I, P, B 프레임의 구성 비율은 비디오 스트림의 성격, 출력 스트림이 갖어야 하는 대역폭(bandwidth)등에 따라 정해진다. 인코딩에 걸리는 시간도 비율을 결정하는 한 요소이다. 이를테면 실시간으로 전송해야 하는 생방송의 경우에 인코딩에 동원되는 자원은 한정되어 있으며, B 픽처가 많이 들어간 스트림은 I 픽처만으로 이루어진 스트림에 비해 인코딩에 3배 정도의 시간이 들 수 있다.

MPEG-2 인코더의 출력 비트율은 일정해야 하거나, 정해진 최대 비트율을 갖고 변할 수 있다. 가변 비트율의 예로 10.4 Mbps를 최대 비트율로 갖는 DVD 영화를 들 수 있다. 일정한 비트율을 얻기 위해서 양자화의 수준을 변경시킬 수 있다. 그러나 양자화가 심하게 될 경우엔 전송된 스트림이 디코딩 된 화면에 격자모양이 나타날 수 있다. 이 현상은 비트율이 내려갈수록 더욱 심각해진다.

[편집] MPEG-2 오디오 부호화

MPEG-2 는 또한 새로운 오디오 인코딩 방식을 도입한다. 이는

• 반으로 줄어든 샘플링 율을 사용하는 저속 비트율 인코딩 (MPEG-1 Layer 1/2/3 LSF)
• 다채널 인코딩. 최고 5.1 채널

[편집] DVD의 MPEG-2

DVD 표준에는 다음과 같은 제한 사항이 더해진다.

• 해상도의 제한
  • 720 x 480 픽셀, 초당 59.94 필드 (FCC)
  • 720 x 480 픽셀, 초당 29.97 프레임 (FCC)
  • 720 x 576 픽셀, 초당 50 필드 (CCIR)
  • 720 x 576 픽셀, 초당 25 프레임 (CCIR)
• 초당 최고 9,8 메가비트
• YUV 4:2:0
• 부가적인 자막 가능
• 오디오
  • 48 kHz MPEG-2 Layer 2 가능
  • 48 kHz 최고 초당 448 킬로비트의 디지털 돌비 가능
  • 754 또는 초당 1510 킬로비트 의 DTS 가능
  • 최소한 하나의 MPEG 오디오 또는 DD 오디오 트랙 포함
• GOP 구조의 제한

[편집] DVB에서의 MPEG-2

DVB-MPEG에 더해진 제한 사항.

• 다음의 SDTV 급 해상도만 허용됨.
  • 720 × 480 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 640 × 480 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 544 × 480 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 480 × 480 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 352 × 480 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 352 × 240 화소, 24/1.001, 24, 30/1.001 또는 30 프레임/초
  • 720 × 576 화소, 25 프레임/초
  • 544 × 576 화소, 25 프레임/초
  • 480 × 576 화소, 25 프레임/초
  • 352 × 576 화소, 25 프레임/초
  • 352 × 288 화소, 25 프레임/초

[편집] MPEG-2 표준 문서

ISO/IEC 13818-1 

시스템 - 비디오와 오디오 데이터의 동기화와 다중 송신을 정의.

ISO/IEC 13818-2 

비디오 - 비월주사, 순차주사 비디오 신호의 압축 코덱을 정의.

ISO/IEC 13818-3 

오디오 - 오디오 신호의 개념적인 압축 코덱, MPEG-1 (MP3)에 여러 채널을 쓸 수 있게 한 확장을 정의.

ISO/IEC 13818-4 

테스트 절차를 정의. 호환성 테스트를 위한 절차를 서술하였음.

ISO/IEC 13818-5 

소프트웨어 시뮬레이션 시스템을 정의.

ISO/IEC 13818-6 

DSM-CC (Digital Storage Media Command and Control의 약자)의 확장을 정의.

ISO/IEC 13818-7 

AAC (고급 오디오 코딩)

ISO/IEC 13818-9 

실시간 인터페이스를 위한 확장.

ISO/IEC 13818-10 

DSM-CC의 순응 확장

ISO/IEC 13818-11 

MPEG2 시스템 위의 IPMP

연재순서
1회. 32비트 윈도우 프로그램을 엄호하라
2회. 윈도우의 변신은 무죄? 64비트 윈도우 파악하기
3회. 64비트 윈도우 프로그램으로 가는 길

19세기말 노르웨이의 화가 에드바르트 뭉크가 남긴 ‘절규’는 노을이 비낀 하늘과 멀리 펼쳐진 북유럽의 해안선을 배경으로 불안한 얼굴을 한 남자를 그린 작품이다. 그동안 32비트 컴퓨팅에 안주해 있던 우리들은 이제 그림 속의 남자와 같이 혼란스러운 64비트 컴퓨팅 시대를 눈앞에 두고 있다.

이번 회에서는 혼돈 속에 작은 빛이 되기 바라는 마음으로 64비트 응용 프로그램을 개발하기 위한 환경 구축 방법과 새로운 소스를 개발하거나 기존의 32비트 소스를 포팅할 때 유념해야 할 사항들, 그리고 컴파일러의 적극적인 활용법에 대해 설명하겠다.

지난 2회에 걸쳐 64비트 윈도우에서 32비트 응용 프로그램을 WOW64 호환모드 위에서 동작하도록 개발하는 방법과 64비트 윈도우의 달라진 점을 개발자의 관점에서 설명했다.

하지만 이번 연재를 접한 독자들은 아직까지도 막상 64비트 응용 프로그램을 어떻게 개발해야 할지 막막할 수 있을 것이다. 64비트 응용 프로그램은 64비트 윈도우에서 개발해야 하는 걸까? 컴파일은 어디서 해야 하고 테스트는 어떻게 해야 하는 걸까? 64비트 개발 환경은 있는 것인가? 등등의 수많은 물음이 생길 것인데, 이번 회에는 그 물음에 작으나마 도움이 되는 내용을 언급하려고 한다.

먼저 32비트와 64비트 환경이 공존하는 지금 응용 프로그램 개발 모델은 어떻게 설정해야 할까? MS에서 권장하고 있는 개발 모델은 <그림 1>과 같이 32비트 윈도우에서 32비트와 64비트 코드를 하나로 개발하고 컴파일하며 32비트 응용 프로그램은 32비트 윈도우에서 테스트하고 64비트 응용 프로그램은 64비트 윈도우에서 테스트하는 것이다.

<그림 1> 윈도우 응용 프로그램 개발 모델

심지어 완벽한 64비트 개발환경 지원을 목표로 하는 비주얼 스튜디오 닷넷 2005(아직까지는 베타이므로 변경될 수도 있다)도 64비트 윈도우에서는 WOW64에서 동작하기 때문에 32비트/64비트 소스의 작성 및 컴파일은 32비트 환경에서 하는 것이 풍부한 32비트 개발 지원 도구를 사용할 수 있다는 점에서 훨씬 유리하다. 결론적으로 32비트 윈도우에서 크로스 컴파일된 64비트 실행 파일을 64비트 윈도우에서 실행하고 테스트하면서 남아 있는 버그를 잡는 것이 훨씬 효율적인 개발 모델인 것이다.

무엇을 준비해야 하는가?
이제 드디어 64비트 응용 프로그램을 만들어야 할 시간이다. 현재 64비트 응용 프로그램을 개발하기 위한 환경은 아직 완벽하지 않은 상태라고 할 수 있다. 키를 쥐고 있는 MS에서 제공하는 방법은 몇 가지 개발 가이드 정도를 제공하고 있다. 무엇보다 64비트 응용 프로그램을 개발하기 위해 가장 어려운 점 중 하나는 아직까지 공식 64비트 컴파일러와 통합개발환경이 제공되고 있지 않다는데 있다.

MS는 올해 상반기에 출시 예정인 비주얼 스튜디오 닷넷 2005를 통해 x64 및 IA64 플랫폼에서 수행 가능한 응용 프로그램을 통합개발환경에서 원활하게 개발할 수 있도록 계획하고 있다. 그렇다면 비주얼 스튜디오 닷넷 2005가 정식 출시될 때까지 우리는 64비트와 32비트가 맞물린 이 혼란의 시대에 가만히 앉아 있어야 할 것인가? MS가 제공하는 플랫폼 SDK에 그 해답이 있다.

이가 없으면 잇몸으로 - 플랫폼 SDK와 비주얼 스튜디오 닷넷 2003
현재 플랫폼 SDK는 64비트 응용 프로그램을 개발하기 위해 필요한 가장 기본적인 툴킷이다. 플랫폼 SDK에는 64비트 응용 프로그램을 개발하기 위한 C/C++ 컴파일러와 라이브러리 및 헤더 그리고 기본적인 디버깅 도구를 포함하고 있다. 그래서 64비트 응용 프로그램을 개발하기 위해서는 플랫폼 SDK 최신판과 비주얼 스튜디오 닷넷 2003이 필요하다. 플랫폼 SDK를 설치하기 위해서는 어떻게 해야 할까? 관련된 MS 웹사이트를 통해 설치할 수 있다(방법은 그다지 어렵지 않으므로 각자 설치해 보자).

플랫폼 SDK의 설치를 마친 후에는 플랫폼 SDK에서 제공하는 64비트 빌드 환경을 이해해야 한다. 플랫폼 SDK는 미리 준비된 5개의 빌드 환경을 제공하는데 이 중에서 64비트 빌드 환경(윈도우 서버 2003 64비트 및 윈도우 XP 64비트)을 찾아 볼 수 있고 각 빌드 환경을 실행하면 지정한 빌드 환경이 설정된 커맨드 윈도우가 실행된다. 이 빌드 환경은 「시작메뉴->프로그램->플랫폼 SDK 설치 그룹->Open Build Environment Window」에서 찾아볼 수 있다.

이 빌드 환경들은 내부적으로는 플랫폼 SDK가 설치된 디렉토리에 존재하는 SetEnv.bat 파일을 특정 파라미터로 실행해 구성된 환경이다. 시작 프로그램에 미리 등록된 빌드 환경을 실행하지 않고 개발자가 직접 SetEnv.bat을 특정 파라미터로 실행해 빌드 환경을 변경할 수도 있는데 그 방법은 ‘SetEnv.bat /?’ 로 실행해 보면 어렵지 않게 알 수 있다. 이 빌드 환경을 구성하는 주요 요소는 다음과 같다.

개발자가 특정 빌드 환경을 지정해 실행하면 그 빌드 환경애 맞도록 %LIB%, %INCLUDE%, %PATH%가 설정되어 실행된다. 이 빌드 환경을 정확하게 이해하기 위해 다음과 같은 순서로 테스트를 해보자.

[1] C나 C++로 된 간단한 응용 프로그램 하나를 작성한다.
[2] 플랫폼 SDK의 빌드 환경 중 Set Windows XP 64-bit Build Environment (Debug)을 실행해 보자.
[3] 커맨드 윈도우가 나타나면 작성한 응용 프로그램을 다음과 같이 컴파일하자. 참고로 /Wp64는 아주 유용하며 필수적인 옵션으로 작성된 소스에서 64비트 프로그램으로서 적합하지 않은 부분을 자동으로 검출해 경고해 준다.

[4] 생성된 오브젝트의 링킹을 수행해서 빌드를 마무리하자.

[5] 생성된 실행 파일이 32비트 윈도우에서 실행되지 않고 64비트 윈도우로 복사해서 수행되는지 확인해 보자.

지금까지 한 작업을 간단히 정리해 보면 64비트 응용 프로그램을 개발하기 위해서는 MS에서 제공하는 기존의 컴파일러로는 불가능하기 때문에 플랫폼 SDK를 설치해야 하고 설치한 후에는 64비트 빌드 환경을 설정하고 간단히 커맨드 윈도우에서 소스를 컴파일 및 링킹하는 방법을 설명해 보았다.

커맨드 윈도우에서 컴파일 및 링킹 작업에 익숙한 개발자라면 여기까지만 설명을 해도 더 이상 플랫폼 SDK를 이용한 방법을 설명할 필요가 없겠지만 대부분의 개발자들은 통합개발환경인 IDE에 익숙하기 때문에 비주얼 스튜디오 2003과 플랫폼 SDK를 이용한 64비트 개발환경 구축이 필요하다. 이 방법도 다음과 같은 순서대로 따라하면 그다지 어렵지 않게 습득할 수 있다.

[1] C나 C++로 된 간단한 응용 프로그램 하나를 작성한다.
[2] 플랫폼 SDK의 빌드 환경 중 Set Windows XP 64-bit Build Environment (Debug)을 실행해 보자.
[3] 비주얼 스튜디오 닷넷을 다음과 같이 실행한다. 참고로 devenv는 일반적으로 C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE에 존재한다.

[4] 비주얼 스튜디오 닷넷 2003 통합 환경에서 작성한 응용 프로그램 프로젝트를 연다.
[5] 통합환경 메뉴의 「빌드->구성관리자」에서 <화면 1>과 같이 64BitDebug라는 새로운 솔루션 구성을 추가한다. 이때 기본 구성은 Debug 설정을 복사하도록 한다.

<화면 1> 새로운 솔루션 구성 추가

[6] 통합환경 메뉴의 「프로젝트->프로젝트 속성페이지」에서 몇 가지 정보를 조정한다. 먼저 디버깅 정보 형식을 <화면 2>와 같이 ‘프로그램 데이터베이스(/Zi)’로 변경한다. ‘편집하며 계속하기를 위한 프로그램 데이터베이스(/ZI)’ 형식은 플랫폼 SDK에서 제공하는 64비트 컴파일러에서는 지원하지 않기 때문이다.

<화면 2> 디버깅 정보 형식 변경

[7] 계속해서 <화면 3>과 같이 프로젝트 속성 페이지의 ‘코드 생성’에 있는 ‘버퍼 보안 검사’를 ‘아니오’로 변경한다.

<화면 3> 버퍼 보안 검사 변경

[8] 계속해서 <화면 4>와 같이 프로젝트 속성 페이지의 「링커-명령줄」에 ‘/MACHINE:IA64’ 추가 옵션을 입력한다.

<화면 4> 링커에 추가옵션 설정

[9] 앞 단계에서 ‘/MACHINE:IA64’로 설정했기 때문에 <화면 5>와 같이 「링커-고급」에서 ‘대상 컴퓨터’를 ‘설정 안함’으로 변경한다.

<화면 5> 링커의 대상 컴퓨터 설정을 변경

[10] 통합환경에서 프로젝트를 빌드하고 생성된 실행 파일이 32비트 윈도우에서 실행되지 않고 64비트 윈도우로 복사해서 수행되는지 확인해 보자.

이제까지 플랫폼 SDK와 비주얼 스튜디오 2003을 이용한 64비트 응용 프로그램 개발 환경 구축을 살펴봤다. 참고로 플랫폼 SDK로는 IA64 계열에 비해 아쉽게도 x64 계열은 완벽히 지원하지 않고 있는 상황이어서 x64 계열 응용 프로그램을 작성하기는 어렵다. 또한 managed C++를 사용한 프로그램을 작성할 수 없고 native C++로 작성된 프로그램만 지원한다. x64 계열과 IA64 계열을 모두 지원하고 managed C++를 지원하는 개발환경은 아직 없는 것일까? 완벽한 지원을 기대한다면 올 상반기 출시 예정인 비주얼 스튜디오 닷넷 2005를 기다려봐야 할 것 같다.

64비트 개발을 위해 준비된 개발도구 - 비주얼 스튜디오 닷넷 2005
닷넷 프레임워크 2.0과 완벽한 64비트 개발 환경 지원을 탑재한 비주얼 스튜디오 닷넷 2005(코드명 : Widbey)는 <화면 6>과 같이 통합개발환경에 존재하는 구성관리자의 플랫폼 항목에서 x64와 IA64를 선택할 수 있어서 앞서 설명한 바와 같이 플랫폼 SDK의 64비트 헤더와 라이브러리 및 컴파일러를 사용하지 않아도 된다. 또한 native C./C++ 및 managed C++도 64비트 컴파일을 할 수 있는 64비트 응용 프로그램 개발을 하기 위한 완전한 개발 환경이다.

<화면 6> 비주얼 스튜디오 닷넷 2005의 구성 관리자

현재까지는 베타테스트가 진행 중이므로 웹사이트에서 각자 다운받아 설치후 사용해 보기 바란다.

32비트에서 64비트로 이사가기
64비트 컴퓨팅 세상이 온다고는 하지만 아직까지는 32비트 컴퓨팅을 위한 소스가 많이 존재하는 것이 현실이고 64비트 윈도우를 위한 소스를 새로 개발하기 보다는 기존 소스를 64비트 윈도우에서도 동작할 수 있도록 포팅하는 것이 대부분의 경우 현실적일 것이다.

개발자 측면에서 볼 때 기존 16비트 윈도우 응용 프로그램 소스를 32비트 응용 프로그램 소스로 포팅하는 것보다는 32비트 소스를 64비트 소스로 포팅하는 것이 훨씬 손쉬운 작업이다, 그러나 쉽다고 해서 무작정 할 수 있는 것은 아니고 포팅 가이드라인을 정하고 계획을 세우고 개발을 한 후 실제 64비트 윈도우에서 테스트해 보는 일련의 공정을 거쳐야만 한다.

64비트 포팅 가이드라인
포팅 계획 세우기
포팅 계획을 세우기에 앞서 먼저 포팅 작업을 위한 작업량을 측정해야 한다. 작업량을 측정할 수 있는 요소로는 첫 번째로 현재 32비트 응용 프로그램 소스의 문제를 먼저 인식해야 한다. 그래서 64비트 컴파일러로 일단 컴파일을 해 보고 나타나는 오류와 경고들을 알아야 한다.

두 번째로는 공유해서 사용하는 모듈들의 리스트와 모듈간의 사용 관계를 파악해야 한다. 그래서 사용하고 있는 모듈 중 다른 팀 또는 다름 개발회사에서 개발한 모듈이 있다면 그 모듈이 64비트로 포팅할 계획을 수립하고 있는지 점검해야 한다.

세 번째로는 하위 호환을 위한 코드나 어셈블리 코드를 점검해야 한다. 예를 들어 64비트 윈도우에서는 16비트 응용 프로그램을 구동할 수 없기 때문에 16비트 윈도우 응용 프로그램 코드는 더 이상 64비트 윈도우에서 동작하지 않기 때문이다. 반면에 x86 어셈블리 코드는 WOW64에서 동작하고 x64의 경우 성능에도 별다른 차이가 없지만 아이테니엄을 사용하는 IA64의 경우 성능의 저하가 있을 수 있기 때문에 성능 향상을 위해서는 x86 어셈블리 코드를 IA64 어셈블리 코드로 변경하는 것을 고려해봐야 한다.

작업량 측정이 끝났다면 전체 응용 프로그램을 포팅할 계획을 세워야 한다. 이때 일부분만을 포팅하기는 어렵다. 만약 부득이한 경우 거의 소스를 변경하지 않고 32비트 소스를 64비트 응용 프로그램으로 컴파일할 수 있는 방법이 있는데 ‘/LARGEADDRESSAWARE:NO’ 옵션을 사용하는 것이다. 이 옵션은 생성된 코드 내의 모든 포인터와 데이터가 32비트 프로세스와 같이 2G안에서 동작하도록 하는 옵션이다. 그러나 이 옵션은 매우 단기적인 처방이며 같이 사용하는 모든 모듈이 이 방식으로 컴파일되어야 하므로 향후 더 많은 문제점을 발생시킬 수 있다.

또한 개발에 사용되는 기술들을 검토해봐야 하는데 DAO(Data Access Object)나 Jet 데이터베이스 엔진의 경우 64비트 윈도우에서 지원하지 않기 때문에 소스 내에서 이런 기술을 사용했다면 유사한 다른 기술을 사용할 것을 검토해봐야 한다. 그리고 하나의 소스에서 생성되는 32비트와 64비트 응용 프로그램을 별개의 제품군으로 취급하고 출시하는 것을 권장한다. 왜냐하면 소스는 공유하지만 테스트 및 제품 마스터링, 마케팅 및 고객지원 이슈가 다르기 때문이다.

개발하기
아직까지 비주얼 스튜디오 닷넷 2005와 같은 완전한 64비트 개발환경이 구축되어 있지는 않지만 신속히 64비트 응용 프로그램을 출시하려는 개발자라면 64비트 응용 프로그램 개발을 늦출 수는 없다. 그러므로 앞서 설명한 플랫폼 SDK를 이용해 먼저 64비트 응용 프로그램을 작성하는 것이 좋다.

그리고 여러 번 강조하지만 하나의 소스코드로 32비트와 64비트 응용 프로그램이 컴파일될 수 있도록 해야 한다. 이것이 바로 이렇게 하위호환성을 유지하고 하나의 코드로 32비트와 64비트를 개발하게 하기 위해 LLP64 데이터 모델을 채택한 이유이기 때문이다. MS의 윈도우와 SQL 서버도 하나의 소스코드에서 32비트와 64비트 제품군을 빌드했다고 한다. 그리고 뒤에 자세히 언급하겠지만 컴파일러에 새롭게 추가된 최적화 특징들을 사용할 것을 권장한다. 다음은 상세한 포팅 순서이다.

[1] 64비트 프로젝트를 구성한다. VC++ 6.0으로 작성된 프로젝트라면 VS 2003/VS 2005를 이용해서 포팅하려는 타입(APP/LIB/DLL)에 맞는 64비트 빈 프로젝트를 만들고 VC++ 6.0의 프로젝트를 참조해서 파일들을 64비트 프로젝트에 추가한다.
[2] 64비트 프로젝트에 맞게 프로젝트 설정들을 변경한다. 일반적으로 신경써서 맞춰줘야 하는 부분은 다음과 같다.

[3] /Wp64 옵션을 켜고 컴파일을 해보면(/Wp64 옵션은 일반적으로 기본으로 켜져 있다) 경고/오류가 나타나는데 일반적으로 다음과 같은 내용들이 나온다.

[4] 발생한 오류와 경고를 MSDN을 참조해 해결한다.
[5] 여러 개의 모듈로 제품이 구성되어 있을 경우 기본 라이브러리->DLL->실행파일 순으로 전체 프로젝트를 포팅해야 한다.

테스트하기
먼저 테스트할 프로그램이 순수하게 64비트로 구성된 프로그램인지 아니면 WOW64를 사용하는 부분도 있는지를 검토해야 한다. 이러한 것은 테스트 계획 수립단계에서 결정되어야 하며 이에 따라서 테스트 도구가 64비트용만 있으면 되는지 아니면 32비트와 64비트용이 모두 필요한지가 결정이 되고 테스트 환경 구축 및 일정 산정에도 도움이 되기 때문이다.

일반적으로 32비트와 64비트 프로그램 모두 같은 소스를 기반으로 하기 때문에 테스트 단계에서의 버그 수정은 64비트 환경에서 테스트하고 버그를 수정한 후 32비트 환경에서 부작용이 없는지 재컴파일 한 후 테스트하고 다시 64비트 환경에서 재컴파일한 후 테스트해야 한다. COM이나 RPC를 사용할 경우에는 32비트와 64비트 모두 정상적으로 통신하는지 테스트돼야 하고 필요할 경우 네트워크 너머에 존재하는 16비트 컴퍼넌트들과 네트워크 통신에 이상이 없는지도 테스트돼야 한다.

때에 따라서는 32비트 윈도우를 위해 개발된 제품도 64비트 윈도우에서 테스트돼야 하는데 제품을 사용하는 고객들이 32비트 응용 프로그램을 64비트 윈도우에서 WOW64를 통해 사용할 수도 있기 때문이다. 그밖에 64비트 윈도우에서는 32비트 윈도우에 비해 메모리 사용방법이 크게 변경되었기 때문에 많은 메모리를 탑재한 시스템에서도 테스트를 해봐야 한다.

포인터를 다룰 때 신경써야 할 것들
64비트 윈도우가 채택한 LLP64 데이터 모델은 기존의 데이터 타입은 호환성을 위해 32비트를 유지하고 포인터를 64비트로 변경한 데이터 모델이다. 그래서 64비트 응용 프로그램을 개발하기 위해서는 다른 어떤 데이터보다 포인터를 다룰 때 주의해야 한다. 이번 절에서는 포인터를 다룰 때 신경써야 할 사항 몇 가지를 살펴보자.

◆ 포인터를 int, long, , UINT, ULONG, DWORD.으로 타입 캐스팅하지 말아야 한다

비트 수준의 작업을 하기 위해 포인터를 타입 캐스팅해야 할 때는 반드시 32비트와 64비트 윈도우에서 모두 사용할 수 있는 타입인 UINT_PTR, INT_PTR을 사용해야 한다. 64비트 윈도우에서는 포인터의 크기가 64비트이고 int나 long은 32비트이기 때문에 포인터를 int, long, ULONG, DWORD로 타입캐스팅 해서는 안 된다. 다음 예를 참고하자.

참고로 HANDLE도 void*로 정의되어 있기 때문에 HANDLE도 포인터와 마찬가지로 취급해야 한다.

◆ 부득이하게 포인터의 데이터가 손실되더라도 32비트로 타입 캐스팅해야 할 경우에는 PtrToLong()이나 PtrToUlong() 함수를 이용해야 한다
이 함수들은 Basetsd.h에 정의되어 있다. 이 함수들을 사용하면 데이터 손실 경고를 발생시키지 않는다. 이 함수들은 조심해서 사용해야 하는데 포인터가 타입 캐스팅된 이후에는 데이터가 손실된 것이므로 이 값들을 포인터로 다시는 사용해서는 안 된다. 이 함수들은 상위 32비트 값들을 얻어낸다.

◆ 값을 얻어오는 OUT 형태의 인자를 사용할 때 주의해야 한다
다음과 같이 정의된 함수를 예로 생각해 보자.

이 함수를 다음의 예와 같이 호출해서는 안 된다. &ul을 PULONG*으로 타입캐스팅을 했기 때문에 컴파일러 오류는 발생하지 않지만 함수에서는 &ul에 64비트 포인터 값을 쓰게 된다. 이 코드는 32비트 윈도우에서는 정상적으로 동작하겠지만 64비트 윈도우에서는 포인터 데이터의 손실이 발생하게 된다.

대신에 다음과 같이 호출해야 한다.

◆ 다형성 인자를 사용할 경우 UINT_PTR이나 PVOID를 사용해야 한다
32비트 윈도우에서는 어떤 타입의 데이터를 넘길지 결정할 수 없을 때 DWORD 등을 함수의 인자로 사용해서 인자를 넘길 때 타입 캐스팅을 해서 사용하기도 했었다. 그러나 64비트 윈도우에서는 반드시 UINT_PTR이나 PVOID와 같은 64비트 윈도우와 32비트 윈도우에서 모두 사용할 수 있는 데이터 형을 사용해야 한다.

◆ 새로운 윈도우 클래스 함수를 이용해야 한다

윈도우나 클래스에 포인터 데이터를 포함하고 있다면 새로운 윈도우 클래스 함수(GetClassLongPtr/GetWindowLongPtr/SetClassLongPtr/SetWindowLongPtr)를 사용해야 한다. 또한 64비트 응용 프로그램 개발 환경의 WInUser.h에는 GWL_WNDPROC/GWL_HINSTANCE/GWL_HWDPARENT/GWL_USERDATA은 정의되어 있지 않고 대신에 GWLP_WNDPROC/GWLP_HINSTANCE/GWLP_HWNDPARENT/
GWLP_USERDATA/GWLP_ID가 정의되어 있다. 예를 들어 다음과 같은 코드는 64비트 윈도우에서는 동작하지 않는다.

이 예를 64비트 윈도우에서 동작하도록 수정하면 다음과 같다.

이밖에도 WNDCLASS 구조체의 cbWindExtra 멤버를 추가적인 값을 저장하기 위해 사용하려고 할 때 기존에는 sizeof(DWORD) 크기만큼만 할당해도 되었지만 64비트 윈도우에서는 sizeof(DWORD_PTR)만큼을 할당해 사용해야 한다.

◆ 윈도우나 클레스의 데이터를 접근할 때에 FIELD_OFFSET.을 이용해야 한다
기존에는 윈도우 데이터를 접근할 때 오프셋 크기를 4바이트로 가정하고 하드코딩해 접근하기도 했다. 하지만 64비트 윈도우에서는 절대 사용해서는 안 되고 대신에 윈도우나 클래스 데이터를 접근할 때는 FIELD_OFFSET 매크로를 사용해야 한다.

◆ 플랫폼에 따라 LPARAM, WPARAM, LRESULT 타입의 크기는 변한다
이 타입들은 포인터나 다형성 인자로 사용되는 타입이기 때문에 64비트 코드로 컴파일될 때 이 타입들은 64비트 크기로 컴파일된다. 그러므로 64비트 환경에서 정상적으로 동작하게 하려면 LPARAM, WPARAM, LRESULT 들을 32비트의 크기를 가지는 DWORD, ULONG, UINT, INT, int, long 값들과 같이 사용하면 안 된다.

구조체를 다룰 때 신경써야 할 것들
64비트 윈도우에서는 32비트 윈도우와 달리 데이터의 팩킹을 8바이트 단위를 기본으로 한다. 그래서 구조체 내의 구성요소를 적절히 배치하는 것이 구조체가 실제 메모리에서 차지하는 양을 줄일 수 있는 좋은 방법이다. 또한 #pragma pack을 지정해 소스를 작성하는 것에 주의해야 하는데 기본 패킹인 8바이트를 4바이트나 2바이트, 심지어는 1바이트로 변경할 경우 코드 크기가 증가할 뿐만 아니라 동적인 메모리의 사용량도 늘어날 수밖에 없다.

그러므로 64비트 윈도우에서 동작하는 응용 프로그램 소스를 작성할 때는 구조체의 구성요소 배치 및 8바이트 정렬에 신경을 써야 하고 팩킹 크기에 의존적인 코드를 작성하지 않아야 한다. 그러나 예를 들어 유닉스, 32비트 윈도우, 64비트 윈도우 등에서 모두 동작하게 하려는 코드의 경우 어쩔 수 없이 패킹을 최소공배수로 조정해야 할 수도 있지만 그런 경우 코드 크기 증가와 처리 속도의 저하가 있을 수 있다는 것을 항상 고려해야 한다.

신경써야 할 다른 여러 가지 것들
앞서 설명한 것들 외에도 64비트 응용 프로그램을 개발할 때는 다음과 같이 신경써야 할 것들이 몇 가지 더 있다.

◆ 32비트 윈도우에서 사용하던 라이브러리나 프레임워크 중에 DAO나 VBA와 같이 64비트에서 더 이상 사용할 수 없는 것들이 있으므로 64비트 응용 프로그램의 개발을 할 때 사용하려는 라이브러리나 프레임 워크가 64비트 윈도우를 지원하는지 확인해봐야 한다.

◆ 사용하는 API가 64비트 윈도우용인지도 살펴봐야 한다. 대부분의 윈도우 API는 64비트에서 사용 가능하지만 일부 API는 변경된 것이 있으므로 사용하는 API의 지원 여부를 MSDN을 통해서 항상 확인해야 한다.

◆ 비트연산에 대해서도 신경써야 하는데 기존의 32비트 윈도우에서는 -1을 비교할 때나 INVALID_HANDLE 대신 0xffffffff를 사용하는 소스도 있었지만 64비트 윈도우에서는 사용해서는 안 되는 값이다. 또한 32비트 소스에서 1<<33과 같이 비트 시프트 연산을 할 경우 정상 동작하겠지만 64비트 소스에서는 유효하지 않는 코드이다. 이와 유사하게 고려할만한 점으로는 기존에 사용하던 소스의 알고리즘이 비트 크기에 관련 있을 경우 수정을 해야 한다.

◆ 데이터 크기를 알아 올 때에는 반드시 컴파일 타임에 데이터 타입의 크기를 알아올 때 사용하는 sizeof()를 사용하도록 해야 한다.

◆ 구조체 내의 특정 필드의 오프셋을 알고 싶을 때에는 컴파일 타임에 오프셋을 얻어 오는 FIELD_OFFSET 매크로를 이용해야 한다.

◆ 플랫폼에 의존적인 어셈블리 코드를 소스 내에 사용하지 말아야 하며 필요할 경우 컴파일 타임에 각 플랫폼 별로 어셈블리 코드를 사용하도록 해야 한다.

◆ 꼭 필요한 경우가 아니라면 명시적인 구조체 팩킹을 하지 말고 64비트 윈도우에서는 8바이트를 기본으로 패킹되는 것이 좋다.

◆ 인터페이스를 개발할 때는 플랫폼에 의존적이지 않은 잘 분리되고 추상화된 인터페이스로 만들어야 한다.

◆ 64비트 윈도우에서는 _WIN16, _WIN32외에도 _WIN64가 추가되었기 때문에 다음과 같은 가정은 더 이상 유효하지 않다.

◆ 데이터 타입 정렬에 주의해야 한다. TYPE_ALIGNMENT 매크로는 지정한 데이터 타입의 정렬 바이트를 리턴하는 기능을 한다. 다음 코드를 참조하자.

데이터 정렬은 상당히 중요한데 32비트 윈도우에서는 커널 모드와 사용자 모드 모두에서 데이터 정렬이 되어 있지 않아도 시스템이 자동으로 처리했지만 64비트 윈도우에서는 커널 모드의 경우 자동으로 데이터 정렬 예외를 처리하지 않기 때문이다. 그래서 반드시 데이터 정렬을 맞추어 코드를 작성해야 한다.

◆ NOT 오퍼레이션을 사용할 때 주의해야 한다. 다음과 같은 경우를 생각해 보자.

이 코드의 문제는 ~(b?1) 연산이 생성하는 결과가 0xFFFF FFFF xxxx xxxx.이 아닌 0x0000 0000 xxxx xxxx 이라는데 있다. 그래서 다음과 같이 코드를 수정해야 한다.

◆ unsigned와 signed 데이터 연산에 주의해야 한다. 다음과 같은 경우를 생각해 보자.

x가 unsigned이기 때문에 문제가 발생하는데 x로 인해 전체 수식이 unsigned로 바뀌기 때문이다. 이 수식에서 y가 음수만 아니라면 정상적으로 동작할 수도 있다. 만일 y가 음수라면 수식에서 y는 unsigned 값으로 변경되고 32비트 정밀도로 pvar1과 곱셈과 덧셈을 수행하게 되고 32비트 unsigned 음수 값은 64비트 양수 값으로 변경되게 되어서 비정상적인 결과가 생성된다. 이 문제를 해결하려면 x를 signed 값으로 선언하거나 수식 내에서 명시적으로 LONG으로 타입캐스팅해야 한다.

◆ 작은 크기의 데이터 할당을 할 때 주의해야 한다. 다음과 같은 예를 살펴보자.

다음 코드는 잘못된 코드인데 컴파일러는 8바이트 정렬을 맞추기 위해 4바이트를 추가적으로 패딩해서 할당할 것이기 때문이다.

이 코드를 다음과 같이 수정하면 된다.

◆ printf나 wsprintf를 이용해 포인터를 출력할 때는 포인터를 출력하는 형식인 %p를 사용해야 한다. 32비트 윈도우에서는 다른 형태로 포인터를 출력해도 되었지만 64비트 윈도우에서는 포인터만이 64비트이기 때문이다.

컴파일러를 적극적으로 활용하자
64비트 개발환경에서는 새로운 최적화 옵션들이 추가되었다. 이 최적화 옵션들은 x64 계열보다는 IA64 계열에서 더욱 중요한데 이전의 x86 CPU들이 컴파일러의 최적화뿐만 아니라 CPU의 최적화 수행에도 의존했었지만 IA64의 경우 CPU에서의 최적화 수행보다는 컴파일러의 최적화가 더욱 중요해졌기 때문이다.

컴파일러에 새롭게 추가된 최적화 옵션은 크게 두 가지인데 하나는 수행성능 측정데이터를 이용한 최적화(Profile Guide Optimization)이고 다른 하나는 전체 프로그램 영역 기반의 최적화(Whole Program Optimization)이다.

수행성능 측정 데이터를 이용한 최적화는 두 단계의 컴파일 단계로 진행된다. 첫 번째 컴파일 단계에서는 생성된 프로그램을 주어진 테스트 상황에 따라 구동시키고 프로그램의 실행 패턴을 기록해 두었다가 이 정보를 이용해서 두 번째 컴파일 단계에 최적화 자료로 활용한다. 기존의 컴파일 방식을 생각해 보자. 다음의 간단한 두 코드 중 첫 번째를 참조해 보면 foo()와 bar() 함수 중 어떤 함수가 실제로 많이 호출될까? 즉 실제 코드가 수행될 경우 a가 b 보다 작은 경우는 몇 %나 될까? 두 번째 코드에서는 bar()가 반복 수행 되는 횟수는 얼마나 될까? 즉, count 값은 얼마나 될까?

이 값들은 컴파일 타임에는 결정할 수 없는 값으로서 코드가 수행 중에만 알 수 있는 값이다. 이러한 테스트 시나리오에 의해 생성된 이 값들을 코드 최적화에 활용하는 것이 수행성능 측정 데이터를 이용한 최적화이다. 전체 프로그램 영역 기반의 최적화 방법은 한 프로그램이 여러 개의 소스코드로 구성될 경우 각각의 소스코드 내에서만 최적화를 수행하는 것이 아니고 프로그램을 구성하는 모든 소스코드를 대상으로 최적화를 수행한다. 전체 프로그램 영역기반 최적화와 수행 성능 측정 데이터를 이용한 최적화를 적용하는 순서는 <그림 2>를 참고하면 손쉽게 알 수 있다.

<그림 2> 전체 프로그램 영역기반 최적화와 수행 성능 측정 데이터를 이용한 최적화

MS에서 측정한 값에 의하면 모든 아키텍처에서 수행성능 측정 데이터를 이용한 최적화를 하게 되면 정수연산과 부동소수점 연산 모두 <그림 3>과 같이 성능이 향상된다고 한다.

<그림 3> LTCG를 적용했을 때의 성능 향상 비율

LTCG를 적용했을 때의 성능 향상 비율(%) 인텔 아이테니엄 2 AMD AMD64 인텔 x86 정수 연산 부동소수점 연산

그러나 수행 성능 측정 데이터를 이용한 최적화가 항상 좋은 것만은 아니다. 예를 들어 입력 조건이 일정치 않은 응용 프로그램의 경우 코드가 자주 수행되거나 코드의 반복 수행 횟수 등이 그때그때 달라질 수 있기 때문이다. 일반적으로 수행 성능 측정 데이터를 이용한 최적화는 입력이 예측 가능한 범주 내에서 일정 분포를 유지할 경우 유용한 성능 최적화 방법이라고 할 수 있다.

결론적으로 수행 성능 측정 데이터를 이용한 최적화는 실제 사용자 환경과 유사한 테스트 시나리오를 사용해야만 좋은 최적화 결과를 얻을 수 있다.

64비트 컴파일러의 경고
앞에서 64비트 응용 프로그램을 개발하기 위한 환경을 구축하는 방법과 주의해야 할 점, 그리고 최적화하는 방법을 설명했다. 그렇다면 정작 64비트 소스의 컴파일을 수행한 후에 나타나는 컴파일 경고들은 어떤 것들이 있을까?이전에 설명했듯이 32비트와 64비트 응용 프로그램은 하나의 소스로 작성되는 것을 권장하고 있다.

대신 컴파일러에 ‘/Wp64’ 옵션을 제공하는데 이 스위치를 이용하면 컴파일을 수행할 때 소스 내에서 LLP64 데이터 모델, 즉 64비트 소스로서 문제가 있을 만한 포인터 타입 캐스팅, 데이터 타입 캐스팅, 기타 여러 가지 문제점들을 경고해 준다. 자세한 경고의 종류와 내용은 <표 1>을 참고하자.

<표 1> /Wp64로 컴파일할 때 나타나는 경고 종류

이중 가장 많이 보게 되는 경고가 C4311인데 다음의 간단한 두 코드 중 첫 번째 코드의 경우에 발생하는 경고이다. 64비트 윈도우에서는 ULONG은 32비트이고 PUCHAR는 64비트이므로 첫 번째 코드대로라면 64비트를 32비트로 형변환하게 되어서 포인터의 정보 손실이 발생할 수 있다. 그러므로 두 번째 코드와 같이 ULONG_PTR을 사용하도록 소스를 수정하면 경고를 제거할 수 있다.

64비트 응용 프로그램을 개발하기 위해서는 컴파일러가 알려주는 이러한 기본적인 경고들을 모두 제거하는 것이 64비트 소스의 잠재적인 문제를 해결하고 코드의 오류 발생 가능성을 최소화하는 방법이므로 반드시 경고를 제거하도록 해야 한다.

변화의 시대를 두려워 말자
필자는 이번 연재를 통해 먼저 64비트 윈도우에서 32비트 응용 프로그램을 구동시키기 위한 방법을 언급했고 두 번째로 64비트 윈도우가 핵심적으로 변화된 점을 설명했으며, 마지막으로 64비트 윈도우에서 동작하는 순수한 64비트 응용 프로그램을 만드는 방법과 기존 32비트 소스를 64비트로 포팅하는 방법을 설명했다. 비록 짧은 설명이었지만 64비트 세상으로 가기 위한 작은 다리는 되었으리라고 생각한다.

흔히들 소프트웨어 분야는 아직 많은 기술들이 더 많이 개발되어야 하는 신생 학문이기 때문에 새로운 기술 습득에 어려움이 많다고 한다. 필자 역시 새로운 길로 가는 것을 두려워한다. 하지만 혼돈과 변화의 시대를 두려워하기 보다는 적극적으로 받아들여 그 시대의 주인이 되는 것이 최근 개발자들이 겪고 있는 정체성에 대한 답이 되지 않을까 생각한다. 무언가 필요한 것을 만들어내는 사람은 개발자라는 것을 잊지 말고 다가오는 64비트 세상을 주인이 되기를 바라며 이번 연재를 마치려 한다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다

유병인 (안철수연구소)

2005/05/23

원문 : http://www.zdnet.co.kr/techupdate/lecture/os/0,39024998,39136563,00.htm