.
Предисловие
Для тех, кому лень или некогда много читать, основные тезисы:
- Я сделал модуль, который вносит в VB поддержку указателей на функции и вызова функций через эти указатели.
- Модуль поддерживает VB6, VB5, компиляцию в Native-код, компиляцию в P-код и работу под IDE без каких-либо ограничений, не нуждается в дополнительных библиотеках, в установке Add-in'ов для VB, не использует ассемблерных вставок и тому подобного. В VBA (в Office) тоже должен сработать.
- Модуль оформлен как «кирпич». Хотите скачать модуль — идите по этой ссылке.
- В той теме — сухое описание, самая последняя версия, обсуждения строго по теме, сообщения об обнаруженных багах.
- В этой теме — обсуждение самой идеи, рассуждения на тему, впечатления, мнения.
Вступление
Что такое указатель на функцию?
Физически — это ячейка памяти, в которой хранится адрес какой-то функции.
Семантически — это особая переменная, используя которую можно сделать вызов любой нужной функции. Кроме того, с такой переменной связана контрольная информация о функции: количество и тип всех её параметров и тип возврата. Так что язык/средство разработки проконтролирует, чтобы функцию вызывали всегда именно так, как она сама того ожидает.
Так уж сложилось, что (из соображений безопасности) в VB указателей на функции (во втором смысле) нет.
Вот в Си, например, указатели на функцию есть:
- Код: Выделить всё
int (*func_ptr_1)(char a, long b); // Мы объявили указатель на функцию, принимающую 2 параметра и возвращающую int
...
x = func_ptr_1(4, 5); // Мы вызвали функцию по указателю на неё
Си не даст нам вызвать функцию по указателю, передав три параметра вместо двух или один. Си проконтролирует правильность типов. Задача была сделать в VB6 что-то такое же лёгкое в использовании и синтаксически дружественное.
Замысел
Дело в том, что в VB нет указателей на функции именно во втором смысле. В первом смысле указатели на функции для вызова каких-то функций используются в трёх случаях:
- Для вызова методов классов при раннем связывании.
- Для вызова модульных процедур, объявленных в TLB, располагающихся сторонних библиотеках.
- Для вызова процедур, объявленных через Declare Sub/Function.
Привязаться к первому нельзя: имеет место быть неявная передача первым параметром ссылки на Me (This).
Привязаться ко второму нельзя: адреса импортируемых функций кешируются в регистрах, так что перезапись IAT не даст эффект сразу же.
А вот к третьему... Никаких преград.
Вы объявляете:
- Код: Выделить всё
Declare Sub Foo Lib "xxx" ()
И со стандартной точки зрения — это объявление процедуры Foo из библиотеки xxx, а мы сделаем так, что при особом (волшебном!) значении Lib это будет считаться не функцией из библиотеки, а переменной-указателем. И можно будет присвоить переменной-указателю Foo любое значение и сделать вызов.
Набросочно, так:
- Код: Выделить всё
Foo = 123123
Foo()
Foo = 7798987
Foo()
Немного истории
- Впервые эта идея пришла мне в голову, судя по всему, 06 ноября 2008 года — вот здесь (там же она была впервые описана). Был начат писаться модуль, было написано некоторое количество кода, а затем это дело было заброшено.
- Второй раз об идее я вспомнил и более подробно написал о ней чуть больше года назад — в начале февраля 2010. Тогда же был дописан модуль, вызовы по указателям работали, но только в скомпилированном файле. На тот момент решения проблемы, не дающей использовать указатели в IDE, приемлемого я не видел. Модуль был заброшен ещё на год. Если прочитать ту тему полностью, можно найти уже там много подробностей, которые будут далее изложены здесь.
- Недавно я вспомнил о своей давней задумке и стал писать модуль — с нуля. И в процессе понял, что забыл многие аспекты внутреннего устройства «момента». Но вспомнил, что где-то на форуме я вдавался в какие-то подробности, и стал искать их. И наткнулся на код, который по стилю был похож на мой собственный, но при этом я абсолютно не помнил о том, что писал такой код. Как оказалось, модуль, который я честно собирался написать с нуля, уже был на 90 процентов написан, а я об его существовании просто забыл.
Техника
VB(A) устроен так:
Для всех существующих в проекте Declare-функций имеется одна таблица, в которой хранятся адреса вызываемых функций. Это можно назвать таблицей отложенного импорта, но эта таблица отложенного импорта не имеет ничего общего с той таблицей отложенного импорта, которую определяет PE-формат. Это VB-специфичная таблица, и для каждой Declare-функции имеется ячейка, которая хранит адрес соответствующей Declare-функции.
Изначально эта таблица вся заполнена нулями.
Как только какая-либо из Declare-функций вызывается в первый раз, в её ячейке содержится 0, что означает, что адрес функции ещё не известен. При этом (в первый раз) вызывается DllFunctionCall.
DllFunctionCall определяет адрес вызываемой сейчас функции и заносит его в таблицу.
DllFunctionCall (несмотря на название) не вызывает функцию. На самом деле её название не CallDllFunction (вызвать Dll-функцию), а DllFunctionCall (вызов Dll-функции). То есть она просто обрабатывает вызов, причём только самый первый.
Последующие вызовы некоторой Declare-функции берут адрес прямо из таблицы и делают переход по нему. Никакие посторонние функции, кроме самой вызываемой функции, не вызываются. Вызов получается достаточно быстрым.
Алгоритм действия при вызовах Declare-функций следующий:
Здесь нужно сделать два важных вывода:
- Перехватывая вызов DllFunctionCall, можно полностью контролировать процесс преобразования пар {функция;библиотека} в адреса. Например, можно пакостить: когда программист вызывает MessageBox из user32, возвращать адрес ExitProcess из kernel32. То есть мы имеем возможность сделать так, чтобы вместо той функции, которую вызывают, выполнилась любая, какая нам хочется.
- Для каждой Declare-функции существует физическая переменная-указатель, хранящая адрес, по которому совершается вызов. Теоретически можно править этот адрес, и вызовы, совершённые после правки, пойдут по новому адресу. Но мы не имеем хорошего интерфейса доступа к этой переменной, не можем напрямую читать и писать в неё нужное нам значение-адрес.
И вывести следствия:
- Итак, раз DllFunctionCall занимается выяснением адреса функции по имени библиотеки и имени/ординалу функции, совершенно очевидно, что ей (DllFunctionCall) передаётся эта информация (имя библиотеки, имя/ординал функции).
- DllFunctionCall также записывает в таблицу вместо нуля адрес найденной функции. Значит она не только знает имя функции, которую сейчас вызывают, но и знает, где расположена ячейка таблицы (она же физическая переменная-указатель) для данной функции.
А значит, для нужных нам Declare-функций мы можем как «подставить» какой-то свой произвольный адрес, подменив DllFunctionCall на свою функцию функцию-аналог, так и узнать, где располагаются ячейки, хранящие адреса, для нужных нам функций. А узнав местоположение ячеек, мы фактически владеем настоящими указателями на функции: синтаксический контроль есть, возможность менять значени указателя есть, возможность делать вызов по этому адресу — есть.
Остаётся только отделить Declare-функции, используемые как указатели на функции, от Declare-функций, используемых по прямому назначению.
Сделать это довольно легко: достаточно для Declare-функций, играющих роль указателей, в качестве библиотеки указывать такую строчку, которая заведомо не может являться именем файла библиотеки.
Например:
- Код: Выделить всё
Declare Sub Example1 Lib ":::" ()
Declare Sub Example2 Lib "***" ()
Declare Sub Example3 Lib "???" ()
Совершенно точно, что в имени файла библиотеки этих символов быть не может. Значит мы имеем возможность принять особое волшебное значение «параметра» Lib, которое бы говорило нашему заменителю DllFunctionCall, что это не Declare-функция в истинном виде, а наш волшебный указатель, и обрабатывать его нужно по-особенному, а не отдавать дело в руки оригинальной DllFunctionCall.
Я в качестве волшебного признака (имя библиотеки) взял одинарную звёздочку — просто и со вкусом.
Вот так выглядит алгоритм действий при первом вызове Declare-функций после включения волшебных указателей:
Предположим, у нас есть следующая Declare-функция:
- Код: Выделить всё
Declare Function MagicPointer1 Lib "*" (ByVal x As Long, ByRef Y as string) as Integer
И совершается вызов функции. Поскольку это первый вызов, ячейка таблицы адресов содержит ноль. Раньше выполнение перешло сразу в DllFunctionCall, но теперь оно переходит в нашу функцию-перехватчик. Наша функция перехватчик получается всю необходимую информацию: в частности, что вызываемая функция имеет имя «MagicPointer1», а имя библиотеки — «*». Наша функция-перехватчик понимает, что библиотеки с таким именем быть не может, что это специальный маркер, и делает следующее: пытается в своём массиве (коллекции, словаре) найти адрес, соответствующий указателю с именем «MagicPointer1». Если это удаётся, этот адрес записывается в таблицу адресов и возвращается. Вызов идёт по этому адресу. Все довольны.
Что будет, когда будет сделан второй (третий, четвёртый, и так далее) вызов MagicPointer1? В этот раз в ячейке не будет нуля. В ячейке будет адрес, поставленный туда в прошлый раз нашей функцией-перехватчиком. И именно по этому адресу сразу же устремится выполнение.
Но что, если нам нужно поменять значение нашего указателя? Ведь перехватчик никогда больше не будет вызван (потому что в таблице в ячейке не ноль), а значит у него не будет шанса заменить теперь уже старое значение в таблице на новое значение указателя?
Решается это очень просто: из тех соображений, что перехватчик больше не будет вызын для этой функции, он добавляет в другой свой массив (коллекцию, словарь) имя переменной-указателя и сопоставляет ему адрес ячейки таблицы адресов. Теперь, когда нам нужно изменить значение указателя MagicPointer1, мы знаем, куда напрямую нужно писать новый адрес.
Поэтому я делаю все указатели на две группы:
- Undiscovered — те, для которых первого вызова ещё не состоялось, а значит адрес ячейки с адресом для данного указателя ещё не известен. Для этих указателей хранится сопоставление ИмяУказателя --> ЗначениеУказателя.
- Discovered — те, для которых первый вызов уже состоялся, и поэтому адрес ячейки таблицы адресов известен. Для этих указателей не хранятся их значения, а хранятся адреса соответствующих ячеек таблицы адресов, в которых наконец и хранятся сами значения этих указателей.
Как только происходит самый первый вызов какого-либо очередного указателя, если функция-перехватчик находит имя текущего указателя в наборе Undiscovered, она переносит этот указатель в набор Discovered. В противном случае генерируется ошибка: «Specified pointer is not set.», которую программист может отработать. Если же функция-перехватчик вызывается, а текущий указатель уже находится в категории Discovered, значит указатель был обнулён после первичного вызова. В этом случае генерируется ошибка «Null pointer call». Именно так: мой модуль вынужденно не даёт вам «выстрелить себе в ногу», вызвав код по адресу 0.
Отключение же магических указателей ещё более простое: нужно снять перехват функции DllFunctionCall, пройтись по набору Discovered-указателей и занулить их ячейки таблицы адресов. Тогда последующие обращения к ним пойдут в стандартную DllFunctionCall, которая честно заявит: «File not found: *».
Технические проблемы
Методика порождения указателей на функции одинакова как для скомпилированных файлов, так и для проекта, работающего под IDE. Поэтому включение и выключение указателей на функции выполняется одинаково — перехватом DllFunctionCall.
Однако в отличие от скомпилированного файла, перехват DllFunctionCall в среде разработке (IDE) оказывается достаточно сложной задачей. В скомпилированном файле для модуле-локального перехвата DllFunctionCall достаточно заменить значение ячейки IAT этого самого модуля. Все обращения к DllFunctionCall из этого модуля пойдут по новому направлению, а вызовы из других модулей останутся незатронутыми. В случае работы проекта под IDE, никакой IAT с ячейкой, которую можно было бы перезаписать, просто нет. При работе под IDE используется DllFunctionCall из vbaX.dll. Эта функция экспортируется, но вызов DllFunctionCall идёт из самой vbaX.dll, так что это внутримодульный вызов. Для каждой Declare-функции по одному шаблону создаётся свой динамически генерируемый кусочек Native-кода, в который адрес DllFunctionCall прошит жесткой константой. Так что единственной возможностью проект-локального перехвата DllFunctionCall является поиск всех динамически сгенерированных кусочков кода и перезапись адреса DllFunctionCall прямо в этих кусочках на свой адрес. Для этого используются функции из vbaX.dll, с помощью которых можно получить множество информации и загруженных в IDE проектах. В том числе и адреса динамически сгенерированных кусочков-переходничков для Declare-функций.
Конкретную реализацию можно посмотреть в коде.
Итоги
- Мы имеем модуль, превращающий Declare-функции в функции-указатели со множеством достоинств.
- Указатели на функции требуют указания прототипа вызываемой функции, что повышает контроль за правильностью кода.
- Модуль генерирует ошибки при попытках использования Null-указателя, а не допускает Access violation.
- У каждого проекта своё изолированное пространство указателей. Одноимённые указатели в двух (и более) одновременно работающих (в рамках одного процесса) VB-проектах не мешают друг другу и никак не влияют друг на друга.
- Модуль работает как в VB6, так и в VB5, и должен заработать в VBA-приложениях (пока не проверялось за неимением оных).
- Модуль автономен: не нужны доп. библиотеки, не нужна модификация среды, нет пугающих многих ассемблерных вставок.
- В отличие от многих подобных трюков: работает без малейших ограничений в IDE и в файлах, скомпилированных в псевдокод.
- Вызов (не первый) по такому указателю очень быстр: единственный накладной ресурс, по сравнению с вызовом по указателю, например, в Си — проверка указателя на равенство нулю.
- Не выключенная поддержка указатель не фатальна (как, например, неснятый сабклассинг).
- Возможно объявить множество различных прототипов для одного указателя:
- Код: Выделить всё
Declare Function FooAsAny Lib "*" Alias "Foo" (x as any) as long
Declare Function FooAsLong lib "*" Alias "Foo" (ByVal x As Long) As Long
Declare Function FooWithoutParams Lib "*" Alias "Foo" () As Long ' Даже так
- Указатели могут быть объявлены как публичные и как приватные. В модулях, в классах, формах — где угодно, так же, как это действует для простого Declare.
Недостатки:
- Свойственная Declare конвертация Unicode->Asciiz и обратно. Легко борется As Long или As Any параметрами.
Благодарности
- iGrok-у — за удалённую отладку модуля на VB5 (которого у меня нет) и моральную поддержку,
- arthur-у 2 — за напоминание год назад о забытом три года назад модуле
