Dll как SDK

[Hooter]

что человек который купит такую программу сможет написать DLL как ему хочется только с набором нужных функций и подключить ее
а) в рантайм.
б) без изменения кода программы.
в) сможет получить максимально удобную и простую функциональность для себя.

Что именно будет содержаться в библиотеке, которую напишет пользователь программы? Или что предполагается там содержать? Функции тестов устройств? Или функции для решения каких-то реальных задач? Это разные вещи.

Пока все находится только в моей голове и проблема с библиотеками возникает именно из-за того, что
а) SDK должны подключаться и в программе и в тестовых билиотеках и иметь общий экземпляр.
б) Я должен уметь правильно все конигурировать из программы для каждого теста - и т.д. и т.п

Ну, во-первых, если программа использует и SDK и библиотеки пользователя, то все это происходит в одном процессе и общий экземпляр им должен быть обеспечен.
А во-вторых, такой вопрос: что чем используется? Библиотека пользователя использует SDK или SDK будет использовать библиотеку пользователя?
В-третьих, как я понял основная программа должна обеспечивать эту самую связь? Так?

[Гром]

1. содержимое DLL определяется пользователем.
ИМХО - там должны быть тесты, но тестирование может подразумевать наличие трафика в случае тестирование девайса для сети, и содержать некую задачу, которая и будет формировать какие-то ответы, которые обеспечат проверку на ликвидность устройства.

2. Программа пользуется SDK ппользовательские тесты тоже пользуются SDK - это прослойка между нами и интерфейсом устройства.
Я об этом выше писал не раз ....

3. Основная программа обеспечивает визуальную часть и рантайм-запуск всех тестов с установкой пропертис интерфейсво и т.д. и т.д.

[Hooter]

Давай, для простоты примера ограничимся следующим:
1. Основная программа обеспечивает визуальную часть, рантайм загрузку DLL пользователя и рантайм-запуск всех тестов.
2. Инициализация тестов и тестовых случаев проходит в DLL пользователя по инициативе основной программы.
3. Основная программа выводит на экран результаты выполнения функций DLL пользователя.

Пример решения, которое я предлагаю:

1. Рантайм загрузка DLL - никаких сложностей не представляет (это уже обсуждали).

2. Инициализация тестов и тестовых данных - экспортируем из dll пользователя функцию bool init(), которая инициализирует тестовые данные всех тестов в dll пользователя.

3. Запуск всех тестов из dll пользователя основной программой - посмотрим, что для этого нужно... Основной программе нужно знать сколько экспортируется функций из dll пользователя, а также имена этих функций. Пусть dll нам сама об этом скажет - она (или ее разработчик) лучше знает.
Для этого необходимо экспортировать из DLL одну функцию, которая будет возвращать список символьных имен функций тестов. Назовем ее - enumTestFunctions.

4. Возвращение результатов - ограничимся текстовым выводом. Пусть dll делает у себя внутри, что пожелает, а нам пусть предоставит отчет в текстовом виде (const char * или string). Функция в dll, которая это делает, пусть называется getResult.

Итак, что у нас получилось:
1. LoadLibrary (dll пользователя)
2. init = GetProcAddress ("init")
3. init ()
4. enumerateTestFunctions = GetProcAddress ("enumerateTestFunctions")
5. list functions = enumerateTestFunctions ()
6. for each in functions :
6.1. func = GetProcAddress (functions)
6.2. func ()    // <== это запуск очередного теста
7. getResult = GetProcAddress ("getResult")
8. string result = getResult ()
9. show result

Ограничения в этом примере:
1. у функций запуска тестов должна быть одинаковая семантика.
2. минимальный интерфейс библиотеки:
- init
- enumerateTestFunctions
- getResult

Ну как?

Использование SDK библиотек в dll пользователя тоже никакой сложности не представляет.... Так?

[Гром]

Мля Я тебе сказад, что не знаю, только одну вещь, которая описана в первом постинге...

А вот насчет разработки программного обеспечения я пока не берусь это выносить для всех...

Так что спасибо - но пока я до конца все не продумаю - никак.....

[Гром]

