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

AJD>>В чем проблема создать прокси?

А>если проблемы нет, означает что Вы можете сейчас сесть и в черновую накатать код, который осуществляетсяуниверсальный маршалинг Можете? Если да, поделитесь идеями как. Я например не могу, поэтому спрашиваю.

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

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

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

AJD>>>В чем проблема создать прокси?

А>>если проблемы нет, означает что Вы можете сейчас сесть и в черновую накатать код, который осуществляетсяуниверсальный маршалинг Можете? Если да, поделитесь идеями как. Я например не могу, поэтому спрашиваю.

AJD>Прокси создать довольно просто. По описанию из библиотеки типов типов налету создадим струтктуру которая будет бинарно идентична требуемому интерфейсу и отдаем клиенту.

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

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

AJD>>Прокси создать довольно просто. По описанию из библиотеки типов типов налету создадим струтктуру которая будет бинарно идентична требуемому интерфейсу и отдаем клиенту.

А>налету гененить код — реализации методов прокси — неслабая задача.

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

Занимается этим rpcrt4.dll

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

AJD>Это почему же? К тому же код методов не генериться, а только заполняется поля структура размером в твой кастомный интерфейс. Причем для каждого метода устанавливается один и тот же обработчик.

AJD>Занимается этим rpcrt4.dll

ну если обработчик один и он по typelib узнаёт скока параметров снять со стека для формирвания rpc запроса то в принципе вполне реально...

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

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

а не пробовали интересоваться стандартной реализацией IDispath? Тоже все работает волшебным образом.

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

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

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

GSD>а не пробовали интересоваться стандартной реализацией IDispath? Тоже все работает волшебным образом.

Стандартной нет, есть та что зашита в ATL — там по сути всё делегируется к ITypeLib