Re: deliver full path by argv[0] and GetCommandLine for win9x
"Frank Schruefer" <frank.schruefer(a)t-online.de> wrote:
Was this patch forgotten/rejected?
Did you consider to provide a test suite as well to justify the change? -- Dmitry.
Dmitry Timoshkov wrote:
"Frank Schruefer" <frank.schruefer(a)t-online.de> 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. -- Thanks, Frank
Frank Schruefer <wine(a)man-made.de> 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. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Frank Schruefer <wine(a)man-made.de> 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. " -- Thanks, Frank
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 <wine(a)man-made.de> 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. "
participants (5)
-
Alexandre Julliard -
Chris Morgan -
Dmitry Timoshkov -
Frank Schruefer -
Frank.Schruefer＠t-online.de