Software patches Опции

[-=CHE@TER=-]

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=-]

Переименовал тему.

FlashGet 1.73 Build 128 (2006)
Устранение подвисания после завершения загрузки файла.

Эта последняя "классическая версия" FlashGet (между прочим до сих пор доступная на официальном сайте), которая ещё не поддерживала Torrent и eMule протоколы, а также другие свистопыхтелки и от того не падала с фатальными ошибками при закачке.
Единственная замеченная проблема - почему-то по окончании загрузки файла программа подвисает на минуту и впадает в ступор (странно, что это не происходит, если открыть какое-нибудь окно внутри - например "О программе"). Иногда из него так и не выходит. При закачке, скажем, музыкального альбома с 10 и более композициями отдельными файлами это удовольствие растягивается на непонятно сколько времени, когда должно было закончиться минут за 5 от силы.
Отутюжив вчера программу Олькой нашёл из-за чего такая херня:

WaitForSingleObject(Handle, INFINITE);

Удивительно, что оно из него всё таки иногда выходит. В общем, для исправления меняем один байт:

C:\Program Files\FlashGet\flashget.exe
0000254B: FF -> 7F

После чего программа перестаёт зависать по окончании загрузки какого-либо файла.
Проверил - файлы качаются целые и без проблем.

Внимание! Некоторые антивирусы при изменении файла flashget.exe начинают ругаться на него, как на вирус! Это потом что он в исключениях самого антивируса по контрольной сумме, которая, после изменений, уже не совпадает.

[-=CHE@TER=-]

Да, блин! Долбанный ACDSee!
Добавил в первое сообщение ещё 3 байта, которые нужно изменить, чтобы программа не пыталась запустить БД - сейчас лог в системе посмотрел (Просмотр событий - Система) - там одни ошибки от ACDSee, что она не может COM объект создать. Теперь, кстати, и IDBSvr.exe трогать не надо, т.к. он даже не запускается.

[-=CHE@TER=-]

Как выяснилось, ACDSee 5 - самый лучший из ACDSee, а я не единственный, кто им до сих пор пользуется. Добавил в первое сообщение uni-processor patch (это байт по смещению 0x167), т.к. программа на многоядерных процессорах, как оказалось, разваливается.
На Windows 7 она работает, но почему-то заваливается при попытке выбрать Рабочий стол в дереве каталогов слева - надо будет как-нибудь в отладчике поглядеть чего там происходит.

Ещё про антивирусы к FlashGet добавил.

[-=CHE@TER=-]

На Windows 7 она работает, но почему-то заваливается при попытке выбрать Рабочий стол в дереве каталогов слева - надо будет как-нибудь в отладчике поглядеть чего там происходит.

Как оказалось, Windows 7 тут не причём.

Делаем следующее:
1) Создаём текстовый файл и пишем туда:

CODE

[InternetShortcut]
URL=http://длинная строка - в моём случае там было 830 символов

2) Сохраняем файл как "test.url"
3) Щёлкаем в ACDSee 5 слева, в дереве каталогов, на каталог с этим файлом.
4) Программа падает.

Долбанный стыд просто - ну кто так программы-то пишет? Такое ощущение, что программа просто не справляется с длинной строки.

Чтобы она не падала, в sub_461A90 надо отключить обработку .LNK/.URL файлов - я просто первый символ заменил на ноль (маска для сравнения в lstrcmpi). Первое сообщение обновил.

[-=CHE@TER=-]

Продолжаем разговор.
На этот раз мы будем исправлять Microsoft Paint (mspaint.exe).
Хотя программа и не сильно навороченная, но чтобы быстро сделать скриншот и что-то там подправить - очень удобная.
Но вот что меня там конкретно вышибает, так это то, что после увеличения/уменьшения рисунка последний выбранный инструмент сбрасывается с "Выделение" на "Карандаш", из-за чего можно случайно что-то нарисовать (особенно на тёмном фоне и не сразу заметишь) не обратив на это внимание вовремя внося другие изменения в рисунок. А потом сохраняешь и замечаешь только когда уже поздно и приходится копировать с оригинального рисунка (хорошо, если остался) испорченную область.
Немного поковыряв программу нашёл где это переключалось и отключил эту фигню.
Хочу заметить, что если была выбрана утилита "Надпись", то в увеличенном режиме (так как эта функция там не работает) так и останется выбраным "Масштаб".

