Есть вопросик:

1) Есть экзешник, который дергает .dll
2).dll должна запускать другой экзешник, и получить из него некий объект.
3).dll отдает объект первому экзешнику.

Каким образом проще всего реализовать 2й этап? Ну, запустить-то я могу, а вернуть что-либо дллке...
Спасибо.

Здравствуйте, shvank, Вы писали:

S>Есть вопросик:

S>1) Есть экзешник, который дергает .dll
S>2).dll должна запускать другой экзешник, и получить из него некий объект.
S>3).dll отдает объект первому экзешнику.

S>Каким образом проще всего реализовать 2й этап? Ну, запустить-то я могу, а вернуть что-либо дллке...
S>Спасибо.

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

Здравствуйте, shvank, Вы писали:

S>Каким образом проще всего реализовать 2й этап? Ну, запустить-то я могу, а вернуть что-либо дллке...

COM ?

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, shvank, Вы писали:

S>>Каким образом проще всего реализовать 2й этап? Ну, запустить-то я могу, а вернуть что-либо дллке...

A>COM ?

А не слишком ли это экстремально для такой мелочи COM объект писать?

Здравствуйте, DrMom, Вы писали:

DM>А не слишком ли это экстремально для такой мелочи COM объект писать?

Нет не экстремально. Размер dll слабо зависит от COM-а, зато головной боли меньше.

Здравствуйте, peterbes, Вы писали:

P>Здравствуйте, DrMom, Вы писали:

DM>>А не слишком ли это экстремально для такой мелочи COM объект писать?

P>Нет не экстремально. Размер dll слабо зависит от COM-а, зато головной боли меньше.

Да я не про размер, а про геморой написания COM объекта. Ведь можно просто обявить глобальную структуру и в нее писать при помощи memcpy из разных процессов. Так можно сделать минут за 5, а вот с COM так не получится.

Здравствуйте, DrMom

Я насабачился во всяких пересылках данных через COM. Это действительно удобно. Клиент спокойно жует объекты Сервера, так как если бы они были внутренними. Возни с комом правда меньше.

Здравствуйте, DrMom, Вы писали:

DM>>>А не слишком ли это экстремально для такой мелочи COM объект писать?

P>>Нет не экстремально. Размер dll слабо зависит от COM-а, зато головной боли меньше.

DM>Да я не про размер, а про геморой написания COM объекта. Ведь можно просто обявить глобальную структуру и в нее писать при помощи memcpy из разных процессов. Так можно сделать минут за 5, а вот с COM так не получится.

Не забываем про выравнивание. Как ты узнаешь какой нужен alignment данной структуре? Можно, конечно, пытаться всегда скопировать по адресу, гарантированно обеспечивающему корректность любого alignment (как, например, при использовании file mapping (он всегда проецируется с адреса, кратного гранулярности на данной платформе)), но, IMHO, это моветон .

Здравствуйте, peterbes, Вы писали:

P>Здравствуйте, DrMom

P>Я насабачился во всяких пересылках данных через COM. Это действительно удобно. Клиент спокойно жует объекты Сервера, так как если бы они были внутренними. Возни с комом правда меньше.

Для работы с объектами и пересылки сложных данных, темболее по сети ком конечно же очень удобен, но в данном случае надо передать разово данные и притом локально. Передача через глобальную переменную (глобальную в смысле на машине) будет намного быстрее и проще. Ну да впрочем кому что нравится.

Я понимаю, что мне могут ответить RTFM, но все же
Я с с++ оч слабо знаком, поэтому можно маленький кусочек кода прислать, как глобальную для всех процессов, грузящих эту длл переменную описать?
Или, хотя бы ключевые слова для поиска
Спасибо.

Здравствуйте, MaximE, Вы писали:

ME>Здравствуйте, DrMom, Вы писали:

DM>>>>А не слишком ли это экстремально для такой мелочи COM объект писать?

P>>>Нет не экстремально. Размер dll слабо зависит от COM-а, зато головной боли меньше.

DM>>Да я не про размер, а про геморой написания COM объекта. Ведь можно просто обявить глобальную структуру и в нее писать при помощи memcpy из разных процессов. Так можно сделать минут за 5, а вот с COM так не получится.

ME>Не забываем про выравнивание. Как ты узнаешь какой нужен alignment данной структуре? Можно, конечно, пытаться всегда скопировать по адресу, гарантированно обеспечивающему корректность любого alignment (как, например, при использовании file mapping (он всегда проецируется с адреса, кратного гранулярности на данной платформе)), но, IMHO, это моветон .

