title: Visual studio code binary compatibility
body: <p>Let's say we have one .exe and multiple .dll's, both of them are written in C / C++ using different Visual studio versions.</p>
  
  <p>.exe and .dll's might have heavy number of third party static libraries, and it's difficult to upgrade whole project (either c++ or dll) to use newer visual studio.</p>
  
  <p>Besides binary compatibility which might raise because of visual studio switching:
  <a href="https://stackoverflow.com/questions/35805113/visual-studio-2015-run-time-dependencies-or-how-to-get-rid-of-universal-crt">Visual studio 2015 run-time dependencies or how to get rid of Universal CRT?</a></p>
  
  <p>There might be even more problems - like debugging and so on:
  <a href="https://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/" rel="nofollow noreferrer">https://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/</a></p>
  
  <p>Also as I have understood in older visual studio's there were problems also with C++ function name mangling (which changed from visual studio to visual studio)
  creating more problems with porting your solution.</p>
  
  <ol>
  <li>Allocate / free problem</li>
  </ol>
  
  <p>As I have understood p = malloc() executed in context of .exe (exe is compiled with vs2010) followed with free(p) executed in context of .dll (dll is compiled with vs2013) would simply crash application.</p>
  
  <p>I guess one approach is not to use CRT allocation functions at all (no malloc, free, new, ...) - but to use windows api directly (LocalAlloc, ...) - then code would work across different versions of visual studio's, but overriding all allocation procedures with your own allocation scheme sounds like tedious task.</p>
  
  <p>Do you know any other way for to make vs version mixture possible ?</p>
  
  <ol start="2">
  <li>What I have also tested C++ function mangling is compatible between visual studio 2010 and 2013, but is it became a standard now - will it change in incompatible manner in next visual studio versions ?</li>
  </ol>