임계영역 : 동시에 접근될 수 있는 영역

동기화 : 동시접근에 순서를 배치하는 기법

접근동기화 : 메모리적 영역의 동기화 방법, 순서는 상관 없고 한순간에 하나의 쓰래드가 메모리에 접근하게 하는 방법

순서 동기화 : 프로그램 흐름 순서의 동기화 방법

커널에서 제공하는 임계영역의 범위를 설정할때

최소한의 범위로 임계영역 범위를 설정할 것, 범위가 넓은 수록 다른 쓰레드의 대기 시간이 길어져 성능이 느려질 수 있다

Atomic Access (원자적 접근) : 한순간에 하나의 쓰래드에 의해서만 접근이 가능한 접근

그러한 동기화 함수가 InterlockedIncrement 이고

이함수는 해당 변수에 대한 증가를 실행시키는 함수이다, 이 함수의 장점은 CRITICAL_SECTION 을 사용하기 위한 5,6 개의 함수들을 쓰지 않아도

된다는 것

쓰래드생성 ,_ beeginthreadex, _endthreadex 를 사용 CreateThread, ExitThread 사용 하지말기!

ansi 표준의 CreateThread, ExitThread   쓰래드 생성 함수들은 함수 내부에서 데이터를 저장하고 있을 경우

다른 쓰래드로 즉 CreateThread, ExitThread  로 생성해서 동일한 함수 내부에 데이터를 저장하고 있는 함수를 호출 할경우

메모리 공유가 발생해 의도치 않은 결과가 나오는데

쓰래드를 고려한 함수인 ,_ beeginthreadex, _endthreadex  은 각 함수마다 독립된 메모리 공간을 갖게 해줌으로써

이러한 문제점을 피할 수 있다

의 내용을 살짝 변경하여 올림

#include <windows.h>
#include <stdio.h>
#include <process.h>
#include <tchar.h>
#include <iostream>

unsigned counter;

unsigned __stdcall SecondThreadFunc( void *pArg )
{
 _tprintf(_T(" * In second thread... \n") );
 while(1)
 {
  std::cout<<"쓰래드 실행중"<<std::endl;
  _endthreadex(0);    //쓰래드를 도중에 종료하는 구문으로 주석처리하면 루프가 무한히 돈다
 }
 
 return 0;
}

int main()
{
 HANDLE hThread;
 unsigned threadID;

 _tprintf( _T(" * Creating second thread... \n ") );
 hThread = (HANDLE) _beginthreadex(NULL, 0, SecondThreadFunc, NULL, 0, &threadID );

 WaitForSingleObject( hThread, INFINITE );
 _tprintf( _T(" * Counter should be 1000000; it is -> %d\n"), counter );
 CloseHandle( hThread );   //_endthreadex 안에서 CloseHandle 이 불려지지 않음으로 직접 명시해야한다

 return 0;
}

이 _beginthreadex 함수는 내부적으로 CreateThread 함수를 호출하고 있다.

이를 보고 싶다면 MS사에서 제공하는 코드를 직접 보면 될 것이다.

이 코드 파일은 첨부토록 하겠다. _beginthreadex 함수를 찾아보면 알 것이다.

또한, thread 생성과 파괴시 다음과 같은 함수들이 존재한다.

학습 : CreateThread(), ExitThread()
C Library + API : _beginthreadex(), _endthreadex();
MFC : AfxBeginThread(), AfxEndThread();

C++ 멤버함수 beginthreadex  C/C++ / Programming  2010/06/26 16:36 http://blog.naver.com/haruka7879/140109537378 C++에서 멤버함수를 스레드로 이용시   #pragma comment (lib, "ws2_32.lib")   #include <stdio.h> #include <stdlib.h> #include <string.h> #include <process.h>   // _beginthreadex 함수 참조 #include <windows.h>   class a{ public:     static UINT WINAPI aaa(void *arg); };   UINT WINAPI a::aaa(void *arg) {     printf("[%s:%d]\n", __FILE__, __LINE__);     return 0; }   int main() {     HANDLE hThread;     hThread = (HANDLE)_beginthreadex(NULL, 0, a::aaa, NULL, 0, NULL);     WaitForSingleObject(hThread, 100);     return 0; }

주의해야 하는 것은 부모 프로세스에 등록된 핸들 테이블이나, 자식 프로세스에 등록된 핸들 테이블은 가짜라는 것

직접적으로 연결된 핸들 값이 아니다

http://sosal.tistory.com/98

/*
 * http://sosal.tistory.com/
 * made by so_Sal
 */


환경변수 :: 시스템의 속성을 기록하고 있는 변수.
                변수의 이름과 의미가 대부분 미리 정해져 있고,
                사용자가 의도적으로 변경, 생성 가능하다.

유닉스, 리눅스 운영체제에서는 환경변수를 설정하면
모든 프로세스가 동시에 접근 가능합니다.
따라서 '상속' 과정에 상관 없이, 환경변수라는 공유 메모리 영역을 통해
서로 정보를 주고 받을 수 있습니다.
(사실 환경변수로 정보를 주고받게 끔 프로그래밍 하는건 흔하지 않음)

윈도우에서는 시스템 환경변수를 제외한 
(Path, OS,TMP 등 컴퓨터 환경설정 고급탭에서 설정가능한 환경변수)
환경변수는 각 프로세스마다 테이블이 따로 주어져
공유하지 않게끔 되어있습니다.

환경변수로 정보를 주고받는 과정에서
다른 프로세스의 접근에 의한 정보 손실, 레이스컨디션 취약점 등
취약한 부분이 존재하지만, 실제 정보를 숨기는 차원에서 (특히 웹에서)
환경변수를 통해 변수를 변환하는 경우도 많습니다.

====== 함수 분석 ======

환경변수 설정하기
BOOL SetEnvironmentVariable(
    LPCWSTR lpName,
    LPCWSTR lpValue)

lpName :: 환경변수로 등록할 변수 이름
lpValue  :: 환경변수가 가지는 정보 (보통 Message buffer)

환경변수 반환하기
DWORD GetEnvironmentVariable(
    LPCWSTR lpName,
    LPWSTR lpBuffer,
    DWORD nSize);

lpName ::  환경변수 이름 // 이름을 알아야 반환이 가능z
lpBuffer ::  환경변수가 가지고 있는 정보를 반환하여 저장되어질 버퍼
nSize    ::  버퍼에 들어갈 수 있는 최대 크기

SetEnvironmentVariable( _T("나는"), _T("sosal"));
이렇게 선언시, "나는" 이라는 환경변수가 등록되며
GetEnvironmentVariable( _T("나는"), buffer, sizeof(buffer));
buffer에다가 "나는" 이라는 환경변수의 값을 반환하여 저장합니다.


앞에서 환경변수를 통해서 통신한다는 말을 언급했는데,
윈도우에서 부모프로세스와 자식프로세스처럼
직접적인 관계가 있는 프로세스들만이 통신이 가능합니다.
(리눅스에서는 모든 프로세스가 함께 공유)

자식프로세스 생성시에 < CreateProcess > 매개변수중
LPVOID lpEnvironment 이란 변수가 있는데,
NULL을 넣어주면 환경변수를 상속처리하게 됩니다.


Set/GetEnvironmentVariable, CreateProcess,
그리고 상속 모두를 사용한 예제를 보겠습니다.


========= 환경변수 상속 부모 프로세스 =========

#include<stdio.h>
#include<stdlib.h>
#include<windows.h>
#include<tchar.h>

int _tmain( int argc, TCHAR* argv[]){

 SetEnvironmentVariable(_T("sosal"), _T("winner"));
 SetEnvironmentVariable(_T("limsy"), _T("lo-ser"));
 //sosal, limsy라는 환경변수 2개를 지정합니다.
 //각각의 값은 차례대로 winner, lo-ser

 _tprintf( _T("Set EnvironmentVariables \n"));
 _tprintf( _T("sosal -> winner \n"));
 _tprintf( _T("limsy -> lo-ser \n"));

 STARTUPINFO si = {0,};
 PROCESS_INFORMATION pi = {0,};
 
 si.cb = sizeof(si);
 TCHAR Command[] = _T("EnvChild.exe");
  //Command는 자식프로세스 실행파일의 이름인데,
  //자식프로세스의 프로젝트 이름을 넣어주시면 됩니다.
 
  CreateProcess(
  NULL, Command, NULL, NULL, FALSE,
  CREATE_NEW_CONSOLE | CREATE_UNICODE_ENVIRONMENT,
  NULL, //NULL일 경우 프로세스의 환경변수를 상속합니다.
  NULL,&si,&pi);

 Sleep(330000);
 return 0;
 
}

========= 환경변수 상속 자식 프로세스 =========

#include<stdio.h>
#include<stdlib.h>
#include<windows.h>
#include<tchar.h>

#define BUFSIZE 1024

int _tmain(int argc, TCHAR *argv[]){

 TCHAR value[BUFSIZE];

 if(GetEnvironmentVariable( _T("sosal"), value, BUFSIZE) > 0)
  _tprintf( _T("%s = %s \n"), _T("sosal"), value);
 //부모프로세스가 지정한 환경변수를 가져와서 출력합니다.

 if(GetEnvironmentVariable( _T("limsy"), value, BUFSIZE) > 0)
  _tprintf( _T("%s = %s \n"), _T("limsy"), value);
 //부모프로세스가 지정한 환경변수를 가져와서 출력합니다.

 Sleep(90000);

 return 0;
}

설명은 하단에...

커널 : 운영체제의 핵심적인 부분

커널 오브젝트 : "커널 리소스의 정보를 담고 있는 데이터 블록"

                      -1. 해당 리소스(ex 프로세스) 의 상태 정보를 알려주기 위한 오브젝트

                      - 2. 프로세스  or 파일 등을 생성하면 생성과 동시에 이것들을 구분 짖는 어떤 정보들이 생성되는데 이러한 정보들을 말한다

핸들은 단지 핸들 테이블에 등록되어 있는 번호일뿐 실질적으로 프로세스의 커널 오브젝트에 직접 접근 할 수 없고 핸들 테이블 에서

해당 프로세스에 등록되어 있는 핸들과 매치가 되는 대상과 연결되게 되도록 되어 있다

각 프로세스는 각 프로세스 내에서의 고유 핸들이 있다 ( A ,B 프로세스에서는 A 에도 같은 번호의 프로세스 값은 있을 수 있지만 서로 같은

커널 오브젝트를 가르키고 있진 않을 수 있다 )

또한 각 프로세스는 자식 프로세스를 생성할때마다 자신의 핸들테이블에 생성된 자식 프로세스로 접근 할 수 있는 핸들 값을 리턴 받아

자신의 핸들 테이블에 저장해 놓고 자식 프로세스의 커널오브젝트 정보에 접근 할 수 있는 연결자를 가지고 있는데