На мой взгляд так проще и никаких тебе выравниваний и т.п.

#pragma data_seg( ["section-name"[, "section-class"] ] )

Вот так объявляем общие переменные и ими пользуемся.

Здравствуйте, shvank, Вы писали:

S>Я понимаю, что мне могут ответить RTFM, но все же
S>Я с с++ оч слабо знаком, поэтому можно маленький кусочек кода прислать, как глобальную для всех процессов, грузящих эту длл переменную описать?
S>Или, хотя бы ключевые слова для поиска
S>Спасибо.

#pragma data_seg(".SEG")int data[1024];
#pragma data_seg()

Это в Длл включаешь и все. После этого из разных процессов загрузивших эту длл читаешь и пишешь в этот массив данные.

Здравствуйте, shvank, Вы писали:

S>Я понимаю, что мне могут ответить RTFM, но все же
S>Я с с++ оч слабо знаком, поэтому можно маленький кусочек кода прислать, как глобальную для всех процессов, грузящих эту длл переменную описать?
S>Или, хотя бы ключевые слова для поиска
S>Спасибо.

здесь

Автор: Владислав
Дата: 31.01.02

DM>#pragma data_seg( ["section-name"[, "section-class"] ] )

Я так понял, что section-name — имя моего объекта, section-class — его тип?
Или это имеет какое-то отношение к "разделяемым секциям" в dll?

Все, понял, спасибо большое...

Здравствуйте, DrMom, Вы писали:

DM>На мой взгляд так проще и никаких тебе выравниваний и т.п.

DM>

DM>#pragma data_seg( ["section-name"[, "section-class"] ] ) 
DM>

DM>Вот так объявляем общие переменные и ими пользуемся.

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

ну и не забываем о таком ограничении этого метода, как обязательное использование одной и той же dll всеми заинтересованными участниками процесса!

т.е. если 2 процесса в разных фолдерах имеют эту dll в виде 2х разных файлов, то в памяти будет 2 разных "общих" секции...

Здравствуйте, shvank, Вы писали:

named pipes ?
memory mapped files ?

Здравствуйте, adontz, Вы писали:
A>named pipes ?
Ну оно же тока на серверах ... так же никакой переносимости/совместимости... на текущий момент всего две операционки и порядка 4/5 их комплектаций
A>memory mapped files ?

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Здравствуйте, adontz, Вы писали:
A>>named pipes ?
H_D>Ну оно же тока на серверах ... так же никакой переносимости/совместимости... на текущий момент всего две операционки и порядка 4/5 их комплектаций

CallNamedPipe
The CallNamedPipe function connects to a message-type pipe (and waits if an instance of the pipe is not available), writes to and reads from the pipe, and then closes the pipe.

BOOL CallNamedPipe(
LPCTSTR lpNamedPipeName, // pipe name
LPVOID lpInBuffer, // write buffer
DWORD nInBufferSize, // size of write buffer
LPVOID lpOutBuffer, // read buffer
DWORD nOutBufferSize, // size of read buffer
LPDWORD lpBytesRead, // number of bytes read
DWORD nTimeOut // time-out value
);

Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.

A>>memory mapped files ?
H_D>
А чё я пользовал однажды...

Здравствуйте, adontz, Вы писали:

H_D>>Ну оно же тока на серверах ... так же никакой переносимости/совместимости... на текущий момент всего две операционки и порядка 4/5 их комплектаций
ну ланна... но под 95/98 оно точно не работает, а про сервера — не помню точно где, но я такую информацию встречал... проблемы такие имел... может, конечно, дело было в Win95
А вот и выдержка из MSDN.. в трех версиях смотрел.... взял из July 2000:

Requirements
Windows NT/2000: Requires Windows NT 3.1 or later.
Windows 95/98: Unsupported.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT/2000.

это всего лишь может означать то, что документация отстает от реальной ситуации и не более

есть много разных недокументированных функций, которыми однако пользуются сплошь и рядом вроде NtQuery семейство? про которое даже книги выпускают

но named pipes вроде бы никогда особо НТей не ограничивалось, разве что и правда в 95?

Здравствуйте, Valerio, Вы писали:

V>но named pipes вроде бы никогда особо НТей не ограничивалось, разве что и правда в 95?
А я не говорю, что Name Pipes... я говорю — CreateNamedPipe... а енто — большая разница... ConnectNamedPipe есть везде... а вот CreateNamedPipe — тока в линейке NT (b у меня подспудное чуство, что только в серверном варианте... откудова оно — и не упомню)...