typedef int  (__stdcall *TSetQuery)(void);
.....................
TSetQuery sq1=GetProcAddress(lib1,"SetQuery");
int ins1=sq1();


sq1 = 0000000

Не работает....

[Finch]

Тут могут быть несколько ошибок:
1. По каким то причинам библиотека не была найдена. Скорее всего библиотека не была скопирована в каталог запуска EXE файла проекта.
2. Имя функции не было указано коректно. Если в проект не был подключен Def файл, то имя функции в библиотеке будет иметь вид примерно _SetQuery@0

Если что, могу скинуть свои готовые файлы проекта.

[Hooter]

Мля

Ясно Я просто хотел помочь. Извини, ежели чего не так

[Гром]

Hooter очень зря обиделся - это просто для другой темы.

Тут могут быть несколько ошибок:
1. По каким то причинам библиотека не была найдена. Скорее всего библиотека не была скопирована в каталог запуска EXE файла проекта.
2. Имя функции не было указано коректно. Если в проект не был подключен Def файл, то имя функции в библиотеке будет иметь вид примерно _SetQuery@0

Если что, могу скинуть свои готовые файлы проекта.

Меня терзают смутные сомнения....
А с какого момента люди забывают вопрос и начинают обсуждать отвлеченные темы....

1. Причина вообще бредовая, если бы библиотека не была найдена, то ошибка была бы раньше и я не писал бы о невозможности подгрузить функцию, а искал бы причины отсутствия библиотеки - верно?
2. Сколько раз надо писать, что В ПРОЕКТ НЕ БУДУТ ЯВНО ПОДКЛЮЧАТЬСЯ НИКАКИЕ ФАЙЛЫ, потому, что БИБЛИОТЕКА МОЖЕТ И БУДЕТ ПИСАТЬСЯ МНОГО ПОЗДЖЕ ПОДГРУЖАЮЩЕЙ ПРОГРАММЫ ДРУГИМ ЧЕЛОВЕКОМ и ИМЕЯ ТОЛЬКО ФАЙЛ DLL  НАДО УМЕТЬ ПОДГРУЗИТЬ ПРЕДОПРЕДЕЛЕННЫЕ ФУНКЦИИ О КОТОРЫХ В MSDN НАПИСАНО, что __declspec НЕ ДАЕТ В С++ ПОДГРУЖАТЬ ИМЕНА ФУНКЦИЙ....


Мне очень хочется этого добиться - НО НИЧЕГО КРОМЕ ОДНОГО ФАЙЛА В РАНТАЙМ НЕТ. НЕТ ДЕФ ФАЙЛОВ НЕТ НИЧЕГО!!! И ПЕРЕКОМПИЛИРОВАТЬ НЕЛЬЗЯ ....


Все условия выделенные крупным шрифтом многократно описаны в этой теме. Выделение сделано мной.

[Гром]

Убедившись в забывчивости многих по поводу проблемы повторю условия задачи....

1. Есть программа.
2. Есть билиотека.

1 подгружает 2 в процессе работы имея в наличии только файл dll без описательных експортных и т.д. файлов.
Подгрузка должна осуществляться джинамически, без ссылок на возможности компиляции...

Структутра нужных функций и их имена известны

Init
Open
Close
Read
Write
IoCtrl

Положения:

Задача решаема и решена уже в случае:
- dll написана на языке С.
- все вышеуказанные функции находятся под extern C
вся остальная библиотека на С++.

Однако данные решения ограничивают создателя билиотеки технически устаревшими рамками. Это не всегда удобно и добавляет головной боли.

Необходимо найти решение для случая когда ВСЯ библиотека написана на С++ и подключается при вышеуказанных условиях.

[Hooter]

Тут могут быть несколько ошибок:
1. По каким то причинам библиотека не была найдена. Скорее всего библиотека не была скопирована в каталог запуска EXE файла проекта.
2. Имя функции не было указано коректно. Если в проект не был подключен Def файл, то имя функции в библиотеке будет иметь вид примерно _SetQuery@0

Если что, могу скинуть свои готовые файлы проекта.

