0

2105

0
Автор публикации grifin85

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

Читать дальше...

0

1760

0
Автор публикации grifin85

Тема данной статьи - информация, которую необходимо предоставить COM-серверу системе, чтобы система считала его "настоящим". Как упоминалось ранее, экспортируемая функция DllRegisterServer является тем самым входом, вызывая который можно заставить сервер зарегистрировать существенную для функционирования COM информацию в реестре. Но, что эта за информация, откуда она берется и каким образом она регистрируется?

Читать дальше...

0

1919

0
Автор публикации grifin85

Ну вот, одну ступеньку из крыльца на котором написано "COM" мы одолели - что есть COM-объект должно быть понятно. Подобающие моменту философские выводы мы сделали. У нас ещё будет время и возможность это подробно обозреть "всё вместе", а на данном этапе мы с вами рассматриваем самый простой случай компонентного взаимодействия - вызов объекта из сервера, который реализован в виде DLL. Существуют значительно более сложные случаи - например, вызов объекта из сервера, который реализован в виде EXE, причём этот EXE может исполняться не только на той же машине, где исполняется клиент. Я думаю, что нам плавно не перейти к рассмотрению таких случаев взаимодействия компонент без философских знаний, полученных в результате обобщения пройденного пути по написанию DLL сервера. Поэтому сегодня мы приступим к рассмотрению конструкции того, что есть COM-сервер.

Читать дальше...

0

1792

0
Автор публикации grifin85

В предыдущей нашей статье был опубликован живой пример "настоящего COM-объекта" с просьбой присылать свои вопросы... вопросов по существу прислано не было. Тогда вопрос возникает у меня - могу ли я полагать, что остальное из нашего изложения не вызывает вообще никаких неясностей?

Читать дальше...

0

1812

0
Автор публикации grifin85

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

Читать дальше...

0

1817

0
Автор публикации grifin85

Как быстро (для меня) бежит время - вот мы уже и на пороге IUnknown. Как медленно (для вас) бежит время - мы всего-то добрались только до порога IUnknown... Но, тем не менее, вот мы и на пороге "серьёзного COM".

Читать дальше...

0

1839

0
Автор публикации grifin85

Мы уже знаем точные структуры, которые требуются для организации взаимодействия объектов клиента и сервера, располагающихся в разных модулях. Мы знаем протокол этого взаимодействия. Мы уже сочинили первый работающий пример, иллюстрирующий нашу рассмотренную ранее теорию и выяснили чего ещё не хватает для продвижения вперёд. Но программирование - точная наука. Есть мелкие детали, которые мы считали само собой разумеющимися, но которые таковыми, к сожалению, не являются. О них и речь. Тем более, что я получил целую серию однотипных вопросов, авторов которых можно условно разделить на два "лагеря".

Читать дальше...

0

1809

0
Автор публикации grifin85

Итак, решение о том, что ещё не хватает нашему объекту сервера для того, чтобы с ним мог нормально обращаться клиент - найдено. Остались некоторые детали оформления этого решения в точную программную конструкцию. В предыдущей статье мы установили, что нам требуется аппарат приведения типов указателей на интерфейсы и аппарат подсчёта ссылок на объект, с встроенным "самоликвидатором". Они могут быть доступны клиенту только посредством методов объекта, которые вызывает клиент и эти самые методы должны быть либо в составе каждого интерфейса, реализуемого объектом, либо - оформлены отдельным специальным интерфейсом. И абсолютно каждый объект, какого бы рода и племени он ни был - обязан реализовывать эту функциональность.

Читать дальше...

0

1883

0
Автор публикации grifin85

Итак, по результатам предшествующих тестов, у нас "всё работает". У нас теперь другая проблема, у нас - "не перестаёт работать". Мы обнаружили, что наша механика страдает тяжёлым недостатком - предложенный механизм создания объектов настолько обезличивает их, что их невозможно уничтожить по окончании их использования. Если сервер выдал клиенту ссылку на свой статический объект, то в этом нет никакой проблемы - по завершении сервера все объекты сервера будут уничтожены автоматически. Но если сервер создал экземпляр объекта динамически оператором new, то этот объект не может уничтожить никто. Его не может уничтожить клиент - в контексте клиента такой объект неизвестен и вызов delete на стороне клиента невозможен. Но его не может уничтожить и сервер... Подумайте, даже, если бы мы создали специальную функцию внутри сервера, которую бы вызывали для уничтожения такого объекта (совершенно аналогично подходу, который мы использовали для создания), то всё равно указатель на статический тип, который сервер использует, чтобы создать новый объект, не равен указателю на тот абстрактный тип, который сервер возвращает клиенту. Между ними стоит операция приведения типа, которая, в общем случае, даже численное значение указателя изменяет, не говоря про его семантику.

Читать дальше...

0

1783

0
Автор публикации grifin85

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

Читать дальше...