Je suis confus quant à la compatibilité binary des bibliothèques compilées entre VS2010 et VS2012. Je souhaite migrer vers VS2012, mais de nombreux SDK binarys à source fermée ne sont disponibles que pour VS2010, par exemple des SDK pour l’interfaçage de périphériques matériels.
Autant que je sache, Visual Studio était extrêmement pointilleux sur les versions de compilateur et dans VS2010, vous ne pouviez pas créer de lien vers des bibliothèques compilées pour VS2008.
La raison pour laquelle je suis confus maintenant, c’est que je suis en train de migrer vers VS2012 et que j’ai essayé plusieurs projets. Pour ma plus grande surprise, beaucoup d’entre eux fonctionnent sans problème entre versions.
Remarque: je ne parle pas du mode v100, qui, autant que je sache, n’est qu’une interface graphique VS2012 par rapport au moteur de compilation VS2010.
Je parle d’ouvrir une solution VS2010 dans VS2012, de cliquer sur mettre à jour et de voir ce qui se passe.
Lors de la création de liens vers des bibliothèques plus volumineuses, telles que boost, la compilation ne fonctionnait pas, car la version du compilateur est vérifiée et génère une erreur et annule la compilation. Certaines autres bibliothèques n’abandonnent que les fonctions manquantes. C’est le comportement auquel je m’attendais.
Par ailleurs, de nombreuses bibliothèques fonctionnent correctement sans erreurs ni avertissements supplémentaires.
Comment est-ce possible? VS2012 a-t-il été conçu de manière spéciale pour conserver la compatibilité binary avec les bibliothèques VS2010? Cela dépend-il de la liaison dynamic et statique?
Et la question la plus importante: même s’il n’ya pas d’erreur soulevée au moment de la compilation, puis-je faire confiance au compilateur qu’il n’y aura pas de bugs lors de la liaison d’un projet VS2012 à des bibliothèques compilées VS2010?
«De nombreuses bibliothèques fonctionnent bien. Comment est-ce possible?”
1) la bibliothèque est compilée pour utiliser la RTL statique, de sorte que le code ne récupère pas une seconde DLL RTL qui se heurte.
2) le code appelle uniquement des fonctions (et utilise des structures, etc.) qui se trouvent complètement dans les fichiers d’en-tête afin de ne pas causer d’erreur de l’éditeur de liens, ou appelle des fonctions qui sont toujours présentes dans la nouvelle RTL afin de ne pas provoquer d’erreur de l’éditeur de liens ,
3) n’appelle pas quoi que ce soit avec des structures qui ont changé de présentation ou de signification, de sorte que cela ne plante pas.
Le n ° 3 est celui à craindre. Vous pouvez utiliser les importations pour voir ce qu’elles utilisent et en faire une liste complète, mais il n’existe aucune documentation ni garantie quant à celles qui sont compatibles. Ce n’est pas parce qu’il semble fonctionner qu’il n’ya pas de bogue latent.
Il y a aussi la possibilité de
4) le SDK du pilote ou un autre code assez faible a été écrit pour éviter d’utiliser complètement les appels de bibliothèque standard.
aussi (pas dans votre cas, je pense) les DLL peuvent être isolées et avoir leur propre RTL et ne pas faire passer des choses (comme l’allocation et la libération de mémoire) entre différents régimes. Les serveurs COM in-proc fonctionnent de cette façon. Les DLL peuvent le faire en général si vous faites attention à ce que vous transmettez et renvoyez et à ce que vous faites avec des pointeurs par exemple. Crypto ++, par exemple, est initialisé avec les routines de mémoire du programme englobant et n’expose pas la mémoire de malloc à partir de la version RTL avec laquelle il a été compilé.