Total Commander

CaptainFlint писал(а):Но всё равно не пойму, откуда взялась эта DecodePointer, сам я её не вызываю.

Эта функция используется в CRT для защиты указателей на некоторые важные объекты - указатели хранятся в "слегка" зашифрованном виде и дешифруются при обращении. В MSDN сказано, что с Windows XP SP2 она появилась. Возможно, поможет уменьшение версии Windows, под которой должна работать программа (имею в виду макросы типа WIN32_IE) - после компиляции посмотреть список импортируемых функций. Или скомпилируй в более старой версии Visual Studio, например, в 6-й - там такой защиты еще в помине не было.

CaptainFlint писал(а):Послал письмом пробную версию, собранную 2008-й Студией, глянь.

Глянул, там с запуском полный порядок, а всякие-разные параметры пока не проверял.

MVV писал(а):Эта функция используется в CRT для защиты указателей на некоторые важные объекты - указатели хранятся в "слегка" зашифрованном виде и дешифруются при обращении. В MSDN сказано, что с Windows XP SP2 она появилась.

Да, это я уже и сам посмотрел. Просто сам я их не использую явным образом, а вот Студия, похоже, включает по умолчанию.

MVV писал(а):Возможно, поможет уменьшение версии Windows, под которой должна работать программа (имею в виду макросы типа WIN32_IE) - после компиляции посмотреть список импортируемых функций.

Нет, все эти версии я выставил первым же делом при создании нового проекта, да так и оставил. Не помогло.

MVV писал(а):Или скомпилируй в более старой версии Visual Studio, например, в 6-й - там такой защиты еще в помине не было.

В шестой не скомпилируется. Даже 2003-я уже вызывает проблемы. Впрочем, как Вадим чуть выше подтвердил, 2008-й оказалось достаточно. В таком случае, буду для релизов компилировать ей. Жаль, 2010-я делает бинарник чуть покомпактнее…

Avada
Спасибо.

Интересно, что у тебя там используется такого, что 6-я не скомпилит.

Ещё можно попробовать в опциях проекта в 10 студии включить инструментальный набор от 9 версии. Но тогда возможно и библиотеки по умолчанию будут от 9-ки, т.е. особо заметной компактности не будет.

И, конечно, есть плагин FileInfo, который позволяет сразу проверить, какие импорты отсутствуют в системе, не останавливаясь на каждой отдельно взятой функции. Но это уже проверять нужно на машине у Avada.


Кстати, на 6 студии в принципе компилится, весит 64 кило (с внедренным кодом CRT). Только заменить sprintf_s на sprintf и удалить второй параметр (не думаю, что тебе нужны строки длиннее 1024 символов - это неявный BUF_SZ для sprintf), а также вместо if (_get_wpgmptr(&exe_path) != 0) написать if ((exe_path=_wpgmptr) == 0).

MVV писал(а):Интересно, что у тебя там используется такого, что 6-я не скомпилит.

А чёрт его знает, мне лень было разбираться. И так четыре разные Студии подгонял друг под друга, в 2003-й само не скомпилировалось — ну я и забил. Может, и действительно, достаточно названных тобой исправлений, только я от шестой Студии уже практически полностью отказался. Хоть она мне и нравится до сих пор, слишком много накопилось в ней проблем, которые не решаются или решаются с большим напрягом.

MVV писал(а):Ещё можно попробовать в опциях проекта в 10 студии включить инструментальный набор от 9 версии. Но тогда возможно и библиотеки по умолчанию будут от 9-ки, т.е. особо заметной компактности не будет.

Смысла нет, для меня пока основная среда 2008, в 2010 я только перекомпилировал. А если поставить 9-й тулкит, то она и запустит тот же набор компиляторов-линкеров от 2008-й Студии.

MVV писал(а):И, конечно, есть плагин FileInfo, который позволяет сразу проверить, какие импорты отсутствуют в системе, не останавливаясь на каждой отдельно взятой функции. Но это уже проверять нужно на машине у Avada.

