Russian Qt Forum

А как в этом убедиться?

Конечно я положу ее рядом с exe, но это ничего не гарантирует - если "подходящая" dll уже в памяти - ее и подсунут, на диске ничего искать не будут.

Это их заявленная возможность - совместимость снизу вверх.

Твоя dll и та что в памяти - разные dll, следовательно ничего не подсунут (и кстати в какой ОС такой алгоритм?).

If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

это ничего не гарантирует - если "подходящая" dll уже в памяти - ее и подсунут, на диске ничего искать не будут.

If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

Это если она уже загружена в адресное пространство твоего процесса, т.е., твоим приложением (ну, или вирусом каким-нибудь, который свой код таким образом подгружает :) ). То, что загружают другие приложения, твоего совершенно не касается.

Допустим есть 2 (или более) Qt приложения и каждый положил Qt5Core.dll рядом с exe. По-Вашему выходит а памяти будут 2 копии этой dll - ну если "не касается". В это слабо верится, что за dll если каждый процесс ее опять загружает? Естественно предположить что в памяти будет одна, отмапленная в адресное пр-во каждого процесса.

По-Вашему выходит а памяти будут 2 копии этой dll - ну если "не касается".

Если разные файлы, то и либа грузится дважды (в линукс скорее всего  по inode идет сверка).

Так а Вы сами и проверьте - несложно ведь! Заодно и нам тут расскажите как всё обстоит на самом деле.

Это универсальный ответ на любой вопрос :) А хотелось сначала ознакомиться с теорией - и услышать советы знатоков  :)

http://msdn.microsoft.com/en-us/library/7d83bc18.aspx

Верю, но как пощупать?

Да хотя бы в Вашей, напр MSDN пишет

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

Как ни крути, а сначала должна быть проверка "устраивает ли та что уже в памяти"

Это касается только одного процесса, уже в принципе сказали.

после таких вот ваших заявлений решил привести ссылку.

- это выглядит глупо и противоречит идее dll

Хорошо, давайте так: на 1 машине 10 Qt приложений, каждое имеет Qt5Core.dll рядом с exe. Если все 10 приложений запущены - сколько копий Qt5Core.dll будет загружено в память? Все 10? Я не знаю "правельный ответ", но очень сомневаюсь что все 10 т.к.

- выходит "всегда юзается та dll что рядом c exe - что-то слишком просто. Напр зачем тогда эта городушка http://msdn.microsoft.com/en-us/library/windows/desktop/ms682600%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682600%28v=vs.85%29.aspx)

Думаю будет загружено 10 штук.
Почему это глупо, подскажите пожалуйста?

За 10 не скажу, но 2 приложения у меня сейчас работают каждое со своей копией Qt5Core.dll .

Эта "городушка" работает немного не так, как обычно думают. Если вы через LoadLibrary в коде грузите DLL с указанием абсолютного пути, то при наличии .local-файла абсолютный путь будет проигнорирован и поиск начнётся с каталога .exe-файла.

Т.е. предполагается такой сценарий: инсталлятор куда-то слил dll-ки и, возможно, прописал path. Неск приложений оттуда грузят. Теперь dll-ки обновилось, а одно из приложений это не устраивает. И вот тогда с помощью redirection его можно "подлечить". Хтозна-шо  :'(

Эмм...
А как оно копируется? модуль ваш? с dll или без?
Как вариант симлинки на ваши dll али же в system32 запихать.

Да копия у каждого приложения, копия!

Иначе что, сделал QLibrary::unload () и все, крах системы?  ;D ;D ;D ;D

Если нужна только одна dll-ка, то берем системное API и нагло насилуем библиотеку какого-нибудь одного приложения  ;D

Ведется подсчет ссылок внутри процесса и выгрузится он из этого процесса, а не из памяти.
А вот статейка про то самое  :)
http://www.codeproject.com/Tips/139349/Getting-the-address-of-a-function-in-a-DLL-loaded

Так как перехват практически всегда связан с модификацией памяти (либо кода перехватываемой функции, либо таблиц импорта/экспорта), то для его осуществления необходимо учитывать особенности архитектуры памяти WinNT и Win9X.

Каждому процессу (начиная с Windows 95) выделяется собственное виртуальное адресное пространство. Для 32-разрядных процессов его размер составляет 4 Гб. Это адресное пространство разбивается на разделы, функциональное назначение и свойства которых довольно сильно отличаются у семейств ОС WinNT и Win9Х.

Адресное пространство любого процесса в Win9Х можно разделить на три раздела:

Младшие два гигабайта (00400000-7FFFFFFF) – код и данные пользовательского режима (в диапазоне 00000000-003FFFFF расположены разделы для выявления нулевых указателей и для совместимости с программами DOS и Win16);
Третий гигабайт – для общих файлов, проецируемых в память (MMF), и системных DLL.
Четвёртый гигабайт – для кода и данных режима ядра (здесь располагается ядро операционной системы и драйверы).
Старшие два гигабайта являются общими для всех процессов. Основные системные DLL – kernel32.dll, advAPI32.dll, user32.dll и GDI32.dll загружаются в третий гигабайт. По этой причине эти четыре библиотеки доступны всем процессам в системе. Поскольку этот гигабайт общий, они существуют во всех процессах по одним и тем же адресам. Из соображений безопасности Microsoft запретила запись в область, куда они загружаются. Если же запись туда всё же произвести (а это возможно из режима ядра или недокументированными методами), то изменения произойдут во всех процессах одновременно.

В WinNT общих разделов у процессов нет, хотя системные библиотеки по-прежнему во всех процессах загружаются по одинаковым адресам (но теперь уже в область кода и данных пользовательского режима). Запись в эту область разрешена, но у образов системных библиотек в памяти стоит атрибут «копирование при записи» (copy-on-write). По этой причине попытка записи, например, в образ kernel32.dll приведёт к появлению у процесса своей копии изменённой страницы kernel32.dll, а на остальных процессах это никак не отразится.

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

Перехваты можно разделить на два типа: локальные (перехват в пределах одного процесса) и глобальные (в масштабах всей системы).

Выполнение EXE-модуля
При запуске EXE-файла загрузчик операционной системы создает для его процесса
виртуальное адресное пространство и проецирует на него исполняемый модуль. Далее загрузчик анализирует раздел импорта и пытается спроецировать все необходимые DLL на адресное пространство процесса.
Поскольку в разделе импорта указано только имя DLL (без пути), загрузчику приходится самому искать ее на дисковых устройствах в компьютере пользователя. Поиск DLL осуществляется в следующей последовательности.
1. Каталог, содержащий EXE-файл.
2. Текущий каталог процесса.
3. Системный каталог Windows.
4. Основной каталог Windows.
5. Каталоги, указанные в переменной окружения PATH.
Учтите, что на процесс поиска библиотек могут повлиять и другие факторы
(см. главу 20). Проецируя DLL-модули на адресное пространство, загрузчик проверяет в каждом из них раздел импорта. Если у DLL есть раздел импорта (что обычно и
бывает), загрузчик проецирует следующий DLL-модуль. При этом загрузчик ведет учет
загружаемых DLL и проецирует их только один раз, даже если загрузки этих DLL требуют и другие модули.
Если найти файл DLL не удается, загрузчик выводит одно из двух сообщений

На самом деле LoadLibrary и LoadLibraryEx лишь увеличивают счетчик числа пользователей указанной библиотеки, а FreeLibrary и FreeLibraryAndExitThread его уменьшают. Так, при первом вызове LoadLibrary для загрузки DLL система проецирует образ DLL-файла на адресное пространство вызывающего процесса и присваивает единицу счетчику числа пользователей этой DLL. Если поток того же процесса вызывает
LoadLibrary для той же DLL еще раз, DLL больше не проецируется; система просто
увеличивает счетчик числа ее пользователей — вот и все.
Чтобы выгрузить DLL из адресного пространства процесса, FreeLibrary придется
теперь вызывать дважды: первый вызов уменьшит счетчик до 1, второй — до 0. Обнаружив, что счетчик числа пользователей DLL обнулен, система отключит ее. После
этого попытка вызова какой-либо функции из данной  DLL приведет к нарушению
доступа, так как код по указанному адресу уже не отображается на адресное пространство процесса.
Система поддерживает в каждом процессе свой счетчик DLL, т. е. если поток
процесса А вызывает приведенную ниже функцию, а затем тот же вызов делает поток
в процессе В, то MyLib.dll проецируется на адресное пространство обоих процессов,
а счетчики числа пользователей DLL в каждом из них приравниваются 1.
HINSTANCE hinstDll = LoadLibrary("MyLib.dll");
Если же поток процесса В вызовет далее:
FreeLibrary(hinstDll);
счетчик числа пользователей DLL в процессе В обнулится, что приведет к отключению DLL от адресного пространства процесса В. Но проекция DLL на адресное пространство процесса А не затрагивается, и счетчик числа пользователей DLL в нем
остается прежним.

Dll не берется из памяти, если такая же уже загружена... Она всегда берется с диска..

If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

Test1.exe pid: 3768
Command line: "C:\QT_Training\Test1\Win32\Debug\Test1.exe"

Base                Size      Path
0x0000000050080000  0x7ec000  C:\Qt\5.2.0\msvc2012\bin\Qt5Cored.dll


windowflags.exe pid: 4984
Command line: "C:\Qt\5.2.0\msvc2012\examples\widgets\widgets\windowflags\debug\windowflags.exe"

Base                Size      Path
0x0000000050080000  0x7ec000  C:\Qt\5.2.0\msvc2012\bin\Qt5Cored.dll

Почитайте ради интереса статейки.

Система поддерживает в каждом процессе свой счетчик DLL, т. е. если поток
процесса А вызывает приведенную ниже функцию, а затем тот же вызов делает поток
в процессе В, то MyLib.dll проецируется на адресное пространство обоих процессов,
а счетчики числа пользователей DLL в каждом из них приравниваются 1.

Если же поток процесса В вызовет далее:
FreeLibrary(hinstDll);
счетчик числа пользователей DLL в процессе В обнулится, что приведет к отключению DLL от адресного пространства процесса В. Но проекция DLL на адресное пространство процесса А не затрагивается, и счетчик числа пользователей DLL в нем остается прежним.

Здесь важно "same module name" - это должен быть "именно тот файл" (а не др хоть и идентичный) 

MSDN говорит о загрузке библиотеки внутри одного процесса, а не среди нескольких.

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

А как проверяется соответствие модуля с диска модулю в памяти?

Моя версия проста - если в местах поиска dll ее нет, то ничего и не загрузится,

а если есть, то загружается непосредственно эта найденная dll в память процесса и больше никуда.

Я говорю это не по наслышке, а по опыту. Мне приходилось в свое время патчить системные библиотеки во время их загрузки в память процессов. При чем набор этих библиотек был ограничен и требовало его более 10-20 процессов, запускаемых поочередно. И единственным способом было - отлов каждого "события" загрузки dll и подмена этих dll для каждого процесса. Был бы механизм, который берет библиотеку из памяти, этих мытарств можно было бы избежать, но к сожалению, это не так.

Значит что-то не так делали (понимаю - легко говорить). Что за "события", как подменяли и.т.п - расскажите

Допустим простейший вариант: кладем  все рядом с exe. Тогда придется вдаваться в не очень удобные объяснения типа  "Вы ж все что начинается с "Q" тоже копируйте" + расход памяти.

Конечно копированием одного exe все равно не обойтись, поэтому пользователи уже приучены копировать фолдер Resources, это не вызовет никаких вопросов. Заметно лучше было бы слить dll-ки туда, но тогда нет никаких гарантий что там они найдутся первыми. Кстати пробовал подсунуть др Qt5Core.dll - он ее хватает и вякает что плохая.

А лучше всего было бы создать фолдер с именем DLL и туда все лить - но опять-таки, как обеспечить надежную "находимость"?

Есть 4 exe модуля - ну теперь все с Qt. После установки все лежат в оной папке/мамке. Однако один exe-шник пользователи часто копируют (вернее 2 вместе) в рамках 1 машины. Вариант "копируйте вместе со всеми dll-ками" будет работать, но не выглядит элегантным. Как организовать грамотно?

Ваши предложения взрывают мозг. Однако, предполагаю, что речь идет о распространении собранного приложения на Qt5 под windows?

Плюньте на всё, напишите загрузчик на winApi и его пусть копируют. А сам загрузчик будет лезть в реестр, находить папку с программой и запускать необходимые приложения.
Для вас это гораздо проще, чем таскать "тонны" dll :D

Как вариант, можно извернуться и сделать предстартовое приложение маленькое, которое делает вот это http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx
а потом запускает основное в виде dll, которое упаковать вместе с этим предстартовым приложением  ;D
Диковато, но зато не таскать все библиотеки  ;D

Не только, речь идет о том что некоторые модули приложения могут/будут копироваться

Лоадеры будут очень лёгкими и переносимыми в пределах компа, на котором установлена программа.

Вопрос в службу поддержки:
Уважаемая служба поддержки, я хочу сохранить фильм на дискету, но компьютер мне пишет, что недостаточно места, поэтому мне приходится сохранять ярлык. Если я хочу посмотреть фильм на другом компьютере, то он мне выдает ошибку, что файл не найден. Но ведь на моем компьютере фильм прекрасно проигрывается! В чем проблема?
С дружеским приветом, Катя Иванова

Толку ноль, запуск 2 и более копий не поддерживается, а для одной гораздо проще опять-таки положить рядом.

Здесь хватит простого командного файла,
..
Даже простых ярлыков должно хватить,

Огласите список солидностей. :) Сейчас, пользователь копирует несколько exe с dll и это солидно, а копировать один файлик, это не солидно.

Вот подумал - а если сделать какую-то свою маленькую dll которая грузится первой и разбирается с Qt либами делая для них LoadLibrary? Ведь если загружена в память процесса - искать на диске не должна.

Возня с батниками в эту схему не вписывается, не тратьте время

Тогда пользователю нужно будет копировать эту библиотеку вместе с exe.

лучше один ланчер, чем два exe+dll.

Хорошо, а как добиться чтобы "вот эта " грузилась первой?

А что это за ланчер, как он будет разбираться с копиями?

Вот подумал - а если сделать какую-то свою маленькую dll которая грузится первой и разбирается с Qt либами делая для них LoadLibrary? Ведь если загружена в память процесса - искать на диске не должна.

Бред?