[윈도우즈 시스템 프로그래밍] 3. 프로그램 구현 관점에서의 32비트와 64비트 & 오류의 확인

이 포스트는, 윤성우 저자님의 '뇌를 자극하는 윈도우즈 시스템 프로그래밍'을 바탕으로 제 생각을 재구성하여 정리한 포스트입니다.

 

목차

---

• 64비트 기반 프로그래밍
• 64비트와 32비트 공존의 문제점
• Windows 스타일 자료형

 

64비트 기반 프로그래밍

---

 64비트 기반 프로그래밍이란, 64비트 시스템을 고려한 프로그래밍으로 자료형에 대해서 고려해야 한다.

LLP 64 vs LP64

64비트 시스템으로 가면 자료형이라던가 타입을 재구성할 필요 있다.

운영체제	모델	char	short	int	long	포인터
Windows	LLP64	1바이트	2바이트	4바이트	4바이트	8바이트
UNIX	LP64	1바이트	2바이트	4바이트	8바이트	8바이트

기존 32비트 시스템과 큰 차이는 포인터밖에 없네..?라고 생각할 수 있는데, 맞는 이야기다.

32비트 시스템과의 호환성을 고려해서 자료형이 디자인되었기 때문에 우리는 포인터의 크기만 생각하면 된다.

 

64비트와 32비트 공존의 문제점

---

데이터 손실의 문제

#include <stdio.h>
int main(void)
{
	int arr[10] = {0,};
	int arrVal = (int)arr; // 데이터 손실이 발생 할 수 있는 위치
	printf("pointer: %d \n", arrVal);
	return 0;
}

 64비트 기반으로 프로그래밍을 할 때 주의할 점은 포인터는 4바이트가 아니라 8 바이 트라는 점이다.

arr이라는 배열 이름은 포인터고, 배열의 이름도 8바이트로 처리가 된다.

arr이라는 포인터를 int형으로 명시적으로 형 변환하면 8바이트를 4바이트로 형 변환을 하니까 문제가 생긴다.

 

Windows 스타일 자료형

---

Polymorphic 자료형

#if defined(_WIN64)
	typedef __int64 LONG_PTR;
	typedef unsigned __int64 ULONG_PTR;
	typedef __int64 INT_PTR;
	typedef unsigned __int64 UINT_PTR;
#else
	typedef long LONG_PTR;
	typedef unsigned long ULONG_PTR;
	typedef int INT_PTR;
	typedef unsigned int UINT_PTR;
#endif

하나가 둘 이상의 특성을 지니는 것을 다형성(Polymorphic)이라 한다.

__WIN64가 정의되어있다면 그에 맞게 64비트 타입 자료형으로 매크로 타입이 정의된다.

여기서 주의할 점은 이름에 PTR이라고 붙어있어서 포인터라고 착각할 수 있는데 포인터가 아니다.

포인터 연산을 위한 Polymorphic 자료형이다.

 

[예제 1-1]

UINT CalDistance(UINT a, UINT b)
{
	return a-b;
}

int _tmain(void)
{
	INT val1 = 10;
	INT val2 = 20;
	_tprintf(_T("Position %d, %d \n"), (UINT)&val1, (UINT)&val2);
	_tprintf(_T("Dosition %d \n"), CalDistance((UINT)&val1, (UINT)&val2));
	return 0;
    
}

 위의 예제는 val1과 val2의 메모리 상의 거리를 계산하는 예제이다. (주소 값의 차)

UINT는 4바이트다. 32비트 시스템에서는 적절히 계산하겠지만 64비트 시스템에서는 계산이 이상하게 될 것이다.

 

[예제 1-2]

UINT CalDistance(UINT_PTR a, UINT_PTR b)
{
	return a-b;
}

int _tmain(void)
{
	INT val1 = 10;
	INT val2 = 20;
	_tprintf(_T("Position %d, %d \n"), (UINT_PTR)&val1, (UINT)&val2);
	_tprintf(_T("Dosition %d \n"), CalDistance((UINT)&val1, (UINT_PTR)&val2));
	return 0;
    
}

Polymorphic 자료형을 통해 64비트 시스템과의 호환성을 맞춰주었다.

이제 자료형 이름에 PTR이 왜 붙었는지 감이 오는가..?

자료형 자체가 포인터 타입이 아니라, 주로 포인터 연산을 목적으로 활용되는 자료형이기 때문에 _PTR이 붙는 것이다.

 

오류의 확인

---

 앞의 내용과 흐름에 안 맞는 내용이긴 하지만 알아야 하는 내용이다.

• 함수 호출의 성공 여부 확인의 기본
  • GetLastError 함수 호출

Constant/value	Description
ERROR_ARITHMETIC_OVERFLOW = 534	Arithmetic result exceeded 32bits.
ERROR_PIPE_CONNECTED = 535	There is a process on otehr end of pipe.
ERROR_PIPE_LISTENING = 536	Waiting for a process to open the other end of pipe.
ERROR_EA_ACCESS_DENIED = 994	Access to extended attribute was denied.
ERROR_OPERATION_ABORTED = 995	The I/O operation has been aborted because of either a thread exit or an application request.
ERROR_IO_INCOMPLETE = 996	Overlapped I/O event is not in a signaled state.
ERROR_IO_PENDING = 997	Overlapped I/O operation is in progress.
ERROR_NOACCESS = 998	Invalid access to memory location.
ERROR_SWAPERROR = 999	Error performing inpage operation.

Windows 시스템에서는 오류가 어떻게 처리되냐 하면, 오류가 발생하면 전역 공간에 선언된 변수에다 오류가 발생한 이유를 저장한다.

그래서 우리들은 전역공간에 접근해서 왜 오류가 발생했는지 알 수 있는데, GetLastError라는 함수를 통해 전역공간에 접근하여 오류의 이유를 가져올 수 있다.

 

여기서 주의할 점이 있는데, GetLastError함수는 에러 발생 이유를 알고 싶은 함수 바로 직후 써야 한다.

왜냐하면, 다른 함수의 에러가 우리가 검사하고자 하는 에러 내용을 뒤덮어 버릴 수 있기 때문이다.