Задача такая:
Есть: DLL для Windows в исходниках C++.
Нужно: shared lib для Linux с сохранением совместимости на уровне исходников приложений.
DLL использует активно OVERLAPPED IO, Notyfication, Event, Thread.
В Linux (кроме Thread) нет аналогов этому. Или есть? Тогда какие, что почитать?
Опыта программирования в Windows очень мало, потому и вопросы тупые:
После анализа кода появилось ощущение, что переменные в Windows DLL могут использоваться разными приложениями. В смысле одна и та же копия переменной доступна нескольким процессам. Это так?
В коментариях в исходниках есть фразы на подобие
"Отсылаем WM_MESSAGE всем процессам, использующим DLL что очередь изменилась."
Вопрос: Windows DLL является самостоятельной сущностью, типа процесса? А иначе как DLL может отослать что-то ВСЕМ процессам, ее использующим?
Прошу не пинать ногами и не посылат сразу в MSDN. Я его пытаюсь читать, но эти вопросы ставят меня в тупик.
Полная версия этой страницы: Портирование DLL на Linux
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Про линукс ничего не скажу.
А про Win DLL упрощенно:
Динамически линкованные код и данные после загрузки ДЛЛ ничем не отличаются от статически линкованных.
"Обычные" данные принадлежат тому процессу в контексте которого работает ДЛЛ и соответственно имеется столько копий, сколько раз ДЛЛ загружена.
Однако можно разместить статические данные в shared сегменте, тогда такие данные всех экземпляров загруженных ДЛЛ будут отображатся на одну и туже область памяти.
Т.е. они будут доступны из всех процессов загрузивших эту ДЛЛ.
Правда это так не только для ДЛЛ.
Нет. ДЛЛ это часть процесса ее загрузившего.
Т.е. вызвали функцию из ДЛЛ - обратились к части кода который расположен в адресном пространстве вызывающего процесса.
А под той фразой видимо понимается, что текущий процесс может послать сообщения другим процессам, которые используют эту же ДЛЛ.
Чтобы понять как это может быть реализовано поRTFMте по ф-ции DllMain() и посмотрите на ее код в Вашем проекте.
Или по функции API RegisterWindowMessage().
Почитайте Рихтера "Windows для профессионалов" или хотя бы второй том Петзолда "Програмирование для Win95".
А про Win DLL упрощенно:
Динамически линкованные код и данные после загрузки ДЛЛ ничем не отличаются от статически линкованных.
Цитата(amw @ May 18 2007, 18:15) 
После анализа кода появилось ощущение, что переменные в Windows DLL могут использоваться разными приложениями. В смысле одна и та же копия переменной доступна нескольким процессам. Это так?
"Обычные" данные принадлежат тому процессу в контексте которого работает ДЛЛ и соответственно имеется столько копий, сколько раз ДЛЛ загружена.
Однако можно разместить статические данные в shared сегменте, тогда такие данные всех экземпляров загруженных ДЛЛ будут отображатся на одну и туже область памяти.
Т.е. они будут доступны из всех процессов загрузивших эту ДЛЛ.
Правда это так не только для ДЛЛ.
Цитата
В коментариях в исходниках есть фразы на подобие
"Отсылаем WM_MESSAGE всем процессам, использующим DLL что очередь изменилась."
Вопрос: Windows DLL является самостоятельной сущностью, типа процесса? А иначе как DLL может отослать что-то ВСЕМ процессам, ее использующим?
"Отсылаем WM_MESSAGE всем процессам, использующим DLL что очередь изменилась."
Вопрос: Windows DLL является самостоятельной сущностью, типа процесса? А иначе как DLL может отослать что-то ВСЕМ процессам, ее использующим?
Нет. ДЛЛ это часть процесса ее загрузившего.
Т.е. вызвали функцию из ДЛЛ - обратились к части кода который расположен в адресном пространстве вызывающего процесса.
А под той фразой видимо понимается, что текущий процесс может послать сообщения другим процессам, которые используют эту же ДЛЛ.
Чтобы понять как это может быть реализовано поRTFMте по ф-ции DllMain() и посмотрите на ее код в Вашем проекте.
Или по функции API RegisterWindowMessage().
Цитата
Прошу не пинать ногами и не посылат сразу в MSDN. Я его пытаюсь читать, но эти вопросы ставят меня в тупик.
Почитайте Рихтера "Windows для профессионалов" или хотя бы второй том Петзолда "Програмирование для Win95".
Спасибо!!!
А если DllMain выглядит так:
какие можно сделать выводы в контексте моих вопросов?
shared сегменты как-то декларируются или есть отдельные функции для их запроса/выделения/использования?
А если DllMain выглядит так:
Код
BOOL APIENTRY DllMain( HINSTANCE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
hInstance = hModule;
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
hInstance = hModule;
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
какие можно сделать выводы в контексте моих вопросов?
shared сегменты как-то декларируются или есть отдельные функции для их запроса/выделения/использования?
Цитата(amw @ May 18 2007, 21:41)
А если DllMain выглядит так:
.....
какие можно сделать выводы в контексте моих вопросов?
.....
какие можно сделать выводы в контексте моих вопросов?
В приведенном коде ничего нет "из такого".
Имелось ввиду что можно вести учет использующих данную ДЛЛ процессов, пользуясья DllMain().
Она вызывается при проецировании ДЛЛ в память процесса (попадаем в ветку case DLL_PROCESS_ATTACH:)
и при выгрузке (case DLL_PROCESS_DETACH:) когда процесс прекращает существование или явно выгружает ДЛЛ.
Цитата
shared сегменты как-то декларируются или есть отдельные функции для их запроса/выделения/использования?
Ну конечно.
Например в компиляторе от MS это
#pragma data_seg
Плюс нужна соответствующая опция для линкера.
См. проекты типа xine - там написан раппер для вызова f() из dll, которые валяются в linux'е. Про wine я вообще молчу.
Цитата(ms1 @ May 18 2007, 22:02)
В приведенном коде ничего нет "из такого".
Имелось ввиду что можно вести учет использующих данную ДЛЛ процессов, пользуясья DllMain().
Она вызывается при проецировании ДЛЛ в память процесса (попадаем в ветку case DLL_PROCESS_ATTACH:)
и при выгрузке (case DLL_PROCESS_DETACH:) когда процесс прекращает существование или явно выгружает ДЛЛ.
Ну конечно.
Например в компиляторе от MS это
#pragma data_seg
Плюс нужна соответствующая опция для линкера.
Имелось ввиду что можно вести учет использующих данную ДЛЛ процессов, пользуясья DllMain().
Она вызывается при проецировании ДЛЛ в память процесса (попадаем в ветку case DLL_PROCESS_ATTACH:)
и при выгрузке (case DLL_PROCESS_DETACH:) когда процесс прекращает существование или явно выгружает ДЛЛ.
Ну конечно.
Например в компиляторе от MS это
#pragma data_seg
Плюс нужна соответствующая опция для линкера.
Понял. Спасибо!!!
Пошел курить RTFM.
Цитата(amw @ May 18 2007, 18:15)
Задача такая:
Есть: DLL для Windows в исходниках C++.
Нужно: shared lib для Linux с сохранением совместимости на уровне исходников приложений.
Есть: DLL для Windows в исходниках C++.
Нужно: shared lib для Linux с сохранением совместимости на уровне исходников приложений.
Насколько я знаю, Winelib придумана как раз для вашего случая.
Цитата(scifi @ May 19 2007, 16:57)
Насколько я знаю, Winelib придумана как раз для вашего случая.
В моем случае исползование внешних библиотек крайне нежелательно.
Вам стоит посмотреть проект mplayer (http://www.mplayerhq.hu/). Там цепляются dll виндовские с кодеками.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.