Меня терзают смутные сомнения....
А с какого момента люди забывают вопрос и начинают обсуждать отвлеченные темы....

1. Причина вообще бредовая, если бы библиотека не была найдена, то ошибка была бы раньше и я не писал бы о невозможности подгрузить функцию, а искал бы причины отсутствия библиотеки - верно?
2. Сколько раз надо писать, что В ПРОЕКТ НЕ БУДУТ ЯВНО ПОДКЛЮЧАТЬСЯ НИКАКИЕ ФАЙЛЫ, потому, что БИБЛИОТЕКА МОЖЕТ И БУДЕТ ПИСАТЬСЯ МНОГО ПОЗДЖЕ ПОДГРУЖАЮЩЕЙ ПРОГРАММЫ ДРУГИМ ЧЕЛОВЕКОМ и ИМЕЯ ТОЛЬКО ФАЙЛ DLL  НАДО УМЕТЬ ПОДГРУЗИТЬ ПРЕДОПРЕДЕЛЕННЫЕ ФУНКЦИИ О КОТОРЫХ В MSDN НАПИСАНО, что __declspec НЕ ДАЕТ В С++ ПОДГРУЖАТЬ ИМЕНА ФУНКЦИЙ....

[/b]
Гром, для использования функции GetProcAddress не нужно подключать DEF файл к приложению, в котором ты хочешь использовать DLL.

DEF файл нужно подключить к тому проекту, в котором ты (или пользователь твоей системы) создаешь библиотеку. Просто необходимо, чтобы нужная тебе функция была прописана в таблице импорта библиотеки.

Теперь, если у тебя есть DLL, с корректной таблицей импорта, то для ее использования в твоем приложении тебе нужно иметь только DLL файл. И вызвать LoadModule - GetProcAddres...

Вот цитата из msdn по этому поводу:

"You can only obtain the export ordinal if the DLL you are linking to was built with a module definition (.DEF) file, and if the ordinals are listed with the functions in the EXPORTS section of the DLL's .DEF file."


Теперь о __declspec.

Использовние этой директивы не позволяет подгружать библиотеки динамически, тем более не зная заранее ее содержимого. ДЛя подключения таких библиотек необходимо иметь lib- и h-файлы.
Пусть меня поправят, если в чем-то ошибся.

Убедившись в забывчивости многих по поводу проблемы повторю условия задачи....

1. Есть программа.
2. Есть билиотека.

1 подгружает 2 в процессе работы имея в наличии только файл dll без описательных експортных и т.д. файлов.
Подгрузка должна осуществляться джинамически, без ссылок на возможности компиляции...

Структутра нужных функций и их имена известны

Init
Open
Close
Read
Write
IoCtrl

Положения:

Задача решаема и решена уже в случае:
- dll написана на языке С.
- все вышеуказанные функции находятся под extern C
вся остальная библиотека на С++.

Гром, может ты сразу напишешь, что и каким образом уже сделано, чтобы никто не задавал повторяющихся вопросов?..
А то с каждым твоим ответом выясняется все больше и больше...

Что это за функции, например? Названия похожи на функции библиотеки драйвера устройства...
Эти функции предполагается экспортировать из библиотеки пользователя или это какие-то внутренние функции используемые приложением?

Ты так и не ответил на вопрос: какое место занимает SDK во взаимодействии модулей?
Мне видится следующее: SDK само по себе знает только об устройствах и интерфейсах с ними; библиотека пользователя использует SDK; приложение использует библиотеку пользователя и, может быть, SDK. Так? Или по-другому? Напиши как..

[Гром]

  не верю - что все что я написал вызывает след. вопросы...

Гром, для использования функции GetProcAddress не нужно подключать DEF файл к приложению, в котором ты хочешь использовать DLL.

Финч предлагал сделать именно с деф файлом. Я так и сказал, где ты увидел, что я это пишу?

Теперь, если у тебя есть DLL, с корректной таблицей импорта, то для ее использования в твоем приложении тебе нужно иметь только DLL файл. И вызвать LoadModule - GetProcAddres...

