On Oct 18, 2012, at 4:18 AM, Anders Broman <anders.broman@xxxxxxxxxxxx> wrote:
> I changed most occurrences in the nsi installer of wireshark to ${PROGRAM_NAME} and also in some places of
> Makefile.nmake in error as it now seems. So at least as convention (on windows) we used wireshark/Wireshark
> (As file names are case insensitive on Windows I don't think capital W or not matters).
> For:
> - Part of the program installation path (InstallDir $PROGRAMFILES\Wireshark)
> - Name of the wireshark executable (wireshark.exe)
> - part of the path name to personal configuration files (%APPDATA%/Wireshark)
>
> So should I drop this completely and back out the changes done so far?
I think the high-order bit is that, if you're going to make the file name of the personal configuration directory configurable, the code must *not* determine the file name by looking at the last component of the path name of the executable - that means that Wireshark and TShark would have different personal configuration directories in the *standard* Wireshark package, which is a radical change and is probably an undesirable change.
I think it would also be highly desirable that, if you run Wireshark from the build directory, it be able to find the personal configuration files appropriate to that version of Wireshark.
Given that, I think it would be best if the personal configuration directory name be configurable at *compile time*, i.e. be set with a #define in, for example, config.nmake.
I suspect that whoever's building the version of Wireshark knows whether it would require a separate set of configuration files or not, so I think that the personal configuration directory name should just default to "Wireshark" on Windows, regardless of the name of the directory under $PROGRAMFILES into which it's installed or the name given to any of the executable images, and have the configuration #define in config.nmake be independent of the name of the directory under $PROGRAMFILES into which it's installed or, *if* that's configurable, the name of the Wireshark executable image. That would allow somebody to build a special version of Wireshark that *can* use the same personal configuration directory as the standard version.
That also would allow special versions of Wireshark, using a separate personal configuration directory, to be built for UN*X, regardless of where the special version is installed - under /Applications/Wireshark-special.app, under /opt/wireshark-special, in /usr/local/bin/$program-special, etc..
How the executable image should be named may depend on the platform's conventions.
For Windows, I don't know whether there would be problems if you have $PROGRAMFILES\Wireshark-special\wireshark.exe rather than $PROGRAMFILES\Wireshark-special\wireshark-special.exe. If you have both $PROGRAMFILES\Wireshark-special and $PROGRAMFILES\Wireshark, there are a couple of ways of getting at the right version of the command-line tools - either set your search path to include the right directory, or name the command-line tools differently, so that you have $PROGRAMFILES\Wireshark-special\tshark-special.exe and $PROGRAMFILES\Wireshark\tshark.exe, and you can run "tshark-special" or "tshark". If the name of the dumpcap executable changes, Wireshark and TShark need to know about that when built.
For OS X app bundles, the actual application binary is hidden from the user, so its name doesn't matter. The installer puts scripts in /usr/local/bin that run the actual command-line executables, which are in the application bundle. In that case, having "tshark-special" and "tshark" would probably work better, as the user's more likely to run the command-line tools from /usr/local/bin rather than to tweak $PATH to search in /Applications/Wireshark{-special}.app/Contents/Resources/bin.
For installation under /opt, I'm not sure whether users would expect /opt/wireshark-special/bin/wireshark or /opt/wireshark-special/bin/wireshark-special.
