Total Commander

BeTeP · (Separately) Posted: Sat Mar 22, 2025 17:12 Post subject:

Давно хотел написать, но всё времени не было.

В общем проблемка такая.
Начиная с версий плагина 3.0.17.х при просмотре цифровой подписи файла, данные в этой вкладке появляются с задержкой до 35 сек.
Если повторно открыть тот же файл, то данные в этой вкладке отображаются сразу.

В версиях плагина 3.0.16.х и ранее такой проблемки нет. На любом файле данные в этой вкладке появляются моментально.

ТС: 11.51 (х86)
ОС: Win 7 (x64) и Win 10 (x64).
_________________
«The Truth Is Out There»

iteg · Joined: 01 Dec 2011 Posts: 95

BeTeP
Иногда такое замечал, но зависание было несколько секунд, а не десятков. Буду искать причину. Спасибо за участие в проекте.

Destiny · Joined: 15 Dec 2015 Posts: 272

iteg
В целом какие-то чудеса получаются. И только лишь из-за того, что я собираю 2019 студией?
Собственно файл FontsListing у вас уже есть. Я же присылал вам его ранее. Вы же не удаляете такие файлы
и они же хранятся для перепроверки каких-то багов, для которых они и были присланы?
Он и другие были в присланном вам ссылкой архиве usedFiles.rar.

Но в нем я вижу именно то что описывал... Если что....
Сейчас попробую найти этот проект. Пересобрать всё заново.
Тут на саму студию за всё время пришло куча обновлений. Может что-то и было сломано/починено?

Касательно "Никакого упоминания 0x04E4 я тоже не нашел" - дык это же ваши изначально слова:

Destiny · Joined: 15 Dec 2015 Posts: 272

iteg
После пересборки вроде наверное бОльшая часть вопросов отошла.
Сейчас реально есть видимость и Английского И Русского языков.
И мы теперь реально можем показать древо версионности на энных языках,
спрятанных под одним лишь идентификатором VS_VERSION_INFO.

Но что осталось - это та самая кодовая страница)))
Ведь вроде как, подняв историю переписки тут, я вижу, что и в ваших тестах:

Destiny · Joined: 15 Dec 2015 Posts: 272

Почему так хотелось бы с кодовыми страницами разобраться окончательно - потому как
ещё же и этим параметром обладает сам текст файла RC, в котором хранится эта инфа.
И для 1251 и 1200 - вроде всё нормально. Хотя странно, что это так.
А вот в более для нас всех предпочтительном варианте UTF-8 - начинаются проблемы...
И решение явно лежит в плоскости понятия кодовой страницы.
https://devblogs.microsoft.com/oldnewthing/20190607-00/?p=102569
https://stackoverflow.com/questions/71281527/changing-resource-encoding-from-windows-1252-to-unicode-utf-8-with-signatures

И вроде бы потому как компилятор все равно принудительно сохраняет всё в формате UTF-16LE (Unicode) в итоговом
бинарном виде - то вроде как получается предпочтительно использовать 1200....
НО очень хотелось бы UTF-8 (65001). А для этого надо тогда уметь ЧЁТКО и ТОЧНО для ресурсов задавать их кодовые
страницы. А не оставлять всё на откуп этому нулю-пустышке = ANSI-что-то-там по умолчанию....

P.S.
https://www.ryanliptak.com/blog/every-rc-exe-bug-quirk-probably/
интересненько излагает))))

iteg · Joined: 01 Dec 2011 Posts: 95

Тестовая версия 3.0.17.3:
- Исправлена ошибка проверки валидности сертификатов.
- Для поля сертификата "Valid To" добавлена цветовая индикация валидности относительной текущего времени.
- Для цепочки сертификатов подписи и отдельного сертификата добавлена проверка на аннулирование. Проверка проводится по кэшу ОС без запросов в сеть.
- Внутренняя оптимизация кода.
https://www.upload.ee/files/17984417/wlx_peviewer_3.0.17.3.rar.html
Просьба к BeTeP и Destiny, проверить на зависание при просмотре цифровых подписей.

Добавлено спустя 13 минут:

Destiny
Если честно, то не доводилось устанавливать кодовую страницу для ресурса.
Смог найти следующее:
1) #pragma code_page(65001)
https://learn.microsoft.com/en-us/windows/win32/menurc/pragma-directives
2)
https://learn.microsoft.com/en-us/windows/win32/menurc/using-rc-the-rc-command-line-
3)
VS2022 Configuration Properties\Resources\Command Line\Additional Options = /c 1251
https://devblogs.microsoft.com/oldnewthing/20190607-00/?p=102569
4) Delphi Project Options\Building\Resource Compiler\Code page
Использование code_page или явное задание параметра ресурсному компилятору для VS 2022 или Rad Studio 12.2 (через проектные параметры или напрямую через консоль) к результату не привили.
Возможно на FreePascal можно сделать.
Если кто-то знает как сделать, то напишите здесь.

Destiny · Joined: 15 Dec 2015 Posts: 272

Благодарю за попытку....
Вот в этом-то и цымус, что плагин/код/алгоритм вроде как вполне себе валидно умудряется
считывать эти "ненули" в некоторых случаях некоторых ресурсов.
А вот взять и выставить при компиляции мы почему-то не можем. И в итоге крякозяблы...

А что касается цифровых подписей - где смог - проверил и очень стабильно быстро получил просмотр.

BeTeP · (Separately) Posted: Mon Apr 21, 2025 01:18 Post subject:

iteg
Проверил на нескольких файлах просмотр цифровых подписей. Пока все нормально.
Спасибо за исправление.
_________________
«The Truth Is Out There»

Destiny · Joined: 15 Dec 2015 Posts: 272

iteg
Есть директория %LOCALAPPDATA%\Microsoft\WindowsApps\
А в ней есть спецссылки типа IO_REPARSE_TAG_APPEXECLINK.
Сама Винда на глубоком уровне обрабатывает их. А нам, простым смертным,
даже и увидеть ничего нельзя. НО любопытство - двигатель прогресса!!
https://github.com/JFLarvoire/SysToolsLib/blob/master/Docs/Catalog.md
там есть утилита (и главное есть полный исходный код), которая уже
умеет "видеть" настоящие пути до реальных ЕХЕ файлов, которые же
и скрываются за нулевыми ссылками в этой директории: truename.exe.

Предложение - внести в плагин возможность УВИДЕТЬ правильные полные
пути до реальных ЕХЕ файлов, при попытке открыть путь-спецссылку вида
%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe, который должен сам
трансформироваться в настоящий путь до:
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.0.0_x64__8wekyb3d8bbwe\pwsh.exe
Ну и далее плагин уже работает по своей прямой специальности...

просто из той библиотеки можно вытащить код, который уже корректно
разбирается со всеми этими IO_REPARSE_TAG_****

Ну и в плагине соответственно ввести новую строку в блоке информации,
которая бы описывала эту ситуацию.