powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / MFC DLL для приложения, не использующего MFC
18 сообщений из 18, страница 1 из 1
MFC DLL для приложения, не использующего MFC
    #38911068
nop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день
Бьюсь над такой проблемой - создаю win32 DLL проект в VS 2013 с поддержкой MFC. Создаётся исходник:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
#include "stdafx.h"
#include "mfcdll.h"
#include "MWin.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#endif


// The one and only application object

CWinApp theApp;

using namespace std;

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
	int nRetCode = 0;

	HMODULE hModule = ::GetModuleHandle(NULL);

	if (hModule != NULL)
........



DllMain отсутствует. После компиляции и инжекта, конкретно данный код не выполняется (проверял, вставляя в него мессаджбоксы). Отсюда вопрос, почему не работает дефолтный проект? Видимо, из-за отсутствия поддержки MFC в том приложении, в который я инжекчу эту DLL. Как решить этот вопрос?

В опциях проекта выставил "Use MFC in a Static Library"
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911085
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторDllMain отсутствует.

Не должно.


авторПосле компиляции и инжекта, конкретно данный код не выполняется (проверял, вставляя в него мессаджбоксы). Отсюда вопрос, почему не работает дефолтный проект?


Не знаю. Давай код весь. Видимо, что-то не так делаешь.


авторВидимо, из-за отсутствия поддержки MFC в том приложении, в который я инжекчу эту DLL. Как решить этот вопрос?

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

авторВ опциях проекта выставил "Use MFC in a Static Library"

Так делать в общем нельзя.
Даже кажется вообще нельзя. Если ты испльзуешь MFC DLL , то MFC надо использовать в виде DLL, а не статически.

Причина простая -- если будет ещё одна DLL с использованием MFC, то у тебя будет две копии MFC в памяти, а это может не работать.

В общем, там всё так просто не объяснишь.
Нарисуй предполагаемую структуру выполняемых модулей твоего приложения, чтобы посмотреть, правильна ли архитектура.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911089
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nopБьюсь над такой проблемой - создаю win32 DLL проект в VS 2013 с поддержкой MFC. Создаётся исходник
...
DllMain отсутствует...конкретно данный код не выполняется...Как решить этот вопрос?

IMHO Создать DllMain

nopВидимо, из-за отсутствия поддержки MFC в том приложении, в который я инжекчу эту DLL.
В опциях проекта выставил "Use MFC in a Static Library"

IMHO & AFAIK нет

MFC не при чем. Ты все правильно выставил "Use MFC in a Static Library". MFC должен быть в твою DLL влинкован, соответственно от хозяйского процесса ничего не нужно.

Еще бы хорошо почитать хелпы по MFC, у меня воспоминания, что в DllMain нужно еще какие-то MFC-инициализирующие функции вызывать. Иначе может падать. (но не уверен)

p.s. давно не держал в руках MS VS, MFC и dll'ки. Могу местами ошибаться
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911096
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. В VS 2012 Prof Ru студии у меня на MFC DLL такой текст создался. DllMain тоже нет ))), но слов с буковками DLL полно.
2.
Leonid KudryavtsevЕще бы хорошо почитать хелпы по MFC, у меня воспоминания, что в DllMain нужно еще какие-то MFC-инициализирующие функции вызывать. Иначе может падать. (но не уверен)
Похоже я имел в виду AFX_MANAGE_STATE )))


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
// MFCLibrary1.cpp: определяет процедуры инициализации для DLL.
//

#include "stdafx.h"
#include "MFCLibrary1.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

//
//TODO: если эта библиотека DLL динамически связана с библиотеками DLL MFC,
//		все функции, экспортированные из данной DLL-библиотеки, которые выполняют вызовы к
//		MFC, должны содержать макрос AFX_MANAGE_STATE в
//		самое начало функции.
//
//		Например:
//
//		extern "C" BOOL PASCAL EXPORT ExportedFunction()
//		{
//			AFX_MANAGE_STATE(AfxGetStaticModuleState());
//			// тело нормальной функции
//		}
//
//		Важно, чтобы данный макрос был представлен в каждой
//		функции до вызова MFC. Это означает, что
//		он должен быть первым оператором 
//		функции и предшествовать даже любым объявлениям переменных объекта,
//		поскольку их конструкторы могут выполнять вызовы к MFC
//		DLL.
//
//		В Технических указаниях MFC 33 и 58 содержатся более
//		подробные сведения.
//

// CMFCLibrary1App

