Re: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, Sep 10, 2004 at 02:19:40PM -0500, David A. Rogers wrote: >On Fri, 10 Sep 2004, Chuck McDevitt wrote: > >> argv and argc are concepts from the C runtime, not the Windows OS. >> >> The actual entry point to your program is to a routine that calls the >> initialization routines of the C library, then calls winMain. >> > >Yes, certainly. The point I was making was that the information was available >in a true win32 app. David Korn implied that the WinMain call was the only >access to the calling arguments that were available to a win32 app. That is >not true, as I showed. This is what Dave Korn said: >But it's fair to point out that the argv concept is not part of the OS, >it's part of a compiler support library; You don't seem to be getting the concept that this is not part of the OS. It is an extension imposed by msvcrt.dll. If the application doesn't use msvcrt.dll then there is no guarantee that argv[0] will be set as expected. You can write 100 programs showing that you are seeing argv and argc. That doesn't mean that it is part of the standard Windows API. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, 10 Sep 2004, Chuck McDevitt wrote: > argv and argc are concepts from the C runtime, not the Windows OS. > > The actual entry point to your program is to a routine that calls the > initialization routines of the C library, then calls winMain. > Yes, certainly. The point I was making was that the information was available in a true win32 app. David Korn implied that the WinMain call was the only access to the calling arguments that were available to a win32 app. That is not true, as I showed. dar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, 10 Sep 2004, Chuck McDevitt wrote: > argv and argc are concepts from the C runtime, not the Windows OS. > > The actual entry point to your program is to a routine that calls the > initialization routines of the C library, then calls winMain. > > Those initialization routines get the command line via Win32 call, > allocates memory for argv, and parses the command line. > > Windows itself has no requirement that an application support argv and > argc, and in fact programs in other languages (VB etc) don't have any such > concept. Ok, so I didn't use quite the right phrasing, but I believe it's been explained adequately since. > Cygwin, when launching an application, just needs to make sure the > CreateProcess call has the command line passed to it. > Everything else is handled by the the receiving program (via C runtime, if > a C program). Exactly, with one small clarification: "Cygwin, when launching an application, just needs to make sure the CreateProcess call has the *right* command line passed to it.". Currently, spawn_guts() munges the first token in that command line to match the image name, even if instructed otherwise (via the args array). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
argv and argc are concepts from the C runtime, not the Windows OS. The actual entry point to your program is to a routine that calls the initialization routines of the C library, then calls winMain. Those initialization routines get the command line via Win32 call, allocates memory for argv, and parses the command line. Windows itself has no requirement that an application support argv and argc, and in fact programs in other languages (VB etc) don't have any such concept. Cygwin, when launching an application, just needs to make sure the CreateProcess call has the command line passed to it. Everything else is handled by the the receiving program (via C runtime, if a C program). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, 10 Sep 2004, Dave Korn wrote:
> There is no concept of argv in the windows OS itself. The application gets the
> entire commmand line as one unparsed string.
>
Actually, this is not true. Even in a true win32 app, argc and argv are
available, they are just not as obvious. The following program will print
the location of the exe.
---
#include "stdafx.h"
#include "stdlib.h" // for __argc and __argv
#include "stdio.h" // for sprintf
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
char msg[300];
sprintf(msg, "%d args. Arg0 is %s", __argc, __argv[0]);
MessageBox(NULL, msg, "argv test", MB_OK);
return 0;
}
---
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, 10 Sep 2004, Dave Korn wrote: > > -Original Message- > > From: cygwin-owner On Behalf Of Igor Pechtchanski > > Sent: 10 September 2004 14:57 > > > On Fri, 10 Sep 2004, Christopher Faylor wrote: > > > > There is no such thing as "argv[0]" for a Windows program. Cygwin > > > uses CreateProcess to create processes. CreateProcess does not have > > > the concept of "argv[0]". Perhaps Microsoft's exec functions do > > > something funky that is understood by other msvcrt programs. > > > Cygwin doesn't do that. > > > > Allow me to disagree. CreateProcess takes two separate arguments: the > > image to run, and the command line (yes, as one long line). The > > actual executable being run is the image parameter, but the value of > > argv[0] is extracted from the command line one (well, unless the image > > name is NULL, in which case the image name and argv[0] are the same). > > That's the value of argv[0] that I meant. > > Allow me to disagree! The Win32 API specifies precisely the form that > the entry function of a win32 application must conform to: > > int WINAPI WinMain( > HINSTANCE hInstance, // handle to current instance > HINSTANCE hPrevInstance, // handle to previous instance > LPSTR lpCmdLine, // command line > int nCmdShow // show state > ); > > There is no concept of argv in the windows OS itself. The application > gets the entire commmand line as one unparsed string. Fair enough. Thanks for the clarification. What I meant was that the first token of the command line was set to the image name when invoking Windows applications from Cygwin. So, even if a Cygwin app sets argv[0] explicitly (which should be incorporated into the lpCmdLine), that first token would be the same as the image name, and not what was specified. > Now, it may well be the case that most applications link against the > msvcrt library, which contains an implementation of WinMain that parses > lpCmdLine into separate tokens, puts them into an array, and then calls > out to a function named 'main' in the user's app that is linked with the > library, passing it argc and argv parameters. But it's fair to point > out that the argv concept is not part of the OS, it's part of a compiler > support library; it's not handled by the OS, it's not passed to > applications, it's not defined in the API, and there are plenty of > applications that implement their own (or a predefined) WinMain in a > different fashion and do _not_ tokenize and parse the command line; 99% > of all MFC apps, for instance. True, but irrelevant. My complaint was that the first token of the command line, as specified by Cygwin's execv(), was ignored in favor of the image name. Hope this clarifies things, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
> -Original Message- > From: cygwin-owner On Behalf Of Igor Pechtchanski > Sent: 10 September 2004 14:57 > On Fri, 10 Sep 2004, Christopher Faylor wrote: > > There is no such thing as "argv[0]" for a Windows program. > Cygwin uses > > CreateProcess to create processes. CreateProcess does not > have the concept > > of "argv[0]". Perhaps Microsoft's exec functions do > something funky that > > is understood by other msvcrt programs. Cygwin doesn't do that. > > Allow me to disagree. CreateProcess takes two separate arguments: the > image to run, and the command line (yes, as one long line). > The actual > executable being run is the image parameter, but the value of > argv[0] is > extracted from the command line one (well, unless the image > name is NULL, > in which case the image name and argv[0] are the same). > That's the value > of argv[0] that I meant. Allow me to disagree! The Win32 API specifies precisely the form that the entry function of a win32 application must conform to: int WINAPI WinMain( HINSTANCE hInstance, // handle to current instance HINSTANCE hPrevInstance, // handle to previous instance LPSTR lpCmdLine, // command line int nCmdShow // show state ); There is no concept of argv in the windows OS itself. The application gets the entire commmand line as one unparsed string. Now, it may well be the case that most applications link against the msvcrt library, which contains an implementation of WinMain that parses lpCmdLine into separate tokens, puts them into an array, and then calls out to a function named 'main' in the user's app that is linked with the library, passing it argc and argv parameters. But it's fair to point out that the argv concept is not part of the OS, it's part of a compiler support library; it's not handled by the OS, it's not passed to applications, it's not defined in the API, and there are plenty of applications that implement their own (or a predefined) WinMain in a different fashion and do _not_ tokenize and parse the command line; 99% of all MFC apps, for instance. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, 10 Sep 2004, Christopher Faylor wrote: > On Fri, Sep 10, 2004 at 12:38:31AM -0400, Igor Pechtchanski wrote: > >Hi, > > > >I'm getting the following behavior consistently: > >[snip] > >In other words, invoking a Cygwin program sets argv[0] correctly, but > >invoking a Windows program doesn't. Interestingly enough, using the MinGW > >execv works properly: > > There is no such thing as "argv[0]" for a Windows program. Cygwin uses > CreateProcess to create processes. CreateProcess does not have the concept > of "argv[0]". Perhaps Microsoft's exec functions do something funky that > is understood by other msvcrt programs. Cygwin doesn't do that. Allow me to disagree. CreateProcess takes two separate arguments: the image to run, and the command line (yes, as one long line). The actual executable being run is the image parameter, but the value of argv[0] is extracted from the command line one (well, unless the image name is NULL, in which case the image name and argv[0] are the same). That's the value of argv[0] that I meant. Now, spawn_guts() *seems* to retain the original (correct) argv[0] when constructing the command line string, but it apparently replaces it with the prog_arg parameter somewhere for Windows programs... Hmm, wait a minute, now that I phrased it this way, I think it enabled me to find the culprit. Lines 513-515 of spawn.cc say: /* Replace argv[0] with the full path to the script if this is the first time through the loop. */ newargv.replace0_maybe (prog_arg); Is there a particular reason why this is done for ".exe" files? Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
On Fri, Sep 10, 2004 at 12:38:31AM -0400, Igor Pechtchanski wrote: >Hi, > >I'm getting the following behavior consistently: > >$ bash -c 'exec -a java -h' 2>&1 | egrep 'options?]' >Usage: java.exe [-options] class [args...] > or java.exe [-jar] [-options] jarfile [args...] >$ > >but > >$ bash -c 'exec -a bash --help' 2>&1 | egrep 'options?]' >Usage: [GNU long option] [option] ... > [GNU long option] [option] script-file ... >$ > >In other words, invoking a Cygwin program sets argv[0] correctly, but >invoking a Windows program doesn't. Interestingly enough, using the MinGW >execv works properly: There is no such thing as "argv[0]" for a Windows program. Cygwin uses CreateProcess to create processes. CreateProcess does not have the concept of "argv[0]". Perhaps Microsoft's exec functions do something funky that is understood by other msvcrt programs. Cygwin doesn't do that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin 1.5.11: execv doesn't set argv[0] on Windows programs
Hi,
I'm getting the following behavior consistently:
$ bash -c 'exec -a java -h' 2>&1 | egrep 'options?]'
Usage: java.exe [-options] class [args...]
or java.exe [-jar] [-options] jarfile [args...]
$
but
$ bash -c 'exec -a bash --help' 2>&1 | egrep 'options?]'
Usage: [GNU long option] [option] ...
[GNU long option] [option] script-file ...
$
In other words, invoking a Cygwin program sets argv[0] correctly, but
invoking a Windows program doesn't. Interestingly enough, using the MinGW
execv works properly:
$ cat ex.c
#include
int main(int ac, char *av[]) {
char const *args[] = { "", "-h", NULL };
return execv("c:/Program Files/IBM/Java14/bin/java", args);
}
$ make -W ex.c CC="gcc -mno-cygwin" ex
gcc -mno-cygwin ex.c -o ex
$ ./ex 2>&1 | egrep 'options?]'
Usage: [-options] class [args...]
or [-jar] [-options] jarfile [args...]
$ make -W ex.c ex
gcc ex.c -o ex
$ ./ex 2>&1 | egrep 'options?]'
Usage: java.exe [-options] class [args...]
or java.exe [-jar] [-options] jarfile [args...]
$ uname -a
CYGWIN_NT-5.1 pechtcha 1.5.12(0.116/4/2) 2004-09-07 15:07 i686 unknown unknown Cygwin
(yes, a self-built DLL from CVS, but the same problem occurs with 1.5.10).
I have a nagging suspicion that the culprit is somewhere in spawn_guts(),
and will poke some more at it unless someone knows off-hand where the
problem is.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing." -- Dr. Jubal Harshaw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
