Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
mex3
Смотрел, но идея с переделкой в голову не пришла, вернее отмёл почему и сам не понимаю. Спасибо за подсказку! Называется "в трёх соснах запутался". Согласись, с любым такое бывает.
И уж, коли мы с тобой говорим - твои плагины MBlokEditor, RegEdit, враппер - работают и в 2237 без вопросов, MBlok просто пересобирается с новыми хидерами, нет проблемы, RegEdit и враппер не удаётся собрать в 2010 студии - для первого части исходников не хватает, а второй ты же под 9-ю сделал, и в 11-й батник только лоадера формирует, саму библиотек студия собирает, но её работа мне не нравится. А третий - EditWrap вообще не собрать - исходники его только у тебя ведь есть. Может соберёшь его с новыми хидерами? Да и регедит с враппером не помешали бы - не удаётся мне поставить на машину и 9-ю и 11 студии - уже и места нет на винтах, и 11-я стоит, а на 7-ку стендовую дистрибутив что есть у ребят (у них беру с лицензией на их контору благо по их словам её сейчас они не используют) вставать не хочет не понятно по чему - просто виснет установка молча после запуска setup и всё, процесс не отвечает хоть как с ним воюй - приостанавливай, перезапускай - бесполезно. Говорят что диск покупной и похоже по виду, что от Билли, ну да ладно, 2010 работает, а 9-й компиллер в 7.0А SDK есть. Под не я твои батники и правил, но не всё выходит. 11 нужен сейчас чаще - основные вещи, что приходится собирать под него уже подстроены. Просил их пишите под 9-й или GCC с ними нет проблем, а они а нам в 2010 удобнее... Черти полосатые, лентяи записные. Кстати, чуть позже скину и новый Process Hacker 2.23.4746 в его тему - он сейчас здорово выручает и помог ряд "особенностей" поведения Far 3 отследить, и заодно с ними бороться:
1) не понятно для какого лешего запускается Observer 1.85 с модулем Vdisk - эта парочка лочит любой файл если его попытаешься как архив поглядеть - РН показывает что они в ОЗУ и Far держит хендл файла с правом "чтение";
2) MultiArc не освобождает хендл после открытия файла на чтение;
3) твой плагин PictureView 2 mod 26 создаёт в %TMP% файлы-времянки вида pic*.tmp, хендлы так же на чтение, после закрытия плагина не освобождаются;
4) Так же по хендлам на чтение лочит фалы и ImpEx.
5) При выходе из far, если плагин не закрыл хендлы, процесс far завершается бесконечно, и тут либо крестик в окошке жать, либо ему сигнал killprocess посылать - сиё по выбору и настроению решаем.
Это те кого я уверенно на этом занятии отследил, остальные вроде за сим "грехом" пока не отметились.
Способов борьбы два:
1) UNLOCKER - успешность с первого раза 60% - 70%, в остальных случаях говорит мол не найден дескриптор давайте после ребута удалю - дело ясное, способ кривой как и перезапуск far ради чистки мусора;
2) вызвать РН, по PID посмотреть хендлы, найти в списке нужные и грохнуть их хоть кучей по Del - (новый РН это уже умеет) - этим пользуюсь сейчас чаще всего, и делай с файлами/каталогами что тебе надо;
Вот и подумалось - а может стоит враппером после завершения вызова плагина принудительно закрывать открытые им хендлы? Ведь частенько именно монопольно открытые плагином хендлы мешаются под ногами, и если их после завершения плагина закрыть, то как мне кажется при отсутствии к ним обращений от иных модулей никто вроде не должен пострадать, а проблему блокировки объектов мы решим. Понятно, что это не столько к тебе просьба, сколько к авторам плагинов - они забыли закрыть эти хендлы, но мне кажется, что не все из них свои плагины доработают, и в такой ситуации враппер с таким механизмом контроля станет дополнительным средством предотвращения ошибок, но именно дополнительным, а не основным. Основным всё же должен быть плагин, как бы его автору не хотелось упростить себе задачу. За такие фокусы - открытые и не освобождённые после завершения программы DCB/JCB/MCB когда я ещё на OS/360 писал наше начальство виновников прогрессивки и надбавок на год лишало. А это было от 40% до 100% оклада. Сам понимаешь, действовало безотказно - боялись попасть за это под раздачу больше, чем чёрт ладана. Ведь в конечном итоге эта ошибка приводит к утечке памяти вне зависимости от её расположения в иерархии системы памяти ЭВМ. Ведь согласись, что не суть важно где будет располагаться не занятая, но заблокированная область памяти - на внешней памяти или в ОЗУ, но для пользователя важно только то, что в неё нельзя поместить данные, и она до своего освобождения исключена из работы установки, что приводит к увеличению срока получения им решения, а значит стоимости решения его конкретной задачи. Ведь как мы не думай и не говори, но понятие "стоимость часа машинного времени ЭВМ" никто пока не отменял, и эту стоимость всегда приходится учитывать какой бы величины она не была.
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Или нужно дорабатывать как баг.
) проверить почему в Advanced Compare 2 build 034 не вызывается Visual Compare по F2 на паре файлов. Вроде код его вызова есть, но он действительно не срабатывает - я специально в РН смотрел и не обнаружил там запуска этой DLL после нажатия F2. Может ей чего-то не хватает? Например макроса вызова?
