Extended Command Line LFN issue

[shidel]

As mentioned briefly in issue #95, there is a separate issue with the extended command line.

I'm not sure if this technically a bug. However, it makes it excessively cumbersome for a program to correctly parse an extended command line that is passed through the CMDLINE environment variable.

The issue is Long File Names. So, first I will demonstrate what happens. Ignore the errors regarding the missing carriage return, that should be fixed in pull request #96

So, I created a LFN directory, changed into it and ran the test program with a very long set of parameters.

Looks good. So, I move up one directory, used the short name for LFN directory to execute the test again.

Looks good. So, I then used the LFN version of the directory and ran the test again.

Um. Not so good. Where did the quotes go? Look at all of those spaces.

This makes it more difficult for the program to determine the first parameter passed on the command line.

For example: Was the program extension included? What if program was renamed?

Although I did not rename the binary to use an LFN, I would assume it would exhibit the same issue.

I can see how I could reliably find the start of the first parameter after the program (even from a com file). It is not going to be fun to process in the program and most programs probably won't bother. I think it would be more practical and reliable to change this behavior.

There are three potential solutions to the issue.

First, simply keep the quotes. This would be the easiest. But, I am not sure how well programs that support the CMDLINE variable will handle having them present.

Second, always send the short name in the CMDLINE variable. This should be very reliable. However, it would require running that portion of the string through the GET SHORT NAME function provided by the LFN driver. As long as the driver is functioning properly, this may be the best solution and should not have any adverse side effects.

Third, just strip that out and put a dummy name there. It is doubtful any programs are relying on the included executable name, they will be expecting something there. Stripping out the information passed regarding the executable and replacing it with something like PROGRAM , should be good. But, would need testing.

[ecm-pushbx]

I used your tstcmdln.com and on MSW 98 SE (with its command.com and with Windows loaded to provide LFNs) it does pass along the double quote marks of the command when I run the program from a directory with a long name.

[shidel]

@ecm-pushbx, thanks.
That answers how it should be solved.
Quotes should be present.

[ecm-pushbx]

Same if the program filename is also long. Interestingly enough I can run a long named executable but the short name is passed to interrupt 21h function 4Bh. I can't put a breakpoint on function 71h however, as in the debugger won't gain control. This is likely because the MSWindows handler hooks the interrupt in its PM handler so the function 71h is never passed to the DOS.

[shidel]

@boeckmann I thought of another concern.

Be sure to check how microsoft will handle a file or directory that includes a quote in the name. Will it be escaped, double quoted or something else.

[ecm-pushbx]

I don't think doublequote marks are allowed in filenames.

[shidel]

I don't think doublequote marks are allowed in filenames.

I now you can have them on Mac, Linux, BSD, etc.

I've been away from Windows for a very long time. I honestly do not recall if it is doable. It will require some checking. It may not be possible in short names. It may not be possible for a user in long file names. But, it may be possible for a program to do it. I really don't know.

But, it will be great and much easier to implement if they are simply forbidden.

[ecm-pushbx]

Refer to the answer and comments in https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names/31976060#31976060