4가지 DLL: NON-MFC DLL, Regular DLL Statically/Dynamically Linked to MFC, MFC Extension DLL

참조 자료:
https://msdn.microsoft.com/en-us/library/30c674tx.aspx
http://www.cnblogs.com/qrlozte/p/4844429.html
http://www.cnblogs.com/qrlozte/p/4850642.html
 
위에서 설명한 MSDN 링크에서는 네 가지 DLL의 정의를 볼 수 있습니다.여기에는 군말하지 않겠다.주워 말하다
차이점은 다음과 같습니다.

NON-MFC DLL 내부에서는 MFC를 사용할 수 없습니다(물론 내보낸 API도 MFC와 관련될 수 없습니다).(여기서 내가 말한'내보낸 API'는 지도된 C 함수, C++ 클래스 또는 공유된 전역 변수 등)

Regular DLL Statically/Dynamically linked to MFC 내부에서 MFC를 사용할 수 있습니다.그러나 그 도출된 API는 MFC와 관련될 수 없다(예를 들어 MFC와 관련된 어떤 클래스나 그 하위 클래스, 네가 쓴 MFC의 하위 클래스, 그리고 이 DLL에서 실행되지 않은 MFC 코드, 말하자면 MFC와 관련된 모든 코드는 DLL 내부에서만 실행될 수 있다. 만약에 DLL에서 내보낸 다음에 다른 EXE나 DLLL에서 실행된다면 안 된다.)물론 DLL이 MFC 라이브러리에 동적으로 연결되는지, 아니면 정적으로 MFC 라이브러리에 연결되는지에 따라 두 가지로 세분화된다.

MFC Extension DLL 내부에서 MFC를 사용할 수 있으며 내보낸 API도 MFC와 관련될 수 있습니다.

NON-MFC DLL에서 MFC Extension DLL까지 다양한 기능을 사용할 수 있습니다.NON-MFC DLL은 C 함수, 전역 변수, 일반적인 C++ 클래스를 내보낼 수 있으나 MFC와 관련될 수 없습니다.Regular DLL은 NON-MFC DLL의 모든 기능을 갖추고 그 내부에서 MFC를 사용할 수 있으나 MFC와 관련된 부분을 내보낼 수 없습니다.MFC Extension DLL은 Regular DLL의 모든 기능을 갖추고 있으며 MFC를 사용하는 API를 내보낼 수 있습니다.

 
1. VS에서 네 가지 DLL 프로젝트를 만드는 방법
1.1、NON-MFC DLL
새 항목 > VC++ > Win32 > Win32 항목 > DLL 선택
1.2、Regular DLL Statically/Dynamically linked to MFC
새 프로젝트 > VC++ > MFC > MFC DLL > Statically linked to MFC/Dynamically linked to MFC 선택
1.3、MFC Extension DLL
새 항목 > VC++ > MFC > MFC DLL > MFC Extension DLL 선택
 
DLLDEMO 프로젝트:
 
예를 들어 NON-MFC DLL(AddXx.dll): C 함수, 전역 변수, 비 MFC의 C++ 클래스를 내보냅니다.
예를 들어 Regular DLL Dynamically linked to MFC(Add.dll): C 함수를 내보냈습니다. 이것은 MFC가 아닌 C++ 클래스입니다. 둘 다 그 내부에서 MFC를 사용하여 대화상자를 만들 수 있습니다.또한 InfoDlgFactory를 통해 Regular DLL이 MFC 클래스를 내보내지 못하는 이유를 설명했습니다.InfoDlg 만나요.cpp의 InfoDlgFactory 주석
예를 들어 MFC Extension DLL(AddExt.dll): 대화상자인 C 함수, MFC 하위 클래스를 내보냅니다.
테스트 프로그램:FontView.exe, Print Sample 단추를 누르면 세 가지 DLL을 테스트할 수 있습니다. 관련 코드는 CMain Window::OnPush Button Clicked에서 볼 수 있습니다.
다운로드 주소: DLDEMO 다운로드
 
참고:
1、AFX_MANAGE_STATE의 역할
https://msdn.microsoft.com/en-us/library/0asx94f7.aspx
https://msdn.microsoft.com/en-us/library/30c674tx.aspx
 
간단하게 말하자면 당신의 프로젝트에 a.EXE, b.DLL, c.DLL, a는 b, b는 c로 동적 연결이 있다고 가정하면 실제로 a, b, c는 세 개의 모듈이다.코드 실행 경로(code path)가 a에서 b로 또는 b에서 c로 전환될 때'모듈 상태'의 전환이 관련된다. 물론 이'모듈 상태'는 쪼개서 깨물어야 한다. 말하면 전날도 다 말한 것은 아니다. 어쨌든AFXMANAGE_스테이트가 이 일을 한 거야.만약 그것이 없다면 각종 오류가 발생할 것이다.
 
