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

06.12.18

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

Создание внешней компоненты по технологии Com "с нуля", используя ассемблер goAsm.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Разработка внешних компонент на ассемблере goAsm.:
.zip 8,94Kb
9
9 Скачать (1 SM) Купить за 1 850 руб.

Введение

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

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

Статья может быть интересна тем, кто использует внешние компоненты, но сам их ни разу не разрабатывал или создавал по шаблонам, предоставленным 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-ти байтовое представление, поэтому  делаем преобразование.

  1. Функция  «_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 при этом указывает на интерфейс, который нам уже известен. Второй параметр riidID-интефейса, который требуется получить. Если объект поддерживает запрашиваемый интерфейс, то по адресу третьего параметра помещается указатель на него.

Обратимся к нашему листингу и посмотрим, как работает метод 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.

внешняя компонента ассемблер goAsm

См. также

Разработка внешних компонент POS терминал Рабочее место Розничная торговля Программист Пользователь Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Рестораны, кафе и фаст-фуд Реклама, PR и маркетинг Управленческий учет Платные (руб)

Медиадисплей покупателя может отображать текущую покупку на кассовом месте, показывать видеорекламу, баннеры, во время простоя разворачивать рекламу на весь экран. Экран можно использовать в качестве графического меню-борда в кафе и видеовывески. В качестве устройства отображения можно использовать Android-планшеты, смарт-телевизоры с Android, мониторы или проекторы под управлением Windows или Linux-компьютера. Linux-версия успешно запускается на одноплатных компьютерах Raspberri Pi и Orange Pi. Настраивается ЛЮБОЙ ДИЗАЙН экрана при помощи встроенного графического редактора! Решение можно масштабировать от одного экрана до тысяч экранов с централизованным управлением.

15000 руб.

30.05.2017    53394    8    69    

45

Разработка внешних компонент Программист Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 Платные (руб)

Внешняя компонента позволяет работать c TWAIN-совместимым оборудованием (сканерами, камерами) . Полностью совместима со стандартной TWAIN-компонентой из БСП и может применяться как ее замена без изменения вызовов, при этом может работать с 64-разрядной платформой, а так же имеет расширенную функциональность, например, сохранение результата непосредственно в PDF без использования сторонних утилит. Прекрасно работает на сервере, тонком клиенте и веб-клиенте (проверена работа в браузерах Google Chrome, Mozilla Firefox и Microsoft Internet Explorer).

3000 руб.

12.05.2020    27773    137    98    

89

Разработка внешних компонент Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Внешняя компонента позволяет печатать PDF файлы непосредственно из 1С, не используя при этом сторонних программ. Прекрасно работает на сервере, тонком клиенте и веб-клиенте. Основана на проекте PDFium из состава проекта Chromium/Chrome

1500 руб.

17.09.2018    36225    113    127    

114

Разработка внешних компонент Телефония, SIP Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

Внешняя компонента выполнена по технологии Native API для 1С 8.х, обеспечивает доступ к программным АТС Asterisk (FreePBX, Elastix) через AMI интерфейс. Через него можно управлять многими функциями Asterisk (определение номеров, перевод звонков, набор телефона и т. д.)

2400 руб.

04.05.2018    46420    119    66    

64

Разработка внешних компонент Программист Платформа 1С v8.3 Платформа 1C v8.2 Платные (руб)

Внешняя компонента, позволяющая посылать команды и получать ответы по GraphQL протоколу из 1С.Может быть использована при интеграции. В 1С работает на стороне "клиента".

4600 руб.

27.06.2023    3216    2    0    

3

Разработка внешних компонент Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Внешняя компонента в виде библиотеки (.dll файл), позволяющая посылать команды и получать ответы по протоколу WebSocket из 1С. Компонента работает только на стороне "клиента".

4440 руб.

22.06.2020    17884    17    33    

21