BEGIN_MESSAGE_MAP(CMFCLibrary1App, CWinApp)
END_MESSAGE_MAP()


// создание CMFCLibrary1App

CMFCLibrary1App::CMFCLibrary1App()
{
	// TODO: добавьте код создания,
	// Размещает весь важный код инициализации в InitInstance
}


// Единственный объект CMFCLibrary1App

CMFCLibrary1App theApp;


// инициализация CMFCLibrary1App

BOOL CMFCLibrary1App::InitInstance()
{
	CWinApp::InitInstance();

	return TRUE;
}


...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911101
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
приложил картинку, что выбирал при создании проекта
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911131
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivавторDllMain отсутствует.

Не должно.

Я так же думаю. Но VS действительно, несмотря на галочку DLL тупо делает main

Поискал по I-net, народ пишет http://www.ni.com/white-paper/3056/en/ Сгенерировали проект, теперь добавьте DllMain

MasterZivТак делать в общем нельзя.
Даже кажется вообще нельзя. Если ты испльзуешь MFC DLL , то MFC надо использовать в виде DLL, а не статически.

Причина простая -- если будет ещё одна DLL с использованием MFC, то у тебя будет две копии MFC в памяти, а это может не работать.
Можно и даже иногда нужно

Я так делал. DLL использующая MFC работающая из-под Oracle Forms который так же использует MFC но ДРУГОЙ версии.

Если MFC DLL динамически линковать, получается "падеж падежей" и понятное дело ничего не работает. А с учетом, что не только MFC но и менеджер памяти (new/delete) разный, периодически падало на совершенно непредсказуемых местах.

А статически каждый код работает со своей копией MFC. В общем, у меня работало и не падало.

AFAIK
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911150
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот пример проекта нужной конфигурации.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911152
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevЯ так делал. DLL использующая MFC работающая из-под Oracle Forms который так же использует MFC но ДРУГОЙ версии.
Если MFC DLL динамически линковать, получается "падеж падежей" и понятное дело ничего не работает. А с учетом, что не только MFC но и менеджер памяти (new/delete) разный, периодически падало на совершенно непредсказуемых местах.

А статически каждый код работает со своей копией MFC. В общем, у меня работало и не падало.


Да, иногда это работает, но это -- хождение по краю.
В принципе, это нарушение ODR и программа получается некорректной.
Но иногда такие программы могут работать.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911227
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivВ принципе, это нарушение ODR и программа получается некорректной.
Но иногда такие программы могут работать.

Что такое ODR и почему нарушение ?

Есть две копии run time (alloc,free,new,delete) + MFC разных версий:
1. Одна копия "процесса хозяина"
2. Вторая копия библиотеки, DLL'ки

В целом обычная и ЧАСТАЯ ситуация. Когда я пишу библиотеку, я не всегда имею доступ к ровно тем же версиям компилятора на которых собран "процесс хозяина".

Более того, раз это библиотека, она должна быть более-менее универсальной. Т.е. я не могу гарантировать, что "процесс хозяина" всегда будет на той же версии и даже требоваться этого от "заказчика" достаточно сложно. Хвост (библиотека) пытается вертеть собакой (приложением)

AFAIK все работает. Если внимательно читать, что мелким шрифтом написано в документации. И разумеется, передавая объекты туда-сюда-обратно, не пытаться их захапать и тем более удалять.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911233
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevЧто такое ODRone definition rule, я думаю
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911344
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что такое ODR и почему нарушение ?

One Definition Rule.

авторВ целом обычная и ЧАСТАЯ ситуация. Когда я пишу библиотеку, я не всегда имею доступ к ровно тем же версиям компилятора на которых собран "процесс хозяина".

Ты считал , чтобы говорить, что она частая ? Статистику дашь ?
Ещё раз, это НЕОБЫЧНАЯ и НЕЧАСТАЯ ситуация.
Это -- вообще потенциально неработоспособное приложение.
Которое иногда работает.
Несколько экземпляров CRT в приложении -- ровно та же самая ситуация.

авторБолее того, раз это библиотека, она должна быть более-менее универсальной. Т.е. я не могу гарантировать, что "процесс хозяина" всегда будет на той же версии и даже требоваться этого от "заказчика" достаточно сложно.

Я ничего не знаю про то, что там должна кому библиотека. А ODR -- требование стандарта языка С++.
Если ты что-то не можешь гарантировать -- ты не должен поставлять своё приложение, логично ?

авторAFAIK все работает. Если внимательно читать, что мелким шрифтом написано в документации. И разумеется, передавая объекты туда-сюда-обратно, не пытаться их захапать и тем более удалять.

А вдргут таки придётся передать объектик ? А ? Что тогда ?

Твоё мнение по этому поводу достаточно распространено, и на столько же оно безграмотно. Основная его ошибка -- из того, что иногда это работает делается вывод, что это всегда работает.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911444
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вдргут таки придётся передать объектик ? А ? Что тогда ?
Ничего. Никаких проблем. Если, конечно, компиляторы по одинаковому воспринимают таблицу виртуальных методов и выравнивание ))))

Обычно проблема когда передается право "владения" объектом. И принимающая объект сторона, пытается чужие объекты удалять.

Поэтому почти во всех API, например Java JNI, для "чужого" кода экспортируют ф-ции для ручного выделения/освобождения памяти(объектов) "как принято в хозяйском процессе".
MasterZivЕщё раз, это НЕОБЫЧНАЯ и НЕЧАСТАЯ ситуация.
Несколько экземпляров CRT в приложении -- ровно та же самая ситуация.

Библиотека для Java написанная на MS VS 2012 с использованием JNI. Сколько будет CRT и каких в рабочем пространстве Java Machine? На мой взгляд, КАК МИНИМУМ ДВЕ о которых я знаю. Та, которая требуется и работает вместе с JRE + моя пришедшая с .DLL (alloc/free) + возможно еще какие-то (с другими DLL'ками).

НИКТО не мешает мне выделить память в DLL стандартным new (через личное CRT), передать данную ссылку в Java и там ее использовать... НО освобождать эту память, я должен через те же методы, тот же CRT, которым и выделял, что IMHO и логично.

НИКТО не мешает мне написать кучу DLL'лек на MS VS, Intel Compiler, Watcom, Borland C, Delphi и так далее и выделять память через стандартный CRT моего языка. И радостно все это юзать в одной единственной JRE. Сколько у меня будет CRT в памяти процесса?
А ODR -- требование стандарта языка С++
А если приложение написано на C, а DLL на Pascal'е ?
А если там еще и Java и Cobol ?
Какими стандартами пользоваться и каким CRT ?
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911550
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevА вдргут таки придётся передать объектик ? А ? Что тогда ?
Ничего. Никаких проблем. Если, конечно, компиляторы по одинаковому воспринимают таблицу виртуальных методов и выравнивание ))))


А если объектик память выделяет ? А потом её освобождает ? А ?


Leonid KudryavtsevОбычно проблема когда передается право "владения" объектом. И принимающая объект сторона, пытается чужие объекты удалять.

Поэтому почти во всех API, например Java JNI, для "чужого" кода экспортируют ф-ции для ручного выделения/освобождения памяти(объектов) "как принято в хозяйском процессе".


ОК, покажи мне ссылки на документацию по таким функциям в MFC и/или MSVCCRT.

Leonid KudryavtsevMasterZivЕщё раз, это НЕОБЫЧНАЯ и НЕЧАСТАЯ ситуация.
Несколько экземпляров CRT в приложении -- ровно та же самая ситуация.

Библиотека для Java написанная на MS VS 2012 с использованием JNI. Сколько будет CRT и каких в рабочем пространстве Java Machine? На мой взгляд, КАК МИНИМУМ ДВЕ о которых я знаю. Та, которая требуется и работает вместе с JRE + моя пришедшая с .DLL (alloc/free) + возможно еще какие-то (с другими DLL'ками).

НИКТО не мешает мне выделить память в DLL стандартным new (через личное CRT), передать данную ссылку в Java и там ее использовать... НО освобождать эту память, я должен через те же методы, тот же CRT, которым и выделял, что IMHO и логично.

НИКТО не мешает мне написать кучу DLL'лек на MS VS, Intel Compiler, Watcom, Borland C, Delphi и так далее и выделять память через стандартный CRT моего языка. И радостно все это юзать в одной единственной JRE. Сколько у меня будет CRT в памяти процесса?
А ODR -- требование стандарта языка С++

А если приложение написано на C, а DLL на Pascal'е ?
А если там еще и Java и Cobol ?
Какими стандартами пользоваться и каким CRT ?

CRT для язака С, DLL на языке С -- значит, стандартом языка С.
Да и собственно, требование ODR вполне логично -- чтобы в программе была только одна переменная/функция с определённым именем.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911572
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivА если объектик память выделяет ? А потом её освобождает ?

Без проблем. Он же будет всегда "своей" копией CRT пользоваться. Главное, что бы он "чужие" объекты не пытался освобождать.

MasterZiv...чтобы в программе была только одна переменная/функция с определённым именем...."

только теперь осталось понять, что мы считаем "программой" в ситуации "процесс" + "внешняя DLL". Это одна программа или несколько ?

Ну и данное "сокращение определения" как бы не полно ))) никто не мешает иметь десяток разных переменных/функций с определённым именем в одной программе. Если они в разных программных модулях. Я вот например, люблю переменные для счетчика цикла называть "i". И у меня их в программе много ))) в разных местах.