Опять вернемся к вопросу о том, что ТАКИМ ОБРАЩОМ ТЫ НЕ СМОЖЕШЬ ПОДКЛЮЧИТЬ ФУНКЦИИ ОПИСАННЫЕ И СОБРАННЫЕ В С++ стандарте. Перечитай задание еще раз.

Использовние этой директивы не позволяет подгружать библиотеки динамически, тем более не зная заранее ее содержимого. ДЛя подключения таких библиотек необходимо иметь lib- и h-файлы.
Пусть меня поправят, если в чем-то ошибся.

Где я это писал??? Этот макрос нужен для указания билиотеке что она эту функцию экспортирует... Причем тут загрузка?

По деф-файлу...

Я понимаю, что он необходим билиотеке, но насколько я понимаю, это информационный файл создаваемый ДЛЯ МЕНЯ, как для подгружающего члена - устаревший способ подгрузить билиотеку. Вытащить имена.
А динамическое подключение - это когда у меня есть только ДЛЛ файл и я на ДРУГОЙ машине где НЕТ ДЕФ-файла подключаю ДЛЛ в программу - какая связь со всем вышесказанным???

Гром, может ты сразу напишешь, что и каким образом уже сделано, чтобы никто не задавал повторяющихся вопросов?..
А то с каждым твоим ответом выясняется все больше и больше...

Выше написанная тобой цитата содержит все что сделано. То что все делается через динамическую подгрузку в теме написано 50 раз - вопрос совершенно бессмысленен при нормальном чтении темы.

Что это за функции, например? Названия похожи на функции библиотеки драйвера устройства...
Эти функции предполагается экспортировать из библиотеки пользователя или это какие-то внутренние функции используемые приложением?

Ты когда тебе дают на работе написать интерфейс, то же интересуешься кому чего надо и пока не пояснят - не работаешь...

Я не буду ничего пояснять - задача сформулирована, ответ желательно найти, только те кто хочет - пишет, кто просто так ради вопросов - лучше не надо.

[npak]

Разработчик библиотеки "2" отдаёт разработчику приложения 1 три артефакта:
  заголовочный файл
  библиотеку импортов (.lib)
  реализацию функций в DLL

Пара "заголовки" + "загрузочные библиотеки (.lib)" и есть SDK в его обычном понимании, необходимы для компиляции приложения 1.  DLL представляет собой Runtime и нужна для запуска приложения и отладки

Заголовочные файлы необходимы для того, чтобы разработчик приложения 1 знал, какие функции предоставляет библиотека 2, какие параметры принимают функции и что возвращают.  DLL предоставляет реализацию функций.  Библиотека импортов освобождает разработчика приложения 1 от мудоханья с LoadLibrary и GetProcAddress.  При запуске приложения в ходе инициализации код, содержащийся в библиотеке импортов, загрузит нужную DLL или выдаст сообщение, что DLL не найдена и приложение завершится -- стандартная обёртка для LoadLibrary.

В коде приложения 1 стоит просто вызов функции Init.  Этот вызов реализован в библиотеке импортов и сделает следующее: возьмёт указатель соответствующей функции из DLL и вызовет её.  При этом для разработчика приложения 1 не важно, на каком языке написан код и какие на самом деле имена функций в DLL -- эта информация зашита в библиотеку импортов при компиляции.

Теперь как разработчик библиотеки 2 сделает искомые артефакты.  Понятно, что заголовочный файл он напишет ручками, DLL получится компиляцией исходников библиотеки.  Единственный немного нетривиальный шаг -- откуда возьмётся библиотека импортов.  Для того, чтобы её получить, надо сообщить компилятору, какие функции библиотеки предназначены для внешнего использования.  Это можно сделать двумя способами.  Способ первый -- написать .def файл и перечислить в нём те функции, которые библиотека экспортирует, и включить этот файл в проект библиотеки.  Подчёркиваю, библиотеки, а не приложения.  Приложению он нафиг не нужен, у приложения есть библиотека импортов.  При компиляции библиотеки вижуал студия найдёт .def файл и сгенерирует по нему библиотеку загрузки.  Способ второй, пометить в исходниках библиотеки экспортируемые функции при помощи декларатора  __declspec( dllexopt ).  Компилятор автоматически включит код для вызова экспортируемых функций в библиотеку импортов.

