Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Guy Harris]

On Feb 14, 2018, at 5:15 PM, Gerald Combs  wrote:

> As far as library compatibility goes, according to
> 
> https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017
> 
> we *should* be able to build using Visual C++ 2017 and use libraries compiled 
> with Visual C++ 2015. I did a test build here using Visual C++ 2017 and the 
> "msvc2015" Qt component here and it seems to work OK. Dependencies[1] reports 
> that it's using msvcp140.dll and vcruntime140.dll.

OK, so


https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/

says that for VS 2002, 2003, 2005, 2008, 2010, 2012, and 2013, the C/C++ 
run-time library version was tied to the compiler version, so that something 
built with version X had to use version X's CRT - meaning that if it used a 
dynamically-linked CRT, it needed to find the version X CRT's DLL.  It says 
that for VS 2015, the CRT was split into multiple parts, and that:

the VCRuntime, with vcruntimeXXX.dll names, is still tied to the 
compiler;

the AppCRT, with appcrtXXX.dll names, will have a stable ABI, so that 
Microsoft can update it for a new compiler but programs built with the older 
version will work with the newer version (i.e., the way the C/system library on 
UN*Xes with dynamically-linked shared libraries and ABI guarantees have worked 
since, err, umm, forever) - this library contains most of the routines that are 
directly called (including, I infer from the reference to "the heap", the 
memory allocation routines, as well as the "standard I/O library" routines that 
work with FILE *'s and *possibly* the UN*X-like I/O wrappers);

the DesktopCRT, with desktopcrtXXX.dll names, will also have a stable 
ABI - this library contains the remaining directly-called routines, with the 
ones not available in the Windows Store and Windows Phone platforms being in 
the DesktopCRT.

They also indicate that the libraries with msvcpXXX.dll are the STL libraries 
("cp" - "C Plus plus"?) and that those won't have a stable ABI.


https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

mentions the "Universal CRT", and says that the AppCRT and DesktopCRT were 
combined into the Universal CRT, with the names ucrtbase.dll for the release 
version and ucrtbased.dll for the debug version, with *no* version number, as 
it's not tied to the compiler.  To quote that post:

"1. The Universal CRT is a Windows operating system component. It is a 
part of Windows 10. For Windows versions prior to Windows 10, the Universal CRT 
is distributed via Windows Update. There are Windows Update MSU packages for 
Windows Vista through Windows 8.1. Currently these MSU packages are installed 
as part of the VCRedist installation. In a future build of Visual Studio 2015, 
these MSU packages will also be distributed separately as part of the Universal 
CRT SDK and made available for download on support.microsoft.com.

2. If you build software designed for use on Windows operating systems 
where the Universal CRT is not guaranteed to be installed (i.e., Windows 8.1 
and below), your software will need to depend on the above mentioned Windows 
Update packages to install the Universal CRT.

3. If you currently use the VCRedist (our redistributable package 
files), then things will just work for you as they did before. The Visual 
Studio 2015 VCRedist package includes the above mentioned Windows Update 
packages, so simply installing the VCRedist will install both the Visual C++ 
libraries and the Universal CRT. This is our recommended deployment mechanism. 
On Windows XP, for which there is no Universal CRT Windows Update MSU, the 
VCRedist will deploy the Universal CRT itself.

4. If you currently statically link the Visual C++ libraries, then 
things will continue to work just as they currently work for you.  We strongly 
recommend against static linking of the Visual C++ libraries, for both 
performance and serviceability reasons, but we recognize that there are some 
use cases that require static libraries and we will continue to support the 
static libraries for those reasons.

5. There will not be a merge module for the Universal CRT. If you 
currently use the CRT merge modules and still want to deploy the Visual C++ 
libraries centrally, we recommend that you move to the above mentioned Windows 
Update package or to the VCRedist. Alternatively, you may choose to link 
statically to the Universal CRT and the Visual C++ libraries.

6. Updated September 11, 2015:  App-local deployment of the Universal 
CRT is supported.  To obtain the binaries for app-local deployment, install the 
Windows Software Development Kit (SDK) for Windows 10.  The binaries will be 
installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt.  You will need 
to copy all of the DLLs with your app (note that the set of DLLs are necessary 
is different on 

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Roland Knall]

I'd second the shorter lifespan of 3.0. It also emphasizes the point, that
this is a major change release, and it should mature over time.

Roland

On Thu, Feb 15, 2018 at 6:55 PM, Anders Broman  wrote:

>
>
> Den 15 feb. 2018 6:41 em skrev "Gerald Combs" :
>
> On 2/14/18 11:08 PM, Alexis La Goutte wrote:
> >
> > 2.6 is TLS release ? i think it will be nice to kept support of 32bits
> and
> > drop for 3.0
>
> I think it makes sense to extend the release lifetime of 2.6 to 30 months.
> At the same time I'd like to avoid having more than three active stable
> releases at any given time. We'd either have to shorten the lifetime of 3.0
> to 18 or 20 months or delay the release of 3.2 or 3.4 to fall 2019 and fall
> 2020 respectively, or both.
>
>
> As we plan major changes in 3.0 perhaps it makes sense with a shorter
> lifespan?
> Regards
> Anders
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscr
> ibe
>
>
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> 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
>
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Anders Broman]

Den 15 feb. 2018 6:41 em skrev "Gerald Combs" :

On 2/14/18 11:08 PM, Alexis La Goutte wrote:
>
> 2.6 is TLS release ? i think it will be nice to kept support of 32bits and
> drop for 3.0

I think it makes sense to extend the release lifetime of 2.6 to 30 months.
At the same time I'd like to avoid having more than three active stable
releases at any given time. We'd either have to shorten the lifetime of 3.0
to 18 or 20 months or delay the release of 3.2 or 3.4 to fall 2019 and fall
2020 respectively, or both.


As we plan major changes in 3.0 perhaps it makes sense with a shorter
lifespan?
Regards
Anders

___
Sent via:Wireshark-dev mailing list 
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
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Gerald Combs]

On 2/14/18 11:08 PM, Alexis La Goutte wrote:
> 
> 2.6 is TLS release ? i think it will be nice to kept support of 32bits and
> drop for 3.0

I think it makes sense to extend the release lifetime of 2.6 to 30 months. At 
the same time I'd like to avoid having more than three active stable releases 
at any given time. We'd either have to shorten the lifetime of 3.0 to 18 or 20 
months or delay the release of 3.2 or 3.4 to fall 2019 and fall 2020 
respectively, or both.
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Alexis La Goutte]

On Thu, Feb 15, 2018 at 2:15 AM, Gerald Combs  wrote:

> On 2/14/18 2:27 AM, Pascal Quantin wrote:
> >
> >
> > 2018-02-14 11:24 GMT+01:00 Graham Bloice  > >:
> >
> >
> >
> > On 14 February 2018 at 06:24, Anders Broman  > > wrote:
> >
> >
> >
> > Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin"
> > >:
> >
> >
> >
> > Le 14 févr. 2018 02:24, "Gerald Combs"  > > a écrit :
> >
> > On 2/13/18 8:26 AM, Anders Broman wrote:
> > >
> > > For what it's worth I have been building and
> distributing
> > for VS 2017 for almost a year on Win7
> > > Cygwin and python set up as per developers guide from
> way
> > back.
> > > I have the following batch script I run in my cmd
> window
> > >
> > **
> 
> > > ** Visual Studio 2017 Developer Command Prompt v15.5.6
> > > ** Copyright (c) 2017 Microsoft Corporation
> > >
> > **
> 
> > > [vcvarsall.bat] Environment initialized for: 'x64'
> > >
> > > set CYGWIN=nodosfilewarning
> > > set WIRESHARK_BASE_DIR=C:\Development
> > > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> > > set WIRESHARK_TARGET_PLATFORM=win64
> > > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
> > Files\CMake\bin;C:\Python27
> > >
> > > Then
> > > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15
> Win64"
> > ..\wireshark
> > > and
> > > msbuild /m /p:Configuration=RelWithDebInfo
> Wireshark.sln
> > 2>&1 > log.txt
> >
> > Is there any reason we shouldn't switch to VS 2017 before
> > the 2.6 release?
> > It's installed on the main and PD Windows builders.
> >
> >
> > The availability of a 32bits Qt package for MSVC2017? I would
> > find it a bit weird to use MSVC2015 for the x86 binary and
> > MSVC2017 for the x64 one.
> >
> >
> > Do we still need to build for 32 bits?
> >
> >
> >
> > Personally I'd be happy to drop the 32 bit version, what the rest of
> > the world would make of it, I'm not so sure.
> >
> >
> > I guess a good indicator would be how often the x86 variant is
> downloaded.
> > Gerald, do you have this number?
>
> Last month about 19% of our downloads were for the 32-bit installer and 7%
> were for the PortableApps package. The percentage of 32-bit installs is
> steadily decreasing over time, but we're not close to zero yet.
>
> As far as library compatibility goes, according to
>
> https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017
>
> we *should* be able to build using Visual C++ 2017 and use libraries
> compiled with Visual C++ 2015. I did a test build here using Visual C++
> 2017 and the "msvc2015" Qt component here and it seems to work OK.
> Dependencies[1] reports that it's using msvcp140.dll and vcruntime140.dll.
>
> I went ahead and switched the Windows master and PD builders over. The
> 64-bit builders are now using the Qt 5.9.4 "msvc2017 64-bit" component and
> the 32-bit builder is using the "msvc2015 32-bit" component. If that
> doesn't work we can try the "MinGW 5.3.0 32-bit" component. We can also
> switch back to Visual C++ 2015 if needed.
>
> [1]https://github.com/lucasg/Dependencies


