Объединение ресурсов

[Dimka]

Пусть у нас в Visual Studio для простоты есть solution, в котором два проекта типа C++ Win32 Project.

Один проект Console Application - назовём его Entry, другой Static Library - назовём его Lib. Оба проекта Empty с отключенными precompiled headers. И проект Entry зависит от проекта Lib.

Пока начну издалека.

Допустим, хочу я в Lib добавить ресурсом некий внешний файл. Пусть даже для простоты проверки текстовый. Test.txt. Кладу я этот файл в проект. Добавляю заголовочный файл Resource.h

Код: (C++)

#pragma once

#define MY_STRING 101

и файл ресурсов Lib.rc

Код:

#include "resource.h"

MY_STRING RT_RCDATA "Test.txt"

Ну и для работы с ресурсом ещё немного кода. Файл API.h

Код: (C++)

#pragma once

void printRes();

и файл API.cpp

Код: (C++)

#include <iostream>
#include <Windows.h>
#include "resource.h"

using namespace std;

void printRes()
{
        HMODULE hModule = GetModuleHandle(NULL);
        if(hModule == NULL)
        {
                cout << "Unknown module: " << GetLastError() << endl;
                return;
        }
        LPTSTR lpName = MAKEINTRESOURCE(MY_STRING);
        HRSRC hResInfo = FindResource(hModule, lpName, RT_RCDATA);
        if(hResInfo == NULL)
        {
                cout << "Resource not found: " << GetLastError() << endl;
                return;
        }
        HGLOBAL hResource = LoadResource(hModule, hResInfo);
        if(hResource == NULL)
        {
                cout << "Resource not loaded: " << GetLastError() << endl;
                return;
        }
        DWORD nSize = SizeofResource(hModule, hResInfo);
        LPVOID resource = LockResource(hResource);
        if(resource == NULL)
        {
                cout << "Resource not locked: " << GetLastError() << endl;
                return;
        }
        char *text = new char[nSize + 1];
        memcpy(text, resource, nSize);
        text[nSize] = '\0';
        cout << text << endl;
        delete[] text;
}

В другом проекте Entry, соответственно, файл Entry.cpp

Код: (C++)

#include <iostream>
#include "..\lib\api.h"

using namespace std;

int main()
{
        printRes();
        getchar();
        return 0;
}

И получаю я при запуске:

Resource not found: 1813

что означает, что ресурс не найден.

При этом компилятор ресурсов успешно отрабатывает, и внутри Lib.lib по байтикам можно видеть содержимое Test.txt - т.е. ресурс в библиотеку включается. Однако внутри Entry.exe уже содержимого Test.txt нет, и ресурса тоже нет.

Отсюда вопрос, чего это линкер выкидывает ресурсы из статических библиотек? И как добиться, чтобы они там всё-таки оказались?


Разобравшись с этим, потом пообсуждаем другой вопрос: когда ресурсы есть одновременно и в Lib, и в Entry.

[Алексей++]

Dimka, а пример проекта прицепи, чтобы поэкспериментировать

[Джон]

1. Ты добавляешь ресурсы "вручную" (сам создаёшь файлы, сам редактируешь) или добавляешь ресурсы через UI Студии?
2. Как выглядят ресурсы в твоих скомпилированных файлах - посмотреть можн в студии или, например, прогой ResHacker или чем-нить подобным.
3. ещё попробуй так:

Код: (C++)

HRSRC hResInfo = FindResource(hModule, lpName, _T("RT_RCDATA"));

судя по описанию

Код: (C++)

HRSRC WINAPI FindResourceA( __in_opt HMODULE hModule, __in LPCSTR lpName, __in LPCSTR lpType )
HRSRC WINAPI FindResourceW( __in_opt HMODULE hModule, __in LPCWSTR lpName, __in LPCWSTR lpType )

последний параметр - строка.

[Dimka]

Алексей++, прикрепил.

Тут дело в том, что есть другой большой проект, где такая цепочка связей работает, и ресурсы линкуются. Но это большой проект, и код там коммерческий - я его выкладывать не будут. И есть ещё один большой проект, где не работает. А разницы в свойствах проектов будто бы нет.

Т.е. как-то это можно включить.

Джон, зануда.