Вот, собственно, и вся схема.  Ей пользуется немеряно народу по всему миру.

[Hooter]

Гром, я тебя сразу попрошу дочитать до конца и только потом отвечать.

Теперь, если у тебя есть DLL, с корректной таблицей импорта, то для ее использования в твоем приложении тебе нужно иметь только DLL файл. И вызвать LoadModule - GetProcAddres...

Опять вернемся к вопросу о том, что ТАКИМ ОБРАЩОМ ТЫ НЕ СМОЖЕШЬ ПОДКЛЮЧИТЬ ФУНКЦИИ ОПИСАННЫЕ И СОБРАННЫЕ В С++ стандарте. Перечитай задание еще раз.

Я и не говорил, что сможешь. Я и Finch попытались тебе объяснить, почему у тебя возникла ошибка при вызове GetProcAddress.

Использовние этой директивы не позволяет подгружать библиотеки динамически, тем более не зная заранее ее содержимого. ДЛя подключения таких библиотек необходимо иметь lib- и h-файлы.
Пусть меня поправят, если в чем-то ошибся.

Где я это писал??? Этот макрос нужен для указания билиотеке что она эту функцию экспортирует... Причем тут загрузка?

При том, что ты хочешь подгружать библиотеки динамически. Так? Но подгрузить библиотеку динамически, которая экспортирует код через __declspec, нельзя. И тем более нельзя подключить код С++.

По деф-файлу...
Я понимаю, что он необходим билиотеке, но насколько я понимаю, это информационный файл создаваемый ДЛЯ МЕНЯ, как для подгружающего члена - устаревший способ подгрузить билиотеку. Вытащить имена.
А динамическое подключение - это когда у меня есть только ДЛЛ файл и я на ДРУГОЙ машине где НЕТ ДЕФ-файла подключаю ДЛЛ в программу - какая связь со всем вышесказанным???

Давай еще раз попробую объяснить.
Для тебя, как для подгружающего члена не нужен DEF  файл. На какой машине бы ты не был. На другой или на своей. Для динамической загрузки достаточно только DLL.
Я уже писал об этом.

Гром, может ты сразу напишешь, что и каким образом уже сделано, чтобы никто не задавал повторяющихся вопросов?..
А то с каждым твоим ответом выясняется все больше и больше...

Выше написанная тобой цитата содержит все что сделано. То что все делается через динамическую подгрузку в теме написано 50 раз - вопрос совершенно бессмысленен при нормальном чтении темы.

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

Вот это, например, всплыло только сегодня:

Задача решаема и решена уже в случае:
- dll написана на языке С.
- все вышеуказанные функции находятся под extern C
вся остальная библиотека на С++.

Ты когда тебе дают на работе написать интерфейс, то же интересуешься кому чего надо и пока не пояснят - не работаешь...
Я не буду ничего пояснять - задача сформулирована, ответ желательно найти, только те кто хочет - пишет, кто просто так ради вопросов - лучше не надо.

Даже как-то странно слышать. Как можно решить задачу правильно, не зная всех ограничений. Или ты хочешь получить множество всех возможных решений во вселенной, а из них уже выбрать?
Проще описать ограничения, чем все возможные решения
Только не надо здесь писать, что уже описал все ограничения.
Мне просто показалось, что наличие функций Init, Write, Ioctl, ... может повлиять на конечное решение.

А вот на этот вопрос ты вообще толком ни разу не ответил. В основном какими-то обрывками фраз.

Ты так и не ответил на вопрос: какое место занимает SDK во взаимодействии модулей?
Мне видится следующее: SDK само по себе знает только об устройствах и интерфейсах с ними; библиотека пользователя использует SDK; приложение использует библиотеку пользователя и, может быть, SDK. Так? Или по-другому? Напиши как..

[Гром]

отвечать не буду...
По h & lib файлам сказано столько что умереть можно...
Программист пишущий библиотеку НИЧЕГО ЕН МОЖЕТ ПРЕДОСТАВИТЬ АВТОРУ ПРОГРАММЫ, потому что он эту программу купил в бинарнике , а бинарнику нах не нужны вышеупомянутые файлы.