2.6 is TLS release ? i think it will be nice to kept support of 32bits and
drop for 3.0

Cheers

>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> 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
>
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Gerald Combs]

On 2/9/18 8:51 AM, Ed Beroset wrote:
> 
> Specifying platform
> ===
> I used this command for CMake:
> 
> cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 2017 Win64" ..
> 
> I found that I had to explicitly specify the platform when using msbuild. 
> For example, to build a Release version on my machine:
> 
> msbuild /m /p:Configuration=Release /p:Platform=x64 Wireshark.sln
> 
> I don't yet know enough about msbuild or sln files to troubleshoot much
> further, but that worked for me.

I had a similar problem building 32-bit code on a 64-bit Windows VM here. The 
setup script that the "x64_x86 Cross Tools Command Prompt for VS 2017" link 
calls sets Platform=x86. However, `CMake -G "Visual Studio 15 2017"` creates 
project files that match the "Win32" platform. "Platform" and "Configuration" 
are environment properties[1], so it was easy enough to fix by setting 
Platform=Win32. You should be able to do the same thing in your environment.

[1]https://msdn.microsoft.com/en-us/library/ms171458.aspx
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Roland Knall]

Should start to bookmark that page ;-)

Just saying, we have to support 2.2 until the end of the year, so removing
libraries might lead to issues.

But otherwise, I think we can handle dropping 32bit support, and just note
in the building instructions, that people cannot rely on the fact, that we
have tested the versions for 32bit.

cheers
Roland

On Wed, Feb 14, 2018 at 11:56 AM, Graham Bloice  wrote:

>
>
> On 14 February 2018 at 10:29, Roland Knall  wrote:
>
>> The question from me would be, would this also mean dropping support for
>> older Windows versions?
>>
>> It will definitely cut off WinXP, but could also cut off a Win7-32bit
>> version? Not sure if such a version exists, but those are also applicable
>> to their Windows Server counter-part.
>>
>> I am all for dropping support on older versions, but some users might
>> never be able to switch, as they are fixed to their Windows version. (ISS
>> for a more fun and exotic example, ;-) )
>>
>> Just something to discuss I guess.
>>
>>
>>
> The last version to officially support XP was 1.10.  The last version to
> support Server 2003 was 1.12.  The last version to officially support vista
> was 2.2.  The last 32 bit OSX version was 2.0.
>
> See the lifecycle page for more info: https://wiki.wireshark.org/
> Development/LifeCycle.
>
>
>>
>> On Wed, Feb 14, 2018 at 11:24 AM, Graham Bloice > l.com> wrote:
>>
>>>
>>>
>>> On 14 February 2018 at 06:24, Anders Broman 
>>> wrote:
>>>


 Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" <
 pascal.quan...@gmail.com>:



 Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :

 On 2/13/18 8:26 AM, Anders Broman wrote:
 >
 > For what it's worth I have been building and distributing for VS 2017
 for almost a year on Win7
 > Cygwin and python set up as per developers guide from way back.
 > I have the following batch script I run in my cmd window
 > 
 **
 > ** Visual Studio 2017 Developer Command Prompt v15.5.6
 > ** Copyright (c) 2017 Microsoft Corporation
 > 
 **
 > [vcvarsall.bat] Environment initialized for: 'x64'
 >
 > set CYGWIN=nodosfilewarning
 > set WIRESHARK_BASE_DIR=C:\Development
 > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
 > set WIRESHARK_TARGET_PLATFORM=win64
 > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
 Files\CMake\bin;C:\Python27
 >
 > Then
 > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
 > and
 > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 >
 log.txt

 Is there any reason we shouldn't switch to VS 2017 before the 2.6
 release?
 It's installed on the main and PD Windows builders.


 The availability of a 32bits Qt package for MSVC2017? I would find it a
 bit weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.


 Do we still need to build for 32 bits?