Разработка внешних компонент Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Как известно, стремление сделать свою рекламную продукцию запоминающейся и выделяющейся — верный путь к успеху. Сегодня, мы поговорим с вами о том, что можно сделать с обычным черно-белым QR-кодом, чтобы он стал более живым и привлекательным. Если вам не терпится попробовать сгенерировать QR-код с логотипом компании, то эта обработка для вас!

2400 руб.

22.06.2016    31276    5    4    

9
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. drmaxart 149 26.11.18 23:59 Сейчас в теме
Большое спасибо за труд, очень интересно на ВК посмотреть изнутри на таком уровне
rintik; CSiER; +2 Ответить
5. chessman 192 27.11.18 09:19 Сейчас в теме
(1) Спасибо. Всё ли понятно?
2. PerlAmutor 130 27.11.18 06:35 Сейчас в теме
Не люблю COM из-за необходимости регистрировать компоненту в системе и поддержку только Windows.
Пытался как-то собрать примеры NativeAPI от 1С через MinGW, так как не перевариваю Microsoft с их компилятором С++, исходники под который не переносятся без танцев с бубнами в другие ОС из-за тесной привязки к собственным, виндовым, типам. А также из-за разности интерпретации стандартов С++ с gcc. Исходники то я собрал в .dll, но вот подключить не смог из разности интерфейсов получившихся в .dll от gcc и msvc В общем из программ собранных с помощью msvc нельзя вызывать .dllки собранные gcc. Кроме того вместе с .dll компоненты нельзя "тащить" с собой зависимые .dllки, типа iconv.dll. 1С предполагает наличие только одного файла NativAPI. Если в zip архив рядом положить все зависимые .dll, 1С их просто проигнорирует. Зависимые dll невозможно описать в XML файле.

В общем технология мне не понравилась своей ограниченностью.
10. nomadon 369 27.11.18 12:26 Сейчас в теме
(2) а по абсолютному пути dll можно прицепить ?
20. PerlAmutor 130 27.11.18 19:36 Сейчас в теме
(10) Честно не помню. Там вроде бы есть особенность, когда 1С копирует твою компоненту куда-то к себе в кэш в одну из пользовательских папок, естественно делает она это без учета её зависимости от других .dll'ок.
3. Идальго 234 27.11.18 08:01 Сейчас в теме
Так-то круто конечно))
4. gzharkoj 518 27.11.18 08:16 Сейчас в теме
Редкая с технической стороны статья на инфостарте, пишите о NativeApi обязательно.
MaxxiMiliSan; zakiap; agafonov_andrei; Йожкин Кот; o.nikolaev; torbeev; frkbvfnjh; maxopik2; adhocprog; dmpas; StrelokCj; A_Max; CSiER; jONES1979; rintik; +15 Ответить
6. chessman 192 27.11.18 09:20 Сейчас в теме
(4) Спасибо. Все ли понятно? Может что-то нужно добавить/убрать?
7. gzharkoj 518 27.11.18 09:54 Сейчас в теме
(6) Более чем, все по делу.
chessman; +1 Ответить
8. Zab 27.11.18 10:02 Сейчас в теме
Класс. Начало статьи обещает "вкусное" чтение. В закладки, чтобы прочитать неторопливо и внимательно позже.
o.nikolaev; chessman; +2 Ответить
9. DoctorRoza 27.11.18 10:42 Сейчас в теме
Думаю, суть этой статьи поняло не больше 1% аудитории, к коим, увы, я не отношусь!
11. aspirator23 339 27.11.18 13:24 Сейчас в теме
(9) Во всяком случае это интереснее чем челябинские сериалы. :)
karpik666; CSiER; +2 Ответить
12. Darklight 32 27.11.18 13:37 Сейчас в теме
Внешние компоненты по технологии COM на ассемблере? Вызовите кто-нибудь медиков автору - крышу явно снесло! Но коли автор хочет разъяснить создание на ассембрере не только COM но и Native компонент - то ладно, не забирайте автора в Кащенку - ему ещё про Native писать.

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

Автор - пиши есЧО!
frkbvfnjh; chessman; +2 Ответить
14. chessman 192 27.11.18 16:27 Сейчас в теме
(12)
(13)
Боюсь, что тогда из Кащенко точно не выпустят.

На самом деле шаблон уже есть. Его только немного поправить нужно, с учетом ошибок которые я нашел в процессе подготовки этой части. В следующей части выложу.
frkbvfnjh; +1 Ответить
15. frkbvfnjh 802 27.11.18 17:07 Сейчас в теме
(14) Ваще супер! Вам будут поклоняться как языческому божеству и приносить девственниц в жертву :)
chessman; +1 Ответить
17. starik-2005 3080 27.11.18 17:19 Сейчас в теме
(15)
Вам будут поклоняться как языческому божеству и приносить девственниц в жертву
Тащи две.
13. frkbvfnjh 802 27.11.18 16:05 Сейчас в теме
Да, пишите еще!!! Сделайте еще шаблон-заготовку для NativeAPI.
chessman; +1 Ответить
16. starik-2005 3080 27.11.18 17:17 Сейчас в теме
Статья в принципе классная, но огорчили две вещи:
1. Как уже сказали, COM - это ограничение по платформе, при этом давно уже есть NativeAPI. Было бы куда интереснее рассмотреть именно его.
2. Зачем делать dec ecx; jnz @loop? Почему не используете LOOP @loop? Но это, конечно, придирка чистой воды.

Ну и есть еще одно некоторым образом возражение - зачем АСМ? Скорости он по сравнению с С/С++ не даст, если программист не особо владеет глубокими знаниями процессорной архитектуры. Да и код на АСМе будет большой и практически неподдерживаемый, ибо АСМ знают на столько небольшое количество людей, что на Инфостарте их, МИХО, можно пересчитать по пальцам одной руки.
chessman; +1 Ответить
21. chessman 192 27.11.18 20:02 Сейчас в теме
(16)
1. NativeAPI планируется в следующей части. Жаль только, что в компоненту ничего кроме примитивных типов передать нельзя.
2. Тут ошибся. Интересно, что в других местах именно loop используется.

Почему именно asm...мне кажется, что так можно лучше прочувствовать "технологии", поскольку используются примитивные конструкции, которые легче воспринимать. Согласен, что код занимает несколько больше места, зато результат того стоит. Опять же, я не призываю поголовно использовать asm, а просто предлагаю его как альтернативу.
24. KAV2 156 28.11.18 10:17 Сейчас в теме
(21) Есть варианты для передачи сложных значений по Native API. Например, последовательный вызов функций для передачи коллекций или JSON\XML.
27. chessman 192 28.11.18 10:40 Сейчас в теме
28. KAV2 156 28.11.18 10:56 Сейчас в теме
(27) Ну например, вам надо передать в компоненту коллекцию значений, скажем список значений. Вы из компоненты вызываете функцию, инициализирующую начало передачи списка, скажем Begin(), далее вызываете функцию, передающую одно значение коллекции за один раз, до тех пор, пока вся коллекция не будет передана и по завершении, вызываете функцию End(), для обозначения завершения коллекции.

С JSON можно сериализовать список значений и передать его строкой, а компонента десериализует.

