command tails and batch file arguments don't work according to MSDOS conventions

[DentDuCrocodile]

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

Have you checked that no other similar question(s) already exists?

• [X] I have searched and didn't find any similar issues.

Question

In native MS-DOS through 7.1, invoking an executable (.com,.exe) involves passing the command tail to the executable through Int 0x21 Function 0x62 or DS and ES without further parsing. This tail starts at the first non-filespec character after the extension and continues literally to the next CR or ctrl-M. I have created a large library over the years of subroutines and executables that make essential use of this; the common convention in these is to take the first (non-filename) character as a field delimiter for the remainder of the line. This allows, among other things, including internal blanks in fields without enclosing quotes. But 4DOS seems to do something else with command tails, some degree of parsing before making them available to the executable. It seems to work if the first tail character is blank, but not with others, such as / or ". Batch file command-line arguments are also parsed differently. Is there any way to disable this initial processing and restore the standard MSDOS conventions without invoking a true 7.1 command processor? I wouldn't mind doing that except that DOSKEY is then required to get alias and history functionality, and it doesn't work at all in DOSBox-X.

[Wengier]

The internal DOS shell already provides built-in DOSKEY functionality and cannot be disabled at this time, so loading a DOSKEY TSR won't work in this case. However, you can indeed load the MS-DOS 7.1 COMMAND so that (Enhanced) DOSKEY will work as expected. But I agree that it is desired to make the built-in DOSKEY functionality optional so that you can load your own DOSKEY TSR and use it instead of the built-in DOSKEY functionality even with the internal DOS shell. It looks like you are familiar with the technical details of the command tail, and you can always make PRs to fix the command shell so that it behaves more like a real DOS system, which is certainly desired by DOSBox-X.

[DentDuCrocodile]

Thank you for considering this. I would be happy to use the built-in DOSKEY functionality provided by 4DOS and not load DOSKEY at all. Changing DOSKEY to ALIAS in my codes is not a problem, and the history treatment is the same. The real trouble is that I don't know how to stop 4DOS from parsing the command tail before storing it in the PSP at offset 0x80 without installing an MSDOS COMMAND.COM (either by invoking after boot or by shell=), and doing that somehow screws up the history functionality in keyboard input, which I can't remedy by installing DOSKEY because that doesn't seem to work. The best solution for me would be a switch in 4DOS to turn off the tail parsing. I've tried setting lfn = false, thinking it might have something to do with long filenames, but that doesn't fix it. I'm not sure what you mean by making PRs to fix the command shell. Thank you again for your help. DOSBox-X is a big improvement for people like me, and I hope to be able to use it with all my own enhancements.

[DentDuCrocodile]

I've checked some more and can be more specific. The main problems are that 4DOS (1) routinely inserts a lead blank in the tail if not already present, and (2) treats a few more lead chars illegal than does MSDOS 6.22 or 7.1 (most importantly /, which I use a lot). (1) is important to me because I'd have to rewrite a lot of code to accommodate it and then have to maintain two sets of mutually incompatible libraries. (2) is less important because I can find mutually compatible chars to replace the newly illegal ones and still maintain only one set of libraries. A pain for sure, but I'd only have to do it once. I've had to do that before as MSDOS has advanced and progressively made more chars illegal in executable file command lines.

[Wengier]

@DentDuCrocodile It appears that your concern is mainly about 4DOS. 4DOS has a lot of config options, and I am not entirely sure if there is a 4DOS config option which will affect this behavior. If not, you can definitely modify the source code by yourself, as both DOSBox-X and 4DOS are open-source. In fact, the 4DOS shell included with DOSBox-X is a somewhat modified version of the original 4DOS 8.00 that fixes certain issues, and anyone can certainly go ahead to fix it further. Alternatively, assuming it is solely a 4DOS issue, you may want to contact Luchezar Georgiev, the original developer of 4DOS 8.00 and ask him if there is an option to achieve what you need, and ask him to fix it if there is no such option currently available. Hope this helps.

[DentDuCrocodile]

Thank you. I'll pursue that.