>>> Personally I'd be happy to drop the 32 bit version, what the rest of the
>>> world would make of it, I'm not so sure.
>>>
>>>
>>> --
>>> Graham Bloice
>>>
>>
>> On Wed, Feb 14, 2018 at 11:27 AM, Pascal Quantin <
>> pascal.quan...@gmail.com> wrote:
>>
>>>
>>>
>>> 2018-02-14 11:24 GMT+01:00 Graham Bloice :
>>>


 On 14 February 2018 at 06:24, Anders Broman 
 wrote:

>
>
> Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" <
> pascal.quan...@gmail.com>:
>
>
>
> Le 14 févr. 2018 02:24, "Gerald Combs"  a
> écrit :
>
> On 2/13/18 8:26 AM, Anders Broman wrote:
> >
> > For what it's worth I have been building and distributing for VS
> 2017 for almost a year on Win7
> > Cygwin and python set up as per developers guide from way back.
> > I have the following batch script I run in my cmd window
> > 
> **
> > ** Visual Studio 2017 Developer Command Prompt v15.5.6
> > ** Copyright (c) 2017 Microsoft Corporation
> > 
> **
> > [vcvarsall.bat] Environment initialized for: 'x64'
> >
> > set CYGWIN=nodosfilewarning
> > set WIRESHARK_BASE_DIR=C:\Development
> > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> > set WIRESHARK_TARGET_PLATFORM=win64
> > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
> Files\CMake\bin;C:\Python27
> >
> > Then
> > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> > and
> > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 >
> log.txt
>

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Graham Bloice]

On 14 February 2018 at 10:29, Roland Knall  wrote:

> The question from me would be, would this also mean dropping support for
> older Windows versions?
>
> It will definitely cut off WinXP, but could also cut off a Win7-32bit
> version? Not sure if such a version exists, but those are also applicable
> to their Windows Server counter-part.
>
> I am all for dropping support on older versions, but some users might
> never be able to switch, as they are fixed to their Windows version. (ISS
> for a more fun and exotic example, ;-) )
>
> Just something to discuss I guess.
>
>
>
The last version to officially support XP was 1.10.  The last version to
support Server 2003 was 1.12.  The last version to officially support vista
was 2.2.  The last 32 bit OSX version was 2.0.

See the lifecycle page for more info:
https://wiki.wireshark.org/Development/LifeCycle.


>
> On Wed, Feb 14, 2018 at 11:24 AM, Graham Bloice  trihedral.com> wrote:
>
>>
>>
>> On 14 February 2018 at 06:24, Anders Broman  wrote:
>>
>>>
>>>
>>> Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" <
>>> pascal.quan...@gmail.com>:
>>>
>>>
>>>
>>> Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :
>>>
>>> On 2/13/18 8:26 AM, Anders Broman wrote:
>>> >
>>> > For what it's worth I have been building and distributing for VS 2017
>>> for almost a year on Win7
>>> > Cygwin and python set up as per developers guide from way back.
>>> > I have the following batch script I run in my cmd window
>>> > **
>>> > ** Visual Studio 2017 Developer Command Prompt v15.5.6
>>> > ** Copyright (c) 2017 Microsoft Corporation
>>> > **
>>> > [vcvarsall.bat] Environment initialized for: 'x64'
>>> >
>>> > set CYGWIN=nodosfilewarning
>>> > set WIRESHARK_BASE_DIR=C:\Development
>>> > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
>>> > set WIRESHARK_TARGET_PLATFORM=win64
>>> > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
>>> Files\CMake\bin;C:\Python27
>>> >
>>> > Then
>>> > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
>>> > and
>>> > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 >
>>> log.txt
>>>
>>> Is there any reason we shouldn't switch to VS 2017 before the 2.6
>>> release?
>>> It's installed on the main and PD Windows builders.
>>>
>>>
>>> The availability of a 32bits Qt package for MSVC2017? I would find it a
>>> bit weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.
>>>
>>>
>>> Do we still need to build for 32 bits?
>>>
>>>
>>>
>> Personally I'd be happy to drop the 32 bit version, what the rest of the
>> world would make of it, I'm not so sure.
>>
>>
>> --
>> Graham Bloice
>>
>
> On Wed, Feb 14, 2018 at 11:27 AM, Pascal Quantin  > wrote:
>
>>
>>
>> 2018-02-14 11:24 GMT+01:00 Graham Bloice :
>>
>>>
>>>
>>> On 14 February 2018 at 06:24, Anders Broman 
>>> wrote:
>>>


 Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" <
 pascal.quan...@gmail.com>:



 Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :

 On 2/13/18 8:26 AM, Anders Broman wrote:
 >
 > For what it's worth I have been building and distributing for VS 2017
 for almost a year on Win7
 > Cygwin and python set up as per developers guide from way back.
 > I have the following batch script I run in my cmd window
 > 
 **
 > ** Visual Studio 2017 Developer Command Prompt v15.5.6
 > ** Copyright (c) 2017 Microsoft Corporation
 > 
 **
 > [vcvarsall.bat] Environment initialized for: 'x64'
 >
 > set CYGWIN=nodosfilewarning
 > set WIRESHARK_BASE_DIR=C:\Development
 > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
 > set WIRESHARK_TARGET_PLATFORM=win64
 > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
 Files\CMake\bin;C:\Python27
 >
 > Then
 > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
 > and
 > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 >
 log.txt

 Is there any reason we shouldn't switch to VS 2017 before the 2.6
 release?
 It's installed on the main and PD Windows builders.


 The availability of a 32bits Qt package for MSVC2017? I would find it a
 bit weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.


 Do we still need to build for 32 bits?



>>> Personally I'd be happy to drop the 32 bit version, what the rest of the
>>> world would make of it, I'm not so sure.
>>>
>>
>> I guess a good indicator would be how often the x86 variant is
>> downloaded. Gerald, do you have 

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Anders Broman]

Hi,
Also remember we are not dropping support for building with older/other Visual 
Studio versions per-se, just not producing packages/verifying them at this 
point.
We will not pick up breakage ourselves though. I guess it will be a problem if 
we update any of the support libraries ☹ But we could let them stay at the 
current level.
If there is people interested in the 32bit version they can perhaps assist in 
checking 32bit builds and help update the support libraries?
Regards
Anders

From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Roland Knall
Sent: den 14 februari 2018 11:29
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Subject: Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

The question from me would be, would this also mean dropping support for older 
Windows versions?

It will definitely cut off WinXP, but could also cut off a Win7-32bit version? 
Not sure if such a version exists, but those are also applicable to their 
Windows Server counter-part.

I am all for dropping support on older versions, but some users might never be 
able to switch, as they are fixed to their Windows version. (ISS for a more fun 
and exotic example, ;-) )

Just something to discuss I guess.



On Wed, Feb 14, 2018 at 11:24 AM, Graham Bloice 
<graham.blo...@trihedral.com<mailto:graham.blo...@trihedral.com>> wrote:


On 14 February 2018 at 06:24, Anders Broman 
<a.broma...@gmail.com<mailto:a.broma...@gmail.com>> wrote:


Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" 
<pascal.quan...@gmail.com<mailto:pascal.quan...@gmail.com>>:


Le 14 févr. 2018 02:24, "Gerald Combs" 
<ger...@wireshark.org<mailto:ger...@wireshark.org>> a écrit :
On 2/13/18 8:26 AM, Anders Broman wrote:
>
> For what it's worth I have been building and distributing for VS 2017 for 
> almost a year on Win7
> Cygwin and python set up as per developers guide from way back.
> I have the following batch script I run in my cmd window
> **
> ** Visual Studio 2017 Developer Command Prompt v15.5.6
> ** Copyright (c) 2017 Microsoft Corporation
> **
> [vcvarsall.bat] Environment initialized for: 'x64'
>
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=C:\Development
> set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> set WIRESHARK_TARGET_PLATFORM=win64
> set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program Files\CMake\bin;C:\Python27
>
> Then
> cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> and
> msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt
Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
It's installed on the main and PD Windows builders.

The availability of a 32bits Qt package for MSVC2017? I would find it a bit 
weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.

Do we still need to build for 32 bits?


Personally I'd be happy to drop the 32 bit version, what the rest of the world 
would make of it, I'm not so sure.

--
Graham Bloice

___
Sent via:Wireshark-dev mailing list 
<wireshark-dev@wireshark.org<mailto: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<mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe


On Wed, Feb 14, 2018 at 11:27 AM, Pascal Quantin 
<pascal.quan...@gmail.com<mailto:pascal.quan...@gmail.com>> wrote:


2018-02-14 11:24 GMT+01:00 Graham Bloice 
<graham.blo...@trihedral.com<mailto:graham.blo...@trihedral.com>>:


On 14 February 2018 at 06:24, Anders Broman 
<a.broma...@gmail.com<mailto:a.broma...@gmail.com>> wrote:


Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" 
<pascal.quan...@gmail.com<mailto:pascal.quan...@gmail.com>>:


Le 14 févr. 2018 02:24, "Gerald Combs" 
<ger...@wireshark.org<mailto:ger...@wireshark.org>> a écrit :
On 2/13/18 8:26 AM, Anders Broman wrote:
>
> For what it's worth I have been building and distributing for VS 2017 for 
> almost a year on Win7
> Cygwin and python set up as per developers guide from way back.
> I have the following batch script I run in my cmd window
> **
> ** Visual Studio 2017 Developer Command Prompt v15.5.6
> ** Copyright (c) 2017 Microsoft Corporation
> **
> [vcvarsall.bat] Environment initialized for: 'x64'
>
> set CYGWIN=nodos

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Pascal Quantin]

2018-02-14 11:24 GMT+01:00 Graham Bloice :

>
>
> On 14 February 2018 at 06:24, Anders Broman  wrote:
>
>>
>>
>> Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" > >:
>>
>>
>>
>> Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :
>>
>> On 2/13/18 8:26 AM, Anders Broman wrote:
>> >
>> > For what it's worth I have been building and distributing for VS 2017
>> for almost a year on Win7
>> > Cygwin and python set up as per developers guide from way back.
>> > I have the following batch script I run in my cmd window
>> > **
>> > ** Visual Studio 2017 Developer Command Prompt v15.5.6
>> > ** Copyright (c) 2017 Microsoft Corporation
>> > **
>> > [vcvarsall.bat] Environment initialized for: 'x64'
>> >
>> > set CYGWIN=nodosfilewarning
>> > set WIRESHARK_BASE_DIR=C:\Development
>> > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
>> > set WIRESHARK_TARGET_PLATFORM=win64
>> > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
>> Files\CMake\bin;C:\Python27
>> >
>> > Then
>> > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
>> > and
>> > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt
>>
>> Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
>> It's installed on the main and PD Windows builders.
>>
>>
>> The availability of a 32bits Qt package for MSVC2017? I would find it a
>> bit weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.
>>
>>
>> Do we still need to build for 32 bits?
>>
>>
>>
> Personally I'd be happy to drop the 32 bit version, what the rest of the
> world would make of it, I'm not so sure.
>

I guess a good indicator would be how often the x86 variant is downloaded.
Gerald, do you have this number?
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Graham Bloice]

On 14 February 2018 at 06:24, Anders Broman  wrote:

>
>
> Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin"  >:
>
>
>
> Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :
>
> On 2/13/18 8:26 AM, Anders Broman wrote:
> >
> > For what it's worth I have been building and distributing for VS 2017
> for almost a year on Win7
> > Cygwin and python set up as per developers guide from way back.
> > I have the following batch script I run in my cmd window
> > **
> > ** Visual Studio 2017 Developer Command Prompt v15.5.6
> > ** Copyright (c) 2017 Microsoft Corporation
> > **
> > [vcvarsall.bat] Environment initialized for: 'x64'
> >
> > set CYGWIN=nodosfilewarning
> > set WIRESHARK_BASE_DIR=C:\Development
> > set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> > set WIRESHARK_TARGET_PLATFORM=win64
> > set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
> Files\CMake\bin;C:\Python27
> >
> > Then
> > cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> > and
> > msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt
>
> Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
> It's installed on the main and PD Windows builders.
>
>
> The availability of a 32bits Qt package for MSVC2017? I would find it a
> bit weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.
>
>
> Do we still need to build for 32 bits?
>
>
>
Personally I'd be happy to drop the 32 bit version, what the rest of the
world would make of it, I'm not so sure.

-- 
Graham Bloice
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Anders Broman]

Den 14 feb. 2018 6:58 fm skrev "Pascal Quantin" :



Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :

On 2/13/18 8:26 AM, Anders Broman wrote:
>
> For what it's worth I have been building and distributing for VS 2017 for
almost a year on Win7
> Cygwin and python set up as per developers guide from way back.
> I have the following batch script I run in my cmd window
> **
> ** Visual Studio 2017 Developer Command Prompt v15.5.6
> ** Copyright (c) 2017 Microsoft Corporation
> **
> [vcvarsall.bat] Environment initialized for: 'x64'
>
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=C:\Development
> set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> set WIRESHARK_TARGET_PLATFORM=win64
> set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
Files\CMake\bin;C:\Python27
>
> Then
> cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> and
> msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt

Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
It's installed on the main and PD Windows builders.


The availability of a 32bits Qt package for MSVC2017? I would find it a bit
weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.


Do we still need to build for 32 bits?


___
Sent via:Wireshark-dev mailing list 
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
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Pascal Quantin]

Le 14 févr. 2018 02:24, "Gerald Combs"  a écrit :

On 2/13/18 8:26 AM, Anders Broman wrote:
>
> For what it's worth I have been building and distributing for VS 2017 for
almost a year on Win7
> Cygwin and python set up as per developers guide from way back.
> I have the following batch script I run in my cmd window
> **
> ** Visual Studio 2017 Developer Command Prompt v15.5.6
> ** Copyright (c) 2017 Microsoft Corporation
> **
> [vcvarsall.bat] Environment initialized for: 'x64'
>
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=C:\Development
> set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> set WIRESHARK_TARGET_PLATFORM=win64
> set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program
Files\CMake\bin;C:\Python27
>
> Then
> cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> and
> msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt

Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
It's installed on the main and PD Windows builders.


The availability of a 32bits Qt package for MSVC2017? I would find it a bit
weird to use MSVC2015 for the x86 binary and MSVC2017 for the x64 one.
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Gerald Combs]

On 2/13/18 8:26 AM, Anders Broman wrote:
> 
> For what it's worth I have been building and distributing for VS 2017 for 
> almost a year on Win7
> Cygwin and python set up as per developers guide from way back. 
> I have the following batch script I run in my cmd window 
> **
> ** Visual Studio 2017 Developer Command Prompt v15.5.6
> ** Copyright (c) 2017 Microsoft Corporation
> **
> [vcvarsall.bat] Environment initialized for: 'x64'
> 
> set CYGWIN=nodosfilewarning
> set WIRESHARK_BASE_DIR=C:\Development
> set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
> set WIRESHARK_TARGET_PLATFORM=win64
> set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program Files\CMake\bin;C:\Python27
> 
> Then
> cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
> and
> msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt

Is there any reason we shouldn't switch to VS 2017 before the 2.6 release?
It's installed on the main and PD Windows builders.
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] report from the bleeding edge (VS 2017)

[Anders Broman]

-Original Message-
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Ed Beroset
Sent: den 9 februari 2018 17:52
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] report from the bleeding edge (VS 2017)

On 04/24/2017 01:01 PM, Graham Bloice wrote:

> Who knows what will be in the next Visual Studio.  I haven't seen any 
> announcements, but as VS 2017 was only released just over a month ago 
> I don't expect any public announcements yet.
> 
> It's possible that future C++ language changes may force them to 
> change the ABI.

I have been working through building an installer package on and for
Win64 on Windows 10 using VS 2017 and NSIS 3.03, so I thought I'd send this 
report from the bleeding edge.

Cylance vs. Cygwin
==
"BLODA" is the Cygwin acronym for "Big List Of Dodgy Apps" and unfortunately, I 
have discovered another one, which is Cylance which is anti-malware software 
(despite both starting with "cy" they have no relationship).  For background on 
that, see https://cygwin.com/faq/faq.html#faq.using.bloda and 
https://cygwin.com/ml/cygwin/2017-04/msg00319.html

I have been able to work around this by getting my IT folks to whitelist the 
following cygwin executables:
xterm.exe
git.exe
perl.exe
python2.7.exe

That seems to have been sufficient (so far) to get Wireshark to compile (for 
building Wireshark, it's probably not necessary to have xterm.exe but I use 
xterm often and it annoyed me!). Although it's more of a Cygwin than a 
Wireshark issue, I mention it here in case anyone encounters this problem and 
does a search.

Specifying platform
===
I used this command for CMake:

cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 2017 Win64" ..

I found that I had to explicitly specify the platform when using msbuild.  For 
example, to build a Release version on my machine:

msbuild /m /p:Configuration=Release /p:Platform=x64 Wireshark.sln

I don't yet know enough about msbuild or sln files to troubleshoot much 
further, but that worked for me.

Results
===
I haven't yet done thorough testing, but the installer, Wireshark and Tshark 
all seem to be to working correctly.

Hope that helps.

Ed

For what it's worth I have been building and distributing for VS 2017 for 
almost a year on Win7
Cygwin and python set up as per developers guide from way back. 
I have the following batch script I run in my cmd window 
**
** Visual Studio 2017 Developer Command Prompt v15.5.6
** Copyright (c) 2017 Microsoft Corporation
**
[vcvarsall.bat] Environment initialized for: 'x64'

set CYGWIN=nodosfilewarning
set WIRESHARK_BASE_DIR=C:\Development
set QT5_BASE_DIR=C:\Qt\5.9.4\msvc2017_64
set WIRESHARK_TARGET_PLATFORM=win64
set PATH=path=%PATH%;C:\cygwin64\bin;C:\Program Files\CMake\bin;C:\Python27

Then
cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 Win64" ..\wireshark
and
msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln 2>&1 > log.txt

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

[Wireshark-dev] report from the bleeding edge (VS 2017)

[Ed Beroset]

On 04/24/2017 01:01 PM, Graham Bloice wrote:

Who knows what will be in the next Visual Studio.  I haven't seen any 
announcements, but as VS 2017 was only released just over a month ago I 
don't expect any public announcements yet.


It's possible that future C++ language changes may force them to change 
the ABI.


I have been working through building an installer package on and for 
Win64 on Windows 10 using VS 2017 and NSIS 3.03, so I thought I'd send 
this report from the bleeding edge.


Cylance vs. Cygwin
==
"BLODA" is the Cygwin acronym for "Big List Of Dodgy Apps" and 
unfortunately, I have discovered another one, which is Cylance which is 
anti-malware software (despite both starting with "cy" they have no 
relationship).  For background on that, see 
https://cygwin.com/faq/faq.html#faq.using.bloda and 
https://cygwin.com/ml/cygwin/2017-04/msg00319.html


I have been able to work around this by getting my IT folks to whitelist 
the following cygwin executables:

xterm.exe
git.exe
perl.exe
python2.7.exe

That seems to have been sufficient (so far) to get Wireshark to compile 
(for building Wireshark, it's probably not necessary to have xterm.exe 
but I use xterm often and it annoyed me!). Although it's more of a 
Cygwin than a Wireshark issue, I mention it here in case anyone 
encounters this problem and does a search.


Specifying platform
===
I used this command for CMake:

cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 2017 Win64" ..

I found that I had to explicitly specify the platform when using 
msbuild.  For example, to build a Release version on my machine:


msbuild /m /p:Configuration=Release /p:Platform=x64 Wireshark.sln

I don't yet know enough about msbuild or sln files to troubleshoot much 
further, but that worked for me.


Results
===
I haven't yet done thorough testing, but the installer, Wireshark and 
Tshark all seem to be to working correctly.


Hope that helps.

Ed
___
Sent via:Wireshark-dev mailing list 
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