Так в этом-то и проблема. У меня всё работало нормально, и проверять смысла не было. А версия, скомпилированная в 2008-й Студии работает даже под Win2000, это я проверил в виртуалке. Просто когда перекомпилировал в 2010-й и увидел, что размер файла получился меньше, решил распространять её, а перепроверить не удосужился. Тоже думал, что раз константы прописаны, то всё в порядке должно быть…

MVV писал(а):не думаю, что тебе нужны строки длиннее 1024 символов

Тут дело не столько в том, нужны или не нужны, сколько в том, что придётся возиться с условной компиляцией. Использовать sprintf везде я не хочу: будут ворнинги. Отключать ворнини не хочу: могу забыть об этой проблеме в другом месте, где строка приходит из Тотала и может иметь произвольную длину, и я из-за отсутствия ворнинга провороню дыру. По-хорошему надо переделать на шаблонный вариант вместо явного указания размера, а потом задефайнить sprintf_s на sprintf для старых Студий, но для этого придётся делать статическую инициализацию вместо new/delete, а пихать два килобайта в стек — не самая лучшая практика (а глобальные переменные недолюбливаю).

MVV писал(а):это неявный BUF_SZ для sprintf

В каком смысле "неявный"? У самого sprintf нет никаких ограничителей, будет писать, пока строка формата не кончится, а поместилось в буфер или нет, его не волнует. Потому и рекомендуется использование sprintf_s.

MVV писал(а):конечно, есть плагин FileInfo, который позволяет сразу проверить, какие импорты отсутствуют в системе, не останавливаясь на каждой отдельно взятой функции.

Для проблемного эзешника в FileInfo KERNEL32.DLL отображается с восклицательным знаком на вкладке Dll Dependency, а на вкладке Exports/Imports результат теста импортной функции следующий:
Functions not sucssesfully loaded
DecodePointer
EncodePointer

CaptainFlint писал(а):

MVV писал(а):это неявный BUF_SZ для sprintf

В каком смысле "неявный"? У самого sprintf нет никаких ограничителей, будет писать, пока строка формата не кончится, а поместилось в буфер или нет, его не волнует. Потому и рекомендуется использование sprintf_s.

Да, это я с wsprintf спутал. Я обычно использую её, так как это системная функция, код которой не нужно включать в экзешник.

Avada писал(а):Для проблемного эзешника в FileInfo KERNEL32.DLL отображается с восклицательным знаком на вкладке Dll Dependency, а на вкладке Exports/Imports результат теста импортной функции следующий:
Functions not sucssesfully loaded
DecodePointer
EncodePointer

Значит, только эти две функции мешают работе экзешника на SP1. Наверное, можно как-то подправить файл kernel32.lib и подложить свои функции-пустышки, но вопрос, стоит ли оно того. Система ведь уже древняя.

MVV писал(а):но вопрос, стоит ли оно того. Система ведь уже древняя.

Описанным методом — явно не стоит. Тем более, что уже был предложен и подтверждён другой способ решения проблемы. А системы по обстоятельствам всякие использовать приходится.

А по мне лично проще пару файлов подключить к проекту и компилить на 10 студии, чем только ради легко решаемой проблемы совместимости использовать предыдущую.

Avada, пожалуйста, попробуй у себя эту версию. Скомпилирована из исходников, выложенных в первом посте, разве что с подменой проблемных функций. По идее, должна работать. И если у кого-то есть Windows 2000, тоже проверьте.

Единственное отличие - подключил к проекту файл kernel32sp1.cpp и положил в папку проекта модифицированный файл kernel32.lib (файл отличается от оригинального лишь тем, что вхождения EncodePointer заменены на EncodePointe_, с DecodePointer - аналогично) - к счастью, компоновщик обратился к этой либе до того как нашел либу в папке SDK, так что оригинальные файлы Visual Studio вообще не тронуты. Оба файла выложил в архиве.