1) Нет, я создают файл ресурсов через UI, просто выкинуто всё лишнее.
2) Выглядят как положено - содержимое текстового файла внутри lib файла. Если бы они попадали в exe, чтобы там их смотреть, не было бы темы
3) Не буду я это пробовать, потому что RT_RCDATA - это числовая константа 10, уже преобразованная в строку, как это делает макрос MAKEINTRESOURCE. Но не буду я это пробовать не поэтому, а потому что контента ресурсов физически нет в exe-файле.

UPD. В проекте чуть поправил опечатку одну - пока экспериментировал, оставил.

[Алексей++]

скачал. Ещё не запуская: у тебя два проекта. Если запустить TestResources, то ресурса там не будет, так как в ЕГО дереве проекта нет этих ресурсов. Они во втором проекте

[Dimka]

Алексей++, да, потому что второй проект - static library, и ресурс должен быть внутри неё и в таком виде линковаться к exe.

[Алексей++]

   

Код:

HRSRC hResInfo = FindResource(hModule, MAKEINTRESOURCE(MY_STRING), L"RT_RCDATA");
	if(hResInfo == NULL)
	{
		cout << "Resource not found: " << GetLastError() << endl;
		return;
	}

вот так находится

но только с учётом добавленной копии resource.h и ResourcesLib.rc в проект теста

Добавлено через 57 секунд:
видимо, так, как ты хочешь - можно только из динамической dll загрузить, а из статической не получается. Либо какие-то ещё танцы нужны ))

Добавлено через 2 минуты и 20 секунд:
можно разместить файлы ресов на шаг выше обеих папок проектов, а в rc будут одинаковые ссылки через "../" .


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

[Джон]

Джон, зануда.

А как же.

RT_RCDATA - это числовая константа 10

Нууу дык, что ж я все константы наизусть знаю?    Я им просто всегда даю своё имя (например BIN) и беру в кавычки. Кстати в твоём первом варианте примера это было "MY_STRINGT".

Но я уже понял чего ты хочешь. Ессно, пока в EXE ресурсов не будет, нечего их и искать. У lib своего хэндла по любому нет, поэтому надо загнать их в ресурсы EXE. Я думаю, что просто линкуя библиотеку ты ресурсы в EXE не получишь. MFC, например, для этого включает файлы своих ресурсов в rc файл EXE или DLL расширения. Типа:

#include "afxres.rc"         // Standard components
#include "afxprint.rc"       // printing/print preview resources
#if !defined(_AFXDLL)
#include "afxribbon.rc"        // MFC ribbon and control bar resources
#endif

Ну и ессно .h тоже надо.

Тут дело в том, что есть другой большой проект, где такая цепочка связей работает, и ресурсы линкуются. Но это большой проект, и код там коммерческий - я его выкладывать не будут. И есть ещё один большой проект, где не работает. А разницы в свойствах проектов будто бы нет.

Посмотри в rc файле работающего проекта. Там должно быть нечто подобное - включение ресурсов библиотеки.

Ну и ещё останется проблема с внешним текстовым файлом - тоже надо ЗНАТЬ где он находится. Может придётся дополнительный путь к ресурсам в настройках проекта указать.

[zubr]

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

[Dimka]

но только с учётом добавленной копии resource.h и ResourcesLib.rc в проект теста

Это я и сам знаю. Дело в том, что эта библиотека должна быть общей для нескольких проектов. И я не могу тащить ресурсы в каждый из проектов - потеряется сама суть библиотеки.

Кстати в твоём первом варианте примера это было "MY_STRINGT".

Поэтому я и обновил приаттаченный архив. Что это были остатки моего эксперимента.

MFC, например, для этого включает файлы своих ресурсов в rc файл EXE или DLL расширения.

В том проекте, где работает, нет MFC, и вообще в exe-проекте нет ресурсов. Через цепочки header-ов тоже resource.h нигде не попадает в компиляцию exe.

надо ЗНАТЬ где он находится

Он находится в папке собираемого проекта. Поэтому пути не указываются. в lib-файл ресурс попадает.

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

Вот об этом я сразу и подумал. Только не знаю, как зависимости подцепить. Попробую поиграться с экспортом.

[Dimka]

Сравнивал командные строки линкеров. Интересный феномен. Там, где не работает, линкуется lib-файл, там где работает, линкуются каждый obj-файл и в том числе res-файл. При этом вручную файлы нигде не перечислены, и свойства проектов одинаковы, а автоматически генерируемые командные строки различаются - и это имеет решающее значение.

Ну разумеется, если в свойствах линкера exe добавить в Additional Dependencies ..\Lib\$(ConfigurationName)\Lib.res, то начинает работать.

Однако в каких случаях Visual Studio решает, что вместо lib-файла нужно подключать все obj и res-файлы по отдельности??

"Чудны дела твои, господи!" (как мой заказчик выражается)

[Джон]

MFC, например, для этого включает файлы своих ресурсов в rc файл EXE или DLL расширения.

В том проекте, где работает, нет MFC, и вообще в exe-проекте нет ресурсов. Через цепочки header-ов тоже resource.h нигде не попадает в компиляцию exe.

MFC, по сути, такая же библиотека, которая может подключаться статиком, поэтому я и привел её в пример. Не к тому, что ты её используешь, а к тому КАК в ней это решено. Как бы то ни было, факт остаётся фактом: ресурсы должны быть скомпилированы в EXE или DLL. КАК этого достичь, решать тебе. Можно сделать ресурсную DLL и использовать её вместо LIB во всех проектах. Если же всё-таки нужно чтобы был только один EXE файл, то можно подключать .res файл к линковщику, или можно добавить "пустые" ресурсы к exe-проекту и в них включить файлы ресурсов библиотеки. ИМХО в таких случаях решающий фактор - время, которое можно затратить на поиск и реализацию оптимального решения.

надо ЗНАТЬ где он находится

Он находится в папке собираемого проекта. Поэтому пути не указываются. в lib-файл ресурс попадает.

Это было на тот случай, если ты будешь подключать rc файлы. Да, в lib он есть, это понятно - у тебя в lib ЕСТЬ ресурсы, но exe-проект находится в другом месте, и не знает этих путей.

[Dimka]

Да, в lib он есть, это понятно - у тебя в lib ЕСТЬ ресурсы, но exe-проект находится в другом месте, и не знает этих путей.

Ничего не понял. Внутри lib-файла уже есть включённый res-файл с ресурсами (не rc-файл! уже всё скомпилировано). Разумеется, линкер знает, где лежит lib-файл.

Вопрос в другом. Ресурсы загружаются динамически через LoadResource, т.е. на этапе линковки статических связей с ресурсами нет, и поэтому линкер их не берёт из lib-файла. Как бы установить статическую связь на ресурсы в lib, чтобы они не были отброшены линкером? Вариант настройки линкера на "не выкидывать" не срабатывает - это я уже проверял, и ко всему прочему для exe, где много других библиотек, это нехорошо - сильно распухает размер.

[Джон]

 

Да, в lib он есть, это понятно - у тебя в lib ЕСТЬ ресурсы, но exe-проект находится в другом месте, и не знает этих путей.

Ничего не понял. Внутри lib-файла уже есть включённый res-файл с ресурсами (не rc-файл! уже всё скомпилировано). Разумеется, линкер знает, где лежит lib-файл.

Да, внутри lib он есть. Он может даже рядом с этим lib находится, или ещё где. При сборке же EXE, линковщику по барабану ресурсы, которые находятся внутри lib. С какой стати он должен их включать в сборку? Только потому что они есть? Линковщик берёт только то, что ему НАДО, что используется в коде exe-пректа. А там у тебя нет никаких ссылок на ресурсы этой самой lib, те нет в них потребности.

Ресурсы загружаются динамически через LoadResource

ДА, но они загружаются из ТЕКУЩЕГО модуля -> HMODULE hModule = GetModuleHandle(NULL), каковым может являться EXE или DLL, но никак не lib, в момент его выполнения.
У lib нет никакого модуля, это просто сборник чего-то: кода, ресурсов. После того как EXE собран никакого lib и связей с ними нет. Просто линковщик зашёл в него, взял что ему нужно и... забыл про этот lib. Никаких связей, даже запаха не осталось. Все вызовы LoadResource будут работать только с тем, что есть в собранном модуле.

на этапе линковки статических связей с ресурсами нет, и поэтому линкер их не берёт из lib-файла.

Совершенно верно (см. выше). Линкеру достаточно того, что он находит нужные ему ф-ции, а что эти ф-ции что-то там ещё делают, например, пытаются динамически загрузить какие-то ресурсы... Его это не волнует.

Как бы установить статическую связь на ресурсы в lib, чтобы они не были отброшены линкером?

Нууу известные способы уже предложили: включить .rc явно, собирать с .res библиотеки.

Вариант настройки линкера на "не выкидывать" не срабатывает - это я уже проверял, и ко всему прочему для exe, где много других библиотек, это нехорошо - сильно распухает размер.

Вот это я не понял. Ресурсы либо есть, либо их нет. И размер EXE будет "распухнут" на размер ресурсов, если они ЕСТЬ. Как я уже тоже говорил, альтернатива - использовать ресурсную DLL вместо lib. Тогда ресурсы будут в единственном экземпляре  в этой самой DLL, а не в каждом исполняемом модуле, как это непременно произойдёт в случае с lib.

[Dimka]

ДА, но они загружаются из ТЕКУЩЕГО модуля -> HMODULE hModule = GetModuleHandle(NULL), каковым может являться EXE или DLL, но никак не lib, в момент его выполнения.

Ты тут мягкое с тёплым не путай: структуру модулей (исполняемых файлов) времени исполнения и структуру модулей (блоков компоновки) времени сборки. Про время исполнения речь вообще не идёт, меня интересует только время компиляции и сборки.

Вот это я не понял.

У линкера есть опция - не выкидывать из сборки нигде неиспользуемые элементы. Однако это касается лишь невызываемых функций (на которые, тем не менее, в коде есть декларационные ссылки), но не касается статических библиотек. Если линкер будет статические библиотеки цеплять целиком без анализа, что нужно, а что не нужно, ресурс окажется внутри исполняемого файла.

использовать ресурсную DLL вместо lib

Это мне не интересно.

Джон, в общем, ты тут прочитал мини-лекцию, пафос которой сводится: оставь затею включения ресурсов в static library. "На это я пойтить не могу" (c) Так что спасибо - дальнейшие рассказы о том, почему так не делается, мне не интересны. Интересны только советы, как это можно сделать.

Например, интересен костыль упаковки res-файла в массив байтиков - автогенерируемый cpp-файл, который затем включается в библиотеку, а статическая ссылка на него может быть организована в header. Но это крайний случай - поищу пока иные средства.

[Джон]

ДА, но они загружаются из ТЕКУЩЕГО модуля -> HMODULE hModule = GetModuleHandle(NULL), каковым может являться EXE или DLL, но никак не lib, в момент его выполнения.

Ты тут мягкое с тёплым не путай: структуру модулей (исполняемых файлов) времени исполнения и структуру модулей (блоков компоновки) времени сборки. Про время исполнения речь вообще не идёт, меня интересует только время компиляции и сборки.

Нууу дык, ты первый начал "путать", вернее запутывать. . К чему был весь этот код, который к сути вопроса не имеет никакого отношения. А "размазюкивание" с поиском ресурсов, которых в принципе нет. Тут, каюсь, моя вина. Сконцентрировался только на коде и просмотрел главный вопрос, поэтому и было про "взять в кавычки" и тд.

Отсюда вопрос, чего это линкер выкидывает ресурсы из статических библиотек? И как добиться, чтобы они там всё-таки оказались?

Но потом-то исправился. После

второй проект - static library, и ресурс должен быть внутри неё и в таком виде линковаться к exe.

я понял, в чём твоя проблема.

Поэтому (мой второй пост в этой теме) я тебе предложил способ КАК подключить ресурсы из lib проекта, чтобы они собрались в exe. Все остальные тезисы про внешний тхт-файл, относились ТОЛЬКО к этому способу сборки, на что я, собственно, периодически и намекал.

Вот это я не понял.

У линкера есть опция...

Уточню.

это нехорошо - сильно распухает размер.

