Не компилирует если в RES-файле уже есть VERSIONINFO

[Adam Smith]

Видимо vb6 не устраивает присутствие ресурса указанного типа с номером 1.
А меня достала необходимость после компиляции модифицировать ресурсы.
Я замечаю, что не все "антивирусы" равнодушны к модицифированным exe.

Подскажите, можно ли заставить компилятор использовать готовые ресурсы,
не брать недоиконку из vb формы, и не генерить VERSIONINFO прошлого века?

Привет всем. Я ничего не изучил, наоборот, за последние 3 года всё забыл.

[Adam Smith]

Нашел поиском что-то про VERSIONINFO. Ту тему поднимать не хочу, но вопросы по теме возникают.

http://bbs.vbstreets.ru/viewtopic.php?f=9&t=34155

[Хакер]

А меня достала необходимость после компиляции модифицировать ресурсы.
Я замечаю, что не все "антивирусы" равнодушны к модицифированным exe.

А какой у антивирусов есть козырь для определения того, что файл был модифицирован, и для отличения его от немодифицированного? Если подумать — то никакого. Кроме того что факта, что exe-файл как-то криво собран, что может быть признаком неумелой модификации. Если собран не криво, то как его отличить от немодифицированного?

Вывод — надо просто грамотно модифицировать.

Подскажите, можно ли заставить компилятор использовать готовые ресурсы,
не брать недоиконку из vb формы, и не генерить VERSIONINFO прошлого века?

Как понять «VERSIONINFO прошлого века»?

[Adam Smith]

Вывод — надо просто грамотно модифицировать.

ResHacker -script ResHacker.txt
[FILENAMES]
Exe= AlertPV.exe
SaveAs= AlertPV.exe

[COMMANDS]
-addoverwrite AlertPV.res,,,

в ресурсе манифест, русская версия VERSIONINFO, рисунок и 32х битные иконки.

Грамотно или нет, но любая свистоперделка привлекает чуть бОльшее внимание антивиров после модификации ресурсов
https://www.virustotal.com/gui/file/3944b045caa35a00611eb0d6f01fea435885391861e3d0d536b97c45295ea889/detection
https://www.virustotal.com/gui/file/70a6775baba81589d694d2630aa6b210b858ad5ed61640f463f005f0699ae8d8/detection
https://www.virustotal.com/gui/file/f7b14125223c41971f5a1acc7117fe11298ed5c757b4ff5cfc423ea5f8acd1c0/detection

[Adam Smith]

Как понять «VERSIONINFO прошлого века»?

VB6 компилит VERSIONINFO только для языка 1033, из параметров проекта, в которых даже с версией не всё ладно.
И этот кривой процесс компиляции ресурса захардкоден в VBIDE.dll по-моему, если не ошибаюсь, читал в Интернетах.

[Хакер]

VB6 компилит VERSIONINFO только для языка 1033, из параметров проекта, в которых даже с версией не всё ладно.

Напиши подробнее, что именно не ладно с версией.
То, что используется язык 1033 логично, потому что берётся язык, используемый на машине разработчика. Логично, что программа, компилируемая на китайском компьютере китайского разработчика будет в качестве языка иметь китайский язык. Как ещё нужно было поступить во времена, когда большинство использовало операционную систему, плохо дружащую с юникодом, а мир не был таким глобализированным, как сегодня?

И этот кривой процесс компиляции ресурса захардкоден в VBIDE.dll по-моему, если не ошибаюсь, читал в Интернетах.

Всё не так.

Начнём с VBIDE.dll. Такая библиотека действительно есть. Но в ней нет никакого кода. Вообще. Эта DLL-библиотека лишь хранит в себе разные ресурсы (картинки, строки, иконки, диалоги). И в ней ничего не захардкожено.

Среда VB — это главным образом связка из VB6.EXE и VBA6.DLL. Эти два файла представляют собой два фундаментальных компонента, из которых состоит VB как продукт: Ruby и EB. Рассказ о Ruby и EB — то, с чего я хотел начать цикл статей о внутреннем устройстве VB (давно задуманный). Он был готов в прошлом году, как и два перевода, сопровождающих его, но я не хотел публиковать его, пока значительная часть цикла не будет готова к публикации.

И всё-таки ты вынудил меня опубликовать эту первую главу цикла.
Моя статья о Ruby+EB, перевод (1) чужой статьи, перевод (2) чужой статьи. Прочитай как минимум мою статью (переводы не обязательно), чтобы понять, о чём речь пойдёт дальше.

Теперь, предполагая, что ты понимаешь, что такое Ruby и EB, я скажу следующее.

Генерация obj-файлов, формирование командной строки и вызов линкера (LINK.EXE) для получения конечного EXE-файла — это чисто EB-шная вещь. Весь этот процесс закодирован в VBA6.DLL. При этом, хотя Microsoft-овский линкер умеет принимать на вход res-файлы наряду с obj-файлами (получив на вход res-файл, он с помощью CVTRES.EXE конвертирует .res в .obj и обходится с этим .obj так же, как с остальными obj-файлами на входе), в VB такой прямолинейный подход не используется. RES-файл, привязанный к VB-проекту, на вход линкеру никогда не попадает.

В процессе компиляции на каждый «модуль» (форма, класс, обычный модуль, юзерконтрол и т.п) генерируется свой obj-файл, по имени совпадающий с именем модуля, плюс генерируется дополнительный obj-файл, имя которого соответствует имени проекта. Именно в этом общем OBJ-файле находятся все ресурсы, именно таким путём ресурсы попадают в конечный EXE-файл.

И здесь наступает очень важный момент: EB понятия не имеет и знать ничего не хочет о ресурсах. EB не знает о том, что в Ruby есть редактор ресурсов, что там есть диалог свойств проекта, где можно задать данные для VERSIONINFO. EB ничего не знает об ограничениях на язык ресурсов, об ограничениях на размер и битность иконок.

EB самостоятельно не формирует ресурсы — и это главное.

Редактор ресурсов, возможность привязать res-файл к проекту, тот факт, что иконкой программы обязательно выступает иконка одной из форм (и нельзя задать произвольную иконку), диалог свойств проекта с полями для указания версии, компании разработчика, описания — всё это заморочки уровня Ruby. Точнее, редактор ресурсов не относится вообще ни к EB, ни к Ruby, потому что это сторонний Add-in с точки зрения VB, но вот возможность присоединять внешний res-файл (без возможности редактирования) к проекту — это, как я выше и сказал, концепции уровня Ruby.

Так что за формирование ресурсов, за содаржание этих ресурсов ответственность несёт Ruby, а не EB. То есть, выражаясь твоим языком, всё это захардкожено в VB6.EXE. EB лишь предоставляет внешнему хосту (которым выступает Ruby) возможность предоставить данные, которые EB любезно поместит сначала в obj, а потом и (не без участия линкера) в итоговый EXE.

Поэтому слово «захардкоженно» по отношению к формированию ресурсов, и попытка мыслить о ресурсах так, будто из генерация целиком запрограммирована в одном месте — это неправильный подход.

Таких места два: в одном (Ruby, VB6.EXE) месте решают, что положить в ресурсы, а в другом месте (EB, VBA6.DLL) определяются с тем, как и куда.

И поскольку взаимодействие между Ruby и EB идёт не напрямую, а через малочисленные фиксированные и более-менее доступные API (которыми выступают обычные экспортируемые/импортируемые функции и объектно-ориентированные интерфейсы), нам, как желающим вмешаться в этот процесс, не придётся преодолевать непреодолимое и совершать невозможное.

Процесс компиляции проекта в EXE работает примерно следующим образом.

В недрах Ruby есть огромная функция ExeMake, которая делает кучу работы, и которая от начала до конца отвечает за генерацию исполняемого файла. В общем и целом, она обходит все сущности, собирает все данные и скармливает это всё EB.

С позиции взаимодействия Ruby и EB есть три ключевых точки, а именно три вызова из Ruby в EB:

• TipStartMakeExe
• TipMakeExe2
• TipFinishExe2

Это всё экспортируемые из VBA6.DLL функции (это к вопросу о лёгкости их перехвата).

Основная часть работы, которую выполняет Ruby при компиляции, находится между вызовами TipMakeExe2 и TipFinishExe2.

TipMakeExe2, помимо прочего, возвращает вызывающей стороне ссылку на объект, поддерживающий интерфейс IExeFile. Вызывающей стороной является Ruby, Ruby получает ссылку на этот интерфейс и именно через него скармливает EB все ресурсы, которые должны попасть в итоговый EXE-файл.

И, наконец, происходит вызов TipFinishExe2. Именно TipFinishExe2 проходится по всем данным, которые хост скормил EB, собирает их в кучу, записывает в obj-файл, затем берёт все obj-файлы, вызывает линкер и собирает конечный EXE-файл.

Мораль в том, что: если нас каким-то образом не устраивает то, как формируются ресурсы, мы можем написать Add-in, который перехватив TipMakeExe2 получит ссылку на объект, поддерживающий IExeFile, а перехватив методы этого интерфейса, получит полный контроль над тем, как формируются ресурсы, что в них попадает, а что не попадает.

И это довольно таки легко: перехват экспортируемой функции и перехват методов интерфейса делаются очень легко по сравнению с, например, перехватом неэкспортируемых функций где-то в недрах неведомой DLL или неведомого EXE.

[The trick]

Мораль в том, что: если нас каким-то образом не устраивает то, как формируются ресурсы, мы можем написать Add-in, который перехватив TipMakeExe2 получит ссылку на объект, поддерживающий IExeFile, а перехватив методы этого интерфейса, получит полный контроль над тем, как формируются ресурсы, что в них попадает, а что не попадает.

Не помню точно, но кажется там были проблемы с условной компиляцией. При перехвате TipMakeExe2 вызывалась TipSetConstantValues для того чтобы динамически поменять константы и это вызывало креш при дальнейшей компиляции, кажется на SP6. Точно не скажу - давно было. Идея была создать автоматические константы во время компиляции в EXE и при компиляции в среде (TipCompileProject/TipCompileProjectFull) по типу DEBUG/RELEASE, чтобы не делать вручную каждый раз при компиляции в EXE. Действительно ли нельзя задавть условные константы непосредственно перед TipMakeExe2?

[Adam Smith]

И этот кривой процесс компиляции ресурса захардкоден в VBIDE.dll по-моему, если не ошибаюсь, читал в Интернетах.

Всё не так.

Как и предполагал, я ошибся с названием dll.

vbe6.dll - 1 693 968 байт, версия - 6.0.0.8964 по офсету D9A56h меняем je->jmp.

Напиши подробнее, что именно не ладно с версией.

Невозможно указать все параметры версии.

The version consists of two 32-bit integers, defined by four 16-bit integers. For example, "FILEVERSION 3,10,0,61"

По поводу остального у меня только одно слово - ОФИГЕТЬ

[Adam Smith]

В конечном итоге по моему вопросу

Подскажите, можно ли заставить компилятор использовать готовые ресурсы,
не брать недоиконку из vb формы, и не генерить VERSIONINFO прошлого века?

я делаю вывод, что нет, невозможно заставить компилятор использовать отдельный RES-файл при сборке EXE и игнорировать недоресурсы "по-умолчанию".