Windows 98 SE (удивитесь - он лежит не в C:\WINDOWS)
C:\Program Files\Accessories\MSPAINT.EXE
000141BE: 0A -> 00

Windows XP SP3 (сначала меняем в первых двух файлах, затем в третьем, иначе он из них восстанавливаться будет!)
C:\WINDOWS\ServicePackFiles\i386\mspaint.exe
C:\WINDOWS\system32\dllcache\mspaint.exe
C:\WINDOWS\system32\mspaint.exe
000145D8: 0A -> 00

Windows 2003 R2 SP2 (mspaint.exe лежит там же, где и в XP)
000146A9: 0A -> 00

Если по указанному смещению нужного байта нет, то ищем последовательность
74 0A 3B CE
и меняем на:
74 00 3B CE

Сразу оговорюсь, что Paint в Windows 7 я не смотрел, так что не могу сказать есть там этот глюк или нет и можно ли его исправить.

[-=CHE@TER=-]

Многие знают, что ещё со времён 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 (см. комментарии выше).
Что, в итоге, позволяет нам не только избежать переполнения буфера, а также записать размер правильно, но и перезаписать тот непонятный байт.
В общем, после сего исправления эту утилиту, наконец-то, можно использовать.

[-=CHE@TER=-]

И последнее дополнение на сегодня.
Не так давно (всего-то пару лет назад) начал слушать файлы в .AAC формате (к примеру, дёргаешь звук из видео с YouTube и чтобы не перекодировать прямо в .AAC и слушаешь).
К тому же благодаря переписке и небольшой помощи с моей стороны (а может и не только?) автор MP3DirectCut добавил возможность резать и .AAC файлы, так что всё ненужное можно отрезать и слушать любую понравившуюся музыку с YouTube.
Как вы помните, я пользуюсь Winamp 2.81 Classic. Для него есть плагин in_mp4.dll (версии там нет, но датируется 2004.07.09), который проигрывает как обычные .AAC, так и .M4A/.MP4. Проблема в том, что последнего формата файлов у меня нет, есть только .AAC, причём после того как я проиграю какой-либо из этих файлов, то теряю к ним доступ - ни удалить, ни изменить, ни переместить не могу, пока не закрою Winamp. Вчера глянул в Unlocker один такой файл и аж офигел - оказывается Winamp держит штук 20 с лишним файловых дескрипторов, т.е. плагин in_mp4.dll каждый раз заново открывал файл при проигрывании, но не закрывал при остановке/переключении на другой трек.
Охренев от такого безобразия полез в Интернет искать новую версию этой библиотеки. Но тут меня ждал облом, т.к. новых версий не было, а исходные коды menno (автор плагина, разработчик из Nero) удалил из репозитория с пометкой "OBSOLETE", потому что поддержка .AAC была в Winamp 5 нативной (через свою библиотеку), но в старых Winamp-то её не было! Начался адский квест по поиску исходных кодов этой бибиотеки. Нашёл вот тут, правда они старые (см. историю изменений), но хоть что-то.
Можно, конечно, было собрать плагин заново, но я не был уверен, что мне для этого не придётся ставить 7-ую студию, плюс пришлось бы выковыривать из репозитория все изменения плагина, которые произошли до его удаления (а там было что).
Короче, я решил поглядеть исходные коды и поправить косяк дописав нужный код на ассемблере в библиотеку.

А теперь, вы можете офигевать вместе со мной.
/bmp-faad/work/faad2/plugins/in_mp4/in_mp4.c:play()

CODE

    if (!(mp4state.mp4file = MP4Read(mp4state.filename, 0)))
    {
        mp4state.filetype = 1; // это будет .AAC
    } else {
        MP4Close(mp4state.mp4file);
        mp4state.filetype = 0; // а это .M4A/.MP4
    }

Обратите внимание, что если что-то пошло не так, то класс автоматически выгружается.
/bmp-faad/work/faad2/common/mp4v2/mp4.cpp

CODE

extern "C" MP4FileHandle MP4Read(const char* fileName, u_int32_t verbosity)
{
    MP4File* pFile = NULL;
    try {
        pFile = new MP4File(verbosity);
        pFile->Read(fileName);
        return (MP4FileHandle)pFile;
    }
    catch (MP4Error* e) {
        VERBOSE_ERROR(verbosity, e->Print());
        delete e;
        delete pFile;
        return MP4_INVALID_FILE_HANDLE;
    }
}

Ещё немножко ходим по коду, смотрим где что открывается - всё ок, но тут...
/bmp-faad/work/faad2/common/mp4v2/mp4file.cpp

CODE

MP4File::~MP4File()
{
    MP4Free(m_fileName);
    delete m_pRootAtom;
    for (u_int32_t i = 0; i < m_pTracks.Size(); i++) {
        delete m_pTracks[i];
    }
    MP4Free(m_memoryBuffer);    // just in case
}

ДА-ДА-ДА! Это именно то, про что вы подумали - в деструкторе НЕ закрывается открытый файловый дескриптор! Там адово нехватает:

CODE

if (m_pFile) {
  fclose(m_pFile);
}

Таким образом, когда MP4Read() возвращает ноль (MP4_INVALID_FILE_HANDLE), то класс уничтожается, но открытый файл не закрывается! А ведь ноль может вернуться не только в случае отсутствующего файла или невозможности его открыть, но и в случае неверного формата или не .M4A/.MP4 формата!

В общем, пришлось впихивать в деструктор упомянутый выше код с fclose() - крови оно мне попортило изрядно, но, в итоге, всё работает. Особенно весело было получать адрес fclose(), с учётом того, что в библиотеке нет функций LoadLibrary(), GetProcAddress() и даже GetModuleHandle(), а также не стоит забывать, что все импортируемые адреса при загрузке .DLL меняются - выкрутился через получение EIP и ручное высчитывание смещения относительно известного у free() (несущественные инструкции я опустил):

CODE

@patch:
call @func
add eax, 035h; free() addr - [A8100610] - see below
mov eax, [eax]
sub eax, 034h; fclose() addr
mov ecx, [ecx][4]; m_pFile
test ecx, ecx; m_pFile == NULL ?
jz @skip
push ecx
call d, [eax]
pop eax; restore stack
@skip:
jmp @continue

<start destructor proc>
...
8B1D [A8100610] mov ebx, free; MSVCRT <-- rebased value!
...
jmps @patch
@continue:
...
</end>

@func:
pop eax; mov eax = esp (eip after return)
push eax; put back
ret; return: pop dd & jmp dd

Так как в оригинале библиотека была сжата UPX 1.24, то я её распаковал (заодно Winamp будет грузить быстрее) и пропатчил - результат каждый может взять вот тут:

in_mp4.dll (fixed) 275 Kb

Для работы поместить "in_mp4.dll" в C:\Program Files\Winamp\Plugins\ или где там Winamp установлен.

[Axsis]

Кстати, пара вопросов на тему.
Я так понимаю, что aac это чистый сжатый поток, а m4a - это он же в mpeg4 контейнере. Например foobar2000, которым я пользуюсь, играет и то и то, но в чистом aac не работает перемотка и даже не показывает длительность трека.
Собственно вопросы: чем можно извлечь .aac из .mp4 и чем конвертнуть в m4a?
По идее ведь можно из .mp4 удалить видеопоток и получим .m4a? В идеале, конечно, консольные утилитки найти бы...

[-=CHE@TER=-]

Например foobar2000, которым я пользуюсь, играет и то и то, но в чистом aac не работает перемотка и даже не показывает длительность трека.

А вот в Winamp 2.81 Classic с упомянутым выше плагином всё работает - и длительность и перемотка. (*улыбается*)

Собственно вопросы: чем можно извлечь .aac из .mp4 и чем конвертнуть в m4a?

Для извлекания .AAC из видео я делаю так:

CODE

ffmpeg -i filename.flv -vn -acodec copy filename.aac

-i - input flie
-vn - video = none
-acodec copy - audio codec = direct copy
Если заменить ".aac" на ".m4a", то программа обернёт файл в контейнер.
Правда у меня получившийся файл (ни .M4A, ни .MP4) Winamp жрать не хочет - может у тебя работать будет.
Пардон, заработало вот так (рекомендую версию 0.4.5 - там всего 2 файла нужно: MP4Box.exe и js32.dll):

