Разработка внешних компонент на ассемблере goAsm

Введение

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

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

Статья может быть интересна тем, кто использует внешние компоненты, но сам их ни разу не разрабатывал или создавал по шаблонам, предоставленным 1С, не задумываясь о деталях. В данном случае, компонента будет написана «с нуля». Основная среда разработки – текстовый редактор.

Так как 1С предлагает две технологии для разработки Com и NativeAPI, то мне бы хотелось осветить их обе. В этой части мы рассмотрим технологию Com (большинство внутренних объектов движка платформы, как раз представляют собой Com-объекты).  В следующей (если будет интерес у читателя) -  NativeAPI. Тут следует отметить (вдруг кто-то не в курсе), что технология Com это так сказать общеизвестная  технология, в отличии от NativeAPI, которая является сугубо внутренним стандартом, разработанным 1С.

 Компонента будет разрабатываться для 32-х разрядной ОС Windows, но ничто не мешает в дальнейшем переработать ее для 64-разрядной ОС. Это актуально в первую очередь для серверов, а c недавнего времени и для клиентов x64. Что будет «уметь» наша компонента? Во-первых, получать изображение из буфера обмена в виде Base64 строки. Мне показалось, что задача интересная и при этом актуальная. Во-вторых, обращаться к методам платформы 1С. В-третьих, генерировать внешние события. В-четвертых, компоненту можно будет создавать через Новый ComОбъект. Думаю, что для примера этого вполне достаточно. Размер готовой Dll-ки будет в районе 5К байт. Согласен, что это не столь актуально в нынешних условиях, когда объем памяти измеряется Гигабайтами, но и  плохого в этом тоже ничего нет.

Компонента будет работать в толстом/тонком клиенте управляемого приложения, в обычном приложении и в web-клиенте (IE) (ограниченный функционал).

Что нам потребуется для разработки? Ассемблер goAsm. В общем-то всё. Там есть свой IDE (EasyCode). На практике, я использую EasyCode в связке с Notepad++. В последнем, как мне кажется, все-таки удобнее набивать код, а в Easycode переключаюсь только для компиляции.

Пишем первую функцию

Предлагаю перейти к практике. Начнем вот с таких строк…

.const

.data

.code

Всего три строки. Это секции нашего файла. Никаких мастеров для создания проектов, никаких заголовочных файлов от 1С. Все довольно аскетично.

И так, давайте напишем нашу первую функцию, которая присутствует в любой dll. Это так называемая точка входа. Можно сказать, что эта функция аналог 1С-м ПриНачале/ПриОкончании РаботыСистемы.

В зависимости от значения параметра dwReason это либо начало (загрузка DLL), либо окончание (выгрузка) «работы». Как и в случае с 1С, здесь удобно расположить действия, которые должны быть выполнены единожды. Например, тут можно провести инициализацию значений.

В нашем случае, мы выполним ряд действий при загрузке (dwReason = DLL_PROCESS_ATTACH).

1. Сохраняем параметр функции «hInstance». Его мы используем в дальнейшем, при вызове других API-функций.
2. Загружаем строку с ID = 100 (OBJ_NAME) из таблицы строк компоненты.
3. Получаем хендл для работы с памятью. Ведь нам придется создавать/уничтожать наш Com-объект.
4. Т.к. «технология Com» подразумевает регистрацию в реестре, то нашему объекту необходим GUID. В данном случае он хранится в текстовом виде в разделе «.data».

Но, для работы нам потребуется также его 16-ти байтовое представление, поэтому  делаем преобразование.

5. Функция  «_getMaxID» выполняет инициализацию небольшой структуры. Подсчитывает кол-во свойств и методов у нашего 1С-го объекта. Об этом позже.

Обратите внимание, на наличие метки “start:”. Именно она указывает на место, с которого будет выполнен код при загрузке/выгрузке DLL. Имя функции «DllEntryPoint» выбрано произвольно и не имеет принципиального значения, кроме как для читаемости кода.

В тексте модуля я старался соблюсти единообразие, поэтому, чтобы не путать в вызовах invoke имена функций API и обычных функций, они (API) начинаются с заглавной буквы (MessageBox, GetProcessHeap и т.д.). Также с заглавной начинаются вызовы функций интерфейсов. Но у них «особый» вид (IInitDone_QueryInterface, ILanguageExtender_IsPropReadable и т.д. ). Вспомогательные функции начинаются с подчеркивания и маленькой буквы (_getMaxID).

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

Регистрация в реестре

После успешной загрузки, приходит очередь экспортной функции DllRegisterServer. Вот тут имя функции уже важно.

Полный код приводить не имеет смысла, поскольку он однообразен.

В случае успешной регистрации, мы получаем вот такую конструкцию в реестре:

А теперь давайте разберемся, зачем все это нужно. Тут я позволю себе процитировать выдержки из перевода статьи уважаемого Rustem c wasm.ru (увы, сам ресурс уже давно не работает, но всегда можно найти архив).

“Одна из важнейших основ, которая активно используется и без которой невозможна сама инфраструктура COM, - это системная база данных. На платформе Windows в качестве таковой выступает системный реестр.

<…>

Вся эта и другая относящаяся к COM/OLE/ActiveX информация хранится в разделе реестра "HKEY_LOCAL_MACHINE\Software\CLASSES". Этот раздел настолько важен, что для него был создан алиас под видом отдельного корневого раздела реестра "HKEY_CLASSES_ROOT".

<…>

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

Рассмотрим, например, ключ "Excel.Application" (в нашем случае это «AddIn. _goasm_1c_com», прим. автора). Он имеет подключ CLSID, значение по-умолчанию которого и является искомым CLSID в строковом представлении. Это значит, что в разделе "HKEY_CLASSES_ROOT\CLSID" имеется соответствующий ключ, содержащий всю необходимую для загрузки компонента информацию.”

Здесь я хотел закончить с регистрацией, но в процессе тестирования обнаружил некие «особенности» при работе в обычном и управляемом приложении. Может быть они общеизвестны, но для меня они оказались сюрпризом.

Начнем с того, что 1С каждый раз при вызове «ЗагрузитьВнешнююКомпоненту» в обычном и «НачатьПодключениеВнешнейКомпоненты» в управляемом приложении (тут я подразумеваю, что компонента была предварительно установлена «НачатьУстановкуВнешнейКомпоненты»), пытается запустить DllRegisterServer. В принципе, ничего сверхестественного тут нет. Если компонента уже была зарегистрирована, а у пользователя нет админских прав, то DllRegisterServer заканчивается с ошибкой (SELFREG_E_CLASS), но управление передается дальше. Особенность заключается в том, что если успешная регистрация происходит в управляемом режиме, то в реестре прописывается имя временного файла, который потом удаляется и соответственно, нужно опять запускать приложение с админскими правами, что не есть хорошо. Мне видится, что единоразовая  регистрация через regsvr32 или запуск обычного приложения с соответствующими правами, решит эту «проблему».

Вторая особенность заключается в необходимости использования ресурсов в DLL - речь про имя компоненты, которое может храниться в ресурсах. Вот выдержка из документации:

При загрузке внешней компоненты функцией ЗагрузитьВнешнююКомпоненту или ПодключитьВнешнююКомпоненту(<МестонахожденияКомпоненты>, <ИмяМетки>,  ТипВнешнейКомпоненты.COM) "1С:Предприятие" определяет ProgID COM—объекта компоненты следующим образом:

• ProgID имеет вид <Vendor>.<Component>;
• в качестве первой части (<Vendor>) используется строка "AddIn";
• в качестве второй части (<Component>) используется строка с ID 100 из таблицы строк компоненты. Строка может иметь вид "Name1|Name2|...|NameN", и в этом случае будут созданы все объекты с ProgID вида "AddIn.NameX". Если такая строка отсутствует, то используется имя файла внешней компоненты без расширения.

Изначально, я планировал обойтись без использования ресурсов (для упрощения), тогда бы имя компоненты совпадало бы с именем файла без расширения. Но, оказалось, что в управляемом режиме такой фокус не срабатывает и система воспринимает отсутствие ресурса, как пустое имя компоненты. К тому же, имя временного файла всегда произвольно и очевидно, не может быть именем компоненты.

Третья особенность, в общем-то и не особенность, а закономерный факт. Если компонента зарегистрирована «по постоянному адресу» и этот «адрес» не меняется в реестре, то управляемое приложение будет работать именно с DLL по «постоянному адресу», несмотря на то, что временный файл с нашей же компонентой будет создаваться. Отсюда вывод – эти DLL’ки могут быть совсем разными и соответственно с разным функционалом. И эта временная DLL никак не коррелирует с той, что будет реально использована.

(Здесь видно, что этот .tmp на самом деле DLL с 4-мя экспортными функциями).

Резюмируя: в реестре создается ключик ProgID, который указывает на CLSID. В последнем лежит ссылка на DLL, реализующую наш компонент.

Лирическое отступление

Прежде, чем двигаться дальше, я хотел бы немного порассуждать о том, что представляет собой объект в памяти.

Ну…объект, это некий кусок памяти, который каким-то образом структурирован. Давайте создадим объект из 2х указателей, например такой:

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

Через некоторое время оказалось, что нужно добавить еще пару строк в объект:

Все работает и печатается.

Спустя какое-то время, потребовалось еще печатать пару дат и число. Наш объект приобретает такой вид:

И вы смотрите на этот объект и понимаете, что так дальше продолжаться не может. Объект получается каким-то «нерегулярным». Какая-то смесь указателей  на данные и методы. Поэтому вы решаете переделать его таким образом, чтобы все указатели были собраны в массивы.

Как-то, вот так:

Ну, вот, совсем другое дело. Теперь можно сколько угодно методов, строк, дат и чисел добавлять.

Вам ставят очередную задачу: кроме вывода, нужно еще сделать ввод данных.

Вы пишете 3 функции для ввода данных. И вот вопрос – куда эти функции поместить? Добавить их к имеющимся методам или сделать отдельную таблицу. Вы решаете разделить методы по 2м группам. Одна отвечает за вывод, другая за ввод данных. В дальнейшем, это позволит без проблем добавить функции ввода и вывода картинок и не нарушить при этом стройность конструкции.

Вы хорошо потрудились и вашим объектом решили пользоваться другие граждане. Перед вами встает дилемма, как поделиться своим объектом, чтобы народ не тратил время на изучение внутренней структуры объекта и не привязывался к ней жестко, поскольку возможны дальнейшие изменения? Вы решаете, что на запрос, будете возвращать  адрес 0x1000, который является  указателем на  ваш объект и по этому адресу лежит указатель на таблицу с методами вывода. Вы думаете, а не назвать ли этот указатель красиво – указатель на интерфейс? А что - звучит не плохо, да, и в действительности это интерфейс для взаимодействия. Остается только решить вопрос – как безболезненно получать интерфейс, который отвечает за ввод данных? Это сейчас он расположен по адресу 0x1010, а завтра объект изменится и указатель сдвинется…

И тут вам приходит идея -  почему бы в каждую из таблиц функций, не поместить некую служебную функцию. Назвать ее, как-нибудь «Запрос_интерфейса». Поместить ее самой первой в эти таблицы, а сами интерфейсы пронумеровать? Допустим, тот, что выводит данные номер «1», а тот, что вводит «2». Тогда, имея указатель на 1-й интерфейс, мы обращаемся к его функции «Запрос_интерфейса» и просим взамен вернуть указатель на 2-й интерфейс. И наоборот, имея указатель на 2-й интерфейс, получаем по запросу 1-й.

Поскольку мы (как разработчики объекта) знаем его структуру, нам не составит труда написать метод «Запрос_интерфейса» таким образом, чтобы он выдавал нужный клиенту указатель по номеру интерфейса. Теперь, всё что должен знать клиент  об объекте это указатель на один из его интерфейсов. Всё. Будем считать, что наша задача решена.

Если идея понятна, то считайте, что вы знаете, как выглядят Com-интерфейсы.

Первый Com-объект

Возвращаемся к нашей DLL. Если вызов DllRegisterServer завершился «успешно», т.е. 1С-ка нашла ProgID и CLSID, происходит вызов экспортной функции DllGetClassObject. Это своего рода «точка входа в COM» со стороны нашего Com-сервера.

Вот реализация этой функции:

Система передает ей такие параметры:

• rclsid              -  адрес структуры, содержащей CLSID объекта класса
• riid                  - адрес структуры, содержащей IID интерфейса, который запрашивается у объекта класса
• ppv                  - адрес переменной, в которой возвращается указатель на затребованный интерфейс

Первый параметр rclsid это указатель как раз на тот самый CLSID, который соответствует нашему компоненту. В общем случае, DLL может реализовывать несколько классов объектов с различными CLSID, поэтому в данной функции предполагается предусмотреть соответствующие сценарии для каждого из них. Наша DLL реализует только один класс, поэтому мы ограничиваемся только проверкой на равенство GUID’ов, вызывая IsEqualGUID. Хотя мы могли бы и это опустить.

Второй параметр riid – тоже ссылка на GUID, но этот GUID уже означает ID (номер) интерфейса. Что такое интерфейс? В терминах Com - это просто таблица, т.н. виртуальная таблица, содержащая ссылки на функции. Набор и последовательность этих функций строго регламентирован. Реализация самих функций ложится на плечи разработчика. Далее, на примере мы рассмотрим, как выглядит интерфейс.

Третий параметр ppv -  адрес, куда необходимо возвратить результат. 

Давайте посмотрим на нашу функцию под отладчиком и убедимся, что туда приезжают те самые параметры. Установим точку останова на начале функции:

Параметры располагаются в стеке сразу за адресом возврата. И действительно, это три указателя. Первые два на структуры GUID, а третий на память, куда мы должны вернуть результат (сейчас там нулевое значение).

Теперь давайте заглянем в реестр и поищем там строку с GUID’ом второго параметра:

Находим еще один важный раздел реестра. Тут собраны GUID’ы различных интерфейсов. Конечно, ссылаться на такие ID не удобно, поэтому у каждого есть человеческое имя. В нашем случае это IClassFactory. Если мы посмотрим на строчку выше, то увидим, что самым первым располагается GUID {00000000-0000-0000-C000-000000000046}. Это ID интерфейса IUnknown. Этот интерфейс является «родоначальником». Это значит, что все остальные интерфейсы являются его потомками, прямыми или косвенными. Принцип наследования в терминах Com-интерфейсов означает, что интерфейс-потомок наследует всю виртуальную таблицу интерфейса-родителя, добавляя указатели к собственным методам в ее конец.

Виртуальная таблица интерфейса IUnknown содержит три ссылки на реализацию методов QueryInterface, AddRef и Release, а это значит, что первые три указателя виртуальной таблицы любого интерфейса COM содержат адреса реализаций трех методов IUnknown в одном и том же порядке.

Тут наверное у читателя может возникнуть вопрос – а причем тут IClassFactory? Дело в том, что DllGetClassObject должна вернуть не наш 1С-й Com-объект, а посредника, т.н. Фабрику-классов. Фабрика – это тоже Com-объект. Именно она (фабрика) будет в дальнейшем создавать экземпляры 1С-х объектов.

Теперь посмотрим, как выглядит Фабрика-классов на практике. Как было сказано выше, объект это кусок памяти, структурированный определенным образом. Каким именно – решает разработчик. Вот, например, так:

Это наша фабрика. 8 байт. Это место мы выделили в секции .data. Фабрика будет существовать в единственном экземпляре и под нее не придется динамически выделять/освобождать память. Тут мы видим, что первые 4 байта выделены под указатель на vtClassFactory. Другие 4 – счетчик ссылок. Думаю, что читатель уже догадался, что адрес первых 4-х байт объекта это и есть указатель на интерфейс. Помним, что интерфейс это таблица с адресами функций (в x32 адреса занимают 4 байта, поэтому смещение относительно начала таблицы каждого следующего метода +4 байта). Вот как выглядит эта таблица у нас:

Теперь про сами функции. Это не абы какие функции, сваленные в кучу, а функции отвечающие определенным условиям.

IClassFactory_QueryInterface(pObj, riid, ppv) (или IClassFactory::QueryInterface в терминах C++)

Этим методом мы запрашиваем поддержку у Com-объекта интерфейса, передавая id интерфейса. Все так, как было описано ранее в «рассуждениях». Первый параметр pObj при этом указывает на интерфейс, который нам уже известен. Второй параметр riid – ID-интефейса, который требуется получить. Если объект поддерживает запрашиваемый интерфейс, то по адресу третьего параметра помещается указатель на него.

Обратимся к нашему листингу и посмотрим, как работает метод QueryInterface.

После успешной проверки CLSID, выполняется следующий код:

Сначала мы загружаем в eax указатель на интерфейс. Конструкция [eax] возвращает значение, которое лежит по адресу из eax. А там лежит ссылка на виртуальную таблицу. Вот эта ссылка и загружается в ecx. Тоже самое с invoke [ecx + IClassFactory.QueryInterface](эквивалентно invoke [ecx + 0]) - выполняется функция, которая находится по смещению +00h из ВТ.

Таким образом, мы запрашиваем у нашей Фабрики поддержку интерфейса riid. Вы еще помните, что riid и ppv это параметры DllGetClassObject? В большинстве случаев riid это IClassFactory, но могут быть и варианты.

Реализация метода QueryInterface довольно проста. Вызовом IsEqualGUID мы сравниваем запрошенный интерфейс с  IUnknown и IClassFactory. В случае успеха возвращаем указатель на  интерфейс через ppv. Не забываем при этом увеличить счетчик ссылок.

Методы AddRef (смещение +04h) и Release (+08h) увеличивают и уменьшают счетчик ссылок. Release еще обычно освобождает память, выделенную под объект, когда счетчик ссылок становится равным 0. Release должен вызвать клиент, когда он закончил работать с интерфейсом.

Резюмируя вышесказанное: клиент (в лице 1С) вызывает (не напрямую) DllGetClassObject, запрашивая Com-объект, поддерживающий интерфейс IClassFactory. Мы в свою очередь, предоставляем этот Com-объект и возвращаем указатель на запрошенный интерфейс. Три метода этого интерфейса мы разобрали. Эти методы унаследованы от IUnknown и являются обязательными для любого интерфейса. В следующей главе рассмотрим 4й метод фабрики классов.

Создаем объект 1С

Каждый раз, когда мы пишем Новый ("AddIn._goasm_1c_com") система вызывает метод фабрики IClassFactory::CreateInstance. В этом методе создается новый Com-объект и возвращается указатель на один из его интерфейсов, тот который запрошен в riid.

Хочу обратить внимание читателя на то, что при вызове любых методов Com-интерфейсов, первый параметр всегда указатель на интерфейс. Сделано это для того, чтобы понять, с каким экземпляром Com-объекта мы работаем. На примере Фабрики это не столь очевидно (использование первого параметра), поскольку она у нас в единственном экземпляре и расположена по постоянному адресу, а вот с 1С-ми объектами это уже актуально.

Рассмотри м параметры метода:

• pObj указатель на интерфейс (в терминах C++ это this). Читатель может использовать любое имя формального параметра, мне удобнее использовать pObj, как указатель на объект

• pUnkOuter должен содержать NULL, поскольку мы не планируем агрегацию в состав другого объекта

• riid ID интерфейса, который должен поддерживать наш создаваемый Com-объект

• ppv адрес переменной, куда нужно вернуть результат

Вот тот самый код, который создает «1С-й объект»:

Предварительно мы описали структуру объекта. Это полезно во-первых, для подсчета места в байтах для выделения памяти, а во-вторых для удобства обращения к частям объекта.

После выделения памяти, мы производим инициализацию. Наш объект будет поддерживать 4 интерфейса, два из которых обязательны (IInitDone и ILanguageExtender). ILocale приведен для локализации решения, но методы его не реализованы (читатель может сделать это самостоятельно). Интерфейс IDispatch тоже необязателен, но призван показать, что поддержка одного только этого интерфейса позволяет использовать наш Com-объект не только в среде 1С, но например, в скриптах, браузере, да и в 1С, без использования ЗагрузитьВнешнююКомпоненту, т.е. наш объект можно будет создать обоими способами:

• Новый ("AddIn._goasm_1c_com")
• Новый COMОбъект("AddIn._goasm_1c_com")

Думаю, стоит упомянуть, что IInitDone, ILanguageExtender, ILocale сугубо внутренние интерфейсы платформы. Вряд ли вы найдете их GUID’ы в реестре, в отличии, например от, IDispatch, который является стандартным интерфейсом. Так же нужно понимать, что в зависимости от того, как мы создаем наш объект (Новый или Новый COMОбъект) 1C будет использовать те или иные интерфейсы. Если, например, Новый, то интерфейс IDispatch даже запрошен не будет, хотя наш объект его будет поддерживать. И наоборот – IDispatch, будет использован, а 3 других интерфейса нет.

Надо так же понимать, что у двух вариантов создания объекта будет различие в функционале. Заключается оно в том, что во втором случае не будет выполнен метод IInitDone::Init, и следовательно передан указатель на IDispatch платформы, со всеми вытекающими (см. доку). Если этот указатель не предполагается использовать, то разница нивелируется.

Вернемся к нашему коду. Нам необходимо завершить инициализацию, а т.к. наш 1С-й объект будет иметь свойства, то мы должны хранить их каким-то образом, так что следующие несколько строк выделяют кусок памяти под значения VARIANT (16 байт на свойство) и записывают ссылку на буфер в pPropsArray.

Далее мы запрашиваем у нашего созданного и проинициализированного объекта, поддержку интерфейса riid. Делаем это стандартным образом:

В ebx у нас хранится указатель на начало буфера под объект, а по смещению +00h мы записали указатель на ВТ IInitDone. Таким образом, ebx содержит указатель на интерфейс IInitDone. Важно понимать, что результат выполнения этого кода не изменился бы, если бы мы, например, предварительно выполнили add ebx, 4, поскольку ebx содержал бы указатель на ILanguageExtender и т.д. И не важно, какой указатель на интерфейс нам известен, QueryInterface позволяет получить указатель на любой из поддерживаемых объектом интерфейсов.

В результате работы метода фабрики CreateInstance создается запрошенный Com-объект, а клиенту (платформе 1С) возвращается указатель на один из его интерфейсов.

И еще раз хочу обратить внимание вот на что: (я уже об этом говорил, но хочу повториться) вы когда-нибудь задумывались, почему, например, в скриптах Word'а обычно нельзя использовать 1С-ю компоненту, созданную казалось бы по "технологии Com"? Все правильно - отсутствие поддержки IDispatch. Если разработчик, т.е. Вы, его реализовал, то в этом случае всё будет работать. Это первое.

Второе - вот в нашем объекте указатели на интерфейсы идут последовательно, один за одним. Это не принципиально. Вы, как разработчик, можете их расположить в произвольном порядке и вообще как угодно, вперемежку с данными, т.е. в нашем случае, мы могли бы Counter и pPropsArray расположить где-нибудь между указателями на интерфейсы. Важно то, что вы знаете структуру объекта и можете по запросу вернуть верный указатель.

Реализация интерфейсов

Сначала оценим, что нужно реализовать…

На первый взгляд - довольно много. В действительности же, методы IUnknown (QueryInterface, AddRef и Release), для каждого интерфейса создавать не нужно. Достаточно написать один рабочий код и соответствующие методы свести к нему. Часть методов практически пустые, часть требуют минимальных усилий.  

Рассмотрим реализацию некоторых методов.

IInitDone::QueryInterface

Для того, чтобы проще получать указатели на интерфейсы, мы подготавливаем массив простых структур  <отступ указателя в объекте - ссылка на IID >, сопоставляя отступу указателя в объекте его IID.  Перемещаясь по этому массиву, находим нужный нам IID (используя стандартную ф-ю IsEqualGUID) и тут же определяем отступ в объекте. Зная структуру объекта - получаем указатель на запрашиваемый интерфейс, просто прибавляю этот offset к указателю на IInitDone (поскольку pObj  в данному случае указатель на IInitDone):

Возвращаем найденный указатель на  интерфейс по адресу из edi .

Реализации остальные методов QueryInterface выглядят аналогично нижеследующему:

Здесь pObj это уже указатель на интерфейс ILanguageExtender. Вычитая из него отступ в объекте, мы получаем в eax указатель на интерфейс IInitDone. Ну, а дальше по стандартной схеме…

IInitDone::Init

Вот выдержка из документтации:

При загрузке "1С:Предприятие" инициализирует объект компоненты, вызывая метод Init и передавая указатель на IDispatch. Объект может сохранить этот указатель для дальнейшего использования. Все остальные интерфейсы 1С:Предприятия объект может получить, вызвав метод QueryInterface переданного ему интерфейса IDispatch.

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

Итак, при вызове данного метода 1С передает нам указатель на интерфейс. Т.е. это адрес, который принадлежит некому Com-объекту и объект этот поддерживает по крайней мере интерфейс  IDispatch. Это стандартный интерфейс для доступа «через точку». (Если этот указатель вернуть какой-нибудь функцией, то в режиме пользователя, к нему можно будет обратиться. У него будет свойство AppDispatch, которое тоже содержит указатель на IDispatch, но этот указатель уже от другого объекта и вот через этот 2й IDispatch уже можно обращаться к методам платформы).

Для начала, мы сохраним этот указатель в нашей переменной и увеличим счетчик ссылок. Иначе, после выхода из метода Init, 1С вызовет Release и объект уничтожится.

Далее, мы стандартным образом запрашиваем поддержку интерфейса IAsyncEvent. Он нам потребуется при работе с таймером.

ILanguageExtender

За интерфейс «доступа через точку» в 1С отвечает интерфейс ILanguageExtender. Для того, чтобы реализовать его методы, нам потребуется организовать некий массив структур, для удобного получения данных. Вариантов может быть множество (например, связанный список или списки). В данном случае, это массив указателей на структуры.

Заполняем структуры, соответствующим образом и сводим их в массив указателей (table_methods_props), для удобства доступа.

Из контекста, я думаю понятно, какие поля структур для чего предназначены. У нас будет пара свойств и 4 метода. При формировании массива указателей свойств/методов, есть небольшое требование – в начале массива должны располагаться указатели на свойства, а потом на методы. Это сделано для облегчения нумерации свойств/методов.

Рассмотрим реализацию некоторых методов интерфейса:

Здесь вызывается вспомогательная функция _getAmount, которая получает данные из ранее подготовленной структуры. Саму структуру мы проинициализировали на этапе загрузки DLL количеством свойств и методов нашего 1С-го объекта (см. DLLEntryPoint). Аналогично выглядит метод ILanguageExtender::GetNMethods.

Следующий метод выполняет поиск свойства по заданному id:

Вспомогательная ф-я _getNameById возвращает строку, соответствующую названию свойства по его номеру. Аналогично выглядит метод ILanguageExtender::GetMethodName.

Вызов процедур и функций нашего 1С-го объекта происходит с использованием этих двух методов интерфейса:

С реализацией остальных методов интерфейсов IInitDone, ILanguageExtender и IDispatch, можно познакомиться в листинге.

Процедуры и функции нашего объекта.

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

Для примера, реализованы несколько процедур/функций, которые могут быть полезны в использовании. Здесь только стоит отметить, что 1С автоматически добавила нашему объекту несколько методов для работы в асинхронном режиме:

Приводить код самих функций я здесь не буду, а дам лишь некоторые комментарии.

Процедура test1.

Выполняет вызов метода платформы Сообщить. В этом примере можно посмотреть, как работать с интерфейсом IDispatch. Порядок тут такой: с помощью метода IDispatch::GetIDsOfNames получаем ID пользовательской функции/свойства, далее вызываем метод IDispatch::Invoke, который вызывает функцию/возвращает значение свойства. У самих методов много параметров, но не все обязательны к «заполнению» (см. вспомогательные методы _getDisp1C и _message).

Тут же можно посмотреть вариант работы со структурами SAFEARRAY и DISPPARAMS.

Функция test2.

Делает скриншот экрана и заворачивает данные в строку base64. Конвертацию выполняет вспомогательная ф-я _getBase64.

Процедуры startTimer, stopTimer.

Демонстрируют использование таймера и интерфейса IAsyncEvent.