연결된 개수만큼 해당 커널 오브젝트에는 usage count 가 올라가 있음으로 부모에서 자식 프로세스를 생성한다면 UC 는 2 가 되며

부모에서 자식을 닫으면 UC 는 1 이 되어 아직 살아 있게 된다, 즉 이것은 자식과 부모 관계를 끊는 결과를 가져오며 프로세스 종료는

UC=0 이 되야 종료 됨으로 자식 프로세스에서 UC 를 0 으로 낮춰야 (죽어야 최종적으로 죽어야 ) 자식 프로세스가 종료 된다

vs 는 파일 실행파일 경로를 순차적으로 아래 순서대로 검색해나간다

http://cs.knou.ac.kr/~khkim/faq/file.asp?code=aa027&num=1&snum=15

lib 파일 만든후 lib 링크 하고

lib파일과, 헤더파일 해당 프로젝트에 복사 한 후

헤더파일을 include 하면 함수를 사용 할 수 있다.

우선 해당 lib파일을 project에 include 시켜주어야 합니다.

그방식은 project->Setting->Link탭에서 library modules에 포함시키시거나

아래와 같이 Header파일에 포함하는 방식이 있습니다.

#pragma comment(lib, "C:\\abc\abc.lib")

다음으로 PcmtoWave()함수가 선언된 Header파일을 님이 사용하시려는 곳에서 include 시켜주시고

PcmtoWave()를 호출하시면 됩니다.

첫번째 Parameter는 PCM파일의 Path를 집어넣으시면 되고, 두번째 Parameter에서는 변환되서 저장될

Wav파일의 Path를 넘겨주시면 될듯 하네요

 http://pmguda.com/52

 라이브러리란?

특정한 코드(함수 혹은 클래스)를 포함하고 있는 컴파일된 파일이다. 

라이브러리를 만드는 이유?
 자주 사용되는 특정한 기능을 main 함수에서 분리시켜 놓음으로써, 프로그램을 유지, 디버깅을 쉽게하고 컴파일 시간을 좀더 빠르게 할수 있기 때문이다.

라이브러리에도 그 쓰임새에 따라서 여러가지 종류가 있다(크게 3가지). 가장 흔하게 쓰일수 있는 "정적라이브러리"와 "공유라이브러리", "동적라이브러리" 가 있다.

이들 라이브러리가 서로 구분되어지는 특징은 적재 시간이 될것이다.

http://blog.naver.com/guriis/40002401420

여기에 사용되는 설명은 DLLs for Beginners.Doc 문서에서 발췌 했다.

내가 설명하는 것 보단 훨씬 좋기 때문이다. 물론 난 글을 잘 못쓴다.

DLLs for Beginners.Doc 문서는 첨부 했다.

 

Static Linking(정적 링크)

C, Pascal, FORTRAN와 같은 고 수준의 프로그래밍 언어들에서는, 실행가능한 파일을 생성하기 위해서 응용프로그램의 소스 코드를 컴파일하고 다양한 라이브러리에 링크한다. 이러한 라이브러리들은 메모리를 할당하거나 숫자의 제곱근을 계산하는 것과 같은 일반적인 작업을 수행하기 위해서 호출되는 미리 컴파일된(precompiled) 함수들의 개체(object) 파일을 포함한다. 이러한 라이브러리 함수들이 응용프로그램에 링크될 때, 그것들은 응용프로그램 실행파일에 영구적으로 속하는(permanent) 부분이 된다. 그 라이브러리 함수에 대한 모든 호출은 링크 시간에 결정된다(resolved) - 즉 그 이름은 정적 링크(static linking)이다.

Dynamic Linking(동적 링크)

동적 링크는 실행시간에 응용프로그램이 라이브러리를 링크하는 메커니즘을 제공한다. 그 라이브러리들은 자체의 실행 파일에 존재하며, 응용프로그램의 실행 파일에 정적 링크처럼 복사되지 않는다. 이들 라이브러리들은 동적 링크 라이브러리(DLL)라고 불리우는데, 그것들이 로드되고 실행될 때가 그것이 링크되었을 때가 아니라 응용프로그램에 링크되었을 때임을 강조한 것이다. 응용프로그램이 DLL을 사용할 때, 운영 체제는 DLL을 메모리로 로드하고, DLL 안의 함수들에 대한 참조를 결정한다. 그래서 그것들은 응용프로그램에 의해 호출될 수 있으며, 더 이상 필요하지 않을 때 DLL은 언로드될 수 있는 것이다. 이 동적 링크 메커니즘은 응용프로그램이나 운영체제에 의해서 명시적으로 수행될 수 있다.

1.    File에서 New를 선택해서 Project 탭을 선택한다.

2.    프로젝트 타입 목록에서 Win32 Dynamic-Link Library를 선택한다 .

 

 

 

3.    적절한 프로젝트명을 기입하고, Finish.

 

 

 

이제 DLL을 위한 기본적인 프로젝트 파일이 만들어진 것이다

 

4.    cpp 및 헤더 파일 생성은 알아서 해라.

5.    def 파일은 File-New-C/C++HeaderFile 을 선택하고 파일명 기입시 확장자를 입력하면 된다.

 

MyDLL.cpp

#include <windows.h>

 

BOOL WINAPI DllEntryPoint(HINSTANCE hDll, DWORD dwReason, LPVOIDReserved)

{

             switch(dwReason)

             {

                           case DLL_PROCESS_ATTACH:

                                        break;

                                       

                           case DLL_PROCESS_DETACH:

                                        break;   

             }

 

             return TRUE;

}

 

