Re: Questions about the behavior for argv(0)
On Jun 4, 7:33 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
On June 4, 2009 13:20, in comp.lang.c, Nate Eldredge (n...@vulcan.lan)
wrote:
James Kanze <james.ka...@gmail.com> writes:
[...]
Call the Windows API GetModuleFileName(NULL, ...) to get the
fully qualified path of your .exe
That's what I use.
Note that under Unix, it is generally not possible to do
this reliably at all, so if you intend to port someday, you
should design your program in a manner that does not require
this information.
Indeed. In my experience, the usual reason for a Windows
programmer to complain about Unix not providing the full
pathname (through whatever mechanism) of the executable is
that the programmer intends to use the supplied path in a
manner not compatible with Unix system configuration and/or
usage. Typically, the Windows programmer wishes to continue to
use the Windows convention of having program configuration and
data files reside in the same directory as the program
executable, which is contrary to the spirit and often to the
configuration of a Unix standard environment.
That's not what I've seen (but most of what I do under Windows
comes from the Unix world to begin with). Generally, both under
Windows and under Unix (but more strictly under Unix), a
"product" is installed in a sub-directory of its own
("/opt/ProductName", under classical Unices). The executable
will be under "/opt/ProductName/bin", the man pages in
"/opt/ProductName/man", various libraries or "resource" files in
"/opt/ProductName/etc" or "/opt/ProductName/lib", etc. The
classical Unix solution for the program to find it's data is to
require the user to define an environment variable,
PRODUCTNAMEHOME, and use it. (The classical Windows solution is
to put this information in the registry. Which is easier for
the user, but tends to cause problems when you start maintaining
different versions of the same product on the same machine.)
There are several alternative solutions to avoid each user
having to specify this. The most common, I think, is to have
the user invoke a shell script, rather than invoke the program
directly. When the program is installed, the shell script is
edited (automatically) to set PRODUCTNAMEHOME correctly. (I've
seen this used under Windows as well, but it's not the
"standard" solution.)
I won't debate on the rightness or wrongness of this mechanism
here, but I will say that, in general, programmers either need
to write programs for portability (and not depend on /any/ of
the platform and language-specific features available to
them), or they need to write for /specific/ platforms. Porting
"portable" code (like code written exclusively to the C
standard) is easy and needs only a recompilation for the
target environment; porting "platform specific" code is hard,
needs platform-specific substitutions, and often /really
needs/ (but is seldom acted apon) a complete rearchitecting.
The problem is that if you limit yourself to the C or the C++
standard, you can't do a lot of necessary things, like opening a
socket, connecting to a data base, or displaying a GUI.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34