Работа с файлами манифеста Visual Studios C ++

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

Это то же самое на всех платформах. Это не то, что изобрела Microsoft.

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

a.dll
    dllexport void* createBla() { return malloc( 100 ); }

b.dll
    void consumeBla() { void* p = createBla(); free( p ); }

Когда a.dll и b.dll связаны с разными временами, происходит сбой, потому что функции времени выполнения реализуют свою собственную кучу.

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

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

Для справки:

• не выделять / освобождать память / объекты через границы модуля
• не используйте сложные объекты в вашем интерфейсе dll. (например, std :: string, ...)
• не используйте сложные механизмы C ++ через границы dll. (typeinfo, исключения C ++, ...)
• ...

Но это не проблема манифестов.

Манифест содержит информацию о версии среды выполнения, используемой модулем, и внедряется компоновщиком в двоичный файл (exe / dll). Когда приложение загружено и его зависимости должны быть разрешены, загрузчик просматривает информацию манифеста, встроенную в exe-файл, и использует соответствующую версию DLL среды выполнения из папки WinSxS. Вы не можете просто скопировать среду выполнения или другие модули в папку WinSxS. Вам необходимо установить среду выполнения, предлагаемую Microsoft. Microsoft поставляет пакеты MSI, которые можно запустить при установке программного обеспечения на тестовом компьютере или компьютере конечного пользователя.

Поэтому установите среду выполнения перед использованием приложения, и вы не получите ошибку «отсутствует зависимость».

(Обновлено до вопроса «Как Linux избегает использования файлов манифеста»)

Что такое файл манифеста?

Файлы манифеста были введены для размещения информации разрешения неоднозначности рядом с существующей исполняемой / динамической библиотекой или непосредственно встроены в этот файл.

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

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

Почему это делается?

Версия не является частью имени dll по историческим причинам. Таким образом, comctl32.dll назван так во всех его версиях. (Таким образом, comctl32 под Win2k отличается от такового в XP или Vista). Чтобы указать, какая версия вам действительно нужна (и с которой вы проводили тестирование), вы помещаете информацию о версии в файл «appname.exe.manifest» (или вставляете этот файл / информацию).

Почему это было сделано именно так?

Многие программы устанавливают свои библиотеки DLL в каталог system32 каталога systemrootdir. Это было сделано для того, чтобы исправления ошибок в разделяемых библиотеках можно было легко развернуть для всех зависимых приложений. А в дни ограниченной памяти общие библиотеки сокращали объем памяти, когда несколько приложений использовали одни и те же библиотеки.

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

Это привело к подходу «Распределить все dll в каталог приложения».

Почему это было плохо?

Когда появлялись ошибки, приходилось обновлять все dll, разбросанные по нескольким директориям. (gdiplus.dll) В других случаях это было даже невозможно (компоненты Windows)

Явный подход

Такой подход решает все вышеперечисленные проблемы. Вы можете установить dll в центральное место, где программист не может вмешиваться. Здесь dll могут быть обновлены (путем обновления dll в папке WinSxS), а загрузчик загружает «правильную» dll. (сопоставление версий выполняется dll-загрузчиком).

Почему в Linux нет этого механизма?

У меня есть несколько догадок. (Это действительно просто предположение ...)

• Большинство вещей имеют открытый исходный код, поэтому перекомпиляция для исправления ошибок не является проблемой для целевой аудитории.
• Поскольку существует только одна «среда выполнения» (среда выполнения gcc), проблема с разделением среды выполнения / границами библиотеки возникает не так часто.
• Многие компоненты используют C на уровне интерфейса, где этих проблем просто не возникает, если все сделано правильно.
• Версия библиотек в большинстве случаев встроена в имя ее файла.
• Большинство приложений статически привязаны к своим библиотекам, поэтому не может возникнуть никаких проблем с dll.
• Среда выполнения GCC поддерживалась стабильной ABI, чтобы эти проблемы не могли возникнуть.

Если сторонняя DLL будет выделять память и вам нужно ее освободить, вам понадобятся те же библиотеки времени выполнения. Если в DLL есть функции выделения и освобождения, все в порядке.

Если сторонняя DLL использует std контейнеры, такие как vector и т. Д., Могут возникнуть проблемы, поскольку расположение объектов может быть совершенно другим.

Можно заставить что-то работать, но есть некоторые ограничения. Я столкнулся с обеими перечисленными выше проблемами.

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

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

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

В качестве альтернативы (и решение, которое мы должны использовать там, где я работаю), заключается в том, что если все сторонние библиотеки, которые вам нужно использовать, построены (или доступны в готовом виде) с одной и той же версией компилятора, вы можете «просто» использовать эту версию. Например, может быть затруднительно «использовать» VC6, но если есть библиотека, которую вы должны использовать, а ее источник недоступен, и вот как это происходит, в противном случае ваши возможности, к сожалению, ограничены.

...я так понимаю. :)

(Моя работа не в Windows, хотя мы время от времени сражаемся с библиотеками DLL в Windows с точки зрения пользователя, однако мы должны использовать определенные версии компиляторов и получать версии стороннего программного обеспечения, которые все построены с тот же компилятор. К счастью, все поставщики стараются оставаться в курсе последних событий, поскольку они уже много лет поддерживают такого рода.)