TN011: Использование MFC как часть библиотеки DLL

В настоящей записке описываются обычные библиотеки DLL, которые позволяют использовать библиотеку MFC как часть Windows динамически подключаемой библиотеки (DLL). Предполагается, что вы знакомы с Windows DLL и как построить их. Сведения о расширения MFC DLL, которые позволяют вам создавать расширения для библиотеки MFC, найти Версию библиотеки DLL MFC.

Интерфейсы DLL

Обычные библиотеки DLL на себя указанные интерфейсы между приложением и библиотекой DLL в обычных C-подобных функций или явно экспортируемые классы. Не могут быть экспортированы интерфейсов классов MFC.

Чтобы использовать MFC DLL и приложение, затем оба имеют выбор использовать общую версию библиотеки MFC или иметь копию библиотеки MFC, статически скомпонованная в них. В версиях, предшествующих Visual C++ 4.0 статическими библиотеками MFC, отличаются для приложений и библиотек DLL. С текущей версией MFC, приложения и библиотеки DLL может как использовать один из стандартных версий библиотеки MFC. Существует не отдельная библиотека для библиотек DLL в этой версии (MFC делает выбор во время выполнения).

Обычные библиотеки DLL имеют ряд преимуществ:

В приложение с помощью библиотеки DLL не нужно использовать MFC, или на то пошло, не должны быть для приложений Visual C++.
С обычным библиотекам DLL, статически связанным с MFC размер DLL зависит только от тех MFC и c времени выполнения подпрограмм, которые должны использоваться и связаны компоновщик.
Размер файла обычные библиотеки DLL, которые динамически связываются с MFC могут быть намного меньше, чем обычные библиотеки DLL, статически связанным с MFC, и экономия в памяти, используя общую версию MFC могут быть значительными. Однако необходимо распределить общие DLL MFCx0.DLL и MSVCRTx0.DLL (или похожих файлов) с библиотекой DLL.
Нет никаких проблем с классами, изменяя под вас. Ваш дизайн DLL экспортирует только те API-интерфейсы вы желаете его для.
С обычным библиотекам DLL, статически связанным с MFC если DLL и приложения MFC, нет никаких проблем с приложением, желающих другую версию MFC DLL (или наоборот). Так как библиотека MFC статически связан в каждой библиотеки DLL или EXE, не идет о какой версии у вас.

Ограничения API

Некоторые возможности MFC не применимы к версии DLL, либо из-за технических ограничений или потому, что эти услуги обычно предоставляются приложением. Ниже перечислены эти ограничения:

CWinApp::Enable3dControls
CWinApp::SetDialogBkColor (цвет игнорируется для окон сообщений)

Создание библиотеки DLL

При компиляции обычным библиотекам DLL, статически связанным с MFC, необходимо определить символы "_USRDLL" и "_WINDLL". Ваш код библиотеки DLL должны быть скомпилированы с следующие переключатели компилятора:

/ D_WINDLL означает, что компиляция для библиотеки DLL
/ D_USRDLL указывает, что выполняется построение обычной библиотеки DLL

При компиляции обычные библиотеки DLL, которые динамически связываются с MFC, необходимо определить выше символов и использовать выше переключатели компилятора. Дополнительно, должен быть определен символ "_AFXDLL" и ваш код библиотеки DLL должны быть скомпилированы с:

/ D_AFXDLL указывает, что выполняется построение обычной библиотеки DLL, динамически связывает с MFC

Интерфейсы (API) между приложением и библиотекой DLL должна быть явно экспортированы. Рекомендуем, что определенные интерфейсы, чтобы быть низкой пропускной способности, прилипание к c интерфейсов, где это возможно. Более прямой c интерфейсы проще чем более сложные классы C++.

Поместите ваш API-интерфейсы в отдельный заголовок, который могут быть включены файлы c и C++ (таким образом, вы не будет ограничивать ваших клиентов DLL для программистов с ++). Смотрите заголовка TRACEAPI.H в MFC концепции перспективных образцов DLLTRACE в качестве примера. Чтобы экспортировать ваши функции, введите их в разделе EXPORTS файла определения модуля (.DEF) или включить ключевое слово __declspec(dllexport) на определения функций. Использовать __declspec(dllimport) для импорта этих функций в клиентский исполняемый модуль.

