TL; DR - Документы MS утверждают, что двоичная совместимость между библиотеками VS2015 и VS2017 равна односторонняя , хотя я предположил, что она обязательно двусторонняя. Где подвох?
Сначала для фона:
Предпосылки / связанные вопросы:
Запутывающее ограничение, которое я нахожу:
Есть два исключения из этого правила. Двоичная совместимость не гарантируется в следующих случаях:
...
При использовании библиотек , созданных с использованием набора инструментов, версия которого больше , чем набор инструментов , используемый для компиляции и компоновки приложения . Например, программа, скомпилированная и связанная с версией компилятора 19.12, может использовать библиотеки, скомпилированные с 19.0 до 19.12.
Это предостережение, ИМХО, технически небрежно и запутанно. Какой будет техническая причина для этого?
Я говорю, что он небрежный, потому что он неполный, потому что интерфейс между исполняемым файлом и DLL довольно симметричен, но этот маркер охватывает только «приложение».
В частности, и при условии, что все модули построены на основе динамической версии CRT, и эта динамическая версия CRT является самой новой доступной версией, я вижу следующие комбинации, где двоичное сравнение является проблемой:
my_2017.exe <-> my_2015.dll - вроде бы поддерживается my_2015.exe <-> my_2017.dll - казалось бы, не поддерживается my_2017.exe <-> my_2015.dll <-> my_2017_x.dll - что теперь, в каком "направлении" это поддерживается между прочим DLL?
Поскольку бинарное сжатие - чисто с точки зрения бинарного интерфейса / интерфейса - должно выполняться в обоих направлениях , я не совсем понимаю, где мы можем внезапно получить несовместимость: вызовы API могут идти в обоих направлениях (обратные вызовы и т. Д.) .) объекты «перемещаются» в обе стороны, даже порядок загрузки DLL может быть смешанным.
Это важный момент, ИМХО, поскольку он означает двоичную совместимость , как указано равно серьезно ограничено:
- Если мое приложение хочет использовать какую-либо скомпилированную библиотеку
VC14*, я "официально" все равно должен убедиться, что мое приложение построено с "самой новой версией".
- С другой стороны, если вы не создаете «приложение», но у вас есть DLL, я, похоже, могу использовать любую другую
VC14* DLL и быть совместимой?
- С помощью VCRedist мы имеем точно случай, который, по-видимому, не поддерживается , а именно нам разрешено использовать библиотеку VC2017 (CRT в этот случай) из приложения 2015 года!
Вопрос
Итак, почему (!) Это ограничено тем, как оно есть, и как оно связано с зависимостями между dll, а также с обращенным (!) Требованием к версии CRT-dll.