Re: Visual Studio 2013/2015/2017 compatibility and libraries

[Pascal Quantin <pascal.quantin () gmail com>]

2017-04-24 16:25 GMT+02:00 Graham Bloice <graham.bloice () trihedral com>:

> On 24 April 2017 at 14:56, Pascal Quantin <pascal.quantin () gmail com>
> wrote:
>
> > Hi Peter
> >
> > 2017-04-24 15:43 GMT+02:00 Peter Wu <peter () 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-Decem
> > ber/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.

This is exactly the issue we faced with our GeoIP library (bug 13578) and
why I added a GeoIP_free symbol.


> 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/

Nice. But do you know if practice is working as good as theory ?


> --
> 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-request () wireshark org?subject=unsubscr
> ibe
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe