[Ulf Lamping <ulf.lamping@xxxxxx>]

John T. Haller wrote:
> If you mean the HostCleanup processes, be sure you're not doing anything
> critical within them as they are not guaranteed to run.  Obviously, if
> the PC crashes, they never run (which most people know) but if you turn
> the PC off with the drive in, the U3 platform never shuts down.  So,
> even if you closed Wireshark for U3 and then shut the PC off (or put it
> to sleep), the HostCleanup will not be run.  It's best to have any
> cleanup stuff run as the app closes as I do with all the portable apps
> (and as I did with the U3 versions of them: Firefox, Thunderbird, etc).
>   
Well, having a single "eject" button is a nice way to close all apps 
you've opened from the stick. It's easier than to close the apps opened 
from the stick one by one.

And yes, I've already noted that the U3 eject doesn't work all the time ;-)
> I personally recommend a commandline option as this provides the most
> flexibility.  That way the end user has complete control should they
> want it.  Firefox, Thunderbird, etc all provide commandline switches for
> this.  And, you could use this same commandline switch for your U3
> package (no need to check for the environment variables = less code).
>
>   
Well, someone *has* to check for the U3 env settings, so in effect 
there's no difference in code length.

I'm not sure, but if the U3 WS is started through a special launcher, 
the U3 specific code to get the dir(s) could be moved to that launcher, 
making the WS code cleaner.
> Now that is a tad odd.  It is unfortunate, too, as that would completely 
> preclude me from hosting it on SourceForge.
>
>  From what I've analyzed, it installs the following files:
> %WINDIR%\system32\Packet.dll
> %WINDIR%\system32\pthreadVC.dll
> %WINDIR%\system32\WanPacket.dll
> %WINDIR%\system32\wpcap.dll
> %WINDIR%\system32\drivers\npf.sys
>
> The Packet.dll and npf.sys files appear to vary depending on the OS 
> (probably different ones for Windows 98, etc) as there are 3 variations 
> of each in the installer.  It does more than simple regsvr32 them as 
> well, since it appears to need to hook it's network driver to each 
> interface on the system.  I can run a registry and file system 
> comparison to get a rough idea of this.
>
>   
First of all, you may have a look at our System Requirements, 
http://www.wireshark.org/docs/wsug_html_chunked/ChIntroPlatforms.html

We don't support Win9x,NT so there's no need (at least for WS) for the 
WinPcap install to support these systems (WinPcap officially doesn't 
support 9x any longer since 4.0).

AFAIK, it will be registered as a network protocol driver, which is 
pretty tricky to do. Some time ago I tried to find some OSS source how 
to do this but didn't found anything :-(((

If you find some good infos about it on the web (or through your own 
work), please let me know...
> Even without the WinPCap installer, we'll need admin rights for this as 
> it will require access to the drivers setup within Windows.  There's no 
> way around that unfortunately.
>   
ACK
> The standard setup would be:
>
> X:\PortableApps\
> ------\WiresharkPortable\  (this is where WiresharkPortable.exe lives)
> ------------\App\
> ------------------\wireshark\  (all Wireshark's binaries live here)
> ------------------\winpcap\  (winpcap installer, just to keep it neat)
> ------------\Data\  (this would contain any user settings files, etc)
>
> Obviously, Wireshark Portable would only be concerned with its bits 
> inside its own directories.  that's one of the nice things about 
> portable apps.  And that WiresharkPortable.exe launcher would handle the 
> whole:
> 1. Detect if WinPCap is installed, if not, install it
> 2. Run Wireshark and pass it the commandline switch... something like:
>     wireshark.exe -datapath=X:\PortableApps\WireSharkPortable\Data
> 3. Stick around until Wireshark finishes
> 4. Uninstall WinPCap if we installed it on Wireshark exit
>
>   
Sounds reasonable. This way you can easily update the application 
without loosing your user settings.

This unfortunately will install/uninstall WinPcap each time you start 
Wireshark.
> > - where do we get one of those fancy splash screens for Wireshark from? 
> > Might be derived from the current splash screen picture ;-)
> >     
>
> Oh, you'll get one of those, too :-)  And you'll be able to 
> edit/maintain the Wireshark Portable page on PortableApps.com if you'd like.
>   
Yes, would like that.

I'm occasionally updating screenshots, ...
> Ok, if you can get me a Wireshark build that accepts a commandline 
> parameter pointing it to its data and let me know how you check for PCap 
> being installed (is just checking for the DLL enough?) I can get you a 
> test portable build... fancy splash screen and all.  Oh, and I started 
> checking out compression and I can get the Wireshark install from 68MB 
> down to 22MB using UPX compress with specific settings on the DLLs and 
> EXEs.  I have a script that takes care of this I can give ya.  I can 
> package this all up in a PAF (it stands for PortableApps.com Format) so 
> it can be installed by anyone by itself or auto-installed into the 
> PortableApps.com Menu (it's under Options).
>   
I'll see what I can do about the command line (shouldn't be too 
difficult), however the available time is the limit :-(

WinPcap is loaded in capture-wpcap.c, in function load_wpcap(). It 
simply calls the glib function to load a DLL:

g_module_open("wpcap", 0);

and then looks for the available functions.


Today I've noticed the "standalone" portableapps.com menu application - 
I didn't tried it because I don't needed the "huge" package and didn't 
noticed the standalone package on a "quick view". You might want to make 
the standalone package a bit more "visually prominent" on 
http://portableapps.com/suite :-)


Is this paf format something special of simply a zip file with some meta 
information/structure?

If the build process is not too difficult, we might even want to add the 
paf build into the WS build process, as developers frequently need 
*very* recent versions for test/debug purposes - but that is obviously 
not the first step :-)

Regards, ULFL