Re[5]: Универсальный маршалинг - COM/DCOM/ActiveX

Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

Здравствуйте, Аноним, Вы писали:

А>Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

Если ты про typelib маршалинг — то только стандартные типы и интерфейсы(IDispatch) автоматически маршалятся.

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

AJD>Здравствуйте, Аноним, Вы писали:

А>>Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

AJD>Если ты про typelib маршалинг — то только стандартные типы и интерфейсы(IDispatch) автоматически маршалятся.

Делаю произвольный интерфес с поддержкой диспатча, дёргаю из С++ кода методы этого объекта через raw интерфейс — всё нормально маршалится, как это происходит?

Здравствуйте, Аноним, Вы писали:

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

AJD>>Здравствуйте, Аноним, Вы писали:

А>>>Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

AJD>>Если ты про typelib маршалинг — то только стандартные типы и интерфейсы(IDispatch) автоматически маршалятся.

А>Делаю произвольный интерфес с поддержкой диспатча, дёргаю из С++ кода методы этого объекта через raw интерфейс — всё нормально маршалится, как это происходит?

давай подробнее, как делаешь, что делаешь

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Аноним, Вы писали:

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

AJD>>>Здравствуйте, Аноним, Вы писали:

А>>>>Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

AJD>>>Если ты про typelib маршалинг — то только стандартные типы и интерфейсы(IDispatch) автоматически маршалятся.

А>>Делаю произвольный интерфес с поддержкой диспатча, дёргаю из С++ кода методы этого объекта через raw интерфейс — всё нормально маршалится, как это происходит?

КЛ>давай подробнее, как делаешь, что делаешь

Пример:
делаю outproc сервер с объектом с поддержкой IDraw

interface IDraw: IDispatch {
   [id(1), helpstring("method Draw")] HRESULT Init([in] BSTR txt);
}

В коде делаю

   IDrawPtr pObj = NULL;
   pObj.CreateInstance(__uuidof(Draw));
   pObj->Init(_bstr_t("Hi"));

Каким образом создаётся прокся и реализуется вызов метода?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, Аноним, Вы писали:

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

AJD>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>Рзбираясь с архитектурой возник следующий вопросик... В случае стандартного маршалинга компилятор MIDL генерит проксю/заглушку которая является обьъектом с поддержкой маршалирумого интерфейса. Соответственно для создания прокси активируется объект с IID прокси и объект заглушки, которые живут в этой dll. Тут всё понятно. Непонятно каким образом осуществляется маршалинг через универсальный механизм автоматизации когда для любого объекта используется одна и таже универсальная прокся/заглушка. Если вызов осуществляется через диспатч, то понятно что объект с поддержкой iDispatch зашит в универсальную dll, а если выхов идёт через кастом интерфейс или в качесте параметров передаются кастомные интерфейсы то как всё работает?

AJD>>>>Если ты про typelib маршалинг — то только стандартные типы и интерфейсы(IDispatch) автоматически маршалятся.

А>>>Делаю произвольный интерфес с поддержкой диспатча, дёргаю из С++ кода методы этого объекта через raw интерфейс — всё нормально маршалится, как это происходит?

КЛ>>давай подробнее, как делаешь, что делаешь

А>Пример:
А>делаю outproc сервер с объектом с поддержкой IDraw
А>

А>interface IDraw: IDispatch {
А>   [id(1), helpstring("method Draw")] HRESULT Init([in] BSTR txt);
А>}
А>

А>В коде делаю

А>

А>   IDrawPtr pObj = NULL;
А>   pObj.CreateInstance(__uuidof(Draw));
   pObj->>Init(_bstr_t("Hi"));
А>

А>Каким образом создаётся прокся и реализуется вызов метода?

На основе IDL описания генерится код proxy-stub и все работает

КЛ>На основе IDL описания генерится код proxy-stub и все работает

Нифига, код то генерится, но его я не компилю, и прокся/заглушка зарегистрирована соотвественно универсальная!

Здравствуйте, Аноним, Вы писали:

КЛ>>На основе IDL описания генерится код proxy-stub и все работает

А>Нифига, код то генерится, но его я не компилю, и прокся/заглушка зарегистрирована соотвественно универсальная!

1) что значит " но его я не компилю"?
2) а ты уверен, что у тебя маршалинг вообще вступает в дело? Небось сделал apartment-threaded inproc сервер и зовешь из apartment-threaded клиента

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Аноним, Вы писали:

КЛ>>>На основе IDL описания генерится код proxy-stub и все работает

А>>Нифига, код то генерится, но его я не компилю, и прокся/заглушка зарегистрирована соотвественно универсальная!

КЛ>1) что значит " но его я не компилю"?
КЛ>2) а ты уверен, что у тебя маршалинг вообще вступает в дело? Небось сделал apartment-threaded inproc сервер и зовешь из apartment-threaded клиента

конечно, учитывая что сервер outproc

Здравствуйте, Константин Л., Вы писали:
КЛ>1) что значит " но его я не компилю"?

Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, Аноним, Вы писали:

КЛ>>>>На основе IDL описания генерится код proxy-stub и все работает

А>>>Нифига, код то генерится, но его я не компилю, и прокся/заглушка зарегистрирована соотвественно универсальная!

КЛ>>1) что значит " но его я не компилю"?
КЛ>>2) а ты уверен, что у тебя маршалинг вообще вступает в дело? Небось сделал apartment-threaded inproc сервер и зовешь из apartment-threaded клиента

А>конечно, учитывая что сервер outproc

сорри, не заметил

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:
КЛ>>1) что значит " но его я не компилю"?

А>Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

мммм, затрудняюсь ответить. Значит работает дефолтный RPC маршалер

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>1) что значит " но его я не компилю"?

А>>Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

КЛ>мммм, затрудняюсь ответить. Значит работает дефолтный RPC маршалер

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

PS Как вы убеждаетесь умные слова от МС не объясняют сути происходящего — всё очень нетривиально...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>1) что значит " но его я не компилю"?

А>>>Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

КЛ>>мммм, затрудняюсь ответить. Значит работает дефолтный RPC маршалер

А>дык, нужно создать объект проксиЮ, которая поддерживает интерфейс, который она маршалит, непонятно как это может быть реализовано в рамках одной стандартной dll универсального маршалинга.

А>PS Как вы убеждаетесь умные слова от МС не объясняют сути происходящего — всё очень нетривиально...

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

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>Здравствуйте, Аноним, Вы писали:

А>>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>>1) что значит " но его я не компилю"?

А>>>>Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

КЛ>>>мммм, затрудняюсь ответить. Значит работает дефолтный RPC маршалер

А>>дык, нужно создать объект проксиЮ, которая поддерживает интерфейс, который она маршалит, непонятно как это может быть реализовано в рамках одной стандартной dll универсального маршалинга.

А>>PS Как вы убеждаетесь умные слова от МС не объясняют сути происходящего — всё очень нетривиально...

КЛ>имхо дело в том, что ты гоняешь простые ole-automation типы, которые ole32.dll умеет маршалить. Попробуй добавь в качестве параметра метода какую нить структурку или интерфейс, и посмотрим, что будет

он для начала должен отмаршалить ИНТЕФРЕЙС, создать объект (проксю), поддерживающий интерфейс отмарщаленной интерфейсной ссылки, как он это делает? То что типы должны быть ole cpmliant понятно, это не объясняет технику маршалинга кастомного интерфейса

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>>>1) что значит " но его я не компилю"?

А>>>>>Значит что midl генерит сурсы и make файл для заглушки, я её не собираю

КЛ>>>>мммм, затрудняюсь ответить. Значит работает дефолтный RPC маршалер

А>>>дык, нужно создать объект проксиЮ, которая поддерживает интерфейс, который она маршалит, непонятно как это может быть реализовано в рамках одной стандартной dll универсального маршалинга.

А>>>PS Как вы убеждаетесь умные слова от МС не объясняют сути происходящего — всё очень нетривиально...

КЛ>>имхо дело в том, что ты гоняешь простые ole-automation типы, которые ole32.dll умеет маршалить. Попробуй добавь в качестве параметра метода какую нить структурку или интерфейс, и посмотрим, что будет

А>он для начала должен отмаршалить ИНТЕФРЕЙС, создать объект (проксю), поддерживающий интерфейс отмарщаленной интерфейсной ссылки, как он это делает?
понятное дело должен, а как он это делает — хз. Может он для IDispatch маршалер делает. Ты точно p/s не собирал/регил?
А>То что типы должны быть ole cpmliant понятно, это не объясняет технику маршалинга кастомного интерфейса

Здравствуйте, Аноним, Вы писали:

А>он для начала должен отмаршалить ИНТЕФРЕЙС, создать объект (проксю), поддерживающий интерфейс отмарщаленной интерфейсной ссылки, как он это делает? То что типы должны быть ole cpmliant понятно, это не объясняет технику маршалинга кастомного интерфейса

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

Здравствуйте, Константин Л., Вы писали:
КЛ>понятное дело должен, а как он это делает — хз. Может он для IDispatch маршалер делает. Ты точно p/s не собирал/регил?
нет конечно. если делает для диспатч то кто то должен поборачивать вызовы все чере з диспатч, и это будет жутко тормозить

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Константин Л., Вы писали:
КЛ>>понятное дело должен, а как он это делает — хз. Может он для IDispatch маршалер делает. Ты точно p/s не собирал/регил?
А>нет конечно. если делает для диспатч то кто то должен поборачивать вызовы все чере з диспатч, и это будет жутко тормозить
а ты при outproc сервере vtbl хотел

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>понятное дело должен, а как он это делает — хз. Может он для IDispatch маршалер делает. Ты точно p/s не собирал/регил?
А>>нет конечно. если делает для диспатч то кто то должен поборачивать вызовы все чере з диспатч, и это будет жутко тормозить
КЛ>а ты при outproc сервере vtbl хотел

не хотел, но при inproc в межаппартаментных вызовах не отказался бы

	От:	Аноним
	Дата:	17.07.06 19:58
	Оценка:

	От:	AndrewJD
	Дата:	18.07.06 08:01
	Оценка:

	От:	Аноним
	Дата:	18.07.06 09:16
	Оценка:

	От:	Константин Л.
	Дата:	18.07.06 09:51
	Оценка:

	От:	Аноним
	Дата:	18.07.06 11:06
	Оценка: