Давно хотел написать, но всё времени не было.
В общем проблемка такая.
Начиная с версий плагина 3.0.17.х при просмотре цифровой подписи файла, данные в этой вкладке появляются с задержкой до 35 сек.
Если повторно открыть тот же файл, то данные в этой вкладке отображаются сразу.
В версиях плагина 3.0.16.х и ранее такой проблемки нет. На любом файле данные в этой вкладке появляются моментально.
ТС: 11.51 (х86)
ОС: Win 7 (x64) и Win 10 (x64).
PE Viewer 3.0
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
iteg
В целом какие-то чудеса получаются. И только лишь из-за того, что я собираю 2019 студией?
Собственно файл FontsListing у вас уже есть. Я же присылал вам его ранее. Вы же не удаляете такие файлы
и они же хранятся для перепроверки каких-то багов, для которых они и были присланы?
Он и другие были в присланном вам ссылкой архиве usedFiles.rar.
Но в нем я вижу именно то что описывал... Если что....
Сейчас попробую найти этот проект. Пересобрать всё заново.
Тут на саму студию за всё время пришло куча обновлений. Может что-то и было сломано/починено?
Касательно "Никакого упоминания 0x04E4 я тоже не нашел" - дык это же ваши изначально слова:
Так если теперь мы найти в исходниках её не можем - то как вы в скомпилированном варианте "нашли"?
Ну, точнее плагин смог прочесть. Или Гислер вот прям наглухо спецом менял все подобные константы под себя что ли?
Добавлено спустя 2 минуты:
Секунды 2 понадобилось, чтобы она открылась.
И Винда и Тотал - 64 битные. Винда и 10 и 11.
В целом какие-то чудеса получаются. И только лишь из-за того, что я собираю 2019 студией?
Собственно файл FontsListing у вас уже есть. Я же присылал вам его ранее. Вы же не удаляете такие файлы
и они же хранятся для перепроверки каких-то багов, для которых они и были присланы?
Он и другие были в присланном вам ссылкой архиве usedFiles.rar.
Но в нем я вижу именно то что описывал... Если что....
Сейчас попробую найти этот проект. Пересобрать всё заново.
Тут на саму студию за всё время пришло куча обновлений. Может что-то и было сломано/починено?
Касательно "Никакого упоминания 0x04E4 я тоже не нашел" - дык это же ваши изначально слова:
Т.е. это вы сами уже нашли и увидели эту пресловутую константу. А я лишь наоборот - пишу что именно и не могу ее найти.iteg писал(а):но можно явно задать. Например, в папке ТС 11.51 TC7Z64.DLL CP="0x04E4 (1252) (ANSI - Latin I)".
Так если теперь мы найти в исходниках её не можем - то как вы в скомпилированном варианте "нашли"?
Ну, точнее плагин смог прочесть. Или Гислер вот прям наглухо спецом менял все подобные константы под себя что ли?
И это при пересборке учтем, чтобы уж точно понять - что и как можно воспроизводить и делать....iteg писал(а):Если замените идентификатор IDR_VERSION2 на VS_VERSION_INFO, то получите такую же структуру
Добавлено спустя 2 минуты:
Беру тот же TotalCmd64.exe как пример - там есть подпись - и открываю соответствующую вкладку.BeTeP писал(а):при просмотре цифровой подписи файла,
Секунды 2 понадобилось, чтобы она открылась.
И Винда и Тотал - 64 битные. Винда и 10 и 11.
iteg
После пересборки вроде наверное бОльшая часть вопросов отошла.
Сейчас реально есть видимость и Английского И Русского языков.
И мы теперь реально можем показать древо версионности на энных языках,
спрятанных под одним лишь идентификатором VS_VERSION_INFO.
Но что осталось - это та самая кодовая страница)))
Ведь вроде как, подняв историю переписки тут, я вижу, что и в ваших тестах:
И похоже, что макрос вида LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT отвечает ТОЛЬКО лишь
за факт смены/выставления языка, но никак не кодовой страницы ресурса.
Ну и далее вы пишите, что вроде как это нормально - по умолчанию так и есть. НО, типа, можно
вроде как и принудительно выставить то, что надо. И вот как раз приводите в пример:
ЧТО-ТО и ДОнастроил... НО вот вопрос тогда - ТАК ЧТО можно настраивать, чтобы это поле принимало реально
другие значения, а не этот раздражающий 0? В вашем тестовом примере WindowsAppTest тоже же всё с нулём.
Вот сможете что-то ЭДАК перевыставить в этом проекте, чтобы к примеру, так же СР=1252 получилось?
Ну, или для нас более ближний вариант - 866? Или вообще юникод 1200?
Вот что есть в инете:
[cut="на инглише (я понимаю, что вы и так это знаете - скорее заметка для меня)"]Languages and Code Pages
The Language level of the Resource Table represents the language of the resources. Language identifiers consist of a primary language identifier and a sublanguage identifier, representing the language and the country/region, respectively.
Code pages are used to map character sets for non-Unicode applications. The code page for a resource is given in the IMAGE_RESOURCE_DATA_ENTRY structure. Information about a code page can be retrieved using the GetCPInfoEx function in the Windows API.
It is important to note that while language identifiers and code pages provide a way to support localization in Windows applications, they represent different aspects. Language identifiers are about linguistics while code pages are about character encoding.[/cut]
Т.е. "читать" вроде как это можно даже на уровне API. Ну а где же тогда храниться функционал "записи" этой инфы?
Что вот Гислер смог-таки это сделать.... Ведь этот пресловутый файл TC7Z64.DLL он-таки как-то собрал сам! А не взял откуда-то готовый.
После пересборки вроде наверное бОльшая часть вопросов отошла.
Сейчас реально есть видимость и Английского И Русского языков.
И мы теперь реально можем показать древо версионности на энных языках,
спрятанных под одним лишь идентификатором VS_VERSION_INFO.
Но что осталось - это та самая кодовая страница)))
Ведь вроде как, подняв историю переписки тут, я вижу, что и в ваших тестах:
добиться контролируемого изменения значения этого Компонента - не удалось. Всегда 0.iteg писал(а):Добавлено: Сб Дек 28, 2024 15:43
.......
Тестовый пример:
LANGUAGE LANG_RUSSIAN, SUBLANG_NEUTRAL
//LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT
//LANGUAGE LANG_RUSSIAN, SUBLANG_SYS_DEFAULT
//LANGUAGE LANG_RUSSIAN, 3
103 DIALOGEX 0, 0, 292, 218, 0
STYLE WS_POPUP | WS_BORDER
EXSTYLE WS_EX_RIGHT | WS_EX_RTLREADING | 0x00400000
CAPTION "Error!"
FONT 8, "MS Shell Dlg", 0
BEGIN
CTEXT "Select One:", 1, 10, 10, 280, 12
PUSHBUTTON "&Retry", 2, 75, 30, 60, 12
PUSHBUTTON "&Abort", 3, 75, 50, 60, 12
PUSHBUTTON "&Ignore", 4, 75, 80, 60, 12
END
- LANGUAGE LANG_RUSSIAN, SUBLANG_NEUTRAL
0x0019 (25) (Russian), 0x0000 (0) (ANSI - Cyrillic)
- LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT
0x0419 (1049) (Russian (Russia)), 0x0000 (0) (ANSI - Cyrillic)
- LANGUAGE LANG_RUSSIAN, SUBLANG_SYS_DEFAULT
0x0819 (2073) (Russian (Moldova)), 0x0000 (0) (ANSI - Cyrillic)
- LANGUAGE LANG_RUSSIAN, 3
0x0C19 (3097) (Language Neutral), 0x0000 (0) (ANSI - Cyrillic)
Для ресурса DIALOGEX изменяется только значение поля Language, а CodePage остается 0.
И похоже, что макрос вида LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT отвечает ТОЛЬКО лишь
за факт смены/выставления языка, но никак не кодовой страницы ресурса.
Ну и далее вы пишите, что вроде как это нормально - по умолчанию так и есть. НО, типа, можно
вроде как и принудительно выставить то, что надо. И вот как раз приводите в пример:
Но мы же видели, что в исходниках проекта этого значения нет! Возможно Гислер при компиляции под себяНапример, в папке ТС 11.51 TC7Z64.DLL CP="0x04E4 (1252) (ANSI - Latin I)".
ЧТО-ТО и ДОнастроил... НО вот вопрос тогда - ТАК ЧТО можно настраивать, чтобы это поле принимало реально
другие значения, а не этот раздражающий 0? В вашем тестовом примере WindowsAppTest тоже же всё с нулём.
Вот сможете что-то ЭДАК перевыставить в этом проекте, чтобы к примеру, так же СР=1252 получилось?
Ну, или для нас более ближний вариант - 866? Или вообще юникод 1200?
Вот что есть в инете:
[cut="на инглише (я понимаю, что вы и так это знаете - скорее заметка для меня)"]Languages and Code Pages
The Language level of the Resource Table represents the language of the resources. Language identifiers consist of a primary language identifier and a sublanguage identifier, representing the language and the country/region, respectively.
Code pages are used to map character sets for non-Unicode applications. The code page for a resource is given in the IMAGE_RESOURCE_DATA_ENTRY structure. Information about a code page can be retrieved using the GetCPInfoEx function in the Windows API.
It is important to note that while language identifiers and code pages provide a way to support localization in Windows applications, they represent different aspects. Language identifiers are about linguistics while code pages are about character encoding.[/cut]
Т.е. "читать" вроде как это можно даже на уровне API. Ну а где же тогда храниться функционал "записи" этой инфы?
Что вот Гислер смог-таки это сделать.... Ведь этот пресловутый файл TC7Z64.DLL он-таки как-то собрал сам! А не взял откуда-то готовый.
Последний раз редактировалось Destiny Чт апр 03, 2025 12:07, всего редактировалось 1 раз.
Почему так хотелось бы с кодовыми страницами разобраться окончательно - потому как
ещё же и этим параметром обладает сам текст файла RC, в котором хранится эта инфа.
И для 1251 и 1200 - вроде всё нормально. Хотя странно, что это так.
А вот в более для нас всех предпочтительном варианте UTF-8 - начинаются проблемы...
И решение явно лежит в плоскости понятия кодовой страницы.
https://devblogs.microsoft.com/oldnewth ... /?p=102569
https://stackoverflow.com/questions/712 ... signatures
И вроде бы потому как компилятор все равно принудительно сохраняет всё в формате UTF-16LE (Unicode) в итоговом
бинарном виде - то вроде как получается предпочтительно использовать 1200....
НО очень хотелось бы UTF-8 (65001). А для этого надо тогда уметь ЧЁТКО и ТОЧНО для ресурсов задавать их кодовые
страницы. А не оставлять всё на откуп этому нулю-пустышке = ANSI-что-то-там по умолчанию....
P.S.
https://www.ryanliptak.com/blog/every-r ... -probably/
интересненько излагает))))
ещё же и этим параметром обладает сам текст файла RC, в котором хранится эта инфа.
И для 1251 и 1200 - вроде всё нормально. Хотя странно, что это так.
А вот в более для нас всех предпочтительном варианте UTF-8 - начинаются проблемы...
И решение явно лежит в плоскости понятия кодовой страницы.
https://devblogs.microsoft.com/oldnewth ... /?p=102569
https://stackoverflow.com/questions/712 ... signatures
И вроде бы потому как компилятор все равно принудительно сохраняет всё в формате UTF-16LE (Unicode) в итоговом
бинарном виде - то вроде как получается предпочтительно использовать 1200....
НО очень хотелось бы UTF-8 (65001). А для этого надо тогда уметь ЧЁТКО и ТОЧНО для ресурсов задавать их кодовые
страницы. А не оставлять всё на откуп этому нулю-пустышке = ANSI-что-то-там по умолчанию....
P.S.
https://www.ryanliptak.com/blog/every-r ... -probably/
интересненько излагает))))
Тестовая версия 3.0.17.3:
- Исправлена ошибка проверки валидности сертификатов.
- Для поля сертификата "Valid To" добавлена цветовая индикация валидности относительной текущего времени.
- Для цепочки сертификатов подписи и отдельного сертификата добавлена проверка на аннулирование. Проверка проводится по кэшу ОС без запросов в сеть.
- Внутренняя оптимизация кода.
https://www.upload.ee/files/17984417/wl ... 3.rar.html
Просьба к BeTeP и Destiny, проверить на зависание при просмотре цифровых подписей.
Добавлено спустя 13 минут:
Destiny
Если честно, то не доводилось устанавливать кодовую страницу для ресурса.
Смог найти следующее:
1) #pragma code_page(65001)
https://learn.microsoft.com/en-us/windo ... directives
2)
https://learn.microsoft.com/en-us/windo ... mand-line-
3)
VS2022 Configuration Properties\Resources\Command Line\Additional Options = /c 1251
https://devblogs.microsoft.com/oldnewth ... /?p=102569
4) Delphi Project Options\Building\Resource Compiler\Code page
Использование code_page или явное задание параметра ресурсному компилятору для VS 2022 или Rad Studio 12.2 (через проектные параметры или напрямую через консоль) к результату не привили.
Возможно на FreePascal можно сделать.
Если кто-то знает как сделать, то напишите здесь.
- Исправлена ошибка проверки валидности сертификатов.
- Для поля сертификата "Valid To" добавлена цветовая индикация валидности относительной текущего времени.
- Для цепочки сертификатов подписи и отдельного сертификата добавлена проверка на аннулирование. Проверка проводится по кэшу ОС без запросов в сеть.
- Внутренняя оптимизация кода.
https://www.upload.ee/files/17984417/wl ... 3.rar.html
Просьба к BeTeP и Destiny, проверить на зависание при просмотре цифровых подписей.
Добавлено спустя 13 минут:
Destiny
Если честно, то не доводилось устанавливать кодовую страницу для ресурса.
Смог найти следующее:
1) #pragma code_page(65001)
https://learn.microsoft.com/en-us/windo ... directives
2)
https://learn.microsoft.com/en-us/windo ... mand-line-
3)
VS2022 Configuration Properties\Resources\Command Line\Additional Options = /c 1251
https://devblogs.microsoft.com/oldnewth ... /?p=102569
4) Delphi Project Options\Building\Resource Compiler\Code page
Использование code_page или явное задание параметра ресурсному компилятору для VS 2022 или Rad Studio 12.2 (через проектные параметры или напрямую через консоль) к результату не привили.
Возможно на FreePascal можно сделать.
Если кто-то знает как сделать, то напишите здесь.
Благодарю за попытку....
Вот в этом-то и цымус, что плагин/код/алгоритм вроде как вполне себе валидно умудряется
считывать эти "ненули" в некоторых случаях некоторых ресурсов.
А вот взять и выставить при компиляции мы почему-то не можем. И в итоге крякозяблы...
А что касается цифровых подписей - где смог - проверил и очень стабильно быстро получил просмотр.
Вот в этом-то и цымус, что плагин/код/алгоритм вроде как вполне себе валидно умудряется
считывать эти "ненули" в некоторых случаях некоторых ресурсов.
А вот взять и выставить при компиляции мы почему-то не можем. И в итоге крякозяблы...
А что касается цифровых подписей - где смог - проверил и очень стабильно быстро получил просмотр.
iteg
Есть директория %LOCALAPPDATA%\Microsoft\WindowsApps\
А в ней есть спецссылки типа IO_REPARSE_TAG_APPEXECLINK.
Сама Винда на глубоком уровне обрабатывает их. А нам, простым смертным,
даже и увидеть ничего нельзя. НО любопытство - двигатель прогресса!!
https://github.com/JFLarvoire/SysToolsL ... 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_****
Ну и в плагине соответственно ввести новую строку в блоке информации,
которая бы описывала эту ситуацию.
Есть директория %LOCALAPPDATA%\Microsoft\WindowsApps\
А в ней есть спецссылки типа IO_REPARSE_TAG_APPEXECLINK.
Сама Винда на глубоком уровне обрабатывает их. А нам, простым смертным,
даже и увидеть ничего нельзя. НО любопытство - двигатель прогресса!!
https://github.com/JFLarvoire/SysToolsL ... 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_****
Ну и в плагине соответственно ввести новую строку в блоке информации,
которая бы описывала эту ситуацию.
Destiny
Тестовая версия 3.0.17.4:
- Реализована поддержка "Reparse Point" метки "AppExecLink" для UWP-приложений (%LOCALAPPDATA%\Microsoft\WindowsApps). На вкладке "Инфо" выводится метка "Reparse Point" и параметры "AppExecLink".
- Реализовано получение абсолютного пути к файлу при открытии символьной ссылки (например, созданной с помощью mklink.exe).
https://www.upload.ee/files/18042024/wl ... 4.rar.html
Тестовая версия 3.0.17.4:
- Реализована поддержка "Reparse Point" метки "AppExecLink" для UWP-приложений (%LOCALAPPDATA%\Microsoft\WindowsApps). На вкладке "Инфо" выводится метка "Reparse Point" и параметры "AppExecLink".
- Реализовано получение абсолютного пути к файлу при открытии символьной ссылки (например, созданной с помощью mklink.exe).
https://www.upload.ee/files/18042024/wl ... 4.rar.html
Да! отлично сработано!
Единственно, что для ссылок - наверное тоже где-то бы надо просто вывести эту инфу,
что, мол, этот файл по сути символическая ссылка (опять ReparsePoint?). А то там порой
такие значения выходят: \\?\C:\TotalCmd\TOTALCMD64.EXE
в качестве полного пути. Да, это верно, понятно. Но чуток непривычно.
А то ж для APPEXECLINK прям отдельный ключ/инфа есть же. Вот и тут бы нас могло
успокоить наличие флага...
Единственно, что для ссылок - наверное тоже где-то бы надо просто вывести эту инфу,
что, мол, этот файл по сути символическая ссылка (опять ReparsePoint?). А то там порой
такие значения выходят: \\?\C:\TotalCmd\TOTALCMD64.EXE
в качестве полного пути. Да, это верно, понятно. Но чуток непривычно.
А то ж для APPEXECLINK прям отдельный ключ/инфа есть же. Вот и тут бы нас могло
успокоить наличие флага...
iteg
Это удивительно, но я поговорил с Гислером и выяснилось, что он ничего спецом не делает. Т.е. это "оно само" где-то выставляет CodePage=1252 (0x4E4)
Его исходники - это в чистом виде исходники разработчика 7Z
И Собирается это в VisualStusio! Так что даже не спишешь на то, что там возможно что-то особенное используется....
Причем вроде даже 2005 эта VS у него!
Неужели там просто какая-то особенность, которая была выключена позже????
Или играет роль, что у него в системе набор языков установлен - для целей сборки-проверки Тотала в мультиязычной среде...
Может этот компилятор пытается "вывести" из этих установленных языков текущую локаль, а она бац! и отличается от вшитой по умолчанию.
Он же на немецком в основном пишет/использует винду...
Может тут влияет настройка ОС «Language for non-Unicode programs»?
Возможно это как раз один из глюков старых кодов компилятора ресурсов, что описан в упомянутой выше ссылке
https://www.ryanliptak.com/blog/every-r ... -probably/
Это удивительно, но я поговорил с Гислером и выяснилось, что он ничего спецом не делает. Т.е. это "оно само" где-то выставляет CodePage=1252 (0x4E4)
Его исходники - это в чистом виде исходники разработчика 7Z
И Собирается это в VisualStusio! Так что даже не спишешь на то, что там возможно что-то особенное используется....
Причем вроде даже 2005 эта VS у него!
Неужели там просто какая-то особенность, которая была выключена позже????
Или играет роль, что у него в системе набор языков установлен - для целей сборки-проверки Тотала в мультиязычной среде...
Может этот компилятор пытается "вывести" из этих установленных языков текущую локаль, а она бац! и отличается от вшитой по умолчанию.
Он же на немецком в основном пишет/использует винду...
Может тут влияет настройка ОС «Language for non-Unicode programs»?
Возможно это как раз один из глюков старых кодов компилятора ресурсов, что описан в упомянутой выше ссылке
https://www.ryanliptak.com/blog/every-r ... -probably/
Это только у меня virustotal-проверка всегда активна?
Галка в настройках свой статус не сохраняет после снятия; при выставлении в ini-файле VTGetFileStatus=False галка больше не появляется, но информация со ссылкой на проверку в вирустотале всегда есть.
Если что - ini-файл лежит в %TotalCmd%\Plugins\WLX\PEViewer\PEViewer.ini и другие настройки там сохраняются.
Замечено на версиях 3.0.17.0 и 3.0.17.4, другие не проверял.
Галка в настройках свой статус не сохраняет после снятия; при выставлении в ini-файле VTGetFileStatus=False галка больше не появляется, но информация со ссылкой на проверку в вирустотале всегда есть.
Если что - ini-файл лежит в %TotalCmd%\Plugins\WLX\PEViewer\PEViewer.ini и другие настройки там сохраняются.
Замечено на версиях 3.0.17.0 и 3.0.17.4, другие не проверял.
У меня 3.0.17.2 - галка в меню работает. Но я вот что еще заметил: не всегда срабатывает пробел для открытия связанных библиотек в новом окне плагина. Закономерности я так и не понял, как и не понял, почему нельзя было сделать двойной клик для вызова этой функции. Но возможно, это как-то связано с тем, на какой вкладке открывается плагин. Если вкладка "Import", то пробел работает, если "Info" - пробел не работает.BlackFox писал(а):Замечено на версиях 3.0.17.0 и 3.0.17.4, другие не проверял.