Загрузка плагинов в адресное пространство 1С перенаправлением DLL
Читаем у Дж.Рихтера ("Windows для профессионалов", глава 20):
Перенаправление DLL
Windows 98 не поддерживает перенаправление DLL.
Когда разрабатывались первые версии Windows, оперативная намять и дисковое пространство были крайне дефицитным ресурсом, так что Windows была рассчитана на предельно экономное их использование — с максимальным разделением между потребителями. В связи с этим Microsoft рекомендовала размещать все модули, используемые многими приложениями (например, библиотеку С/С++ и DLL, относящиеся к MFC) в системном каталоге Windows, где их можно было легко найти.
Однако со временем это вылилось в серьезную проблему: программы установки приложений то и дело перезаписывали новые системные файлы старыми или не полностью совместимыми. Из-за этого уже установленные приложения переставали работать. Но сегодня жесткие диски стали очень емкими и недорогими, оперативная память тоже значительно подешевела. Поэтому Microsoft сменила свою позицию на прямо противоположную; теперь она настоятельно рекомендует размещать все файлы приложения в своем каталоге и ничего не трогать в системном каталоге Windows. Тогда Ваше приложение не нарушит работу других программ, и наоборот.
С той же целью Microsoft ввела в Windows 2000 поддержку перенаправления DLL (DLL redirection). Она заставляет загрузчик операционной системы загружав модули сначала из каталога Вашего приложения и, только если их там нет, искать в других каталогах.
Чтобы загрузчик всегда проверял сначала каталог приложения, нужно всего лишь поместить туда специальный файл. Его содержимое не имеет значения и игнорируется — важно только его имя: оно должно быть в виде AppName.local. Так, если исполняемый файл Вашего приложения — SuperApp.exe, присвойте перенаправляющему файлу имя SuperApp.exe.local.
Функция LoadLibrary(Ex) проверяет наличие этого файла и, если он есть, загружает молуль из каталога приложения; в ином случае LoadLibrary(Ex) работает так же, как и раньше.
Перенаправление DLL исключительно полезно для работы с зарегистрированными СОМ-объектами. Оно позволяет приложению размещать DLL с СОМ-объектами в своем каталоге, и другие программы, регистрирующие те же объекты, не будут мешать его нормальной работе.
В случае 1С этим трюком можно воспользоваться следующим образом.
Помещаем в папку BIN пустой файл
1cv8.exe.local - для версии 8
1cv7s.exe.local - для версии 7
Я создал библиотеку shell32.dll, которая содержит две функции, ShellExecuteA и ShellExecuteW (запуск приложения), экспортированные из оригинальной DLL. Именно эту DLL я выбрал по той причине, что там 1С задействует меньше всего функций.
Если положить ее в папку BIN, то вызываться будет именно она - в свою очередь, она может обратиться к оригинальной DLL, используя системный вызов GetSystemDirectory() и динамическую загрузку оригинальной DLL через LoadLibrary и GetProcAddress.
Чтобы дать пользователю возможность загружать неограниченное число других плагинов в адресное пространство 1С, я использую файл ini, в котором перечисляю DLL, подлежащие загрузке.
[Загрузка]
;(знак ; начинает комментарий до конца строки).
LoadDll=Plugin_Unload_Dat_Fix\plugin_Unload_Dat_Fix.dll
LoadDll=Plugin_VkLoader\plugin_VkLoader.dll
Пути к файлам - относительно папки Bin\Plugins, то есть, например,
Bin\Plugins\Plugin_VkLoader\plugin_VkLoader.dll
Имя каталога с плагинами - Plugins (должен располагаться внутри папки Bin).
Имя ini-файла - Hook_1C.ini (он располагается внутри папки bin\Plugins).
Предлагаю, если не будет возражений, пользоваться этой схемой загрузки всем желающим.
Цель ini-файла - возможность произвольно отключать (не выгоняя пользователей из 1С) загрузку тех или иных плагинов, а также возможность загружать их в требуемом (указанном) порядке.
Пользователи Windows 98 могут воспользоваться этим же загрузчиком, но потребуется исправить название DLL (например, на Shell33.dll) и соответственно изменить эту подстроку в бинарных файлах 1С каким-нибудь двоичным редактором, таким как BIEW. |