Необходимо добавить макрос AFX_MANAGE_STATE в начале всех экспортируемых функций в обычных библиотеках DLL, которые динамически связываются с MFC, чтобы установить для текущего состояния модуля одну из библиотеки DLL. Это делается путем добавления следующую строку кода в начало функций, экспортированных из библиотеки DLL:

nbsp; & nbsp;

AFX_MANAGE_STATE (AfxGetStaticModuleState ())

nbsp; & nbsp;

WinMain - > DllMain

Библиотека MFC определяет стандартный точку входа Win32 DllMain , инициализирующего производный объект CWinApp , как в обычном приложении MFC. Поместите все DLL инициализации в функции-члена InitInstance как в обычном приложении MFC.

Обратите внимание, что механизм CWinApp::Run не применяется для библиотек DLL, так как приложение имеет основной конвейер сообщений. Если библиотека DLL вызывает немодальные диалоги или окно или в своих собственных, ваше приложение основной конвейер сообщений должен вызывать экспортируемую DLL процедуру, которая вызывает CWinApp::PreTranslateMessage.

Содержится в разделе Пример DLLTRACE для использования этой функции.

Функция-член ExitInstance вашей CWinApp, производный класс будет вызываться из MFC предоставляет функции DllMain до выгрузки DLL.

Что делать, чтобы связать все это вместе

Обычные библиотеки DLL, статически связанным с MFC необходимо связать библиотеку DLL с библиотекой (NAFXCWD.LIB или NAFXCW.LIB) вместе с версией c сред под названием ' LIBCMT.LIB'. Эти библиотеки являются заранее построили и могут быть установлены, указав их при запуске программы установки Visual C++.

Пример кода

Смотрите пример программы концепции перспективных MFC DLLTRACE полный пример. Это включает в себя простой DLL под названием ' TRACER.DLL' что реализует флаги трассировки AFX диалоговое окно (см. техническое примечание 7). Она также имеет простое приложение HELLO, вызывающий DLL для использования диалогового окна.

Несколько интересных вещь, чтобы отметить:

Флаги компилятора DLL и приложение очень разные.
Линии связи и.DEF-файлов для библиотеки DLL и приложения также очень разные.
Даже в приложение с помощью библиотеки DLL не должно быть в C++.
Интерфейс между приложением и библиотекой DLL является «C»-как API и экспортируются с ТРАССИРУЮЩЕЙ.DEF.

Следующий отрывок из TRACEAPI.H иллюстрирует, что нужно для один API-интерфейс, определенный в обычной библиотеке DLL, которые статически связана с MFC:

# ifdef __cplusplus
{extern «C»
#endifnbsp; / * __cplusplus * /

Структура TracerData
{
    BOOL bEnabled;
    UI&NT флаги;
};

BOOL далеко экспорта Паскаль PromptTraceFlags (TracerData FAR * lpData);

# ifdef __cplusplus
}
# endif

В этом примере Декларация прилагается в блоке "extern"C"{}" для пользователей C++. Это имеет ряд преимуществ. Во-первых это делает ваш API-интерфейсы DLL полезная-C++ клиентскими приложениями. Во-вторых он уменьшает накладные DLL, так как искажения имен C++ не будет применяться к экспортируемое имя. И наконец, это облегчает явно добавить.DEF файла (для экспорта по порядковому номеру) без необходимости беспокоиться о искажения имен.

Все API функции являются "Далеко Паскаль экспорта". Хотя не stricly необходимых для Win32 DLL, эти определения были сохранены для легкой портирования обратно для 16-разрядной версии Windows. Дальний, Паскаль, ЭКСПОРТИРОВАТЬ макросы и все расширения к ничего под Win32.

Структуры, используемые интерфейсом API не являются производными от классов MFC и полностью определяются в заголовке API. Это уменьшает сложность взаимосвязей между DLL и приложение и еще раз, делает DLL пригодным для использования С программами.

Все указатели данных используется в API — явные FAR указатели. Опять же, FAR, не является действительно необходимым для Win32, но является полезным, если вы планируете скомпилировать код для 16-разрядной версии Windows в будущем.

Технические примечания по номеру |nbsp; Технические примечания по категориям

Index