Тоже самое можно делать и в обратную сторону.
29. chessman 192 28.11.18 11:01 Сейчас в теме
(28) С сериализацией понятно.
А как сделать "передающую одно значение коллекции за один раз", если значение имеет не примитивный тип?
31. KAV2 156 28.11.18 11:12 Сейчас в теме
(29) Используя ту же идею что и для первого уровня, технически это возможно, целесообразно ли, другой вопрос.
32. chessman 192 28.11.18 11:13 Сейчас в теме
(31) Ну, т.е. только через строку.
34. KAV2 156 28.11.18 11:59 Сейчас в теме
30. Darklight 32 28.11.18 11:04 Сейчас в теме
(16) Думаю что данная статья больше годится не для практического написания ВК на чистом ассемблере, а для того, чтобы показать как оно устроено изнутри, для тех случаев, когда кому-то понадобится покопаться, скажем, в уже скомпилированном коде - который, при декомпилировании (и отладке без символьного debug файла), будет представлять поток ассемблерных инструкций. Зачем? Это уже другой вопрос. но, к примеру, вот писал я ВК - а она не подлкючается в 1С - возвращает - ложь при подключении и всё - без каких либо ошибок - хоть ты тресни! Вот и берёшь отладчик - и смотришь, что там по инструкциям не так - а без него - это копаться в исходном коде - и вникать в тонкости соответствия стандартам языка и подключенных библиотек и их ограничений для той или иной платформы. В прочем с отладчиком тоже мороки было бы много. Но что делать когда нет исходных кодов? Есть разные готовые старые компоненты - и они - так же не подключаются к 1С 8.3 сейчас - а если очень надо заставить их заработать - тогда только дизассемблирование и анализ.... Поэтому важно понимать и как COM и как Native компоненты устроены в инструкциях ассемблера! Конечно, это статья не для всех, а только для узкого круга программистов с "особенной" психикой! Обычно это те деды, которые, ранее уже изучали и даже, хоть немного, программировали на ассемблере!
18. spectre1978 61 27.11.18 19:25 Сейчас в теме
Крутяк! Не ожидал ничего подобного увидеть на ИС. Плюс однозначно.
chessman; +1 Ответить
19. PerlAmutor 130 27.11.18 19:27 Сейчас в теме
Мне покоя не дает другая задумка - генерить исходники компоненты с помощью 1С, компилировать на сервере в NativeAPI с помощью другой компоненты/утилиты (компилера) и вызывать все что душе угодно на стороне сервера, на что хватит прав.
22. CheBurator 2696 28.11.18 03:43 Сейчас в теме
Девственниц у меня под рукой (а где же еще?) нет, поэтому молюсь как умею:
BE! BNE!
BR 14!
0C1! 0C4!
//GO SYSIN DD!
DVOL PTOM01!
23. IgorKissil 352 28.11.18 08:58 Сейчас в теме
Благодарю за труд и за напоминание о давно забытом ассемблере. Но имея опыт написания десятков компонент, замучился каждый раз прописывать вручную их реализацию. Повысит ли ваш подход производительность труда прикладного программиста?
Считаю, гораздо перспективней создать паттерн, чтобы разработчик при написании ВК был сконцентрирован на своих задачах, используя готовую библиотеку, вроде https://infostart.ru/public/332786/ (не сочтите за рекламу). Но в упомянутой статье рассматривается пример для .net и com-компонент. Для нативных компонент можно использовать одну из библиотек C++ для reflection, а ассемблеру оставить его специфические задачи.
26. chessman 192 28.11.18 10:37 Сейчас в теме
(23) Игорь, спасибо за комментарий. Цель данного материала была, во-первых, - развеять миф, который, как мне кажется, сложился в среде разработчиков на платформе 1С, что ассемблер это сложно. Во-вторых, убрать все "обёртки" в виде сред разработки и показать, что можно обойтись более простыми инструментами. В-третьих, подать материал, используя примитивные конструкции. Не уверен, что у меня получилось идеально, но думаю, что какой-то туман я рассеял.
То, что касается производительности труда, то я давно (со времён 1С++) использую на практике Com-объект DynamicWrapperX, который позволяет (по крайней мере мне) решать некоторый класс задач, не прибегая к созданию очередной внешней компоненты.
33. starik-2005 3080 28.11.18 11:57 Сейчас в теме
(26)
развеять миф, который, как мне кажется, сложился в среде разработчиков на платформе 1С, что ассемблер это сложно
Миф развеян? Думаю, что нет )))
25. Prometeus2011 214 28.11.18 10:18 Сейчас в теме
Мужик, Респект тебе! Снова вспомнился 98й. Дивный вкус, цвет и запах свободы (не только написания кода). Все пронеслось в голове: юность, SoftIce, почивший в бозе www.wasm.ru, вычисление базы кода через стек, защита от отладки через TLS - обработчики, полиморфное шифрование... Эх... где мои 17 лет.
oninfostart; Йожкин Кот; DoctorRoza; RomanMartynenko; Shrayky2; chessman; +6 Ответить
35. RomanMartynenko 28.11.18 12:25 Сейчас в теме
36. PerlAmutor 130 28.11.18 18:54 Сейчас в теме
(25) Аналогично. От SoftIce до сих пор существуют положительные впечатления из области мощнее и интереснее отладчика в своей жизни я больше нигде не видел. На wasm тоже был зарегистрирован, создавал темы. Пробовал Tasm, Masm, Nasm в итоге остановился на Fasm. Писал резидентные утилиты под MS DOS. А чего только IDA Pro стоит. Особое удовольствие получал используя порты устройств,
для CDROM, FM тюнера, клавиатуры (мигание лампочками), PC Speaker (голос Ленина из PC спикера в компьютерном классе при отсутствии колонок - развлечение для всего класса). До сих пор на полках пылятся книжечки.
Прикрепленные файлы:
37. agafonov_andrei 07.01.19 17:00 Сейчас в теме
(25) Прямо мысли мои прочитал
38. agafonov_andrei 07.01.19 17:04 Сейчас в теме
Спасибо Вам большое за статью! Как раз сейчас есть острая необходимость написать компоненту, но проблема в том, что последнее из чего я писал (не 1С и не T-SQL) под windows был FASM и это было лет 10 назад. Есть огромное желание написать компоненту не на C, а именно на asm’е. По этому с нетерпением жду про NativeAPI.
strek_ivan; chessman; +2 Ответить
39. chessman 192 09.01.19 16:26 Сейчас в теме
(38) Интересно, а что за задачу будете решать?
40. strek_ivan 82 22.02.19 12:24 Сейчас в теме
Продвинутая статья для продвинутых программистов! Автору низкий поклон.

