Re: Questions about the behavior for argv(0)
* Lew Pitcher:
On June 4, 2009 13:36, in comp.lang.c, BobF (nothanks@no.spam) wrote:
Nate Eldredge wrote:
Indeed, in the
Unix world, this is the terminology people actually use; the program's
name is independent of filename of its executable. ("If you run this
program with the name 'foo', it does something; if you run it with the
name 'bar', it does something else.")
Which Unix world? It's been a while, but IIRC the command typed at the
Unix prompt had to match an actual filename.
But, with Unix, two (or more) different filenames can point to the same
file. Thus, a Unix executable file can have multiple names, and can test
argv[0] to see /which/ name it had been called for execution.
Well, this is starting to get a little off-topic, but both Unix and Win32 have
always had hardlinks, that is, the possibility of multiple names for the same file.
In Windows that possibility was more or less hidden (only backup utilities had
to deal with it) until, as I recall, Windows 2000, at which point Microsoft
proudly proclaimed that they'd made the file system of the future simply by
exposing this functionality, and some other common-in-*nix, as simpler APIs,
plus, of course, adding a lot of complication, Microsoft-style. It wasn't until
Windows Vista, however, that Windows got symbolic link support, that is, got up
to more or less the standard of *nix.
The main difference is that under Windows the argv values, including argv[0],
are inferred, not provided explicitly to, the invoked process, by its C/C++
runtime library, by parsing a passed command line. For example, by changing the
linking options you can have wildcards expanded, which they're not by default.
Side-note: one of the Old Gods once published an article in DDJ, I think it was,
where wildcard expansion was tacitly assumed, then someone pointed out that hey,
that won't work under Windows!, and then someone else pointed out that hey, you
can easily have that work under Windows (the God was right, but by accident!).
'C Guy' quoted someone unspecified as having suggested
Call the Windows API GetModuleFileName(NULL, ...) to get the
fully qualified path of your .exe
and that's a good idea in Windows, because in Windows argv[0] is really unreliable.
As a practical example of that unreliability,
<example>
C:\Documents and Settings\Alf\temp> type con >name.cpp
#include <iostream>
int main( int, char** argv )
{
std::cout << argv[0] << std::endl;
}
^Z
C:\Documents and Settings\Alf\temp> cl /nologo /GX /GR name.cpp
name.cpp
C:\Documents and Settings\Alf\temp> name
name
C:\Documents and Settings\Alf\temp> C:\Documents^ and^ Settings\Alf\temp\name
C:\Documents
C:\Documents and Settings\Alf\temp> _
</name>
But it goes much further than that:
in Windows, argv values are completely unreliable for filenames etc.
That's because C 'main' was designed for *nix -- the 'main' routine is one of
the most platform specific features of the language.
It's pretty useless for Windows, except for toy programs. :-)
Summing up, one should know what one is doing regardless of platform, and
reliance on a standardized feature while neglecting how that feature is actually
implemented on the platforms one wishes to support, is not recommended.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!