Re: deliver full path by argv[0] and GetCommandLine for win9x

[Dmitry Timoshkov]

"Frank Schruefer"  wrote:
> Was this patch forgotten/rejected?

Did you consider to provide a test suite as well to justify
the change?

deliver full path by argv[0] and GetCommandLine for win9x

[Frank Schruefer]

Dmitry Timoshkov wrote:
> "Frank Schruefer"  wrote:
> > Was this patch forgotten/rejected?
>
> Did you consider to provide a test suite as well to justify
> the change?

Not really: It looks like there's already an existing test in
dlls/kernel/tests/environ.c.
This test is broken BTW *without* my patch, it says:
...
path.c:756: Test succeeded inside todo block: GetFullPathNameA returned 'C:\shortdir\pathtest.pth' instead of 'C:\shortdir\pathtest.pth'
...
which doesn't make any sense anyways.

Justifications for the patch:

-Remark in dlls/kernel/environ.c. Quote:
"
  * WARNING: there's a Windows incompatibility lurking here !
  * Win32s always includes the full path of the program file,
  * whereas Windows NT only returns the full file path plus arguments
  * in case the program has been started with a full path.
  * Win9x seems to have inherited NT behaviour.
"
Although the comment is not accurate, you get what it says and it's exactly
what the patch should fix.

-the patch clearly fixes an incompatibility.

-the patch is free ;-)

Shouldn't that be enough *justification*?

Another thing is: I'm neither familiar with C nor wine nor Windows and it took
me more than a week of my spare time to make that fix. I'm not gonna spend
another week to find out how to write a wine conform test case, sorry.

Well, I'm not mad in any way if you wanna reject it. Just say so.

What I'm doing now is tracking the case until it reached a final state,
that's why I asked what happened to it.

deliver full path by argv[0] and GetCommandLine for win9x

[Alexandre Julliard]

Frank Schruefer  writes:
> -Remark in dlls/kernel/environ.c. Quote:
> "
> - WARNING: there's a Windows incompatibility lurking here !
> - Win32s always includes the full path of the program file,
> - whereas Windows NT only returns the full file path plus arguments
> - in case the program has been started with a full path.
> - Win9x seems to have inherited NT behaviour.
>
> "
> Although the comment is not accurate, you get what it says and it's exactly
> what the patch should fix.

What that comment says is that Win32s behaves differently from normal
Windows. This may or may not be true, but it's pretty much irrelevant,
nobody in their right mind runs Win32s apps anymore.

Your patch changes the Win9x behavior, and I'd really like to see a
test program to demonstrate that Win9x really behaves this way at the
kernel level, not only as a side-effect of the command interpreter
passing a full path to CreateProcess.

deliver full path by argv[0] and GetCommandLine for win9x

Alexandre Julliard wrote:
> Frank Schruefer  writes:
> > -Remark in dlls/kernel/environ.c. Quote:
> > "
> > - WARNING: there's a Windows incompatibility lurking here !
> > - Win32s always includes the full path of the program file,
> > - whereas Windows NT only returns the full file path plus arguments
> > - in case the program has been started with a full path.
> > - Win9x seems to have inherited NT behaviour.
> >
> > "
> > Although the comment is not accurate, you get what it says and it's exactly
> > what the patch should fix.
>
> What that comment says is that Win32s behaves differently from normal
> Windows. This may or may not be true, but it's pretty much irrelevant,
> nobody in their right mind runs Win32s apps anymore.
>
> Your patch changes the Win9x behavior, and I'd really like to see a
> test program to demonstrate that Win9x really behaves this way at the
> kernel level, not only as a side-effect of the command interpreter
> passing a full path to CreateProcess.

Well, that's easily done without a testcase as it is documented by MS:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas...

Quote:
"
Note  The name of the executable in the command line that the operating system provides to a process is not necessarily identical to that in the command line that the calling process gives to the CreateProcess function.
The operating system may prepend a fully qualified path to an executable name that is provided without a fully qualified path.
"

deliver full path by argv[0] and GetCommandLine for win9x

[Chris Morgan]

MS's documentation has been found to be incorrect or misleading in the past.  
Adding a test to wine's regression test suite would be an ideal way of not 
only confirming this behavior on windows but also ensuring that wine has the 
correct behavior and doesn't break it in the future.

Chris

On Thursday 12 February 2004 09:48 am, Frank Schruefer wrote:
> Alexandre Julliard wrote:
> > Frank Schruefer  writes:
> > > -Remark in dlls/kernel/environ.c. Quote:
> > > "
> > > - WARNING: there's a Windows incompatibility lurking here !
> > > - Win32s always includes the full path of the program file,
> > > - whereas Windows NT only returns the full file path plus arguments
> > > - in case the program has been started with a full path.
> > > - Win9x seems to have inherited NT behaviour.
> > >
> > > "
> > > Although the comment is not accurate, you get what it says and it's
> > > exactly what the patch should fix.
> >
> > What that comment says is that Win32s behaves differently from normal
> > Windows. This may or may not be true, but it's pretty much irrelevant,
> > nobody in their right mind runs Win32s apps anymore.
> >
> > Your patch changes the Win9x behavior, and I'd really like to see a
> > test program to demonstrate that Win9x really behaves this way at the
> > kernel level, not only as a side-effect of the command interpreter
> > passing a full path to CreateProcess.
>
> Well, that's easily done without a testcase as it is documented by MS:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
> se/getcommandline.asp
>
> Quote:
> "
> Note  The name of the executable in the command line that the operating
> system provides to a process is not necessarily identical to that in the
> command line that the calling process gives to the CreateProcess function.
> The operating system may prepend a fully qualified path to an executable
> name that is provided without a fully qualified path. "