이것은 이 DLL을 사용하는 프로그램들이 이 DLL을 로드하면 DllEntryPoint()가 자동으로 호출이 되는 것이다. 그리고 위의 코드는 switch ~ case 문으로 구성이 되어있다. DLL_PROCESS_ATTACH는 DLL이 EXE에 로딩될 때, 실행된다. 그러므로 초기화에 관련된 코드는 이 곳에 넣어주면 된다. 또한 DLL_PROCESS_DETACH는 DLL이 EXE 파일에서 해제될 때 실행된다. 그러므로 이 부분엔 DLL을 사용하는 EXE 파일이 종료되기 직전에 실행될 부분을 넣어주면 된다.

 

 

int MyFunc(int a, int b)

{

    return a*b;

}

int CdeclFunc(int  a)

{

    return  2*a;

}

 

MyDLL.h

int MyFunc(int a, int b);

int CdeclFunc(int a);

 

MyDLL.def

EXPORTS

             MyFunc

             CdeclFunc

 

 

 

 

-------------------------------------------------------------------

EXE 프로그램 작성

1.       File에서 New를 선택해서 Project 탭을 선택한다.

2.       프로젝트 타입 목록에서 Win32 Console Application 를 선택한다 .

 

 

 

 

 

 

3.       적절한 프로젝트명을 기입하고, Finish

 

 

 

 

 

APP.cpp

 

#include <windows.h>

#include <stdio.h>

 

void main()

{

             typedef int(*lbFunc1)(int);

             typedef int(*lbFunc2)(int, int); // 포인터 함수 사용

 

    int x = 3;

             int a = 3;

 

             lbFunc2 Func2;

 

             HINSTANCE  hLibrary;

             hLibrary = LoadLibrary("MyCPP.dll"); //Load DLL in main

 

             if( hLibrary == 0 ){ //HINSTANCE handle를 얻음

        printf( NULL, " Load rfm Library failed.", 0 );

exit(0);

    }

 

             Func2 = (lbFunc2)GetProcAddress(hLibrary, "MyFunc"); // 함수 얻음.

             if(Func2 == NULL){

        printf( NULL, " Load CMyFunc failed.", 0 );

        exit(0);

    }

            

             a = ((Func2)(x,a));

 

             printf("%d", a);

 

             FreeLibrary(hLibrary); //Free Library in main

}

dll 파일은 Exe 실행파일이 있는곳에 복사 해야 된다. /Debug 밑이나 /Release밑에 복사 하면 된다.

 

더 이상 태클 걸지 마라. 나도 찾아서 알아 낸 거다.

윈도우 운영체제 환경에서 특정한 프로세스가 장악하고 있는 핸들이나 DLL 파일에 대한 중요한 정보를 자세하게 살펴 볼 수 있는 Process Explorer의 v14.01 버전이 출시되었습니다.

http://www.winapi.co.kr/

http://sol9501.blog.me/70102942944

|DLL 분석 ①|DLL파일 생성과 설명

* 이번 포스팅은 실제 DLL파일이란 무엇인지 알아보고 직접 생성하는 방법을 알아보겠습니다.

 1. DLL(Dynamic Link Library)이란?

   1)정의

     - 어플리케이션에서 동적으로 링크하여 사용할 수 있는 라이브러리를 말하며 확장자로는 .dll, .fon, .drv, .exe 등이 사용된다.

구조는 간단히 코드부분과 데이터로 구성되어있으며, 스택이 없다는 것이 특징이다. 스택은 어플이케이션의 것을 사용한다. 스택이 없으므로 독립적인 프로세스가 될 수 없으며 운영체제로 부터의 메세지를 받을 수 없다. 내부에 Exported Function Table을 가지고 있으며 서수 + 기호이름 + 실제함수를 가리키는 포인터로 구성되어 있다.

   2) 종류

    - Regular DLL (Statically linked MFC DLL) : 배포시 자신의 DLL만 제공가능

    - Regular DLL (using Shared MFC DLL) : 배포시 자신의 DLL과 MFC공유DLL을 같이 제공

      -> 어플리케이션이 MFC이외의 경우에도 사용가능

      C언어 기반의 인터페이스제공 필요.

     - MFC Extension DLL (using Shared MFC DLL) : MFC로 작성된 어플리케이션에서만 사용가능

    3) 로딩방법

     ㄱ) Implicit Loading (암시적 로딩)

        - DLL + Lib + header file 필요. 

- 어플리케이션 로딩때 같이 로딩.

     ㄴ) Explicit Loading (명시적 로딩)

         - 로딩타임 마음대로 결정가능

- 주요함수

- LoadLibrary : DLL모듈 로딩

- GetProcAddress : 함수의 포인터를 얻어옴

- FreeLibrary : DLL 종료 (reference counter를 1감소시킨다)

  2. DLL 생성

    - DLL을 만드는 방법에는 크게 두 가지가 있다. 하나는 고전적인 DLL정의 방법인 모듈 정의 파일을 이용하는 것이고 다른 하나는 내장 Visulal c++ 지시자인 __declspec(dllexport)를 이용하는 것이다. 우선은 고전적인 방법인 모듈정의 파일을 이용해 먼저 DLL 파일을 생성해 보겠습니다. 소스는 아래와 같습니다. VS2010기준으로 DLL 파일을 생성하는 방법은 아래의 그림 1-1부터 1-3과 같습니다.

