Autorun
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Возможно странный запрос, но тем не менее есть различный софт который использует COM dll для, например, интеграции в контекстное меню проводника. Кончено же хотелось бы иметь подобное в портативном виде. В начале я подумал что можно просто делать регистрацию через regsvr32 при запуске тс и разрегистрировать в конце, но это требует админ прав. Нашёл альтернативный regsrv32.exe который делает тоже самое, но под текущим пользователем без прав админа. Однако хотелось бы чтобы расширения были доступны только из контекстного меню вызываемого тс, а не по всей системе. Беглый гугл по запросу "load com dll without registration" говорит что возможно подобную либу подгрузить процессу без регистрации, но моих навыков недостаточно для подобного, вот и вопрос реально ли это?
Autorun загружается в память тотала и перехватывает различные функции, я предположил что находясь в памяти процесса вполне себе можно или хукнуть вызов контекстного меню проводника при пкм, или непосредственно реализовать подгрузку com dll, считайте это запросом на новую фичу у плагина. К тому же "Загрузка dll" одна из заявленных функций плагина.
lz57005
Увы, я тоже не имею существенного опыта работы с COM.
Загружать dll и создавать объекты без регистрации точно можно, например, в Autoit такая возможность есть, хотя и в экспериментальном статусе. Вот только не факт что это поможет. Насколько я понял при беглом ознакомлении с работой расширений, они требуют прописывания в реестре как обработчика. И как правило в HKLM, так что тут без админа все равно не обойтись.
По идее, для тех расширений, которым достаточно ветки HCU, обработчик можно прописать в реестр вручную, зная его CLSID. Т.е. теоретически это можно сделать с помощью простого RegWrite. А при выходе удалить. Это только идея, будет ли такое работать не проверял.
Если же вообще не использовать механизмы оболочки для работы с расширением, то это выглядит... сложновато.
Увы, я тоже не имею существенного опыта работы с COM.
Загружать dll и создавать объекты без регистрации точно можно, например, в Autoit такая возможность есть, хотя и в экспериментальном статусе. Вот только не факт что это поможет. Насколько я понял при беглом ознакомлении с работой расширений, они требуют прописывания в реестре как обработчика. И как правило в HKLM, так что тут без админа все равно не обойтись.
По идее, для тех расширений, которым достаточно ветки HCU, обработчик можно прописать в реестр вручную, зная его CLSID. Т.е. теоретически это можно сделать с помощью простого RegWrite. А при выходе удалить. Это только идея, будет ли такое работать не проверял.
Если же вообще не использовать механизмы оболочки для работы с расширением, то это выглядит... сложновато.
Loopback
Подскажите, решил использовать плагин не как псевдо-wdx, а как обычную dll через патч таблицы импорта totalcmd.exe, понимаю что кроме меня вряд ли подобным многие маются, но тем не менее так я не завишу от цветовых схем и можно успеть изменить wincmd.ini до того как программа его прочтёт.
Если запуск autorun я пофиксил самописной prepare.dll которая назначает переменные среды COMANDER_PATH etc (т.к. процесс этого не успевает и autorun.cfg где эти переменные естественно фигурируют функционирует не корректно). Но я не знаю что сделать с директивой
Pragma AutorunFinalizeSection
я думал она выполняется в момент выгрузки плагина как обычной dll, на условное событие OnProcessDetach, но как я понял - есть отдельное событие именно выгрузки как плагина которое не происходит в моём случаем и секция конфига не выполняется.
Соответственно просьба/вопрос
Можно ли продублировать действие в момент OnProcessDetach (что-то типо если PluginUnload не выполнялась, то выполнить сейчас) или добавить директиву Pragma AutorunUnload? Или как мне самому можно это пофиксить самописной dll которая будет провоцировать выполнение AutorunFinalizeSection при выгрузке?
Подскажите, решил использовать плагин не как псевдо-wdx, а как обычную dll через патч таблицы импорта totalcmd.exe, понимаю что кроме меня вряд ли подобным многие маются, но тем не менее так я не завишу от цветовых схем и можно успеть изменить wincmd.ini до того как программа его прочтёт.
Если запуск autorun я пофиксил самописной prepare.dll которая назначает переменные среды COMANDER_PATH etc (т.к. процесс этого не успевает и autorun.cfg где эти переменные естественно фигурируют функционирует не корректно). Но я не знаю что сделать с директивой
Pragma AutorunFinalizeSection
я думал она выполняется в момент выгрузки плагина как обычной dll, на условное событие OnProcessDetach, но как я понял - есть отдельное событие именно выгрузки как плагина которое не происходит в моём случаем и секция конфига не выполняется.
Соответственно просьба/вопрос
Можно ли продублировать действие в момент OnProcessDetach (что-то типо если PluginUnload не выполнялась, то выполнить сейчас) или добавить директиву Pragma AutorunUnload? Или как мне самому можно это пофиксить самописной dll которая будет провоцировать выполнение AutorunFinalizeSection при выгрузке?
И как тотал реагирует на такую модификацию? В нем же вроде защита присутствует.lz57005 писал(а):через патч таблицы импорта totalcmd.exe
Так и есть, остановка по DLL_PROCESS_DETACH, по крайней мере в последних версиях. Пробовал когда-то делать выгрузку в ContentPluginUnloading, но кажется там были какие-то проблемы, в итоге вернулся к этому методу.lz57005 писал(а):я думал она выполняется в момент выгрузки плагина как обычной dll, на условное событие OnProcessDetach
Конечно присутствует, но на что не пойдёшь ради экспериментовLoopback писал(а):И как тотал реагирует на такую модификацию? В нем же вроде защита присутствует.
Тогда что-то не так, плагин 2.2.10, конфиг условно:Loopback писал(а):Так и есть, остановка по DLL_PROCESS_DETACH, по крайней мере в последних версиях. Пробовал когда-то делать выгрузку в ContentPluginUnloading, но кажется там были какие-то проблемы, в итоге вернулся к этому методу.
LoadLibrary Plugins\Run\Prepare.dll
...
MsgBox "OnStart"
Pragma AutorunFinalizeSection
ShellExec "%COMMANDER_PATH%\Core\CloseTest.cmd"
MsgBox "OnClose"
в prepare.dll на DLL_PROCESS_DETACH свой вывод MessageBox
в CloseTest.cmd - echo в файл
при закрытии тотала, отрабатывает только MessageBox из prepare.dll.
а если использовать как обычно через wdx то всё ок.
запуск CloseTest.cmd,
Сообщение OnClose,
а потом сообщение от prepare.dll о выгрузке,
вот я и подумал что используется некий ContentPluginUnloading.
Это Autorun выгружает библиотеку prepare.dll. И раз он её выгружает, значит секция финализации к тому времени уже отработала, выгрузка библиотек идёт в последнюю очередь.lz57005 писал(а):при закрытии тотала, отрабатывает только MessageBox из prepare.dll.
Почему конкретно в данном случае не выполняется то что в секции - не могу сказать.
Orion9
Чтобы поменять переменную, нужно её менять в адресном пространстве тотала. Проще всего с помощью самого Autorun и TCFS2. Модифицированный пример из справки:
TCFS2.exe /ef "msg(regmsg(MyMessage), 0, 0)"
Чтобы поменять переменную, нужно её менять в адресном пространстве тотала. Проще всего с помощью самого Autorun и TCFS2. Модифицированный пример из справки:
И вызываем функцию с помощью запуска TCFS2 с командой:LoadLibrary Plugins\Autorun_Tweaks.dll
# Функция, которая будет выполнена при получении сообщения
Func MyMessageFunc()
SetEnv ENV_NAME "Новый текст переменной"
EndFunc
# Привязываем функцию к сообщению, регистрируемому строкой "MyMessage"
SetMessageAction "MyMessage" MyMessageFunc
TCFS2.exe /ef "msg(regmsg(MyMessage), 0, 0)"
Классный плуг вы сделали, очень продвинутый. Еще раз спасибо! Orion9
Регистрация практически такая же, нужно только добавить переключатель /P, чтобы в дополнение к пользовательским параметрам команды (если они есть) добавлялись стандартные 4 параметра сообщения. Их формальные имена в функции могут быть произвольными, те что в примере просто соответствуют принятым в Winapi. Из них wParam и lParam могут задаваться пользователем при отправке сообщения. Могут быть только числами.
Вот простой пример, аналогичный тому что выше:
Теперь можно выполнить TCFS2 с командой, в которой передаем 1 или 2 в качестве параметра сообщения, в зависимости от них будут выполняться разные действия:
TCFS2.exe /ef "msg(regmsg(MyMessage), 1, 0)"
TCFS2.exe /ef "msg(regmsg(MyMessage), 2, 0)"
Регистрация практически такая же, нужно только добавить переключатель /P, чтобы в дополнение к пользовательским параметрам команды (если они есть) добавлялись стандартные 4 параметра сообщения. Их формальные имена в функции могут быть произвольными, те что в примере просто соответствуют принятым в Winapi. Из них wParam и lParam могут задаваться пользователем при отправке сообщения. Могут быть только числами.
Вот простой пример, аналогичный тому что выше:
Код: Выделить всё
LoadLibrary Plugins\Autorun_Tweaks.dll
# Функция, которая будет выполнена при получении сообщения
Func MyMessageFunc(hWnd, uMsg, wParam, lParam)
Local text
Switch wParam
Case 1
text = "Первый вариант"
Case 2
text = "Второй вариант"
EndSwitch
SetEnv ENV_NAME %text%
EndFunc
# Привязываем функцию к сообщению, регистрируемому строкой "MyMessage", переключатель /P подразумевает, что функция MyMessageFunc должна иметь минимум четыре параметра.
SetMessageAction /P "MyMessage" MyMessageFunc
TCFS2.exe /ef "msg(regmsg(MyMessage), 1, 0)"
TCFS2.exe /ef "msg(regmsg(MyMessage), 2, 0)"
Loopback
В плагине SysInfo есть функция GetWMIValue, которая считывает значение параметра WMI-класса в переменную.
А как считать несколько параметров в одном запросе? Сейчас такой возможности нет?
В плагине SysInfo есть функция GetWMIValue, которая считывает значение параметра WMI-класса в переменную.
Код: Выделить всё
GetWMIValue VAR "Name" "SELECT * FROM Win32_Processor"