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'ки. Могу местами ошибаться

1. В VS 2012 Prof Ru студии у меня на MFC DLL такой текст создался. DllMain тоже нет ))), но слов с буковками DLL полно.
2.
Leonid KudryavtsevЕще бы хорошо почитать хелпы по MFC, у меня воспоминания, что в DllMain нужно еще какие-то MFC-инициализирующие функции вызывать. Иначе может падать. (но не уверен)
Похоже я имел в виду AFX_MANAGE_STATE )))

приложил картинку, что выбирал при создании проекта

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

MasterZivВ принципе, это нарушение ODR и программа получается некорректной.
Но иногда такие программы могут работать.

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

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

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

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

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

А вдргут таки придётся передать объектик ? А ? Что тогда ?
Ничего. Никаких проблем. Если, конечно, компиляторы по одинаковому воспринимают таблицу виртуальных методов и выравнивание ))))

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

Поэтому почти во всех 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 ?

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?