Я был не понял как ты себе представляешь собрать EXE с дополнительными ресурсами, чтобы его размер не распухал. Ты имеешь ввиду линковку АБСОЛЮТНО ВСЕГО содержимого lib-a? Те ты хочешь чтобы и ресурсы выборочно линковались? Типа: я использую из ГРОМАДНОЙ библиотеки одну единственную ф-ю, которая требует одну единственную строку из ГРОМАДНЫХ реусрсов, и в этом случае в сборку должны перейти только эта ф-я и только эта строка? Не думаю, что с ресурсами такое в принципе получится. У них должна быть определённая структура и адресация. Особенно, когда перейдём ко второй части (да, я теперь всё внимательно прочитал )

когда ресурсы есть одновременно и в Lib, и в Entry.

Надо будет заботится о непересечении идентификаторов ресурсов.

Джон, в общем, ты тут прочитал мини-лекцию, пафос которой сводится: оставь затею включения ресурсов в static library. "На это я пойтить не могу" (c)

"Неправда ваша" (с). Пафос сводится к тому, что ресурсы тебе в любом случае ПРИДЁТСЯ включить, так или иначе,  в сборку exe-проекта, если ты хочешь получать к ним доступ, как ты это описал в первом сообщении. "Не далее, не более" (с)
А без ресурсов в lib ты её не скомпилируешь. Это даже Я понимаю. Так что не знаю, в каких именно моих тезисах ты усмотрел эту "идею"?

Так что спасибо - дальнейшие рассказы о том, почему так не делается, мне не интересны. Интересны только советы, как это можно сделать.

Ещё раз. Где это я рассказывал почему ТАК не делается? Это делается везде и повсеместно, в пример даже привёл, всегда раздражающую тебя, MFC.

Например, интересен костыль упаковки res-файла в массив байтиков - автогенерируемый cpp-файл, который затем включается в библиотеку, а статическая ссылка на него может быть организована в header. Но это крайний случай - поищу пока иные средства.

Нууу дык. Тогда обоснуй, ПОЧЕМУ ты отвергаешь "азбучные истины" и не хочешь делать так, как это испокон веков делается. Какие у тебя ограничения, требования. Тогда можно будет попытаться тебе помочь. А так "Это... как его... волюнтаризм!" (с) Пока я не вижу никаких существенных преимуществ или недостатков (кроме явного указания путей к ресурсам в настройках проекта или ещё хуже - студии) ни одного из способов. В конечном итоге тебе всё-равно придётся включить ресурсы в исполняемый модуль, и абсолютно неважно, где они изначально находятся в lib, res или rc-файле. В массиве байтиков или текстиков.

Какие у тебя есть возможности управления? Я, например, часто использую разные rc-файлы в одном проекте и управляю ими различными компиляциями, в которых исключаю те или иные rc-файлы. Тоже самое можно сделать и с опциями линковщика.

[zubr]

Как тупой, но рабочий вариант - сделать прожку, которая будет читать нужный ресурс из либы и вставлять его в скомпилированный exe (UpdateResource). Прожку поместить в постбайлд проекта, собирающего экзешник.

[Dimka]

Те ты хочешь чтобы

Это твои фантазии, которые я оставлю без комментариев - утомляет.

Надо будет заботится о непересечении идентификаторов ресурсов

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

Где это я рассказывал почему ТАК не делается?

В основном ты рассказываешь что угодно, кроме того, что нужно мне. А мне нужна static library с ресурсами. К счастью, не в бинарном виде, а только в виде проекта для Visual Studio. Но такого, который можно включать одновременно в несколько разных solution (как это делается, я тут обсуждать не буду - это вопрос благополучно решённый). Из этого следует, что все необходимые действия для включения ресурсов в исполняемые файлы в идеале должны быть прописаны в самой библиотеке: либо кодом, либо свойствами проекта. Это вопрос конфигурации.

Я, например, часто использую разные rc-файлы

А я - нет. Меня вообще ресурсы для GUI не интересуют. Мне нужно "вкомпилить" ряд файлов собственного формата. В варианте с утилитой, генерирующей cpp-код, можно даже вообще обойтись без ресурсов.

и управляю ими различными компиляциями, в которых исключаю те или иные rc-файлы.

Опять же: и как это относится к теме?


zubr, тоже вариант. На UpdateResource я смотрел, но такой мысли в голову не приходило. Однако! Этот вариант потребует вывода решения за пределы проекта static library. Это в моём случае нехорошо: в каждом новом soltuion придётся повторять одну и ту же работу по настройке post build на каждом проекте исполняемого файла.