MP4Box.exe -add input.aac output.mp4

А вот упомянутый выше плагин, помимо всего прочего, умеет конвертировать .AAC в .M4A, чтобы потом там теги прописывать и редактировать можно было. (*улыбается*) Правда я этим не пользуюсь.

К слову сказать: как-то брал чистый звук с CD и жал на максимальных настройках качества в .MP3 и .AAC. Увеличивал качество .AAC до тех пор, пока размер выходного файла не получался равным .MP3 с максимальными настройками (.AAC чуть-чуть меньше жмёт). Так вот качество .AAC (на слух) куда чище чем у .MP3. При этом в отличие от .OGG, который как-то не особо прижился в online-сервисах, .AAC куда более распространённее: и в .MP4, и в .FLV и всякие DVDRip'ы в .MKV тоже в нём делают.
Правда с многоканальностью там какая-то проблема была (прям как у .MP3). Я FLAC звук многоканальный в одном видео перекодировал в .AAC и там каналы поплыли - после гугления выяснил, что там как-то через одно место многоканальный звук поддерживается и нумерация каналов другая и иначе они расположены - короче, я забил.
И последнее: как выяснилось в .MP4 можно пихать достаточно много всего (я про кодеки для звука и видео), но всё, что отлично от h264 для видео и AAC для звука не будет проигрываться нативными проигрывателями на Маках. Я как-то знакомому видео перекодировал и чтобы не пережимать звук в .MP4 как .MP3 добавил. У меня везде всё игралось, а у него звука не было. Как пережал в .AAC дорожку - так всё появилось.

[-=CHE@TER=-]

Продублирую тут своё сообщение из другой темы.
У меня стоят несколько плагинов для FAR Manager, в том числе и Calculator v3.0 by Cail Lomecb © 1998-2001 (calc). Калькулятор этот при всех достоинствах адово часто падает, если в выражении встречается буква "e" (экспоненциальная запись числа). Сам я этой функцией редко пользуюсь, а вот если в шестнадцатеричном числе встретилась такая буква, а после неё ещё и цифра - всё, труба.
Что заметил, если запустить FAR и сразу запустить калькулятор вбив туда "9e999", то результат будет "1.#INF" (как и должно). А если сначала открыть любой файл на редактирование (перед этим colorer выводит окно "just wait - i'm realoading..."), то после этого упомянутое выше выражение будет приводить к обвалу калькулятора. Иногда, кстати, и colorer обваливается тоже, но при каких условиях сказать затрудняюсь, ибо это редко происходит.
Так вот! Если в каком-нибудь плагине вызвать:

CODE

Set8087CW($133F); // Delphi
_control87(0x133F, 0x133F); // C++ #include <float.h>

То калькулятор валиться перестанет.
Это команды для управления математическим сопроцессором отключающие ошибки вычисления.
Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 1
По всей видимости colorer за каким-то чёртом меняет флаги сопроцессора (кстати говоря, их даже некоторые функции WinAPI меняют типа CreateWindow() - см. исходные коды Delphi 7 - они там все такие функции оборачивают с сохранением до и восстановлением флагов после вызова).
Немного подумав, я пришёл к выводу что можно, в качестве костыля, отключить в калькуляторе ошибки вычисления таким макаром. Решил поглядеть исходные коды Delphi 7 у обозначенной команды чтобы знать какой код вставлять:

CODE

procedure Set8087CW(NewCW: Word);
begin
  Default8087CW := NewCW;
  asm
    FNCLEX // don't raise pending exceptions enabled by the new flags
{$IFDEF PIC}
    MOV EAX,[EBX].OFFSET Default8087CW
    FLDCW [EAX]
{$ELSE}
    FLDCW   Default8087CW
{$ENDIF}
  end;
end;

Опа-опа-опа! FNCLEX сбрасывает уже накопленные ошибки и только после этого FLDCW загружает новые флаги. Собственно, на FLDCW плагин calc и валился (их там даже два подряд):

CODE

; calc.dll:00009EC4
push  ebp
mov   ebp, esp
add   esp, -00Ch
fstcw [ebp][-02]
fwait
mov   ax, [ebp][-02]
or    ah, 00Ch
mov   [ebp][-04], ax
fldcw [ebp][-04]
fistp q,[ebp][-0C]
fldcw [ebp][-02]; <-- exception here
mov   eax,[ebp][-0C]
mov   edx,[ebp][-08]
leave
retn