Отличную производительность можно получить используя параллельные вычисления на видеокартах (технология CUDA от nVidia). Для манипуляций данным вычислительным сервером требуется интеграция с клиентом 1С. Почему бы для этих целей не воспользоваться старым добрым COM'ом?!
chessman; +1 Ответить
41. Jimbo 10 12.11.20 16:38 Сейчас в теме
Напуркуа это всё ?
Для вуза учебный пример ?
Практическая ценность в чём ?
Сделать реализовать некий хитрый алгоритм, продублировать на С, сравнить 2 варианта скорости - был бы толк.
42. a0212 05.06.21 20:57 Сейчас в теме
Ассемблер всё же тяжеловат для восприятия.. особенно если сталкивался с ним только в институте )
то же самое только на С есть? )
43. gml 12.07.23 23:59 Сейчас в теме
(42) То же самое на C/C++ - есть в составе ИТС...
Наверное, на Ассемблере можно выжать пару наносекунд на выполнении, создав специально оптимизированный под конкретный процессор (или видео процессор) код.

При сравнении скорости работы написанных на разных языках/инструментах надо также сравнивать и время, затраченное на разработку.

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

PS
Разрабатывать внешние компоненты начал еще в 1980-е годы на ассемблере для СМ ЭВМ (PDP-11), затем на ассемблере для IBM PC, когда начал работать с ORACLE - перешёл на C.
44. user1961929 21.11.23 07:15 Сейчас в теме
А что за обработка "информатор", в сети такой не нашел.
45. KillerMann 182 21.02.24 21:37 Сейчас в теме
Зачетная публикация!
Жаль, что не продолжили свои публикации, особенно интересно было бы реализацию NativeAPI.
Оставьте свое сообщение