On 24 April 2017 at 14:56, Pascal Quantin <pascal.quan...@gmail.com> wrote:
> Hi Peter > > 2017-04-24 15:43 GMT+02:00 Peter Wu <pe...@lekensteyn.nl>: > >> Hi, >> >> Are there possible issues to be aware of when using the libraries (built >> with mingw/msvc2013) with the Wireshark binaries built with VS2017? >> When trying it with a friend, it seems to build and run with no issues. >> >> I thought that there can be problems with combining different MSVC >> runtime versions in one binary? Looking through the libraries, it seems >> that there is a combination of at least MingW (GeoIP?) and MSVC (Lua). >> (And apparently VS2015 (14.0) and VS2017 (14.1) are binary compatible.) >> > > Just a side note: most of our 3rd party libraries are compiled with > MinGW(32|64) except zlib (that we compile from scratch if I remember > properly, cannot check right now), Lua for 2.0.X and 2.2.X and Qt. > Historically we were using a MinGW Lua build but that was triggering a > specific MinGW bug and we switched to MSVC based Lua library to work around > this. But it required us to package Lua for every supported MSVC variants > (as you need to have the corresponding C runtime installed on your PC while > Wireshark installer packages the C runtime of the version you used to > compile), which was painful. That's also why it is highly suggested to > install the Qt package matching the MSVC version you intend to use for > compilation. > Since the MinGW bug was fixed, so master branch is again using the MinGW > based Lua library. The only pre-compiled 3rd party package built with MSVC > I can think to right now is Qt. As of today they offer MSVC2013 and > MSVC2015 flavors (there is also a MinGW build but for 32 bits only). It > looks like Qt 5.9 will provide a MSVC2017 version according to > http://lists.qt-project.org/pipermail/development/2016- > December/028159.html > > I think Graham proposed to discuss which MSVC to use (for 2.5 I guess) > during Sharkfest US. > > > The major issue with using DLL's that are compiled with a different C runtime (CRT) from the main application is the issue of different heaps for each CRT and mallocing from one and freeing from a piece of code using another leads to bad things happening. If the malloc\free is all done from within code that uses the same CRT then you should be OK. The reason why the CRT changed with each version of Visual Studio was that this was the only way for MS to service the CRT with bug fixes as it couldn't be upgraded with Windows Updates as that might break various applications (that used the ill-advised static linking to the CRT). The Universal CRT was introduced with Windows 10\VS 2015 to allow Windows Updates to service a portion of the runtime [1]. The part of the CRT that deals with heaps is now serviced by the OS, so theoretically apps built with VS2015 or later (with the Windows 10 SDK) can now use DLL's compiled with VS2015 or later. [1]: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ -- Graham Bloice
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