По сути, всё что нужно - это всунуть инструкцию fnclex (2 байта) перед fistp. Т.к. после этой процедуры есть выравнивающие байты, то я просто сдвинул код:

; version info:
; 100864 bytes
; 2001.05.02 14:10:44
; FAR Manager Calculator v3.0
; Cail Lomecb © 1998-2001
CALC.DLL
00009EE0: D9 DB
00009EE1: 6D E2
00009EE2: FE D9
00009EE3: 8B 6D
00009EE4: 45 FE
00009EE5: F4 8B
00009EE6: 8B 45
00009EE7: 55 F4
00009EE8: F8 8B
00009EE9: C9 55
00009EEA: C3 F8
00009EEB: CC C9
00009EEC: CC C3

После чего калькулятор наконец-то перестал валиться.

[-=CHE@TER=-]

Microsoft Games for Windows 8 v1.2 / Windows 10 fix-patch / SpiderSolitaire.exe

Короче, попросили знакомые люди игры (в основном, конечно же, пасьянс "Паук" / "Spider") для Windows 10 (да кто-то этим пользуется). Там теперь он в магазине, угробищный, чудовищный, некрасивый, непривычный и неудобный.

Погуглил и нашёл "Microsoft Games for Windows 8 v1.2" (там все игры в x86 и x64 - около 180 Mb), всё бы ничего, но после очередного крупного обновления 10-ки (недавно было) оно сломалось и больше уже не запускалось.

Поковырявшись слегка в отладчике нашёл что нужно поменять, чтобы всё снова заработало:

x86 SpiderSolitaire.exe (736768 bytes 14.07.2009 03:14:42)
000282C0: 75 EB

x64 SpiderSolitaire.exe (865280 bytes 20.05.2012 12:31:50)
0002F6D2: 75 EB

Кто будет ломать другие игры: там, скорее всего, также сделано.
1) Ищем в файле вызов HeapSetInformation (в HIEW: F8, F7, HeapSetInformation, Enter).
2) Пропускаем его и следующий за ним call.
3) После чего должен как раз идти jne (75), который нужно сменить на jmps (EB).

P.S. Кстати, сравнивал оригинальный SpiderSolitaire.exe (x64, кажется) из Windows 7 и взломанный из этого пака - там такие отличия (если, вдруг, кто захочет с нуля наломать):
SpiderSolitaire.exe:
0002F6C5: 3B 39
0002F6C6: C6 C0

[-=CHE@TER=-]

Переделал и сократил патч для ACDSee5 - сделал его более аккуратным.
Оказывается, есть официальный (хотя нигде и не документированный) способ отключения базы данных (их там аж две) - это создать ключи:
HKCU\Software\ACD Systems\ACDSee\50\EnableImageDB
HKCU\Software\ACD Systems\ACDSee\50\EnableExtDB
DWORD со значением 0, я полагаю? Судя по коду, если оба ноль, то программа БД не использует.
Я сейчас патч переделал, чтобы там всегда ноль был.
А ещё есть ключик:
HKLM\Software\ACD Systems\ACDSee\50\DBSvrLog
Тоже, видимо, DWORD, но вот при его существовании и значении отличным от нуля, создаётся файл C:\ACDSeeDBThreadLog.txt куда начинает писаться всякая подробная информация и работе программы.
Ещё я заменил в .lnk/.url первый байт на ноль вместо подчерка на всякий случай - в проверку с пустой строкой оно не войдёт, ибо чуть выше проверяется что строка ещё не пустая (не конец строки), так что это точно даст гарантию, что такие файлы обрабатываться не будут (если строка не пустая, то при сравнении с пустой условие всегда будет ложным). Само это условие я не менял, ибо проще занулить два байта строк, чем все места в программе, где они сравниваются (там копипаст в около 7 местах).

[useretail]

Winamp 2.81

А почему не 2.95? Вроде она последняя из вторых...

[-=CHE@TER=-]

А почему не 2.95? Вроде она последняя из вторых...