[Hooter]

Разработчик библиотеки "2" отдаёт разработчику приложения 1 три артефакта:
 заголовочный файл
 библиотеку импортов (.lib)
 реализацию функций в DLL
...
Вот, собственно, и вся схема. Ей пользуется немеряно народу по всему миру.

npak, респект

[Гром]

предыдущий ответ Нпаку.

Хутер....

Я и не говорил, что сможешь. Я и Finch попытались тебе объяснить, почему у тебя возникла ошибка при вызове GetProcAddress.

вы вообще поняли чего сказали тогда???


Эта ошибка с невозможностью подгрузки вознимкает потому, что в стандарте Майкрософт С++ имя функции трансформируется с Init  ---> __Init_hjsk123lksj243k23j43....

И ни по какой другой причине это не происходит.....

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


Даже как-то странно слышать. Как можно решить задачу правильно, не зная всех ограничений. Или ты хочешь получить множество всех возможных решений во вселенной, а из них уже выбрать?

Все очень просто - есть пост

1. Есть программа.
2. Есть билиотека.

1 подгружает 2 в процессе работы имея в наличии только файл dll без описательных експортных и т.д. файлов.
Подгрузка должна осуществляться джинамически, без ссылок на возможности компиляции...

Структутра нужных функций и их имена известны

Init
Open
Close
Read
Write
IoCtrl

Положения:

Задача решаема и решена уже в случае:
- dll написана на языке С.
- все вышеуказанные функции находятся под extern C
вся остальная библиотека на С++.

Это условие задачи.
Если ты ее решить не можешь - не решай. В условии сказано достаточно - что бы решить проблему.
Это же было написано в постинге....

Самый прикол, что в случае работы с Load Library невозможно грузить функции описанные по стандарту С++ только С. Внутре вызывай че хошь а так не моги, так что видимо отменяется вся така байда....

То бишь надо просто читать все внимательно - а не по диагонали....

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

Потом вопрос стал - как с помощью  LoadLibrary подгрудать функции в стандарте С++.

Теперь высняется, что мало кто реально понял чего спрашивают, более того - несмотря на глубочайшие познания в С++ никто не понял почему же они не подключаются.

LoadLibrary не пользуется h , lib & def файлами, но мне в каждом втором постинге пытаются рассказать как удобно ими пользоваться.

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

Впопрос - зачем эти постинги мне? Зачем последний пост с вопросом об истином смысле задачи.

Я хочу получить не бублиотеку не ее структуру, а метод вызова функции одной с помощью двух процедур из юилиотеки написанной НА С++ а мне опять спрашивают зачем - мне надо....


Ну и напоследок маленький практический совет.

Учитесь писать интерфейсы по описанию задачи.
Есть абстракция и ее надо формализовать.
И не спрашивайте зачем и кому эта абстракция нужна.

Мульен раз я сталкивался будучи вольным работникам с готовым описанием и предложением создать интерфейс к чему то конкретному не зная зачем он потом будет нужен....

[Hooter]

Эта ошибка с невозможностью подгрузки вознимкает потому, что в стандарте Майкрософт С++ имя функции трансформируется с Init ---> __Init_hjsk123lksj243k23j43....

И ни по какой другой причине это не происходит.....

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

[Hooter]

Я решил делать маленькие посты, чтобы было легче читать.

Давай так.
Тебе нужно динамически поключать библиотеку.
Вот шаги для этого (я знаю, что ты знаешь, но это просто для уточнения):
1. LoadLibrary
2. GetProcAddress + вызов по полученному адресу.
3. FreeLibrary

Использовать код С++ с помощью динамического подключения нельзя.

Использовать библиотеку ничего не зная о ее содержимом - невозсможно

[Hooter]

Третий мой пост. Гром, не пропускай два предыдущих.

Поначалу я спрашивал одно. Будет ли ....
...
Потом вопрос стал - как с помощью  ...

То то и оно. Народ тебе почти сразу сказал, что сделать, как ты хочешь, нельзя. Именно поэтому люди тебе предлагали другие варианты решения твоей проблемы.

