ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1287] Problem with capturing on an Acc

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 02 Jan 2007 00:56:07 +0100
Gerald Combs wrote:
There are a couple of vulnerabilities that have been found and fixed
since the past release as well.  I'll start making preparations for
another prerelease/release cycle.  Does anyone have time to work on the
major roadmap items (version checking, updating, or online help)?  I can
probably look at version checking.
... back from holidays and still a lot of things to do ...

I'm currently in the process of installing the MSVC 2005 Express Edition (the Platform SDK provides me some trouble). Once the MSVC 2005 build process is running, I will concentrate on the major road map items again.

The online help should be nearly ready - at least for Win32. I've added a Help button to most dialogs that made sense to me and the links to the guide are also ready. To enable it, uncomment the ENABLE_WSUG=USE (line 356) and rebuild all. There's one thing left over: The buildbot is doing the "built docs" as the last step. Obviously, the docs must be generated at least before the "created package" step (maybe even before the compiling step). Gerald, could you please change this sequence in the Win32 buildbot? Then we can simply enable the setting in config.nmake. BTW: this requires everyone to set up the documentation build environment - or disable it in the config.nmake file.

The version checking and updating is a single item in my eyes. I've done some experiments with downloading a file from the internet (derived from the Win32 cygwin setup program) - downloading is already working good (maybe a progress bar should be added). I've also added some basic updating stuff - some data structures and some code, but this is far from complete. I'll check in this stuff (after some cleanup) so you can have a look at it.

Not in the road map, but maybe also worth to be added: Currently if we're running out of memory - we usually get a "strange" assert message from emem.c (there were already some bugzillas about it). It would be much better to inform the user about the problem in a somewhat more informative way, e.g. if the problem happens while capturing, mention the file name and location - maybe with a link to the wiki explaining this. I've experimented to add a new Exception "OutOfMemoryError" so we can catch that exception where e.g. the file information is really available. However, this really needs - as well - a code cleanup before I can commit that stuff.

So much work, so little time ... :-(

Regards, ULFL