그림 1-1) win32 project

그림 1-2) Application Setting

- 그림 1-2에서처럼 어플리케이션 타입은 DLL을 클릭해 줍니다. 프로젝트가 생성되었으면 빈 cpp소스파일을 하나 생성하고 아래의 예제소스를 복사해 붙여 넣고 빌드합니다. 빌드가 성공하면 그림 1-3과 같이 dll 파일이 생성됩니다.

Ex1) 예제소스 1

그림 1-3) Application Setting

- 여기서 잠깐 우리는 저 DLL을 왜 만드는지 짚고 넘어가야 한다. DLL을 사용하는 근본적인 이유는 반복해서 사용하는 코드를(위의 경우 3가지 함수들) 매번 작성할 것이 아니라 따로 바이너리 모듈로 만들어두고 필요할 때마다 링크해서 사용하고자 하는 목적이다. 여기서 확장자가 .lib라는 파일인 정적 라이브러리와 .DLL인 동적 라이브러리로 나뉘는데 이 둘의 차이는 정적 라이브러리는 코드나 데이터가 링크 시에 pe파일 내에 병합되어 그만큼 PE파일의 사이즈가 커지지만 동적 라이브러리의 경우(.DLL) 라이브러리의 코드나 데이터는 해당 PE가 로드 될 때 그 PE의 가상 주소 공간에 병합된다는 것입니다. 즉 링크된 EXE의 PE 파일에는 단지 해당 라이브러이에서 사용할 함수에 대한 간단한 정보만 기록됩니다.(이 부분의 확인은 위에서 링크한 PE파일 익스포트 섹션분석편을 참고하세요.)

모듈 자체가 정적 라이브러리처럼 EXE의 PE이미지 내에 병합되는 것이 아니기 때문에 DLL의 경우 이렇게 실행 이미지에 병합하고자 하는 함수나 변수는 미이 병합될 함수라는 것을 컴파일러나 링커에게 알려주어야 합니다. 이렇게 알려주는 것을 "익스포트"한다라고 하는데 익스포트시키지 않으면 해당 DLL 내의 어떤 함수나 변수를 사용할 수 있는 지 판단한 수 없습니다.

위의 과정은 단지 함수만 정의했을 뿐 그 외 어떠한 것도 지정하지 않았습니다. 즉 익스포트시키지 않은 것입니다. 그 결과 그림 2와 같이 dumbin 으로 익스포트 정보를 요구해도 아무런 정보가 나타나지 않는 것입니다.

이러한 익스포트 하는 방법으로 위에서 언급한 모듈 정의 파일을 정의하거나 __declspec(dllexport) 지시어를 사용하는 방법이 있습니다. 우리는 우선 고전적이고 지금은 사용빈도가 적지만 기본이 되는 모듈 정의 파일을 이용하는 방법을 알아보겠습니다. 제가 항상 말씀드리지만 고수와 하수의 차이는 기본기에 있습니다. ^^ 기초가 튼튼해야죵..^^

그림 2) 익스포트 되지 않은 dll파일

1) 모듈정의 파일 사용

- 모듈 정의 파일의 장점은 서수를 지정할 수 있다는 것이다. 서수를 지정할 수 있다는 이야기는 서수가 익스포트 함수들에 대한 인덱스 역할을 하게 되기 때문에 문자열 비교 없이 빠른 속도로 해당 함수를 링크할 수 있다는 장점이 있다. 또한 DLL에 익스포트 함수를 새로 추가할 때 이 함수에 해당하는 서수를 그 DLL내에서 익스포트된 다른 모든 함수의 서수 값들보다 더 높은 값으로 할달 할 수 있다. 이렇게 되면 암시적 링크를 사용하는 응용 프로그램에서 새로운 함수가 추가된 DLL에 해당하는 LIB파일을 다시 링크할 필요가 없어진다. 이 경우 기존의 DLL에 새로운 기능을 추가하여 계속 업그레이드시키면서도 기존 응용 프로그램이 업그레이드된 DLL과 올바르게 작동하도록 할 수 있다. 또한 만약 익스포트시킬 함수가 많을 경우 모듈 정의 파일을 통해 "NONAME"의 속성을 지정하게 되면 함수 이름을 저장하지 않고 서수만 저장하기 때문에 DLL의 사이즈를 최적화할 수 있다.

아래 그림 3은 모듈정의 파일을 정의하는 방법을 보여주고 있다. 모듈정의 파일은 노트패드나 문서화 도구를 이용해서 아래 그림 3과 같이 만들어 주면 된다.

그림 3)모듈 정의 파일(.DEF)

- 모듈 정의 파일은 말 그대로 모듈을 정의한다는 의미이다. 이 말은 곧 굳이 작성하는 PE가 DLL이 아니라 exe이더라도 링크 시에 모듈정의 파일에 정의된 지시어들이 유효함을 말하며 링커는 모듈 정의 파일이 존재한다면 이 파일에 지정된 지시어들을 링크 스위치로 해석하게 된다. 일반적으로 모듈 정의문 대신에 사용할 수 있는 링커 옵션이 있기 때문에 일반적으로는 모듈 정의 파일이 필요하지 않다. 하지만 함수 익스포트의 경우 위의 그림 3처럼 EXPORTS 키워드 아래에 익스포트 함수들을 한 번에 정의할 수 있기 때문에 DLL 작성시 모듈 정의 파일을 사용하는 것이다. 각 키워드는 표 1을 참고하세요.

[표 1] – 모듈정의 파일

- 위의 그림 3과 같이 모듈정의 파일을 정의했으면 이젠 다음 그림4와 같이 정의 파일을 프로젝트에 포함시켜주자.

그림 4) 모듈정의 파일 추가

- 위의 그림 4와 같이 모듈정의 파일을 추가했으면 다시 한 번 빌드해줍니다. 그러면 이번에는 lib파일과 exp파일이 생성되었음을 알 수 있습니다. 아래의 그림은 dumpbin으로 다시 한 번 DLL의 익스포트 정보를 확인해 보겠습니다.

그림 5) DLL 익스포트 정보

- 그림 2와 비교하여 이 번에는 예제소스의 함수들이 제대로 익스포트되어 출력됨을 알 수 있습니다. 실행방법은 생성된 lib파일을 실행할 프로젝트에 포함시키고 컴파일 시키시면 됩니다. 아래 그림 6은 실행화면 설명입니다. 소스는 실행파일 소스입니다.

Ex2) 실행파일 소스 1

그림 6) 모듈정의 파일 방법실행

2) __dlclspec(dllexport) 지시자 사용

- MS에서는 컴파일러에서 익스포트할 함수나 변수의 이름을 자동으로 생성한 다음에 ,LIB 파일에 포함시킬 수 있도록 하였는데 그 때 쓰이는 지시자가 __declspec이다. dexlspec(dllexport) 지시자를 사용하여 dll에서 데이터, 함수, 클래스 또는 클래스 멤버 함수를 내보낼 수 있도록 변경할 수 있다. 그리고 __declspec(dllexport)와 쌍으로 사용되는 키워드가 __declspec(dllimport)이다. __declspec(dllexport)은 컴파일러로 하여금 해당 함수가 익스포트될 것임을 알려준다. 반대로 __declspec(dllimport)는 컴파일러로 하여금 해당 함수가 임포트되는 함수임을 미리 알려주는 역할을 한다. 소스파일과 헤더파일의 소스는 아래와 같습니다.

Ex3) 소스 1

Ex4) 헤더 1

- 위의 소스가 정의문들이 많아 약간 어려워 하실 분들도 있을 수 있겠지만 실상은 상당히 간단한 문장입니다..

__cplusplus와 extrn "C"는 함수 호출 방법에 따른 스택정리와 이름 데코레이션의 관계때문에 정의해 준 부분입니다. 이 부분을 설명하자면 이번 포스팅의 범위를 넘어가니 이 부분은 따로 관계된 문서를 찾아 보시길 바랍니다.

아래 그림과 같이 소스 파일과 헤더파일을 추가 시키고 빌드 하면 위이 파일정의 모듈방식과 동일하게 LIB파일이 생성됨을 알 수 있습니다. 이 파일을 dumpbin으로 출력해보면 위의 그림 5와 같이 익스포트 정보들이 출력됨을 알 수 있습니다.

그림 9) declspec 빌드

그림 10) dumpbin 출력화면

http://cs.knou.ac.kr/~khkim/faq/slist.asp?code=aa027&num=1

static link 이든 dynamic link 이든 둘다 라이브러리이다

그런데 사용 방법에 있어 좀 차이가 있다

상황에 따라 적절한 것을 사용 하면 되겠다

static link  실행 파일에 라이브러리를 포함하여 배포 : 일반적으로 사용자는 해당 dll 을 가지고 있지 않기 때문에 이 방식으로

배포를 한다

static link(debug) 싱행파일에 라이브러리를 포함하는데 debug 할 수 있는 정보까지 같이 배포한다

dynamic link 라이브러리를 독립적으로 분리한다, 이점은 하나의 파일만 만들어 짐으로 메모리 점유율이 static link 보단 적다

그리고 개발 시 dll 부분에 오류가 있으면 해당 dll 만 수정하여 해당 dll 만 배포하면 된다

또한 여러곳에서 동일한 파일로 툴, 엔진 등의 라이브러리 관리를 static link 처럼 종속되지 않고 독립적으로

관리 할 수 있어 관리의 용이성이 더해진다

dynamic link (debug) dynamic link 에 debug 정보를 포함하여 해당 dll 에서의 debug도 가능하게 해준다

라이브러리란 특정한 코드(함수 혹은 클래스)를 포함하고 있는 컴파일된 파일이다

라이브러리를 만드는 이유는 자주 사용되는 특정한 기능을 main 함수에서 분리시켜 놓음으로써, 프로그램을 유지, 디버깅을 쉽게하고 컴파일 시간을 좀더 빠르게 할수 있기 때문이다.

정적라이브러리 

정적라이브러리는 object file(.o로 끝나는) 의 단순한 모음이다. 정적라이브러린느 보통 .a 의 확장자를 가진다. 간단히 사용할수 있다. 컴파일시 적재(로드)되므로 유연성이 떨어진다. 최근에는 정적라이브러리는 지양되고 있는 추세이다. 컴파일시

적재(로드)되므로 아무래도 바이너리크기가 약간 커지는 문제가 있을것이다.

공유라이브러리

공유라이브러리는 프로그램이 시작될때 적재(로드)된다. 만약 하나의 프로그램이 실행되어서 공유라이브러리를 사용했다면, 그뒤에 공유라이브러리를 사용하는 모든 프로그램은 자동적으로 만들어져 있는 공유라이브러리를 사용하게 된다. 그럼으로써 우리는 좀더 유연한 프로그램을 만들수 잇게 된다.

 