[Гром]

По постингам
1. Деф файл никак не влияет на образование имен в ДЛЛ. Он влияет на факт линковки ДЛЛ в основной процесс. Если Деф файл есть, то при подключении на стадии линковки можно вместо хедер и либ файлов использовать Деф файл где имена функций можно переопределить.

При собирании в Майкрософт студии любой стандартной созданной визардом библиотеки Деф файл создается самостоятельно.


2. Использовать и подгружать файлы можно. Я уже эту проблему решил, теперь осталось узнать есть ли у вас желание решить задачу или есть желание только поспорить....

3. Ни одного варианта решения второй проблемы предложено не было и не предложено до сих пор.
За первую спасибо, ибо мне нужно было именно эксперементальное подтверждение теории, которое вы мне предоставили. И обосновали.

[npak]

Сорри, я как-то решил, что DLL будет использоваться приложением, которое только разрабатывается.  А приложение то, оказывается, уже готово, надо написать к нему плугин, которое приложение по своим собственным правилам подцепит. Понимание верное?

Приложение 1 уже есть, надо сделать DLL 2, затем как-то подпихнуть её приложению 1.

Если приложение 1 уже готово, то должно быть описано, что и как оно грузит.  Предположим, что для того, чтобы DLL могла использоваться приложением, надо, чтобы оно предоставляло функции

Init
Open
Close
Read
Write
IoCtrl

Если это так, то достаточно реализовать в DLL указанные функции так, чтобы в результате они получили именно такие имена.
на Си++, очевидно, это выглядит так
extern "C" WINAPI __declspec( dllexport) return_type Init(input_type_1 arg1, /* аргументы */ )

аналогично остальные функции из интерфейса библиотеки.

Насчёт WINAPI я погорячился, это зависит от приложения, что ему надо.  Некоторым нужны WINAPI (__stdcall), нектором __cdecl.  Должно быть описано в доках по написанию плугинов к приложению. 

В таком сценарии использования устройство библиотеки подчиняются правилам, которые задёт приложение.

[npak]

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

Если такая постановка задачи верна, то по-хорошему, приложение должно предоставлять Extension API -- определённый набор функций, которые может вызывать плугин.  Если такого API нет, то ответ зависит от устройства приложения, его библиотек и операций, которыми хочет воспользоваться плугин.   Так навскидку сказать общий рецепт ... затруднительно.

[Гром]

npak - умничка, я два дня доходил до WINAPI  там стдколы вроде как не нужны в данном случае.

Просто когда ф-ию описываешь в С++ формате, то ее реально загрузить невозможно по имени ибо оно меняется.
Заставлять человека выводить экспорт в С вместо остального проекта на С++ не рельно. А вот поставить везде как обязаловку WINAPI который имеет паскаль стандарт вызова где имена неизменны - О! Саое оно + в репутацию.

[Finch]

Гром, За этот топик ты меня отдергиваеш уже третий раз. Я дал тебе рабочий пример, который я проверил в VC++6.0. Определись что тебе нужно.

[npak]

npak - умничка, я два дня доходил до WINAPI  там стдколы вроде как не нужны в данном случае.

Просто когда ф-ию описываешь в С++ формате, то ее реально загрузить невозможно по имени ибо оно меняется.
Заставлять человека выводить экспорт в С вместо остального проекта на С++ не рельно. А вот поставить везде как обязаловку WINAPI который имеет паскаль стандарт вызова где имена неизменны - О! Саое оно + в репутацию.

Спасибо за добрые слова но ...

Если для обычной функции Си++ задать WINAPI, то это не спасёт от переименования.

Например, в исходниках задано

Код:

int __declspec( dllexport ) WINAPI  Init()

В DLL получим функцию с именем ?Init@@YGHXZ

Надо заставлять разработчиков плугина писать extern "C"

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

[Гром]

Я полностью не проверял, но в принципе так и делается сейчас, будет именнно так - что пользователь должен будет заполнять в своей функции типа Init все остальные поля...

Но почему ты считаешь что будет переименование, насколько мне известно - нет не будет...


Финч - где ты писал, что надо сделать WINAPI ?
Если писал - то извини, видимо и я плохо читал.

[Finch]

Файл WinDef.h

Код:

#define CALLBACK    __stdcall
#define WINAPI      __stdcall
#define WINAPIV     __cdecl
#define APIENTRY    WINAPI
#define APIPRIVATE  __stdcall
#define PASCAL      __stdcall

[npak]

Но почему ты считаешь что будет переименование, насколько мне известно - нет не будет...

Я проверил.  Собрал DLL с  функцией, написанной на Си++, и посмотрел на имя в таблице экспортов получившейся DLL (эта та самая таблица, которой пользуется GetProcAddress чтобы сконвертировать строковое имя функции в адрес).  Посмотрел при помощи утилиты dumpbin

Оказалось, что у в таблице только одна запись, и эта запись имеет вид ?Init@@YGHXZ.  На С++ декларацию "int WINAPI Init(void)" это походит только отадалённо.

[Finch]

Чтобы исключить дальнейшие споры, собственно RTFM Дж. Рихтер "Виндовс -для проффессионалов" Глава 19.

С инструментальные средства от разных поставщиков создают проблемы Дело в том, что компилятор Microsoft С, экспортируя С-функцию, искажает eе имя, даже если Вы вообще не пользуетесь С++ Это происходит, только когда Ваша функция экспортируется по соглашению __stdcall. (Увы, это самое популярное соглашение ) Тогда компилятор Microsoft искажает имя С-функции. впереди ставит знак подчеркивания, а к концу добавляет суффикс, состоящий из символа @ и числа байтов, передаваемых функции в качестве параметров. Например, следующая функция экспортируется в таблицу экспорта DLL как _MyFunc@8:


__declspec(dllexport) LONG __stdcall MyFunc(int a, int b);

Если Вы решите создать ЕХЕ-файл с помощью средств разработки от другого поставщика, то компоновщик попытается скомпоновать функцию MyFunc, которой нет в файле DLL, созданном компилятором Microsoft, и, естественно, произойдет ошибка

Чтобы средствами Microsoft собрать DLL, способную работать с инструментарием от другого поставщика, нужно указать компилятору Microsoft экспортировать имя функции бсз искажений. Сделать это можно двумя способами Первый — создать DEFфайл для Вашего проекта и включить в него раздел EXPORTS так:


EXPORTS MyFunc


Компоновщик от Microsoft, анализируя этот DEF-файл, увидит, что экспортировать надо обе функции: __MyFunc@8 и MyFttnc. Поскольку их имена идентичны (не считая вышеописанных искажений), компоновщик на основе информации из DEF-файла экспортирует только функцию с именем MyFunc, а функцию _MуFипс@8 не экспортирует вообще.

Может, Вы подумали, что при сборке ЕХЕ-файла с тикой DLL компоновщик от Microsoft, ожидая имя _MyFunc8, не найдет Вашу функцию? В таком случае Вам будет приятно узнать, что компоновщик все сделает правильно и корректно скомпонует ЕХЕ-файл с функцией MyFunc.

Если Вам не по душе DEF-фаЙлы, можете экспортировать неискаженное имя функции еще одним способом. Добавьте в один из файлов исходного кода DLL такую строку:


#pragma comment(linker, "/export:MyFunc=_MyFunc@8")


Тогда компилятор потребует от компоновщика экспортировать функцию MyFunc с той же точкой входа, что и _MyFunc@8. Этот способ менее удобен, чем первый, так как здесь приходится самостоятельно вставлять дополнительную директиву с искаженным именем функции И еще один минус этого способа в том, что из DLL экспортируется два идентификатора одной и той же функции MyFunc и _МуFипс@8, тогда как при первом способе — только идентификатор MyFunc. По сути, второй способ не имеет особых преимуществ перед первым — он просто избавляет от DEF-файла

[Гром]

Finch
Спасибо, но это очень и очень плохо....
Мне надо сделать так, что бы разработчик библиотеки не замарорачивался всей этой лабудой, а делал бы так как ему надо - с маленькими упрощениями...

Увы плохо все это....