Потому что после 2.81 туда засунули поддержку проигрывания видео и всё пропало (обрати внимание на постфикс Classic - это была последняя версия, из которой ещё не пытались комбайн сделать). Впрочем, я от 2.95 взял плагины для проигрывание трекерных форматов in_mod.dll - там пофиксили падение плагина, когда у тебя открыта информация о файле и файл закончил играть. А ещё я взял оттуда in_mp3.dll (обновил на всякий случай), он, вроде, даже .AAC должен проигрывать (во всяком случае в два раза толще обычного), но почему-то у меня он ничего не играет (просто не запускает на проигрывание файл и всё), поэтому без in_mp4.dll никуда.

[useretail]

Захожу раз в год и как всегда всякие полезняшки узнаю
Я остановился на версии 2.95 - мне наличие поддежки видео не мешает, я и так в нем только музыку слушаю, все плагины вроде есть, ну и на десерт - использование памяти в Windows 10 не превышает 10-12 Мб.

С описаной проблемой в in_mp4.dll не стыкался, но пропатчился на всякий пожарный
Могу только добавить что это действительно последняя версия что выходила - 2.1beta.

Ну и байты из твоего патча (может кому пригодится): ссылка на pastebin

CODE

upx.exe -d in_mp4.dll
0002C375: 88 89
0002C378: 88 C2
0002C379: 48 04
0002C37A: 69 00
0002C37B: 88 E8
0002C37C: 48 EA
0002C37D: 6A 00
0002C37E: 88 00
0002C37F: 48 00
0002C380: 6B 8B
0002C381: C2 49
0002C383: 00 83
0002C384: 90 C0
0002C385: 90 35
0002C386: 90 8B
0002C387: 90 00
0002C388: 90 83
0002C389: 90 E8
0002C38A: 90 34
0002C38B: 90 E9
0002C38C: 90 A2
0002C38D: 90 02
0002C38E: 90 00
0002C38F: 90 00
0002C3AA: 8B EB
0002C3AB: F1 CF
0002C46A: 90 58
0002C46B: 90 8B
0002C46C: 90 F1
0002C46D: 90 50
0002C46E: 90 C3
0002C632: 90 85
0002C633: 90 C9
0002C634: 90 74
0002C635: 90 04
0002C636: 90 51
0002C637: 90 FF
0002C638: 90 10
0002C639: 90 58
0002C63A: 90 E9
0002C63B: 90 6D
0002C63C: 90 FD
0002C63D: 90 FF
0002C63E: 90 FF

Еще никак не могу пропатчить на юникод. Так как винда стоит американская - кириллицы в плейлисте не видно. Не долго думая поизвращался со шрифтами. Вроде решил. Давай пробовать юникод. Ну никак - только вопросительные знаки . Помню пару дней возился - бросил. Так и сижу без юникода...

[-=CHE@TER=-]

Захожу раз в год и как всегда всякие полезняшки узнаю

Дык! Заходи чаще - тебе запрещают что-ли? У нас тут всегда открыто. (*улыбается*)

Я остановился на версии 2.95 - мне наличие поддежки видео не мешает, я и так в нем только музыку слушаю, все плагины вроде есть, ну и на десерт - использование памяти в Windows 10 не превышает 10-12 Мб.

Нет, я тоже в 2.81 только музыку слушаю, просто какие изменения внесли в ядро 2.95, чтобы оно могло видео и где потом весь этот ад боком может вылезти мне даже думать не хочется. Если проблем нет, то ладно. Кстати говоря, при чём тут Windows 10 не понял - у меня в Windows XP даже до 10 Мб не добирается (9 с копейками), хотя тоже плагинов хватает (.OGG + .FLAC + .AC3 и что-то там ещё).

С описаной проблемой в in_mp4.dll не стыкался, но пропатчился на всякий пожарный