AddExt 작성dll 코드를 볼 때 MSDN의 설명을 자세히 보지 않았기 때문에 InfoDlgFactoryExt에서 AFX 를 사용했습니다MANAGE_STATE로 인해 LNK2005 오류가 발생했습니다(error LNK2005:DllMain@12 already defined in dllmain.obj).실제로 MFC Extension DLL은 이걸 쓰지 않아요,AFXMANAGE_STATE는 MFC에 동적으로 연결된 Regular DLL에 대해서만 사용할 수 있습니다(https://msdn.microsoft.com/en-us/library/30c674tx.aspx;“The AFX_MANAGE_STATE macro should not be used in regular DLLs that statically link to MFC or in extension DLLs. ”).
 
2、AFX를 사용해야 하는 곳MANAGE_STATE
사전 요구 사항, DLL은 MFC 라이브러리에 동적으로 연결되는 regular dll입니다.그리고 모듈 전환과 관련된 부분, 즉 하나의 모듈 호출이 다른 모듈 내의 코드를 실현하고 이 코드가 MFC 라이브러리의 코드를 호출할 때이다.AFX 를 사용해야 합니다MANAGE_STATE.아래는 예를 들어 설명한다
 
Add 프로젝트를 열고CinfoDlg와 DoModalDlgImpl의 정의를 보십시오

class CInfoDlg : public CDialog, public IInfoDlg

IInfoDlg의 정의를 보면 IInfoDlg는 순수한interface이고 그 안에는pure virtual 함수만 Add로 되어 있음을 알 수 있다.dll의 인터페이스용.CDialog는 MFC 클래스입니다.그래서 CinfoDlg도 MFC 클래스이기 때문에 CinfoDlg의 창설, 사용, 소각은 모두 MFC 라이브러리를 호출할 것이다.
따라서 IInfoDlg의 DoModalDlg와Release,InfoDlgFactory는 모두 MFC 라이브러리를 호출한다.그래서 이 세 가지 방법 다 AFX를 사용했어요.MANAGE_STATE

class DoModalDlgImpl : public IDoModalDlg

IDoModalDlg도interface이기 때문에DoModalDlgImpl은 일반적인 C++류일 뿐입니다.MFC 라이브러리의 생성, 사용 및 제거가 호출될지 여부는 MFC 라이브러리의 구현에 따라 달라집니다.
이제 DoModal DlgImpl의 실현을 보러 가자.
Domodal Dlg Impl::Domodal Dlg에만 CinfoDlg가 만들어지고 CinfoDlg::Domodal이 호출되었기 때문에 Domodal Dlg Impl::Domodal Dlg만 MFC 라이브러리를 호출할 수 있습니다.
따라서 DoModalDlgImpl과 관련된 DoModalDlg,Release,DoModalDlgFactory를 볼 수 있다. DoModalDlg만 AFX 를 사용해야 한다.MANAGE_STATE.
 
3. DLL의 C++ 클래스나 MFC 클래스를 직접 export하지 않는 이유
 
http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
 
하나의 C++ 클래스(MFC 클래스도 예외가 아니다)는 두 가지 부분을 포함하는데 인터페이스와implementation, 즉 인터페이스와 실현,public와protected의 부분은interface(protected 부분은 하위 클래스만interface)에 속한다.
 
"What you see is not what you get"
실제 DLL의 클래스를 내보냅니다. 그 목적은 인터페이스를 내보내는 것이지, 실현하는 것이 아닙니다.단, 직접declspec(dllexport)에서 C++ 클래스를 내보내면 인터페이스 부분을 내보낼 뿐만 아니라 그 실현 부분도 내보냅니다. 그래서 하나의 클래스의 실현이 다른 클래스(예를 들어 계승을 통해 또는 구성원을 통해)에 사용된다고 가정하면 이 부분도 내보냅니다. 이 과정은 계속 진행될 것입니다. 그래서 세 가지 방법만 내보내려고 했는데 그 결과 내보내고 싶지 않은 것이 만8천 개가 나왔습니다.
 
이것이 바로 DLLDEMO에서 인터페이스 부분에 모두의interface(pure virtual 함수만 있는 C++ 클래스)를 사용하는 이유입니다. 이렇게 하면 이 문제를 해결할 수 있습니다.