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)

[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]

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 
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 
> wrote:


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


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" 
>:


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
> 

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 

[Wireshark-dev] Qt column sorting?

[Anders Broman]

Hi,
It looks to me that if you sort on a column different from Frame no and apply a 
filter you get redissection and then sort(possibly with redissection). If you 
have a filter applied and
Do a column sort it looks like the packets are redissected.
This seems like it should not be required to me.
Best 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

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] Qt column sorting?

[Roland Knall]

Not at the current data model. We store and sort in epan, not in Qt. The
later would allow to sort without epan knowing, currently, that is not how
it is implemented.

I think this could be changed, would wait for 2.6 or 3.0 though

cheers
Roland

On Wed, Feb 14, 2018 at 9:33 PM, Anders Broman  wrote:

>
>
> Den 14 feb. 2018 20:24 skrev "Guy Harris" :
>
> On Feb 14, 2018, at 6:53 AM, Anders Broman 
> wrote:
>
> > It looks to me that if you sort on a column different from Frame no and
> apply a filter you get redissection
>
> In order to get the contents of the column on which the sort is being done?
>
> (Storing the contents persistently, rather than regenerating them as
> needed, would significantly increase the memory required per packet.)
>
> In The old packet list we stored at least some of the column data I think.
> Still shouldn't it be possible to redissect and sort in one go?
> 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] Qt column sorting?

[Anders Broman]

Den 14 feb. 2018 20:24 skrev "Guy Harris" :

On Feb 14, 2018, at 6:53 AM, Anders Broman 
wrote:

> It looks to me that if you sort on a column different from Frame no and
apply a filter you get redissection

In order to get the contents of the column on which the sort is being done?

(Storing the contents persistently, rather than regenerating them as
needed, would significantly increase the memory required per packet.)

In The old packet list we stored at least some of the column data I think.
Still shouldn't it be possible to redissect and sort in one go?
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] Qt column sorting?

[Guy Harris]

On Feb 14, 2018, at 6:53 AM, Anders Broman  wrote:

> It looks to me that if you sort on a column different from Frame no and apply 
> a filter you get redissection

In order to get the contents of the column on which the sort is being done?

(Storing the contents persistently, rather than regenerating them as needed, 
would significantly increase the memory required per packet.)
___
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] Qt column sorting?

[Guy Harris]

On Feb 14, 2018, at 12:33 PM, Anders Broman  wrote:

> In The old packet list we stored at least some of the column data I think.

We might have done so in older GTK+ versions, but I think we've been generating 
columns as needed for a while now, in both GTK+ and Qt.
___
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] Qt column sorting?

[Roland Knall]

The proxy model should work, but leads to other issues, because of the way
we store the data. But it is definitely the way going forward, but as
mentioned, I would wait for 3.0, as it could mean (not necessarily, but I
would not bet against it) that the underlying model either has to learn
things or needs to forget things.

Sorting btw could be easier, but filtering needs the display filter model
to be incorporated and this seems to be the main issue

cheers
Roland

On Wed, Feb 14, 2018 at 11:14 PM, Guy Harris  wrote:

> On Feb 14, 2018, at 1:24 PM, Roland Knall  wrote:
>
> > Not at the current data model. We store and sort in epan, not in Qt. The
> later would allow to sort without epan knowing, currently, that is not how
> it is implemented.
> >
> > I think this could be changed, would wait for 2.6 or 3.0 though
>
> For example, using a proxy model, as per
>
> https://www.wireshark.org/lists/wireshark-dev/201506/msg00088.html
> 
> ___
> 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] Qt column sorting?

[Guy Harris]

On Feb 14, 2018, at 1:24 PM, Roland Knall  wrote:

> Not at the current data model. We store and sort in epan, not in Qt. The 
> later would allow to sort without epan knowing, currently, that is not how it 
> is implemented.
> 
> I think this could be changed, would wait for 2.6 or 3.0 though

For example, using a proxy model, as per

https://www.wireshark.org/lists/wireshark-dev/201506/msg00088.html
___
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