Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Добрый день Бьюсь над такой проблемой - создаю 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. DllMain отсутствует. После компиляции и инжекта, конкретно данный код не выполняется (проверял, вставляя в него мессаджбоксы). Отсюда вопрос, почему не работает дефолтный проект? Видимо, из-за отсутствия поддержки MFC в том приложении, в который я инжекчу эту DLL. Как решить этот вопрос? В опциях проекта выставил "Use MFC in a Static Library" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 13:33 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
авторDllMain отсутствует. Не должно. авторПосле компиляции и инжекта, конкретно данный код не выполняется (проверял, вставляя в него мессаджбоксы). Отсюда вопрос, почему не работает дефолтный проект? Не знаю. Давай код весь. Видимо, что-то не так делаешь. авторВидимо, из-за отсутствия поддержки MFC в том приложении, в который я инжекчу эту DLL. Как решить этот вопрос? Нет, не изза этого. Одна из штатных конфигураций проекта с испльзованием MFC -- это библиотека, использующая MFC, и расчитанная на работу в не-MFC приложении. Но проблемы могут быть. авторВ опциях проекта выставил "Use MFC in a Static Library" Так делать в общем нельзя. Даже кажется вообще нельзя. Если ты испльзуешь MFC DLL , то MFC надо использовать в виде DLL, а не статически. Причина простая -- если будет ещё одна DLL с использованием MFC, то у тебя будет две копии MFC в памяти, а это может не работать. В общем, там всё так просто не объяснишь. Нарисуй предполагаемую структуру выполняемых модулей твоего приложения, чтобы посмотреть, правильна ли архитектура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 13:46 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
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'ки. Могу местами ошибаться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 13:48 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 13:54 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
приложил картинку, что выбирал при создании проекта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 13:56 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 14:22 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Вот пример проекта нужной конфигурации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 14:35 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЯ так делал. DLL использующая MFC работающая из-под Oracle Forms который так же использует MFC но ДРУГОЙ версии. Если MFC DLL динамически линковать, получается "падеж падежей" и понятное дело ничего не работает. А с учетом, что не только MFC но и менеджер памяти (new/delete) разный, периодически падало на совершенно непредсказуемых местах. А статически каждый код работает со своей копией MFC. В общем, у меня работало и не падало. Да, иногда это работает, но это -- хождение по краю. В принципе, это нарушение ODR и программа получается некорректной. Но иногда такие программы могут работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 14:37 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
MasterZivВ принципе, это нарушение ODR и программа получается некорректной. Но иногда такие программы могут работать. Что такое ODR и почему нарушение ? Есть две копии run time (alloc,free,new,delete) + MFC разных версий: 1. Одна копия "процесса хозяина" 2. Вторая копия библиотеки, DLL'ки В целом обычная и ЧАСТАЯ ситуация. Когда я пишу библиотеку, я не всегда имею доступ к ровно тем же версиям компилятора на которых собран "процесс хозяина". Более того, раз это библиотека, она должна быть более-менее универсальной. Т.е. я не могу гарантировать, что "процесс хозяина" всегда будет на той же версии и даже требоваться этого от "заказчика" достаточно сложно. Хвост (библиотека) пытается вертеть собакой (приложением) AFAIK все работает. Если внимательно читать, что мелким шрифтом написано в документации. И разумеется, передавая объекты туда-сюда-обратно, не пытаться их захапать и тем более удалять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 15:29 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЧто такое ODRone definition rule, я думаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 15:32 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Что такое ODR и почему нарушение ? One Definition Rule. авторВ целом обычная и ЧАСТАЯ ситуация. Когда я пишу библиотеку, я не всегда имею доступ к ровно тем же версиям компилятора на которых собран "процесс хозяина". Ты считал , чтобы говорить, что она частая ? Статистику дашь ? Ещё раз, это НЕОБЫЧНАЯ и НЕЧАСТАЯ ситуация. Это -- вообще потенциально неработоспособное приложение. Которое иногда работает. Несколько экземпляров CRT в приложении -- ровно та же самая ситуация. авторБолее того, раз это библиотека, она должна быть более-менее универсальной. Т.е. я не могу гарантировать, что "процесс хозяина" всегда будет на той же версии и даже требоваться этого от "заказчика" достаточно сложно. Я ничего не знаю про то, что там должна кому библиотека. А ODR -- требование стандарта языка С++. Если ты что-то не можешь гарантировать -- ты не должен поставлять своё приложение, логично ? авторAFAIK все работает. Если внимательно читать, что мелким шрифтом написано в документации. И разумеется, передавая объекты туда-сюда-обратно, не пытаться их захапать и тем более удалять. А вдргут таки придётся передать объектик ? А ? Что тогда ? Твоё мнение по этому поводу достаточно распространено, и на столько же оно безграмотно. Основная его ошибка -- из того, что иногда это работает делается вывод, что это всегда работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 16:45 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
А вдргут таки придётся передать объектик ? А ? Что тогда ? Ничего. Никаких проблем. Если, конечно, компиляторы по одинаковому воспринимают таблицу виртуальных методов и выравнивание )))) Обычно проблема когда передается право "владения" объектом. И принимающая объект сторона, пытается чужие объекты удалять. Поэтому почти во всех 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 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 17:49 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
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 вполне логично -- чтобы в программе была только одна переменная/функция с определённым именем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 19:48 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
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? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 20:22 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Ни в чём - мастера на виражах заносит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 20:38 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovНи в чём - мастера на виражах заносит. Никого никуда не заносит. Ребята, я просто хочу прояснить свою позицию. Я великолепно понимаю , что то, как описывает всё Leonid Kudryavtsev замечательно может работать иногда, сам так не раз делал (вы даже не представляете, как много раз). Но Leonid Kudryavtsev и многие другие программисты на этом и других форумах имеют ложное представление, что именно так и надо всегда делать , что такая архитектура приложений -- "обычная и ЧАСТАЯ ситуация" . Нет, это не так, такая архитектура приложения -- ненормальное явление , она ведёт к большим проблемам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2015, 10:17 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
Мелкомягким об этом скажи, а то они, чурбаки отсталые, не пересобирают винду по мере выхода новых студий. У динамически компонуемых библиотек есть экспорты, импорты и соглашения по использованию. Да, любая техника позволяет создавать несовместимые реализации, но потенциальная неоднозначность - не ошибка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2015, 17:38 |
|
||
|
MFC DLL для приложения, не использующего MFC
|
|||
|---|---|---|---|
|
#18+
MasterZivBasil A. SidorovНи в чём - мастера на виражах заносит. Никого никуда не заносит. Ребята, я просто хочу прояснить свою позицию. Я великолепно понимаю , что то, как описывает всё Leonid Kudryavtsev замечательно может работать иногда, сам так не раз делал (вы даже не представляете, как много раз). Но Leonid Kudryavtsev и многие другие программисты на этом и других форумах имеют ложное представление, что именно так и надо всегда делать , что такая архитектура приложений -- "обычная и ЧАСТАЯ ситуация" . Нет, это не так, такая архитектура приложения -- ненормальное явление , она ведёт к большим проблемам.эээээ.... Не правильно ты делаешь обобщение. Или невнимательно читаешь что пишет Леонид... То как он описывает будет работать всегда. Не иногда, а всегда. И это можно даже доказать. Помнишь еще институтские лекции? Вложение тьюринговых машин друг в друга? Вот то что описывает Леонид это оно самое и есть. Если у нас есть DLL внутри которой происходит все-все необходимое для жизни, то ее можно безболезненно загрузить в приложение в котором есть аналогичные процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2015, 05:31 |
|
||
|
|

start [/forum/topic.php?fid=57&fpage=49&tid=2019054]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
1ms |
| others: | 11ms |
| total: | 162ms |

| 0 / 0 |
