Совместимлсть Qt dll

[Igors]

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

Покажите где это написано

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

Она ищет "модуль" - файл на диске. Если его нет - все, отказ. Если же файл найден, то второй раз этот модуль не грузится, мапится то что уже в памяти.

Да, и какая Ваша версия/сценарий? "берется с диска" - что куда берется? Не очень понял что Вы утвержаете, объясните

[OKTA]

Там и обратного четко не прописано к всеобщему сожалению..

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

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

[Igors]

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

Полагаю что никак, файл тот же, удалить/изменить нельзя, ну и все

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

Полностью согласен

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

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

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

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

[Old]

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

Думаю, тут количество вариантов сделать "не так" стремиться к нулю.
По логике, если процесс решил изменить общий ресурс, то происходит копирование кода библиотеки (тот самый copy-on-write).
Т.е. три процесса используют общую библиотеку system32.dll (refCount = 3) , один процесс решает ее пропатчить, для него создается ее копия и она становится в памяти другой библиотекой. Два других проект по прежнему используют system32.dll и если запуститься процесс, которому она понадобиться, то она будет мапиться к нему а адресное пространство. А пропатченная библиотека останется, у того процесса, который ее изменил и она для загрузчика уже не будет system32.dll, т.е. она делиться с другими процессами не будет.

[OKTA]

Да, наверно все же в памяти что-то остается. И она копируется между процессами.
Забыли мы главное доказательство так сказать!) Ведь библиотеки могут иметь область shared, которая может быть доступна всем процессам, которые юзают эту библиотеку
Стало быть, да, библиотека сидит в памяти и отображается в память процессов, которые требуют именно эту библиотеку. А именно эта библиотека определяется путем на диске. Жаль конечно, что истинных кишков этого механизма врядли найдешь в открытом доступе, хотя можно в ReactOS поинтересоваться.
Всегда приятно открывать что-то новое 
Думаю, на этом спор можно считать законченым?)

[navrocky]

Я когда-то читал, что в Win9x библиотеки шарятся, в WinNT+ - нет, т.е. для каждого процесса отдельно грузятся. Это было сделано из принципов безопасности.

[OKTA]

Да я тоже такое читал, однако с __attribute__((section (".shared"), shared)) все работает и шарится.
В общем, очередной раз понимаю, какая же шарашкина контора эта винда 

[Igors]

Да, вроде разобрались. Теперь как насчет практического/утилитарного аспекта? (проще говоря как деплоить на Вындоуз)?

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

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

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

[OKTA]

Igors, уточните вопрос пожалуйста, а то лень перечитывать всю дискуссию, чтобы вспомнить где собака порылась 

[Igors]

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

[Bepec]

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

[OKTA]

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

[navrocky]

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

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

Если так, то все необходимые либы надо таскать с собой и ни в коем случае не совать в общие папки типа c:\windows\system32. Самое правильное - написать для этого инсталлятор. NSIS, MSI или что-то другое на ваш выбор.

Ну или собрать статику, если не смущают ограничения LGPL лицензии Хотя сборка статики, сама по себе задачка не простая.

[Igors]

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

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

Статика не катит - есть обильные плагины. Инсталлятор есть, им занимается др человек. Ну я могу ему сказать типа "эти файлы должны быть там-то", он сделает. И что с того, где файлы-то класть?

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

Не вижу как это избавляет от dll. И пользователь копирует не для того чтобы запустить неск "instances" одного модуля. Напротив, цель - запустить неск exe, каждый по сети получает свою задачу.

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

Сейчас происходит так, пример: есть "свободная машина" - юзер копирует туда 2 exe-iшки: одна "слушает сеть", другая считает (возможно долго). Результаты отправляются обратно по сети. Или то же самое в рамках 1 машины. Главный модуль (генератор заданий) требует инсталла, с этим никто не спорит. Но делать инсталл для каждого модуля - ну никак не хочется

[Old]

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

Какой в этом смысл?
Можно создать два батника, которые и будут запускать программы. Пусть они эти батники копируют.