Ну, это же не DOS, где у тебя надо переменную FILES= в config.sys (или autoexec.bat? не помню) увеличивать, когда больше 70 что-ли файлов одновременно открыл. Проведи простой тест (с неисправленным, оригинальным плагином):
1) Скопируй куда-нибудь музыкальный файл в .AAC для тестов - убедись, что это именно .AAC, а не .M4A (если там контейнер, то с ним баг не воспроизводится, впрочем, вроде бы, если контейнер кривой, то баг тоже должен появиться).
2) Открой Winamp и добавь в плейлист этот файл и какой-нибудь .MP3 для примера.
3) Начни играть .AAC, останови и запусти .MP3 - главное не закрывай Winamp.
4) Можешь теперь удалить .AAC из плейлиста, но вот удалить файл с диска пока Winamp работает ты не сможешь.
Ещё один способ - запусти на проигрывание .AAC, затем снова запусти и ещё раз так 5. Если у тебя стоит Unlocker, то пока Winamp не закрыт - выбери .AAC правой клавишей мышки и запусти на нём Unlocker. Сколько раз запускал песню - столько раз там будет Winamp указан, потому что Unlocker показывает открытые файловые дескрипторы (handles), которые держат файл.
По поводу Unlocker - если стоит старая версия - обновляйся. Сам видел, как одна из старых версий семёрку (Windows 7) в синий экран при запуске уводила.

Ну и байты из твоего патча (может кому пригодится):

Ну, я не стал их на форуме приводить, ибо и так портянка большая получилась, к тому же их нельзя будет так просто применить - нужно ещё библиотеку распаковывать. Но, пусть будет.

Еще никак не могу пропатчить на юникод. Так как винда стоит американская - кириллицы в плейлисте не видно.

Так ты русскую локаль-то добавь в Windows.
Кстати, глупый вопрос, но тем не менее - ты в Winamp отключил уже:
Preferences -> Options -> Display -> [ ] Use bitmap font for main title display (no int. support)
или нет?

Не долго думая поизвращался со шрифтами. Вроде решил.

Так я ничего не понял. Ты решил или не решил?

[-=CHE@TER=-]

Блин, чёртов ACDSee5! В который раз переделываю патчи для него.
Выяснилось, что тех патчей, что были в прошлый раз, оказалось недостаточно.
В БД, конечно, ничего не писалось, но гадский IDBSvr.exe всё равно запускался, что работу тормозило.
И тут выяснилась офигенная вещь - оказывается, если оба параметра EnableImageDB и EnableExtDB есть в реестре и равны нулю, то ACDSee5 сам видя что БД не нужна не загружает IDBSvr.exe. Однако, при этом программа входит в одной из функций в бесконечную рекурсию (!) и падает, когда кончается место на стеке. Так что часть кода по загрузке БД (который event'ы создаёт) пришлось всё же запускать, дабы программа не рушилась. Походу режим без БД тестировали от слова "никак".

[-=CHE@TER=-]

Решил тут недавно пройтись UPX'ом по одной своей сишной программе собранной под GCC 3.2 из Dev-CPP и опа:
"CantPackException: unexpected value in PE header (try --force)"
Файл всё ещё можно упаковать насильно при помощи ключа "--force", но не удобно.
Полез в исходные коды UPX:

CODE

/src/p_w32pe_i386.cpp
PackW32PeI386::needForceOption()
r |= ((ih.flags & IMAGE_FILE_32BIT_MACHINE) == 0)

В общем, у поля Characteristics в PE-заголовке, нет флага IMAGE_FILE_32BIT_MACHINE (0x100). Разработчики Windows-версии GCC, как и Watcom, тоже как-то документацию не очень читали. Как бы и так всё работает, но давайте поправим.
Берём файл (именно этот, а не C:\Dev-Cpp\bin\ld.exe):
C:\Dev-Cpp\mingw32\bin\ld.exe
И меняем:
00044391: 00 01
Обращаю внимание, что это поправит только компиляцию и сборку через GCC.EXE и LD.EXE. Если, например, с программы нужно снять отладочные символы через утилиту strip.exe или проделать ещё какие-то манипуляции, то все такие программы придётся исправлять тоже, потому что в них всех это поле пересобирается заново!
Для этого ищем последовательность: 66 81 4D DE 00 02 (or word [ebp-22], 0200h), потом поднимаемся вверх до последовательности 66 C7 45 DE 00 00 (mov word [ebp-22], 0000h) и там заменяем последний 00 на 01.
Правильнее, конечно, ставить это флаг вместе с IMAGE_FILE_EXECUTABLE_IMAGE (02h), но так как он всего один байт, то там места нет, поэтому приходится заменять инициализацию (обнуление) всего этого поля перед добавлением других флагов. Теоретически не должно быть фатально, потому что эта версия GCC (3.2 из Dev-CPP) старая и только 32-х битный код собирать и умеет.