윈도우 프로그래밍 개론 -1-
윈도우 프로그래밍이라고 하니까 거창한데 결국 C에서 보면 도스시절과
코드 방식엔 다를것이 없다. 다음은 탁 터놓고 말했을때의 도스시절의
C와 윈도에서의 C코드이다.
----------------------------
#include <stdio.h>
int main()
{
printf("Hello World");
return 1;
}
----------------------------
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL,"Hello World","app_title",MB_OK);
return 1;
}
----------------------------
정말 코드량이 늘긴했어도 기본 모양은 도스시절에서 C를 다루던때와
그리 달라 보이진 않는다.
실행 결과는 도스의 경우 다음처럼 나온다.
Hello World
윈도우의 경우는 실행시키면 중앙에 작은 다이얼로그 박스(대화상자)가
생긴후 타이틀바(제목줄)에는 app_title이라고 써있고 대화상자안에는
Hello World 라는 단어가 찍혀 나온다.
아직은 실제로 이 코드를 컴파일 할 필요는 없다. 먼저 알아두어야할
몇가지 상식적인 말을 하겠다.
Visual C++은 뭔가요?
> Visual C++은 MS(Micro Soft)의 IDE(통합개발환경)제품이며
현재 Visual C++ 6.0까지 나왔다. C와 C++코드를 사용하는 컴파일러
이며 이것의 역사는 MSC 7.0으로 거슬러 올라간다.
*도스시절에는 볼랜드(bolland)의 승리였다. 우리가 잘아는 BC++,TC++
등의 제품군은 모두 볼랜드의 제품이며 그당시 도스용 C/C++컴파일러
를 내놓았던 마소(MS)는 MSC라는 컴파일러를 놓았는데 볼랜드가
이기다 싶이 했다. 그러나 윈도우 체제로 넘어와서는 MSC 7.0 뒤를
잇는 Visual C++ 1.0이 발표 된 후 많은 발전후 결국 윈도우 C/C++컴
파일러 제품으로 이 VC가 승리한 것이다.
두회사의 제품군 개발 약도
볼랜드사 : TC -> TC++ 및 BC++ 발표 -> C++ Builder
TC는 터보씨로 C 통합개발 환경이였다.
TC++는 C/C++ 통합개발 환경이었다.
BC++은 윈도우를 겨냥한 C/C++통합개발환경이었다.
물론 TC++ 4.0 for Window라는 것도 윈도우용 개발환경이다.
C++ Builder 는 Visual C++과 동격이라고 보면 되며 볼랜드의 C/C++
윈도우 개발 환경이다.
마소사 : MSC++ -> Visual C++
MSC++은 Micro soft C++이라는 C/C++ 도스체제 개발환경이다.
Visual C++은 윈도우용 개발 환경이다.
API와 MFC, OWL 이란?
> 먼저 API는 Application Programming Interface의 약자며 한마디로
윈도우에서 개발을 위한 저수준관련 함수묶음이다. 유식한 말로는
인터페이스이다. 인터페이스란 상호간 통신을 위한 수단이라 보면된다.
즉, API 함수를 호출하여 윈도우에서 WAV를 틀었다면 이는 API라는
윈도우용 인터페이스를 이용해 컴퓨터에 붙은 소리관련 기기와 통신을
한것이다.
도스에서의 저수준처리를 한다면 어셈블리같은 저수준언어를 이용해서
했는데 윈도우에서 로우레벨이라고 하면 이 API를 이용한 개발이라고
할 수 있다.
API는 C언어로 가장 최적화하여 쓸수있는 함수 라이브러리로 C/C++이
중요한 이유가 여기에 있는 것이다.
API는 윈도우에서 기본적으로 제공되는 기능이라고 보면 된다.
그리고 더 확장한 것을 확장API이라고 한다. 그 종류를 본다면
MAPI - Messaging API 라고 해서 웹 네트워크상의 확장된 기능을
제공한다. 윈도우의 Exchage Mail도 이것으로 만들었다 한다.
TAPI - Telephone API 로 전화 연결 네트워킹에 대한 확장된 기능제공
DirectX - 게임 개발을 위한 확장된 API ( 부두같은 3D카드 통신가 )
OpenGL - 3D 개발을 위한 확장된 API ( 부두같은 3D카드와 통신가 )
ISAPI - Internet Sever API로 인터넷상의 웹 서버를 위한 확장 API
이외에도 많은 것이 개발되고 있으리라 추측된다 --;
또한 이런 저수준 인터페이스를 개발하는 것을 DDK라고 한다.
( DirectX Development Kit이 아님.) 여기서의 DDK는 무시깽이의 약자
까묵음 -_-; 이다. 헉~! 하여간 만일 내가 OCR 문자 판독 API를 만들
었다면 OCR문자 해독기 기기와 프로그래머간의 통신 인터페이스를 만든
것이므로 이것도 역시 확장 API가 되는것이다.
MFC는 무엇일까? 이는 Micro$oft Foundation Class 라는 약자로 Visual
C++에서 존재하는 클래스 라이브러리의 명이다. 이는 땅에서 솟아난
괴기한 것이 아니라 기존의 저수준 API함수를 한번 더 클래스로 예쁘게
포장한것에 불과하다. 하지만 물론 나름대로의 더 많은 편리한 클래스
를 제공한다. 따라서 비주얼씨를 공부한다 함은 MFC를 공부한다는 이야
기가 되며 MFC를 공부하기 위해서는 먼저 API를 공부해야 할것이다.
OWL은 무엇일까? Object Window Librury의 약자로 볼랜드 회사의 C/C++
윈도우 개발 환경인 C++ Builder의 클래스 라이브러리의 명이다.
MFC와 동격이라고 보면 된다.
RAD와 Visual Basic?? Delphi??
> RAD는 Rapid Application Development 라는 뜻으로 한마디로 빠른개발
툴이라 보면 된다. Visual Basic이 이런 형식의 개발툴에 해당한다.
폼이라 불리는 기본 윈도우에 버튼도 붙이고 스크롤바도 붙이면서 즐겁게
애플리케이션을 개발 하는 것이다. 비주얼틱하지 않나 ^^
역시 그런 맥락에서 볼랜드의 델파이(Delphi)역시 파스칼언어기반 RAD툴
이다. 역시 C++ Builder는 C/C++기반 RAD툴이다. 비베(Visual Basic)는
basic 기반 RAD툴인 것이다. 그럼 비씨(비절씨라 하는 놈두 있다)Visual
C++은 RAD일까? 불행이도 아니다 --; RAD라고 부르지는 않는다.
그래픽에디터를 통해서 폼개발 형식으로도 할수 있으나 그것은 어디까지나
다이얼로그를 만들때나 하는 것이기 때문이다. Visual C++에서는 코딩이
주가 된다.
C++ Builder 는 볼랜드의 C/C++기반 RAD 윈도 언어
Delphi 는 볼랜드의 Pascal 언어기반 RAD 윈도 언어
Visual C++은 마소의 C/C++ 기반 윈도 언어
Visual Basic은 마소의 basic 기반 RAD 윈도 언어
요즘 동향이 어케 되는데요?
> 요즘은 너무나도 빠르게 발전하고 있기 때문에 조금이라도 손을 놓으면
절때 따라갈수 없다. 요즘 개발세계는 마소와 대적하는 세력이 커지고
있는 것이다. 마소가 하두 독단적으로 커서 이를 저지 하기 위한 노력이
일고 있는 것 같다.
JAVA는 C++언어를 모태로 하는 언어인데 플랫폼에 상관없이 돌아간다는
멋진 언어이다. 즉, 플랫폼이 도스던 윈도이던 NT이던 유닉스이던 뭐던
간에 같은 모양으로 실행이 된다는 것을 의미한다.
요즘 자바빈즈니 COBA니 COBRA니 하면서 여러방면으로 발전을 해오고있다.
또한 마소지를 보니 리눅스와 자바와 결합하여 리눅스자바라는 것도 나온
다고 하는 흥미로은 것도 있었다.
Power Builder 역시 C++을 기반으로 하는 RAD툴로 사이베이스라는 회사의
주력 언어이다. 원래 사이베이스는 DB( Database)를 했던 회사라 이 파워
빌더역시 데이타베이스 개발을 편리하게 해준다.
요즘 정말 많은 언어들이 속출하고 있다 Visual Age라는 것도 있고..
듣는 바론 C++ 모양에 클래스간의 모형 시뮬레이션도 할수 있다고 하고
하여간 그렇다고 한다 --;
지금은 윈도우 언어를 시작하는 단계이니 이정도로 그만하고 무엇보다
API와 MFC를 잡기 위해서 노력하자~!
내가 조금씩 알고 있는 것을 그냥 마구잡이로 쓴것이니까 실수한 것도
많이 있을것으로 믿는다. 죄송한 마음에 --
1998년 12월 31일 AM 07:44
조경민 in OPG
bro@shinbiro.com
윈도우 프로그래밍 개론 -2-
기초적인 윈도우 API 프로그래밍 이해
역시 들어가기 전에 몇가지 필요한 용어 설명및..
윈도 플밍 개요..
윈도우 프로그래밍의 새로운 구조는 이벤트 중심으로 된다는 것이다.
도스 시절에서는 한줄 한줄 짠 코드가 어느시점에 호출이 될지
자신이 정하였다.
그런데 윈도우에서는 이벤트중심이라는 것이 틀리다. 윈도우를 자세히
보자.. 어떤 프로그램을 한번 띄어 보자. 그리고 그 프로그램에서 여러
버튼을 눌러보자. 그리고 창을 최대화 최소화 해보고 여러가지 주문(?)을
해보자.... 당연하게 프로그램은 제때 제때 요구에 맞추어 일을 처리한다.
최소화 버튼을 누르면 여지없이 프로그램은 쌱 사리지고, 메뉴 창의 메뉴
를 누르면 팍팍 반응을 보이고...
그런데 프로그래머 입장에서 봤을때 프로그램을 짤때는 분명히 메뉴를
누르면 어떤 일을 하도록 코드를 짜냤을 것이다. 그리고 최소화를 눌를때도
어떤일을 하도록 코드를 짜냤을것이고 그런 의미에서 본다면, 새로운것을
보게 된다... 윈도우의 모든 윈도기반 프로그램들(애플리케이션)은
사용자 (유저)가 요구한 이벤트(메세지)를 받아서 처리하는 코드를 갖고
있는데 이들 코드는 미리 순서에 따라 진행된다기 보다 어던 메세지에
따라서 각각 처리된다는 것이다.
말만 많아봤자 나만 구차해진다 --;
그럼 API로 짠 아주 기초가 되는 유명한 코드입다.....
#include <windows.h>
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
static char szAppName[] = "시작해요 APIWin32";
HWND hwnd;
MSG msg;
WNDCLASS wc;
wc.style = CS_HREDRAW + CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground= (HBRUSH)GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName= szAppName;
RegisterClass(&wc);
hwnd = CreateWindow(szAppName,
"시작하는 Win32",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);
while(GetMessage(&msg,NULL,0,0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
HDC hdc;
PAINTSTRUCT ps;
RECT rect;
switch(msg)
{
case WM_PAINT:
hdc = BeginPaint(hwnd,&ps);
GetClientRect(hwnd,&rect);
DrawText(hdc," 이것이 바로 Win32의 진정한 모습입니다. 꽤 초라하죠? ^^* ",1,&rect,DT_SINGLELINE|DT_CENTER+DT_VCENTER);
EndPaint(hwnd,&ps);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd,msg,wParam,lParam);
}
실행 결과는 하얀 창이 윈도우 화면 중앙에 나타나서 이것이 바로 윈어쩌구
라는 문구가 중앙에 배치됩니다...
아주 간단한 기능을 갖은 것이죠 ^___^
한번 훑어 보시길 바라는데.. 아주 특이한 모양을 한 코드라는것을
알수 있을 거야.. ( 그냥 편한 말로 할께 -_- )
그치만 딱봐도 알만한건 WinMain이라는 함수가 도스시절의 main을
대신한다는 것을 알수 있겠지...
WinMain이 도스시절의 프로그램 메인 엔트리인 main을 대신해 그리고
이 함수는 어떤 C로 짠 프로그램에서든지 존재해야해 (당연-_-)
그리고 아까 말한 이벤트 중심 메세지 중심이라고 했는데.. 사용자가
요구하는 여러 메시지에 반응을 하려면 각 상황에 맞게 알맞는
코드로의 분기를 위해 분기문을 써야 할텐데.. 윈도우에선 대부분
switch문을 씀으로써 해결한다. 위의 WndProc이라는 함수를 보면
기본 골격은 switch로 되어 있는 것을 알것이다... 그리고
그 안의 msg 즉 사용자의 메세지를 받아서 분기해서 알맞는 코드로
분기하는 식이다. 기본 골격은 간단하다.. 단지 낯설어서 그렇지 --
다른것은 제처두고 이제 용어 설명으로 무작정 들어갈려고 한다.
그리고 위의 코드를 한줄 한줄 음미해보자
이정도는 알아 두어야...
메세지 - 윈도우플밍은 메세지 중심의 프로그래밍으로 메세지에는
사용자가 애플리케이션에 보내는 직접적인 메세지도 있으며
시스템(윈도우)에서 애플리케이션에게 보내는 메세지도
있고 반대로 애플리케이션이 시스템에 보내는 메세지도
있을 것이다.
인스턴스 - 인스턴스는 감이 잘 안오면 그냥 프로그램 애플리케이션
하나라고 보면 될것이다. 어떤 프로그램을 실행하여 메모리
에 할당시키면 인스턴스 했다고 한다.
어느정도 인스턴스는 테스크(task)와 프로세스(process)와
혼용되어 쓰일수 있다.
멀티테스킹 - 테스크는 알다싶이 책상에 펴놓고 있는 어떤 작업을 의미
한다. 멀티테스킹은 책상위에 여러 작업을 동시에 펼쳐
놓고 하는 것을 의미하는데 이것은 바로 윈도우라는 한
운영체제하에서 여러 프로그램이 한 작업으로 되어
여러 작업이 동시에 가능하다는 것을 의미한다.
핸들 - 윈도우에서는 여러 윈도우가 있을 수 있고 여러 객체가 있을수
있다. 메모장의 기본 골격 테두리 윈도우와 메모장의 핵심
메모 윈도우( 버튼도 윈도우고 메모장모양도 윈도우다)
그런데 이런 많은 윈도우 객체들을 식별하기 위해서 무엇이 있
어야 할까.. 주소를 기억하는 것도 좋지만 윈도우에서는
객체의 아이디(라벨)이라고 할 만 한 핸들이라는 것으로 이들을
식별하며 통솔한다. 이런 방식은 참 합리적이다.
유닉스의 파일제어(도스에서도 볼수있다. TC의 파일제어에서의)
의 파일 핸들도 그러하고.
HANDLE이라는 자료형이며 32비트 unsigned long형이다.
윈도우 - 윈도우는 꼭 프로그램의 테두리 [_][D][x] 이런 것이 있는것만
윈도우가 아니다. 말했듯이 메모장의 메모 부분도 메모윈도우
이며 버튼도 윈도우다. 정적 텍스트를 놓는 스태틱윈도우도있다
이건 도움말 같은 대화상자에서 글씨가 들어간 부분이 그런것
이다. 그리고 옵션을 주는 것두 버튼윈도우, 체크박스도 윈도우
왠만하면 다 윈도우에 해당한다.
자세한 핸들 - 핸들 HANDLE을 알고 있지만 윈도우(시스템)에는 다시
윈도우에대한 핸들, 그리고 브러쉬,펜등 그리기 위한 객체
를 위한 핸들등 여러 객체에 대해 핸들을 세분화 하였다.
HWND 는 윈도우에 대한 핸들을 의미하며
HDC 는 그리는 객체에 대한 핸들이다.
헝가리안 표기법 - 이것은 꼭 지키라는 것은아니지만 관습이다 코딩 관습
이를 약간 알고 있으면 코드를 이해하는데도 도움을
준다. 자료형에 대해서 접두어를 둠으로써 편리함을
준것이다.
HWND에 H가 붙으면 Handle을 의미하는 것처럼 이런식이다.
n : short, int 형 ( 원랜 short을 의미)
i : int 형 ( 안쓴다. 대부분 요즘은 )
dw : DWORD 형
p : pointer 형
s : 스트링 형
sz : string terminated by zero ( 0으로 끝나는 문자열)
c : char 형
lp : far pointer 포인터형 윈32 현재 구분없다. p와
fn : 펑션 함수임을 의미
wnd : 윈도우임을 의미
m_ : VC/MFC에서 어떤 클래스의 맴버임을 의미
ex) nCount++; nCount가 int형임을 쉽게 알수있다.
strcpy(szStr,"hi"); 문자열szStr에 hi를 복사
wc.lpfnWndProc = WndProc; wc스트럭처의 far 포인터
윈도우 프로시져에 WndProc을 넣는다.
cc.m_nChar = 1; cc라는 클래스의 맴버자료인
int형m_nChar에 1을 대입힌다.
*참고* lp와 p라니..
lp는 원래 16비트 시절의 유물이다. far 포인터라고 해서 아는 사람은 알겠지만
-_-; 대충 설명하도록하겠다... 몰라도 넘아가기 ^.^
16비트 시절에는 세그먼트:오프셋이라는 개념을 놨다( 한번쯤은 들어봐야
예의다) 16비트 시절에는 포인터의 크기는 16비트였다. 오프셋을 가리키는
이 16비트 포인터는 오프셋 벙위까지 가릴킬수 있었다. 그래서 near포인터
라고 한다. 그리고 세그먼트를 넘어가는 넓은 범위에서의 포인터를 두었는데
32비트로 far 포인터가 있다. 여러 세그먼트를 쓰는 HUGE모델같은 경우는
여러 세그먼트로 나뉘므로 기본 pointer는 far 포인터로 지정된다.
어쩟든.. 이것은 과거의 일이고 이제는 32비트 이며 한 주소를 나타내기위한
저장 공간의 크기역시 32비트가 된다. (32비트 플랫 모드이다)
32비트 플랫 모드란 0x00000000에서 0xffffffff까지 가상으로 4GB까지 메모리
접근을 하는 것이다. 간단히 말해서 가상으로 메모리 주소가 쭉 4기가까지
가상으로 나열된 것처럼 메모리 쓰기 읽기를 하며, 시스템에서 가상으로된
이 메모리 주소를 다시 물리적 메모리로 매핑을 한다.
따라서 이제는 lp와 p는 구분이 없다고 봐도 된다. 그러나 쓰는 이유는 뭘까
뭐든지 그렇지만 윈도3.1로 짠 프로그램이나 코드를 버릴수 없기 때문이다.
윈95는 32비트 체제로 넘어오면서 윈3.1이라는 16비트 체제를 버릴수 없기에
그와 호환을 위해 16비트운영체제의 잔존을 허락했고 완전히 전의 것을
배제한후 32비트의 멋진 모습으로 다시 새어난것이 바로 윈NT(New Technoledge)
이다. 각기 현재 서로길을 잘 가고 있다. 윈95는 윈98 윈2000으로
윈NT 역시 버전없을 게속 하고 있다. 4.0까지 나왔냐? -_- 난 멀름..
옛날 주소 매핑 방법인 세그먼트:오프셋 과 32비트 주소 지정방식에
대해선 담에 시간이 남으면 간단히 더 짚어 보도록하자....
( 지금은 솔직히 까먹었음 -_-; )
32비트로 넘어와서 윈도우 프로그래밍에서 놀라운것은 하나의 애플리케이션은
최대 4GB까지 가상 메모리를 갖을수 있다는 것이다. 물론 그에 따른 제악도
있지만 이것은 놀라운 것이다. 예전처럼 많은 메모리를 쓰고 싶어서 변칙적인
EMS,XMS 하면서 보기에도 복잡한 작업을 하지 않아도 된다는 것이다.
윈도우는 4GB를 쓰라고 준다. 그리고 복잡한 메모리 관리는 윈도우가 알아서
해주게 된것이다.
*참고* int형의 크기
int형의 크기는 알다싶이 2바이트이다. 16비트인것이다. 그러나 이것은
잘못된 얘기이다. 만일 윈도우에서의 이야기라면 달라진다. 32비트 체제하
에서 int는 4바이트이며 long 과 같은 크기를 갖게 된다. char는 역시 1바이트
그럼 2바이트를 채워주는 것은 바로 short이다. short는 16비트시절에도
2바이트였다. 원래 short의 용도는 16비트체제와 32비트체제하에서도 같은
크기를 나타내기 위한 것이었다.
이제 API 프로그램 간단한 이 것을 한번 훑어 보자
#include <windows.h>
이 헤더를 포함하는 것으로 왠만한 API함수를 포함한것이다. 물론
멀티프로세스,스레드를 위해선 process.h를 포함해야 하며 MCI 멀티미디어
제어를 위해 mmsystem.h을 포함하며 string을 처리하기 위해 도스처럼
string.h를 포함해야 하지만 기본적인 많은 함수,매크로,상수는 windows.h를
포함하는 것으로 말금히 처리된다.
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM); //원형
:
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
// 정의부
LRESULT가 이 함수의 반환값이다. 지금은 WndProc이라는 함수의 함수원형
프로토타입을 정의한 것이다. LRESULT는 이 콜백 함수의 반환값을 저장하는
32비트의 자료형이다.
CALLBACK이라는 것이 있는데 이것은 콜링컨벤션에 관련된 기술이다.
즉 함수 호출 순서라고 할 수 있는데 기본적으로 콜백은 볼랜드
TC에서의 벤션 구분인 cdelc과 같다. WINAPI라는 방식은 TC의
pascal과 같다고 한다. 콜링컨벤션(Calling Convention)에 대한
자세한 얘기 또한 다음에 기회가 닿으면 같이 보낼것이다.
HWND는 알다싶이 윈도우에 대한 핸들 자료형이며 32비트이다.
UINT는 Unsigned INT이며 대문자로 된 자료형은 윈도 코드의 관례이다.
이제 왠만한 자료형은 대문자로 나올것이다.
실제 정의에서 UINT형에 해당하는 것이 msg인데 즉 이것은 메세지
를 담는 자료형이다. 32비트이며 주 메세지에 해당한다.
WPARAM과 LPARAM이라는 것이 있는데 이것은 주메세지에서 못다한 이야기--
를 담는 것으로 얘를 들어서 WM_LBUTTONDOWN이라는 메세지가
WndProc함수에 두번쨰 파라미터로 들어 왔다면 이 마우스 왼쪽버튼
다운이라는 메세지와 함께 WPARAM쪽으로는 같이 눌려있던 키보드
키를 얻어 오며 LPARAM으로 온 쪽에는 어떤 위치에서 눌렀는가가
나온다. 즉 이 WPARAM과 LPARAM은 부수적인 메세지 정보라고 할수
있다.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
WinMain는 프로그램 메인 엔트리 포인트이며 도스의main과 상응한다.
HINSTANCE는 인스턴스의 핸들에 대한 자료형이며 윈메인은 두개의 인스턴스
핸드를 받는데 처음 하나 hInstance는 현재 이 프로그램이 시작되면서
윈도우(시스템)로 부터 언어낸 인스턴스의 핸들이며 두번째 인스턴스는
이 프로그램이 중복으로 실행되면 여러개의 같은 프로그램 복사본이 나올수
있는데 이때 바로 전의 인스턴스를 기억한다. 그러나 이것은 협력체제하의
16비트 원도3.1에서나 중요한 의미가 되었지 현재 비선점형 멀티테스킹
윈95이상에서는 hPrevinstance는 언제나 0값을 갖게 된다.
그럼 필요없는것을 아직도? 역시나 3.1과의 호환문제이다.
LPSTR은 문자열을 담는 자료형이고 lpCmdLine은 이 애플리케이션을
실핼 할때 부수적으로 등어간 실행 문자열들이다.
c:>dir /w 에서 dir이라는 명령어를 위해서 /w라는 커맨드라인이들어가지
않았는가 같은 의미이다.
int형 nCmdShow는 이 애플리케이션이 뜨면서 어떤 모양이어야 하는 것을
결정한다. 보이는가 안보이는가.. 최대화인가 아니면 최소화인가를 결정
시간이 없는 관계로 --;; 헉.. 다음에 이어서 설명을 하려고 하겠다.
그럼 이를 컴파일 하는 방법을 먼저 알려주겠다....
1.Visual C++을 실행한 후 New를 한후 새로운 워크스페이스를 연다.
2.Projects 탭에서 Win32 Applicatiom을 선택한후 프로젝트명을 쓴후
win32test정도?
3.새로운 프로젝팅 환경이 나타난다면 주메뉴의 Project/Add to Files를
한후 위 코드를 써 넣은 win32test.c 같은 파일을 프로젝트에 추가한다.
4.주메뉴의 Build/Build 를 하던지 F5를 눌른다. 그리고 실행 결과를본다.
어떻게 잘... 멋지게
실행이 된다면 축하드린다. Win32 API프로그래밍이 처음 접한 이들에게....
1999/01/03 03:23 오후 조경민
윈도우 프로그래밍이라고 하니까 거창한데 결국 C에서 보면 도스시절과
코드 방식엔 다를것이 없다. 다음은 탁 터놓고 말했을때의 도스시절의
C와 윈도에서의 C코드이다.
----------------------------
#include <stdio.h>
int main()
{
printf("Hello World");
return 1;
}
----------------------------
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL,"Hello World","app_title",MB_OK);
return 1;
}
----------------------------
정말 코드량이 늘긴했어도 기본 모양은 도스시절에서 C를 다루던때와
그리 달라 보이진 않는다.
실행 결과는 도스의 경우 다음처럼 나온다.
Hello World
윈도우의 경우는 실행시키면 중앙에 작은 다이얼로그 박스(대화상자)가
생긴후 타이틀바(제목줄)에는 app_title이라고 써있고 대화상자안에는
Hello World 라는 단어가 찍혀 나온다.
아직은 실제로 이 코드를 컴파일 할 필요는 없다. 먼저 알아두어야할
몇가지 상식적인 말을 하겠다.
Visual C++은 뭔가요?
> Visual C++은 MS(Micro Soft)의 IDE(통합개발환경)제품이며
현재 Visual C++ 6.0까지 나왔다. C와 C++코드를 사용하는 컴파일러
이며 이것의 역사는 MSC 7.0으로 거슬러 올라간다.
*도스시절에는 볼랜드(bolland)의 승리였다. 우리가 잘아는 BC++,TC++
등의 제품군은 모두 볼랜드의 제품이며 그당시 도스용 C/C++컴파일러
를 내놓았던 마소(MS)는 MSC라는 컴파일러를 놓았는데 볼랜드가
이기다 싶이 했다. 그러나 윈도우 체제로 넘어와서는 MSC 7.0 뒤를
잇는 Visual C++ 1.0이 발표 된 후 많은 발전후 결국 윈도우 C/C++컴
파일러 제품으로 이 VC가 승리한 것이다.
두회사의 제품군 개발 약도
볼랜드사 : TC -> TC++ 및 BC++ 발표 -> C++ Builder
TC는 터보씨로 C 통합개발 환경이였다.
TC++는 C/C++ 통합개발 환경이었다.
BC++은 윈도우를 겨냥한 C/C++통합개발환경이었다.
물론 TC++ 4.0 for Window라는 것도 윈도우용 개발환경이다.
C++ Builder 는 Visual C++과 동격이라고 보면 되며 볼랜드의 C/C++
윈도우 개발 환경이다.
마소사 : MSC++ -> Visual C++
MSC++은 Micro soft C++이라는 C/C++ 도스체제 개발환경이다.
Visual C++은 윈도우용 개발 환경이다.
API와 MFC, OWL 이란?
> 먼저 API는 Application Programming Interface의 약자며 한마디로
윈도우에서 개발을 위한 저수준관련 함수묶음이다. 유식한 말로는
인터페이스이다. 인터페이스란 상호간 통신을 위한 수단이라 보면된다.
즉, API 함수를 호출하여 윈도우에서 WAV를 틀었다면 이는 API라는
윈도우용 인터페이스를 이용해 컴퓨터에 붙은 소리관련 기기와 통신을
한것이다.
도스에서의 저수준처리를 한다면 어셈블리같은 저수준언어를 이용해서
했는데 윈도우에서 로우레벨이라고 하면 이 API를 이용한 개발이라고
할 수 있다.
API는 C언어로 가장 최적화하여 쓸수있는 함수 라이브러리로 C/C++이
중요한 이유가 여기에 있는 것이다.
API는 윈도우에서 기본적으로 제공되는 기능이라고 보면 된다.
그리고 더 확장한 것을 확장API이라고 한다. 그 종류를 본다면
MAPI - Messaging API 라고 해서 웹 네트워크상의 확장된 기능을
제공한다. 윈도우의 Exchage Mail도 이것으로 만들었다 한다.
TAPI - Telephone API 로 전화 연결 네트워킹에 대한 확장된 기능제공
DirectX - 게임 개발을 위한 확장된 API ( 부두같은 3D카드 통신가 )
OpenGL - 3D 개발을 위한 확장된 API ( 부두같은 3D카드와 통신가 )
ISAPI - Internet Sever API로 인터넷상의 웹 서버를 위한 확장 API
이외에도 많은 것이 개발되고 있으리라 추측된다 --;
또한 이런 저수준 인터페이스를 개발하는 것을 DDK라고 한다.
( DirectX Development Kit이 아님.) 여기서의 DDK는 무시깽이의 약자
까묵음 -_-; 이다. 헉~! 하여간 만일 내가 OCR 문자 판독 API를 만들
었다면 OCR문자 해독기 기기와 프로그래머간의 통신 인터페이스를 만든
것이므로 이것도 역시 확장 API가 되는것이다.
MFC는 무엇일까? 이는 Micro$oft Foundation Class 라는 약자로 Visual
C++에서 존재하는 클래스 라이브러리의 명이다. 이는 땅에서 솟아난
괴기한 것이 아니라 기존의 저수준 API함수를 한번 더 클래스로 예쁘게
포장한것에 불과하다. 하지만 물론 나름대로의 더 많은 편리한 클래스
를 제공한다. 따라서 비주얼씨를 공부한다 함은 MFC를 공부한다는 이야
기가 되며 MFC를 공부하기 위해서는 먼저 API를 공부해야 할것이다.
OWL은 무엇일까? Object Window Librury의 약자로 볼랜드 회사의 C/C++
윈도우 개발 환경인 C++ Builder의 클래스 라이브러리의 명이다.
MFC와 동격이라고 보면 된다.
RAD와 Visual Basic?? Delphi??
> RAD는 Rapid Application Development 라는 뜻으로 한마디로 빠른개발
툴이라 보면 된다. Visual Basic이 이런 형식의 개발툴에 해당한다.
폼이라 불리는 기본 윈도우에 버튼도 붙이고 스크롤바도 붙이면서 즐겁게
애플리케이션을 개발 하는 것이다. 비주얼틱하지 않나 ^^
역시 그런 맥락에서 볼랜드의 델파이(Delphi)역시 파스칼언어기반 RAD툴
이다. 역시 C++ Builder는 C/C++기반 RAD툴이다. 비베(Visual Basic)는
basic 기반 RAD툴인 것이다. 그럼 비씨(비절씨라 하는 놈두 있다)Visual
C++은 RAD일까? 불행이도 아니다 --; RAD라고 부르지는 않는다.
그래픽에디터를 통해서 폼개발 형식으로도 할수 있으나 그것은 어디까지나
다이얼로그를 만들때나 하는 것이기 때문이다. Visual C++에서는 코딩이
주가 된다.
C++ Builder 는 볼랜드의 C/C++기반 RAD 윈도 언어
Delphi 는 볼랜드의 Pascal 언어기반 RAD 윈도 언어
Visual C++은 마소의 C/C++ 기반 윈도 언어
Visual Basic은 마소의 basic 기반 RAD 윈도 언어
요즘 동향이 어케 되는데요?
> 요즘은 너무나도 빠르게 발전하고 있기 때문에 조금이라도 손을 놓으면
절때 따라갈수 없다. 요즘 개발세계는 마소와 대적하는 세력이 커지고
있는 것이다. 마소가 하두 독단적으로 커서 이를 저지 하기 위한 노력이
일고 있는 것 같다.
JAVA는 C++언어를 모태로 하는 언어인데 플랫폼에 상관없이 돌아간다는
멋진 언어이다. 즉, 플랫폼이 도스던 윈도이던 NT이던 유닉스이던 뭐던
간에 같은 모양으로 실행이 된다는 것을 의미한다.
요즘 자바빈즈니 COBA니 COBRA니 하면서 여러방면으로 발전을 해오고있다.
또한 마소지를 보니 리눅스와 자바와 결합하여 리눅스자바라는 것도 나온
다고 하는 흥미로은 것도 있었다.
Power Builder 역시 C++을 기반으로 하는 RAD툴로 사이베이스라는 회사의
주력 언어이다. 원래 사이베이스는 DB( Database)를 했던 회사라 이 파워
빌더역시 데이타베이스 개발을 편리하게 해준다.
요즘 정말 많은 언어들이 속출하고 있다 Visual Age라는 것도 있고..
듣는 바론 C++ 모양에 클래스간의 모형 시뮬레이션도 할수 있다고 하고
하여간 그렇다고 한다 --;
지금은 윈도우 언어를 시작하는 단계이니 이정도로 그만하고 무엇보다
API와 MFC를 잡기 위해서 노력하자~!
내가 조금씩 알고 있는 것을 그냥 마구잡이로 쓴것이니까 실수한 것도
많이 있을것으로 믿는다. 죄송한 마음에 --
1998년 12월 31일 AM 07:44
조경민 in OPG
bro@shinbiro.com
윈도우 프로그래밍 개론 -2-
기초적인 윈도우 API 프로그래밍 이해
역시 들어가기 전에 몇가지 필요한 용어 설명및..
윈도 플밍 개요..
윈도우 프로그래밍의 새로운 구조는 이벤트 중심으로 된다는 것이다.
도스 시절에서는 한줄 한줄 짠 코드가 어느시점에 호출이 될지
자신이 정하였다.
그런데 윈도우에서는 이벤트중심이라는 것이 틀리다. 윈도우를 자세히
보자.. 어떤 프로그램을 한번 띄어 보자. 그리고 그 프로그램에서 여러
버튼을 눌러보자. 그리고 창을 최대화 최소화 해보고 여러가지 주문(?)을
해보자.... 당연하게 프로그램은 제때 제때 요구에 맞추어 일을 처리한다.
최소화 버튼을 누르면 여지없이 프로그램은 쌱 사리지고, 메뉴 창의 메뉴
를 누르면 팍팍 반응을 보이고...
그런데 프로그래머 입장에서 봤을때 프로그램을 짤때는 분명히 메뉴를
누르면 어떤 일을 하도록 코드를 짜냤을 것이다. 그리고 최소화를 눌를때도
어떤일을 하도록 코드를 짜냤을것이고 그런 의미에서 본다면, 새로운것을
보게 된다... 윈도우의 모든 윈도기반 프로그램들(애플리케이션)은
사용자 (유저)가 요구한 이벤트(메세지)를 받아서 처리하는 코드를 갖고
있는데 이들 코드는 미리 순서에 따라 진행된다기 보다 어던 메세지에
따라서 각각 처리된다는 것이다.
말만 많아봤자 나만 구차해진다 --;
그럼 API로 짠 아주 기초가 되는 유명한 코드입다.....
#include <windows.h>
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
static char szAppName[] = "시작해요 APIWin32";
HWND hwnd;
MSG msg;
WNDCLASS wc;
wc.style = CS_HREDRAW + CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground= (HBRUSH)GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName= szAppName;
RegisterClass(&wc);
hwnd = CreateWindow(szAppName,
"시작하는 Win32",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);
while(GetMessage(&msg,NULL,0,0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
HDC hdc;
PAINTSTRUCT ps;
RECT rect;
switch(msg)
{
case WM_PAINT:
hdc = BeginPaint(hwnd,&ps);
GetClientRect(hwnd,&rect);
DrawText(hdc," 이것이 바로 Win32의 진정한 모습입니다. 꽤 초라하죠? ^^* ",1,&rect,DT_SINGLELINE|DT_CENTER+DT_VCENTER);
EndPaint(hwnd,&ps);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd,msg,wParam,lParam);
}
실행 결과는 하얀 창이 윈도우 화면 중앙에 나타나서 이것이 바로 윈어쩌구
라는 문구가 중앙에 배치됩니다...
아주 간단한 기능을 갖은 것이죠 ^___^
한번 훑어 보시길 바라는데.. 아주 특이한 모양을 한 코드라는것을
알수 있을 거야.. ( 그냥 편한 말로 할께 -_- )
그치만 딱봐도 알만한건 WinMain이라는 함수가 도스시절의 main을
대신한다는 것을 알수 있겠지...
WinMain이 도스시절의 프로그램 메인 엔트리인 main을 대신해 그리고
이 함수는 어떤 C로 짠 프로그램에서든지 존재해야해 (당연-_-)
그리고 아까 말한 이벤트 중심 메세지 중심이라고 했는데.. 사용자가
요구하는 여러 메시지에 반응을 하려면 각 상황에 맞게 알맞는
코드로의 분기를 위해 분기문을 써야 할텐데.. 윈도우에선 대부분
switch문을 씀으로써 해결한다. 위의 WndProc이라는 함수를 보면
기본 골격은 switch로 되어 있는 것을 알것이다... 그리고
그 안의 msg 즉 사용자의 메세지를 받아서 분기해서 알맞는 코드로
분기하는 식이다. 기본 골격은 간단하다.. 단지 낯설어서 그렇지 --
다른것은 제처두고 이제 용어 설명으로 무작정 들어갈려고 한다.
그리고 위의 코드를 한줄 한줄 음미해보자
이정도는 알아 두어야...
메세지 - 윈도우플밍은 메세지 중심의 프로그래밍으로 메세지에는
사용자가 애플리케이션에 보내는 직접적인 메세지도 있으며
시스템(윈도우)에서 애플리케이션에게 보내는 메세지도
있고 반대로 애플리케이션이 시스템에 보내는 메세지도
있을 것이다.
인스턴스 - 인스턴스는 감이 잘 안오면 그냥 프로그램 애플리케이션
하나라고 보면 될것이다. 어떤 프로그램을 실행하여 메모리
에 할당시키면 인스턴스 했다고 한다.
어느정도 인스턴스는 테스크(task)와 프로세스(process)와
혼용되어 쓰일수 있다.
멀티테스킹 - 테스크는 알다싶이 책상에 펴놓고 있는 어떤 작업을 의미
한다. 멀티테스킹은 책상위에 여러 작업을 동시에 펼쳐
놓고 하는 것을 의미하는데 이것은 바로 윈도우라는 한
운영체제하에서 여러 프로그램이 한 작업으로 되어
여러 작업이 동시에 가능하다는 것을 의미한다.
핸들 - 윈도우에서는 여러 윈도우가 있을 수 있고 여러 객체가 있을수
있다. 메모장의 기본 골격 테두리 윈도우와 메모장의 핵심
메모 윈도우( 버튼도 윈도우고 메모장모양도 윈도우다)
그런데 이런 많은 윈도우 객체들을 식별하기 위해서 무엇이 있
어야 할까.. 주소를 기억하는 것도 좋지만 윈도우에서는
객체의 아이디(라벨)이라고 할 만 한 핸들이라는 것으로 이들을
식별하며 통솔한다. 이런 방식은 참 합리적이다.
유닉스의 파일제어(도스에서도 볼수있다. TC의 파일제어에서의)
의 파일 핸들도 그러하고.
HANDLE이라는 자료형이며 32비트 unsigned long형이다.
윈도우 - 윈도우는 꼭 프로그램의 테두리 [_][D][x] 이런 것이 있는것만
윈도우가 아니다. 말했듯이 메모장의 메모 부분도 메모윈도우
이며 버튼도 윈도우다. 정적 텍스트를 놓는 스태틱윈도우도있다
이건 도움말 같은 대화상자에서 글씨가 들어간 부분이 그런것
이다. 그리고 옵션을 주는 것두 버튼윈도우, 체크박스도 윈도우
왠만하면 다 윈도우에 해당한다.
자세한 핸들 - 핸들 HANDLE을 알고 있지만 윈도우(시스템)에는 다시
윈도우에대한 핸들, 그리고 브러쉬,펜등 그리기 위한 객체
를 위한 핸들등 여러 객체에 대해 핸들을 세분화 하였다.
HWND 는 윈도우에 대한 핸들을 의미하며
HDC 는 그리는 객체에 대한 핸들이다.
헝가리안 표기법 - 이것은 꼭 지키라는 것은아니지만 관습이다 코딩 관습
이를 약간 알고 있으면 코드를 이해하는데도 도움을
준다. 자료형에 대해서 접두어를 둠으로써 편리함을
준것이다.
HWND에 H가 붙으면 Handle을 의미하는 것처럼 이런식이다.
n : short, int 형 ( 원랜 short을 의미)
i : int 형 ( 안쓴다. 대부분 요즘은 )
dw : DWORD 형
p : pointer 형
s : 스트링 형
sz : string terminated by zero ( 0으로 끝나는 문자열)
c : char 형
lp : far pointer 포인터형 윈32 현재 구분없다. p와
fn : 펑션 함수임을 의미
wnd : 윈도우임을 의미
m_ : VC/MFC에서 어떤 클래스의 맴버임을 의미
ex) nCount++; nCount가 int형임을 쉽게 알수있다.
strcpy(szStr,"hi"); 문자열szStr에 hi를 복사
wc.lpfnWndProc = WndProc; wc스트럭처의 far 포인터
윈도우 프로시져에 WndProc을 넣는다.
cc.m_nChar = 1; cc라는 클래스의 맴버자료인
int형m_nChar에 1을 대입힌다.
*참고* lp와 p라니..
lp는 원래 16비트 시절의 유물이다. far 포인터라고 해서 아는 사람은 알겠지만
-_-; 대충 설명하도록하겠다... 몰라도 넘아가기 ^.^
16비트 시절에는 세그먼트:오프셋이라는 개념을 놨다( 한번쯤은 들어봐야
예의다) 16비트 시절에는 포인터의 크기는 16비트였다. 오프셋을 가리키는
이 16비트 포인터는 오프셋 벙위까지 가릴킬수 있었다. 그래서 near포인터
라고 한다. 그리고 세그먼트를 넘어가는 넓은 범위에서의 포인터를 두었는데
32비트로 far 포인터가 있다. 여러 세그먼트를 쓰는 HUGE모델같은 경우는
여러 세그먼트로 나뉘므로 기본 pointer는 far 포인터로 지정된다.
어쩟든.. 이것은 과거의 일이고 이제는 32비트 이며 한 주소를 나타내기위한
저장 공간의 크기역시 32비트가 된다. (32비트 플랫 모드이다)
32비트 플랫 모드란 0x00000000에서 0xffffffff까지 가상으로 4GB까지 메모리
접근을 하는 것이다. 간단히 말해서 가상으로 메모리 주소가 쭉 4기가까지
가상으로 나열된 것처럼 메모리 쓰기 읽기를 하며, 시스템에서 가상으로된
이 메모리 주소를 다시 물리적 메모리로 매핑을 한다.
따라서 이제는 lp와 p는 구분이 없다고 봐도 된다. 그러나 쓰는 이유는 뭘까
뭐든지 그렇지만 윈도3.1로 짠 프로그램이나 코드를 버릴수 없기 때문이다.
윈95는 32비트 체제로 넘어오면서 윈3.1이라는 16비트 체제를 버릴수 없기에
그와 호환을 위해 16비트운영체제의 잔존을 허락했고 완전히 전의 것을
배제한후 32비트의 멋진 모습으로 다시 새어난것이 바로 윈NT(New Technoledge)
이다. 각기 현재 서로길을 잘 가고 있다. 윈95는 윈98 윈2000으로
윈NT 역시 버전없을 게속 하고 있다. 4.0까지 나왔냐? -_- 난 멀름..
옛날 주소 매핑 방법인 세그먼트:오프셋 과 32비트 주소 지정방식에
대해선 담에 시간이 남으면 간단히 더 짚어 보도록하자....
( 지금은 솔직히 까먹었음 -_-; )
32비트로 넘어와서 윈도우 프로그래밍에서 놀라운것은 하나의 애플리케이션은
최대 4GB까지 가상 메모리를 갖을수 있다는 것이다. 물론 그에 따른 제악도
있지만 이것은 놀라운 것이다. 예전처럼 많은 메모리를 쓰고 싶어서 변칙적인
EMS,XMS 하면서 보기에도 복잡한 작업을 하지 않아도 된다는 것이다.
윈도우는 4GB를 쓰라고 준다. 그리고 복잡한 메모리 관리는 윈도우가 알아서
해주게 된것이다.
*참고* int형의 크기
int형의 크기는 알다싶이 2바이트이다. 16비트인것이다. 그러나 이것은
잘못된 얘기이다. 만일 윈도우에서의 이야기라면 달라진다. 32비트 체제하
에서 int는 4바이트이며 long 과 같은 크기를 갖게 된다. char는 역시 1바이트
그럼 2바이트를 채워주는 것은 바로 short이다. short는 16비트시절에도
2바이트였다. 원래 short의 용도는 16비트체제와 32비트체제하에서도 같은
크기를 나타내기 위한 것이었다.
이제 API 프로그램 간단한 이 것을 한번 훑어 보자
#include <windows.h>
이 헤더를 포함하는 것으로 왠만한 API함수를 포함한것이다. 물론
멀티프로세스,스레드를 위해선 process.h를 포함해야 하며 MCI 멀티미디어
제어를 위해 mmsystem.h을 포함하며 string을 처리하기 위해 도스처럼
string.h를 포함해야 하지만 기본적인 많은 함수,매크로,상수는 windows.h를
포함하는 것으로 말금히 처리된다.
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM); //원형
:
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
// 정의부
LRESULT가 이 함수의 반환값이다. 지금은 WndProc이라는 함수의 함수원형
프로토타입을 정의한 것이다. LRESULT는 이 콜백 함수의 반환값을 저장하는
32비트의 자료형이다.
CALLBACK이라는 것이 있는데 이것은 콜링컨벤션에 관련된 기술이다.
즉 함수 호출 순서라고 할 수 있는데 기본적으로 콜백은 볼랜드
TC에서의 벤션 구분인 cdelc과 같다. WINAPI라는 방식은 TC의
pascal과 같다고 한다. 콜링컨벤션(Calling Convention)에 대한
자세한 얘기 또한 다음에 기회가 닿으면 같이 보낼것이다.
HWND는 알다싶이 윈도우에 대한 핸들 자료형이며 32비트이다.
UINT는 Unsigned INT이며 대문자로 된 자료형은 윈도 코드의 관례이다.
이제 왠만한 자료형은 대문자로 나올것이다.
실제 정의에서 UINT형에 해당하는 것이 msg인데 즉 이것은 메세지
를 담는 자료형이다. 32비트이며 주 메세지에 해당한다.
WPARAM과 LPARAM이라는 것이 있는데 이것은 주메세지에서 못다한 이야기--
를 담는 것으로 얘를 들어서 WM_LBUTTONDOWN이라는 메세지가
WndProc함수에 두번쨰 파라미터로 들어 왔다면 이 마우스 왼쪽버튼
다운이라는 메세지와 함께 WPARAM쪽으로는 같이 눌려있던 키보드
키를 얻어 오며 LPARAM으로 온 쪽에는 어떤 위치에서 눌렀는가가
나온다. 즉 이 WPARAM과 LPARAM은 부수적인 메세지 정보라고 할수
있다.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
WinMain는 프로그램 메인 엔트리 포인트이며 도스의main과 상응한다.
HINSTANCE는 인스턴스의 핸들에 대한 자료형이며 윈메인은 두개의 인스턴스
핸드를 받는데 처음 하나 hInstance는 현재 이 프로그램이 시작되면서
윈도우(시스템)로 부터 언어낸 인스턴스의 핸들이며 두번째 인스턴스는
이 프로그램이 중복으로 실행되면 여러개의 같은 프로그램 복사본이 나올수
있는데 이때 바로 전의 인스턴스를 기억한다. 그러나 이것은 협력체제하의
16비트 원도3.1에서나 중요한 의미가 되었지 현재 비선점형 멀티테스킹
윈95이상에서는 hPrevinstance는 언제나 0값을 갖게 된다.
그럼 필요없는것을 아직도? 역시나 3.1과의 호환문제이다.
LPSTR은 문자열을 담는 자료형이고 lpCmdLine은 이 애플리케이션을
실핼 할때 부수적으로 등어간 실행 문자열들이다.
c:>dir /w 에서 dir이라는 명령어를 위해서 /w라는 커맨드라인이들어가지
않았는가 같은 의미이다.
int형 nCmdShow는 이 애플리케이션이 뜨면서 어떤 모양이어야 하는 것을
결정한다. 보이는가 안보이는가.. 최대화인가 아니면 최소화인가를 결정
시간이 없는 관계로 --;; 헉.. 다음에 이어서 설명을 하려고 하겠다.
그럼 이를 컴파일 하는 방법을 먼저 알려주겠다....
1.Visual C++을 실행한 후 New를 한후 새로운 워크스페이스를 연다.
2.Projects 탭에서 Win32 Applicatiom을 선택한후 프로젝트명을 쓴후
win32test정도?
3.새로운 프로젝팅 환경이 나타난다면 주메뉴의 Project/Add to Files를
한후 위 코드를 써 넣은 win32test.c 같은 파일을 프로젝트에 추가한다.
4.주메뉴의 Build/Build 를 하던지 F5를 눌른다. 그리고 실행 결과를본다.
어떻게 잘... 멋지게
실행이 된다면 축하드린다. Win32 API프로그래밍이 처음 접한 이들에게....
1999/01/03 03:23 오후 조경민
'KB > MFC/Win32' 카테고리의 다른 글
| [mfc] 에디트 컨트롤 fix 폰트 쓰기 (0) | 2004.03.19 |
|---|---|
| [mfc] 런타임 클래스 (0) | 2004.03.19 |
| 윈도우프로그래밍 간략설명 (0) | 2004.03.19 |
| 언리쉬드 9장 윈도우 다이얼로그 박스 컨트롤 (0) | 2004.03.19 |
| Unleashed Visual C++ 5.0 ???? (0) | 2004.03.19 |