Передача данных EXE в одну или несколько DLL - PullRequest
1 голос
/ 17 сентября 2008

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

В попытке облегчить работу нашего EXE-файла и поддержать наши попытки управления конфигурацией, мы решили разделить страницы на одну DLL, которую будет загружать EXE-файл. Мы хотим, чтобы EXE был оболочкой, в которую будут загружаться страницы из DLL. EXE все равно будет нести все обязанности по связи (UDP, Corba, User и т. Д.). Страницы будут по-прежнему отвечать за отображение того, что они делают.

Вопрос (наконец-то) звучит так: как передать это множество данных, собранных из EXE-файла, на страницы, основанные на использовании DLL. Концепция Синглтона больше не держит воду, так как используемые нами синглтоны (ACE_Singleton) не позволяют этот уровень направления. Мы можем экспортировать синглтоны из DLL в потребляющий EXE-файл весь день, но мне еще предстоит выяснить обратное. Я предложил следующие варианты - ни один из них мне не нравится, поэтому я надеялся, что кто-то найдет лучший вариант:)

  1. Сверните все данные, которые в настоящее время хранятся в отдельных синглетах, в другую DLL, которая экспортирует «истинный» синглтон. Например. Синглтон, экспортируемый из DLL, будет одинаковым - независимо от того, какой EXE-файл его загрузил - вроде как разделяемая память. Это интригующий выбор, но он может вызвать проблемы со сценариями развертывания. Я мог бы подробно рассказать об этих проблемах, если бы люди действительно были поражены этой идеей.
  2. Создание статической структуры уровня DLL, которая содержит все соответствующие данные. EXE будет загружать эти данные в DLL при загрузке DLL, чтобы страницы, содержащиеся в DLL, имели доступ к данным. Это кажется самым простым решением - даже если оно влечет за собой редактирование каждой страницы в нашем приложении - более 100. Это также кажется немного неаккуратным. Все данные только в глобальном. Не очень сексуально или C ++ y либо.

Так, у кого-нибудь еще есть решение этой проблемы?

Приложение написано с использованием Visual C ++ 9.0 (VisualStudio 2008) для использования в Windows XP. По какой-то причине Vista еще не поддерживается в нашей лаборатории, хотя наши клиенты используют ее.

Ответы [ 5 ]

1 голос
/ 01 октября 2008

Дайте всем DLL функцию SetGlobalDataPointer (Singleton *). Ваш EXE вызывает эту функцию, прежде чем вызывает любую другую функцию DLL. В коде DLL замените все вхождения единственного числа. от theSingletonPtr ->

0 голосов
/ 13 января 2009

Первый вариант: поместите все данные, которые исполняемый файл хранит в общей памяти. Затем dll-ы могут с легкостью получить к нему доступ, если у вас есть правильная блокировка на месте.

Второй вариант: передать память в dll, используя указатель экспортируемой функции - у exe есть функция, dll вызывает другую функцию в exe, которая возвращает эту функцию в качестве указателя, которую затем может вызвать dll. Эта экспортируемая функция может передавать данные в стеке как обычную структуру.

Третий вариант: если вы используете ту же среду выполнения, просто экспортируйте указатель, который дает вам прямой доступ к памяти.

0 голосов
/ 17 сентября 2008

К сожалению, похоже, у вас есть много существующего кода, с которым нужно повозиться. В этом случае я бы просто использовал (2), предполагая, что он не становится слишком большим и громоздким.

Судя по вашему описанию, данные на уровне EXE необходимо отправлять только один раз при загрузке DLL.

Если (2) слишком грязно, я бы немного изменил рефакторинг, чтобы иметь базовый класс "DLLPage" с функциями Serialize / UnSerialize (). Никогда не экспортируйте сам класс, только отдельные функции, которые вам нужны (это очень помогает при изменении класса ... очень странные разрывы случаются при экспорте на уровне класса). Вам понадобится конструктор / деструкторы и, возможно, каждый открытый член.

Могут быть некоторые проблемы с управлением кучей, поэтому мне также нравится перегружать new / delete, и все классы используют централизованное new / delete, расположенное во вспомогательной DLL.

0 голосов
/ 17 сентября 2008

Прежде чем вы решите сломать EXE-файл, вы должны прочитать об управлении памятью и DLL.

Вот одна статья, в которой говорится о проблемах объектов CRT, но то же самое относится и к вашим собственным объектам C ++.

Потенциальные ошибки при прохождении объектов CRT через границы DLL

0 голосов
/ 17 сентября 2008

Вы можете либо:

  • поместить все элементы самой внешней оболочки в «обычную» DLL;
  • используйте файл DEF для генерации функций экспорта из вашего EXE.

Второй вариант очень необычен, но можно создать библиотеку импорта только из файла DEF. Используйте LIB / DEF для создания библиотеки импорта. См. Работа с библиотеками импорта и экспорта файлов .

...