Кстати, интересное наблюдение - с такими изменениями компоновщик добавляет эти две функции в таблицу экспорта бинарника (даже экзешника).

MVV писал(а):А по мне лично проще пару файлов подключить к проекту и компилить на 10 студии, чем только ради легко решаемой проблемы совместимости использовать предыдущую

Если бы я сидел на десятке как на основной, то несомненно. Но я пока сижу на 2008, в десятке больно уж много пока ещё не решённых проблем… Да и тормознутая она нестерпимо.

Вообще, я думал полностью отказаться от использования CRT в TCER, не так там много вещей требуется. Возможно, это также решило бы проблему с (Encode|Decode)Pointer (я пока не уверен, что именно CRT их использует; с другой стороны, больше, вроде, некому). Но пока что количество трудностей на этом пути превысило моё желание заниматься этим делом.

MVV писал(а):Единственное отличие - подключил к проекту файл kernel32sp1.cpp и положил в папку проекта модифицированный файл kernel32.lib (файл отличается от оригинального лишь тем, что вхождения EncodePointer заменены на EncodePointe_, с DecodePointer - аналогично)

Идея интересная, но для production'а я бы поостерёгся такое творить. Мало ли, может, там код как-то завязан на то, что указатели обязаны быть зашифрованными…

Если ты отключаешь CRT и другие библиотеки, использующие CRT, то в импортах будут лишь те функции, которые ты вызываешь явно. А эти две функции используются именно в CRT.

В основном трудности, связанные с неиспользованием CRT - это выделение памяти в куче и использование операций с плавающей запятой. Но в принципе операторы new/delete можно переопределить.

Не думаю, что может возникнуть проблема с незашифрованностью указателей. Максимум проблема безопасности, которая для такого приложения абсолютно несущественна. А так как функции мы переопределяем парные, то условие x == DecodePointer(EncodePointer(x)) будет выполняться, что и требуется.

Я еще более упростил процедуру подключения измененного kernel32.lib - сделал маленькую либу kernel32.lib с этими двумя функциями-пустышками и привязкой к либе kernel32sp1.lib, которая является патченой версией оригинального kernel32.lib. Если обе либы положить в папку, в которой компоновщик ищет либы до стандартной папки, то проект модифицировать вообще не нужно.

MVV
Добрался до машины с SP1 и попробовал тестовую версию. Да, работает.

CaptainFlint писал(а): Кстати, конфиг должен называться tcer.ini

Кстати, не обязательно Твой конфиг имеет имя екзешника, но с раcширением .ini, правда не совсем понятно как такой подход согласуется с минималистичным дизайном... Например, сам тотал совсем не минималистичный, но как екзе не назови, все равно он будет искать wincmd.ini. Еще я бы убрал Array, т.к. для этого есть стандартный vector и вообще коду нужно делать полный рефакторинг, его можно спокойно раза в 2 уменьшить...

Reflector писал(а):Твой конфиг имеет имя екзешника, но с раcширением .ini, правда не совсем понятно как такой подход согласуется с минималистичным дизайном...

По сравнению со всем остальным это копейки.

Reflector писал(а):Еще я бы убрал Array, т.к. для этого есть стандартный vector

Во-первых, я ненавижу STL. Хоть и мощный, но крайне неудобный в использовании (не говоря уж о километровых сообщениях об ошибках, чуть что не так). Во-вторых, я совсем не уверен, что vector сможет жить в программе сам по себе, ничего больше не затащив вместе с собой из STL. В этом случае вряд ли получится экономия. В-третьих, я разрабатывал с учётом возможного отказа от CRT, что в случае использования STL вызвало бы дополнительные проблемы.

Reflector писал(а):и вообще коду нужно делать полный рефакторинг, его можно спокойно раза в 2 уменьшить...

Под минималистичностью я понимаю не количество строчек исходного кода, а размер результирующего бинарника.

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

Мой случай. Что вы подразумеваете под локалью в windows 7?