При статик линковки каждый програмный модуль ( EXE, DLL ) будет пользоваться своей/локальной копией. Что в этом плохого и нарушает ODR?

IMHO Взаимодействие приложения и DLL, под стандарт языка C НИКАК не подпадает. Это нужно смотреть стандарты ОС.

MasterZivCRT для язака С, DLL на языке С -- значит, стандартом языка С.

А вызывающее DLL приложение на Java или Cobole.

Вот лично я, всегда, скорее смотрел требования _вызывающего_ приложения. Что можно в DLL, а чего нельзя. Что можно к DLL линковать, а что сглючит

Например из под Oracle Forms 6i можно использовать только _конкретные_ версии PRO*C. Иначе, будет конфликт с вызывающим приложением. Т.к. PRO*C допускает только динамическую линковку и две разных версии кода в процессе динамической линковки радостно сольются в экстазе в одну и нифига работать не будут.

( вот Вам нарушение Вашего любимого ODP как раз в противоположном случае. При _динамической_ линковке. Разное описание, разные версии .H файлов и одна глобальная реализация "первая попавшаяся" )

Если CRT или другую либу слинковать статически - никаких проблем нет Хоть он будет той же версии, хоть другой, хоть от совершенно другого языка. Ну есть два разных объявления ф-ции alloc/free в разных программных модулях (DLL). Ну и пофиг. Есть и их разная _корректная_ имплиментация в каждом модули (DLL). Статически слинкованная. Никак на остальные модули не влияющая. Полностью локальная в пределах данного программного модуля (DLL). В чем тут нарушение ODP?
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911585
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ни в чём - мастера на виражах заносит.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38911793
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovНи в чём - мастера на виражах заносит.

Никого никуда не заносит.

Ребята, я просто хочу прояснить свою позицию.

Я великолепно понимаю , что то, как описывает всё Leonid Kudryavtsev замечательно может работать иногда,
сам так не раз делал (вы даже не представляете, как много раз).

Но Leonid Kudryavtsev и многие другие программисты на этом и других форумах имеют ложное представление,
что именно так и надо всегда делать , что такая архитектура приложений -- "обычная и ЧАСТАЯ ситуация" .

Нет, это не так, такая архитектура приложения -- ненормальное явление , она ведёт к большим проблемам.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38912015
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мелкомягким об этом скажи, а то они, чурбаки отсталые, не пересобирают винду по мере выхода новых студий.
У динамически компонуемых библиотек есть экспорты, импорты и соглашения по использованию.
Да, любая техника позволяет создавать несовместимые реализации, но потенциальная неоднозначность - не ошибка.
...
Рейтинг: 0 / 0
MFC DLL для приложения, не использующего MFC
    #38912214
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivBasil A. SidorovНи в чём - мастера на виражах заносит.

Никого никуда не заносит.

Ребята, я просто хочу прояснить свою позицию.

Я великолепно понимаю , что то, как описывает всё Leonid Kudryavtsev замечательно может работать иногда,
сам так не раз делал (вы даже не представляете, как много раз).

Но Leonid Kudryavtsev и многие другие программисты на этом и других форумах имеют ложное представление,
что именно так и надо всегда делать , что такая архитектура приложений -- "обычная и ЧАСТАЯ ситуация" .

Нет, это не так, такая архитектура приложения -- ненормальное явление , она ведёт к большим проблемам.эээээ.... Не правильно ты делаешь обобщение. Или невнимательно читаешь что пишет Леонид...
То как он описывает будет работать всегда. Не иногда, а всегда. И это можно даже доказать.
Помнишь еще институтские лекции? Вложение тьюринговых машин друг в друга? Вот то что описывает Леонид это оно самое и есть. Если у нас есть DLL внутри которой происходит все-все необходимое для жизни, то ее можно безболезненно загрузить в приложение в котором есть аналогичные процедуры.
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / C++ [игнор отключен] [закрыт для гостей] / MFC DLL для приложения, не использующего MFC
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]