Software patches |
Добро пожаловать, гость ( Вход | Регистрация )
Software patches |
-=CHE@TER=- |
Oct 23 2010, 16:18
Сообщение
#1
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
ACDSee 5.0.0.0025 PowerPack (2002)
Disable database and Windows 7 compatability patch Отключение IDBSvr.exe и БД изображений Пользуюсь с незапамятных времён этой версией ACDSee. Тут нет огромного количества ненужных свистопыхтелок (или по крайней мере большую часть из них можно отключить или скрыть) которые наводнили другие версии этой программы. Зато всё остальное представлено в полном объёме. Единственная проблема, которую не удалось отключить штатными средствами - это опухание БД с изображениями. Дело в том что ACDSee для быстроты работы делает превью изображений и сохраняет их в свою БД. Последняя, в свою очередь, со временем пухнет всё больше и больше что мне на системном диске как бы нафиг не надо. Ещё, как выяснилось, программа не дружит с многоядерными процессорами и разваливается на них. И, наконец, при попытке открыть каталог содержащий .LNK или .URL файл с длинным адресом программа сразу падает. В общем решение всех проблем такое: 1) Отучаем ACDSee запускать свою БД. Для этого меняем в файле: C:\Program Files\ACD Systems\ACDSee\5.0\ACDSee5.exe ; uni-processor patch ; запускать только на 1 ядре 00000167: 01 -> 41 ; disable IDBSvr database service ; отключаем сервис базы данных изображений 000175D5: 86 -> AE 000175F2: 86 -> AE 0001760E: 29 -> 00 0001761B: 74 -> EB 0001761C: 08 -> 1B 0001B7E7: E8 -> B8 0001B7E8: 74 -> 00 0001B7E9: 8A -> 00 ; fix long URL crash - disable .LNK/.URL handling ; исправляем падение при длинных URL - отключаем их обработку 001E94E4: 2E -> 00 001EA254: 2E -> 00 2) Удаляем всё из каталога: C:\Documents and Settings\%USERNAME%\Application Data\ACD Systems\ После всего этого ACDSee даже быстрее стартует (на глаз), т.к. нет необходимости дожидаться загрузки "IDBSvr.exe", её .DLL, БД и прочего мусора. |
-=CHE@TER=- |
Nov 17 2013, 11:03
Сообщение
#2
|
Walter Sullivan Группа: Root Admin Сообщений: 1,361 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 314 раз(а) |
Многие знают, что ещё со времён MS-DOS есть такая утилита как EXPAND.EXE, которая распаковывает установочные файлы "FILENAME.EX_" во что-нибудь типа "FILENAME.EXT". Упаковка осуществляется программой COMPRESS.EXE. У меня была эта программа, но для DOS. Понадобился этот упаковщик и решил скачать версию для Windows, чтобы работала нормально под любым Windows (в том числе и x64, где DOS не эмулируется никак).
Программа COMPRESS.EXE любезно предоставленна фирмой Microsoft и входит в комплект Windows Server 2003 Resource Kit Tools. Однако, выяснилось, что упакованные ей файлы не хотят распаковываться через EXPAND.EXE. Офигев от такой нагласти упаковал тот же файл DOS-версией программы (её архивы успешно распаковывались) и сравнил результат. Оба файла оказались идентичны, за исключением поля отвечающего за размер распакованного файла. В оригинале файл занимал 2990 байт (0BAEh). В нормальном архиве так и было записано: AE 0B 00 00 В ненормально же было так: 01 AE 0B 00 Возникает резонный вопрос: WTF??? Полез в отладчик и нашёл такой удивительный код: CODE .text:010018F8 mov al, [ecx+0Ah]; put last extension char to al (null) .text:010018FB mov [ebp-0Bh], al; put char to header buffer ;------------- .text:010018FE inc al ; where the WTF??? started - increment last char .text:01001900 mov [ebp-0Ah], al; put as first byte for unpacked buffer in header .text:01001903 mov eax, [ecx+0Ch] ; move actual unpacked size to eax ;------------- .text:01001906 xor esi, esi .text:01001908 xor edi, edi .text:0100190A @loc_100190A: ; put unpacked size to the header buffer .text:0100190A mov ecx, edi ; why so difficult? .text:0100190C mov edx, eax ; by the way - this code NOT SAFE! .text:0100190E shr edx, cl ; because it writes 4 bytes to buffer .text:01001910 add edi, 8 ; but we already use one (see above) .text:01001913 inc esi ; so the last byte makes BUFFER OVERFLOW! .text:01001914 cmp edi, 20h .text:01001917 mov [ebp+esi-0Ah], dl; here we can fix this error: -0Ah to -0Bh .text:0100191B jl short loc_100190A Мало того, что в выходной буфер за каким-то чёртом пишется последний символ расширения файла увеличенный на единицу, так туда же ещё и пытается записаться размер (4 байта), причём после этого самого непонятного байта, что приводит к переполнению буфера! Как видно из комментариев выше, сиё безобразие несложно поправить исправлением всего 1 байта. compress.exe 00000D1A: F6 -> F5 ; version info: ; 39936 bytes ; 2003.04.18 17:46:26 ; 5.2.3790.0 built by: dnsrv_dev(v-smgum) Так как esi при первом шаге цикла уже 1 (inc esi), то нужно как-то это компенсировать, вот и отнимаем больше на 1: вместо -0Ah используем -0Bh (см. комментарии выше). Что, в итоге, позволяет нам не только избежать переполнения буфера, а также записать размер правильно, но и перезаписать тот непонятный байт. В общем, после сего исправления эту утилиту, наконец-то, можно использовать. Спасибо сказали:
|
Упрощённая версия | Сейчас: 26th December 2024 - 19:16 |