Вопросы о «Бинарной совместимости между Visual Studio 2015 и Visual Studio 2017»

Question

https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 говорит о том, что двоичная совместимость C ++ между Visual Studio 2015 и Visual Studio 2017 гарантирована, кроме:

1) Когда статические библиотеки или объектные файлы компилируются с помощью параметра компилятора / GL.

2) При использовании библиотек, созданных с использованием набора инструментов, версия которого больше, чем набор инструментов, использованный для компиляции и компоновки приложения. Например, программа, скомпилированная и связанная с версией компилятора 19.12, может использовать библиотеки, скомпилированные с 19.0 до 19.12. Кроме того, двоичная совместимость существует только между Visual Studio 2015 и Visual Studio 2017; связывание программ 19.x с библиотеками, созданными Visual Studio 2013 или более ранней версии, не поддерживается.

Исключение 2 меня смущает. Почему двоичная совместимость не может быть гарантирована в этом случае?

Давайте сделаем это более конкретным. Предоставляется папка, содержащая пользовательский исполняемый файл, пользовательскую библиотеку DLL и часть библиотеки DLL vc_toolset (v140 или v141). И пользовательский исполняемый файл, и пользовательский dll динамически связаны с частью dll vc_toolset, которая включает в себя библиотеки CRT, msvcp140.dll, vcruntime140.dll. Кроме того, опция / GL не включена.

Я перечислю несколько комбинаций ниже. Я удивляюсь бинарной совместимости каждого из них.

1) exe, созданный vs2015 + dll, созданный vs2015 + v140, набор инструментов dll из vs2015

Я думаю, что двоичная совместимость может быть гарантирована в этом случае.

2) exe, созданный vs2015 + dll, созданный vs2015 + v141 dll из vs2017

на основе случая 1, кроме того, dll набора инструментов были заменены на новую версию, поставляемую с vs2017.

Кроме того, я думаю, что двоичная совместимость может быть гарантирована в этом случае.

3) exe, созданный vs2015 + dll перестроен по vs2017 + v140 dll из vs2015

На основании случая 1, пользовательская DLL была перестроена с использованием vs2017. Тогда есть два варианта:

a) просто замените dll, и exe-файл не будет перестроен с использованием новой библиотеки импорта dll

b) замените dll и пересоберите exe с использованием новой библиотеки импорта dll.

Согласно исключению 2 вышеупомянутой ссылки, двоичная совместимость не может быть гарантирована в a) и b) случае. Но почему ? Все интерфейсы и зависимости пользовательского dll не изменены, и это не зависит от новой функции v141.

4) exe, созданный vs2015 + dll , перестроен vs2017 + набор инструментов dll vs2017

основано на случае 3, кроме того, dll набора инструментов были заменены на более новую версию, поставляемую с vs2017.

5) exe перестроен vs2017 + dll построен vs2015 + v140 инструментарий dlls vs2015

На основании случая 1, пользовательский exe был перестроен с использованием vs2017 и связан с импортом lib из пользовательского dll, который был ранее собран vs2015

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

6) exe перестроен vs2017 + dll, собранный vs2015 + v141 dll из vs2017

на основании случая 5, кроме того, dll набора инструментов были заменены более новой версией, которая поставляется с vs2017. если случай 5 и случай 2 могут быть гарантированы, я думаю, что это также гарантируется в этом случае.

Правильно ли мое понимание?

Answer 1

Поскольку вы явно вызываете

... библиотеки CRT ...

Я отвечу на эту часть:

Обратная Совместимость между CRT VS2017 и CRT VS2015 гарантируется на 100%! (По модулю MS Баги конечно.)

Как я могу это сказать? Метод развертывания по умолчанию для CRT MSVC - это развертывание всех файлов CRT в System32, поэтому существует один (1) глобальный набор библиотек DLL CRT, который будет использоваться большинством приложений. _{(По крайней мере, AFAIKT, многие приложения используют MS CRT в форме DLL, но не связывают все библиотеки CRT в своем каталоге приложений.)}

А в VS 2017 и 2015 все CRT DLL имеют с одинаковыми именами файлов , т.е. msvcp140.dll, vcruntime140.dll, 141 файлов нет! (Таким образом, пункт с маркером 6 не существует.)

Таким образом, данная система Windows может иметь не более одного глобального набора файлов CRT140, и, поскольку ни одно приложение не управляет этим, более новые версии CRT140 должны быть обратно совместимы с приложениями, созданными для более старых версий.

---

Учитывая это, я бы просто не сделал случаев 3 и 5 (в отношении CRT) из вашего вопроса: всегда развертывайте новейшую MS CRT, которую используют ваши компоненты положитесь.

Даже нашел запись в блоге относительно. это (2017/03/07):

... VCRedist совместим только с обратной совместимостью, поэтому вам нужно будет распространить последний VCRedist 140, доступный в VS 2017, с вашим приложением. ...

---

Относительно ситуации с пунктами 3 и 4 маркированного списка. 2015.exe <-> 2017.dll Я создал новый вопрос: Является ли официальная двоичная несовместимость между приложениями VS2017 и VS2015 и dll точной? , потому что это действительно странно, ИМХО.

Answer 2

Суть статьи, которую вы цитируете, заключается в том, что у Microsoft УВЕЛИЧЕНО вероятность совместимости между двоичными файлами MSVS 2015 и MSVS 2017.

В нем перечислены только два исключения:

https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017

Двоичная совместимость C ++ между Visual Studio 2015 и Visual Studio 2017

В предыдущих версиях Visual Studio двоичная совместимость между объектные файлы (OBJ), статические библиотеки (LIB), динамические библиотеки (DLL) и исполняемые файлы (EXE), созданные с использованием различных версий набор инструментов компилятора и библиотеки времени выполнения не гарантировались.

Это изменилось в Visual Studio 2017. В Visual Studio 2015 и Visual Studio 2017, основной номер набора инструментов C ++ - 14 (v140 для Visual Studio 2015 и v141 для Visual Studio 2017). Это отражает тот факт, что библиотеки времени выполнения и приложения, скомпилированные с любая версия компилятора - по большей части - двоичная совместимы.

Это означает, например, что если у вас есть DLL в Visual Studio 2015, вам не нужно перекомпилировать его, чтобы использовать его из приложения, созданного в Visual Studio 2017.

Есть два исключения из этого правила. Бинарная совместимость не гарантируется в следующих случаях:

1. Когда статические библиотеки или объектные файлы компилируются с помощью параметра компилятора / GL.

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