정적라이브러리와 달리 라이브러리가 컴파일시 적재되지 않으므로 프로그램의 사이즈 자체는 작아지지만 이론상으로 봤을때, 라이브러리를 적재하는 시간이 필요할것이므로 정적라이브러리를 사용한 프로그램보다는 1-5% 정도 느려질수 있다. 하지만 보통은 이러한 느림을 느낄수는 없을것이다.

 

 

동적라이브러리

공유라이브러리가 프로그램이 시작될때 적재(로드)되는 반면 이것은 프로그램시작중 특정한때에 적재(로드)되는 라이브러리이다. 플러그인 모듈등을 구현할때 적합하다. 설정파일등에 읽어들인 라이브러리를 등록시키고 원하는 라이브러리를 실행시키게 하는등의 매우 유연하게 작동하는 프로그램을 만들고자 할때 유용하다.

 

 

---

 

 

정적 라이브러리와 동적 라이브러리 차이  C++ /API/MFC  2011/10/13 15:15 http://blog.naver.com/hacker1420/120142196000 정적 라이브러리(lib) : 컴파일할 때 같이 링크  동적 라이브러리(dll) : 컴파일 할 떄가 아닌, 실제로 프로그램이 실행될 때 동적으로 링크   둘 다 실행 모듈이지만 언제 링크가 되느냐의 차이! 메모리를 효율적으로 쓰기 위해서는 lib 보다 dll 방식이 좋음.(필요할 때만 링크해서 쓰고 필요 없으면 바로 해제) lib 방식은 프로그램이 실행되면 바로 메모리를 차지하고 프로그램이 종료될 때까지 메모리에 남아있음.

Microsoft Specific

dllimport, dllexport

DLL에서(로) 함수, 데이터, 개체를 내보내는(가져오는) 속성. 함수를 dllexport로 선언하면, 적어도 export된 함수 스펙과 관련된 .DEF (모듈 정의) 파일이 필요없다. 또한 dllexport는 __export 키워드 (16비트 버전의 VC++에서 사용) 를 대체한다.

declspec(dllexport) 클래스의 클래스 템플릿 특수화(specialization)는 암묵적으로 declspec(dllexport)가 된다. 즉 템플릿은 명시적으로 인스턴스화(==구체화)되고, 그 멤버들은 반드시 정의되어야 한다.

dllexport C++ 함수는 이름장식을 가진 함수를 노출시킨다. C++ 이름장식이 필요없다면, .def 파일 (EXPORTS(MSDN) 키워드)를 사용하거나 함수를 extern "C"로 선언한다.

dllexport와 dllimport는 반드시 declspec과 확장된 속성 구문을 사용해야 한다.

정의와 선언

DLL 인터페이스는 일부 프로그램이 export한 모든 항목 (함수와 데이터) 을 참조한다; 즉 모든 항목은 dllimport나 dllexport로 선언되며, DLL에 선언된 것들은 반드시 둘 중 하나를 가져야 한다. 하지만, 그 정의는 반드시 dllexport여야한다. 즉 다음과 같은 코드는 컴파일 에러란 말이다:

dllexport는 정의를 dllimport는 선언을 의미한다. dllexport와 extern 키워드를 같이 사용하면 강제로 선언할 수 있다; 그렇지 않으면 정의를 의미한다. 다음 코드들을 보자:

dllexport/ dllimport로 선언된 인라인 C++ 함수 정의

dllexport 함수를 인라인으로 선언하면, 어떤 모듈이 그 함수를 참조하던말던 항상 인스턴스화되고 export되며, 다른 프로그램에서 import한다고 가정된다.

dllimport 함수를 인라인으로 선언하면, 그 함수는 확장될 수 있지만 (/Ob(VS6.0) 설정에 따라) 절대 인스턴스화되지는 않는다. 특히 인라인 import 함수의 주소가 있다면, DLL 안에 존재하는 그 함수의 주소가 리턴된다. 이는 인라인이 아닌 import 함수의 주소를 얻는 것과 같은 방식이다.

위 규칙들은 클래스 안에 정의된 인라인 함수에 적용된다. 게다가, 인라인 함수 안의 정적 로컬 데이터와 스트링은 마치 하나의 프로그램 (즉 DLL 인터페이스가 없는 실행 파일) 안에 있는 것처럼 DLL과 클라이언트 사이에서 동일성을 유지한다.

DLL을 업데이트할 때, 클라이언트가 바뀐 DLL을 사용할 거라고 가정하지 않는다. 올바른 버전의 DLL을 로딩하려면, 해당 클라이언트 또한 재빌드한다.

일반적인 규칙과 제한사항

─ dllimport나 dllexport 없이 선언된 함수나 개체는 DLL 인터페이스로 간주되지 않으며, DLL 인터페이스로 만들려면 dllexport로 정의한다. 이런 경우든 dllexport로 선언된 경우든, 같은 프로그램 안에 정의되어야 한다. 아니면, 링커 에러가 발생한다.

─ 하나의 모듈 안에 동일한 함수나 개체가 dllimport와 dllexport 2가지로 선언되면 dllexport 속성이 우선하지만, 이는 파일러 경고를 일으킨다:

─ C++에서는 글로벌/ 정적 로컬 데이터 포인터를 dllimort로 선언된 데이터 개체의 주소로 초기화할 수 있다. 하지만 이는 C에서 에러다. 또한, 정적 로컬 함수 포인터를 dllimport로 선언된 함수의 주소로 초기화할 수 있다. 이 포인터는 C에서 DLL import thunk (함수로 제어를 넘기는 코드 토막) 의 주소, C++에서는 함수의 주소가 할당된다:

하지만 dllexport 개체 선언을 포함하는 프로그램은 반드시 정의도 가져야하므로, 글로벌/ 로컬 정적 함수 포인터를 dllexport 함수의 주소로 초기화할 수 있다. 또한 글로벌/ 로컬 정적 데이터 포인터를 dllexport 데이터 개체의 주소로 초기화할 수 있다. 가령 다음 코드는 C/ C++에서 모두 에러가 아니다:

─ VC++ .NET에서는 regular 클래스와 클래스 템플릿의 특수화 사이에서 dllexport를 가진 애플리케이션이 보다 일관되도록 하기위해, dllexport가 아닌 기본 클래스를 가진 regular 클래스에 dllexport를 적용하면 C4275(한글) 컴파일러 경고가 발생한다.

이 경고는 기본 클래스가 클래스 템플릿의 특수화일 경우도 발생하는데, 이 때는 dllexport를 표시해주면 된다. 즉 클래스 템플릿에 __declspec(dllexport)을 쓸 수 없다. 대신 다음처럼, 명시적으로 클래스 템플릿을 인스턴스화하고 여기에 dllexport를 사용한다:

이 방법은 다음처럼 템플릿 인자가 부모 클래스인 경우 에러가 발생한다:

이는 템플릿에서 흔한 패턴이기 때문에, VC++ .NET 컴파일러는 하나 이상의 기본 클래스를 가지는 클래스에 적용될 때와 하나 이상의 기본 클래스가 클래스 템플릿의 특수화일 경우 dllexport 구문을 바꿨다. 이 경우 컴파일러는 암묵적으로 클래스 템플릿의 특수화에 dllexport를 사용하며, 위 문장은 문제없이 컴파일된다.

dllexport/ dllimport를 C++ 클래스에서 사용하기

dllimport/ dllexport로 클래스를 선언하면, 그 클래스 전체가 import/ export되며, 이렇게 export된 클래스를 exportable 클래스라 한다.

참고 exportable 클래스의 멤버는 dllimport와 dllexport를 명시적으로 쓸 수 없다.

─ dllexport 클래스는 모든 멤버함수와 정적 데이터멤버가 export되므로, 동일 프로그램 안에서 모든 멤버를 정의해야 한다. 그렇지않으면 링커에러가 발생한다. 단 순수 가상함수의 경우 예외이며, 가상 클래스의 소멸자는 항상 기본클래스의 소멸자에서 호출되므로, 순수 가상 소멸자는 반드시 정의해야 한다. 이 규칙들은 exportable 클래스가 아니더라도 적용된다.

클래스타입의 데이터나 클래스를 리턴하는 함수를 export하려면, 클래스를 export해야만 한다.

─ dllimport 클래스는 모든 멤버함수와 정적 데이터멤버가 import된다. 비클래스 타입에서의 dllimport/ dllexport와는 달리, 정적 데이터멤버는 dllimport 클래스가 정의된 프로그램에서 정의할 수 없다.

─ exportable 클래스의 모든 기본 클래스는 exportable이어야 한다. 아니면, 컴파일러 경고가 발생한다. 게다가, 클래스이기도 한 모든 accessible 멤버는 exportable이어야 한다. 이로써 dllexport 클래스는 dllimport 클래스로부터 상속받을 수 있고, dllimport 클래스는 dllexport 클래스에서 상속받을 수 있다 (후자는 권장되지 않는다). 대개, (C++ 접근 규칙에 따라) DLL 클라이언트에서 accessible한 모든 것들은 exportable 인터페이스의 일부여야 한다(should). 이는 인라인 함수에서 참조되는 private 데이터멤버에도 해당된다.

End Microsoft Specific

출처 : http://redsky84.tistory.com/entry/declspec-%ED%99%95%EC%9E%A5%EB%90%9C-%EC%86%8D%EC%84%B1-%EA%B5%AC%EB%AC%B8-III

프로젝트의 속성에서 출력형태를  클래스 라이브러리로 변경하여 빌드하면됨

#ifdef EXPORTRULE 
#define MYDLL __declspec(dllexport) 
#else 
#define MYDLL __declspec(dllimport) 
#endif 

이 같은 매크로를 이용해서 DLL 클래스를 작성하였고 

http://blog.naver.com/kimgudtjr?Redirect=Log&logNo=140096145411 에서 인용한글

http://openarisu.tistory.com/191

다음 순서로 진행이 된다. 
알아두자.

1. WM_CLOSE (OnClose) 발생
2. DestoryWindow (DestoryWindow )  호출 
3. WM_DESTORY ( OnDestory) 발생

각 함수를 수정할려면
WM_CLOSE 메시지 선택시 OnClose()
DestoryWindow 재정의할 때 DestoryWindow()
WM_DESTROY 메시지 선택시 OnDestory() 함수를 작성할 수 있다.

소스 내용 보기.
void CTestDlg::OnClose()
{
    // TODO: 여기에 메시지 처리기 코드를 추가 및/또는 기본값을 호출합니다.
    >> 이 부분에서 종료되는 윈도우를 제어할 수 있습니다.
    CDialog::OnClose();
}

BOOL CTestDlg::DestroyWindow()
{
    return CDialog::DestoryWindow();
}

void CTestDlg::OnDestory()
{
    CDialog::OnDestory();
}


참조 : http://yunhyeon.tistory.com/tag/DestroyWindow