I thought I had an account on BTTR but I guess not. Anyway, I'm sure that
posting here will get across what I intend to say.

One of the criticisms I got when someone linked my project there was the
lack of any kernel stuff or a working shell. Fair. I don't know what I'm
doing at that level.

However, I think I know enough to provide one end of the Chinese wall, if
anyone else has the MS-DOS 2.11 command.com code as I do and would like to
give it a whack, with some very specific suggestions on what needs to be
changed (basically everything that was added to it since 2.11 until PC DOS
7), and even where the code might need to be changed.

Additionally, the document I wrote suggests where some code I *did* write
might be usable.

Original link: https://github.com/buricco/doslite/wiki/command.com

For the record, a paste follows. The "command.a86" mentioned is
https://github.com/buricco/doslite/blob/main/exper/command/command.a86 and
implements some stuff that *could* be used for a command shell but the
scaffolding is too buggy to be of any use.

(If combined with the MS-DOS code, I obviously am granting the permission
to use the X Window license in lieu of the UIUC license, as can be seen
elsewhere in the project where I modified MS-DOS 2.11 code.)

-uso.

These notes regard the MS-DOS 2.11 command.com and how it could be made
usable for DOSLITE.

Obviously the INT24 handler needs to be updated.

Handling of the @ metacommand should go between GETCOM and NOPDRV
somewhere.

Perhaps one byte should be read from the file, checked against @, and then
an lseek(file, -1, SEEK_CUR) (AX=$4201, CX=DX=$FFFF) if it doesn't match.

A rough implementation of CHCP can be found in command.a86.

I'm not sure how to handle CALL.

I suspect the important thing for the /E switch regards ENVIRONSIZ at the
top of INIT.ASM, currently a constant. The fixed value is 160 (I think
this remains the default). Whatever user value is supplied, to reallocate
(there seem to be two points in the same file, search for the word
allocate, case-insensitive) the appropriate memory this value needs to be
SHIFTED RIGHT 4 BITS.

Mutatis mutandis, this should at least bring the functionality up to the
3.3 level, and would be the hardest changes to make.

An implementation of DEL which supports the /P switch (introduced in 4.0)
can be found in command.a86. I don't know if it's better or worse than
what is there now.

It's possible I might have the better implementation of CTTY - haven't
been able to test.

LOADHIGH needs to be implemented.

DIR may need to be gutted to implement the /A, /O and /S switches from
MS-DOS 5.

DATE

Currently, "Enter new date:" is printed at GETDAT in TCODE4.ASM.

The code to determine which order is used is further up, in P_DATE, and at
this point, perhaps another register can be set to point to one of these
three strings, and then print it immediately after - (mm-dd-yy) (0,
USPDAT), (dd-mm-yy) (1, EUPDAT), (yy-mm-dd) (2, the code immediately
preceding USPDAT), to bring DATE up to the level of PC DOS 3.0.

Perhaps the date check should assume a 2-digit year <80 is 20xx.

TIME

Being able to use "AM" or "PM" in time designation has only been a thing
since PC DOS 4.

The important bit for display is P_TIME, again in TCODE4.ASM.

Most likely where support for AM/PM entry needs to be hacked in is a
couple lines before SAVTIM, where AL is compared to 13 (carriage return).
I am not certain about this.

Pseudocode - haven't worked this out yet.

IF hour=12 AND ampm=AM, THEN hour=hour-12, ELSE if hour≠12 and ampm=PM,
THEN hour=hour+12

MS-DOS 6.x and the COMMAND command

/D

In MS-DOS and PC DOS 6+, the /D switch is used by the kernel to handle the
F5 skip startup files option. But it has actually been in the code since
just after version 2.0.

/K

A hint can be found at NEXTCH3 in INIT.ASM. This is where the /C switch is
processed.

The difference between /C and /K is that /K will not abort the shell after
the command is run. If used with /P, the /K switch changes the name of the
AUTOEXEC command that is invoked by the shell.

/MSG

No idea how this could be implemented. None of DOSLITE uses the
functionality of /MSG for anything. Maybe make it a NOP.

/Y

This is used by the F8 step trace option in MS-DOS 6.2/PC DOS 6.3 and
later, but is also documented and can be invoked by the user along with /C
and /K to trace other shell scripts.

/H

This switch is used by PC DOS 7 to cause the shell to move itself high.

Although it is a low priority, this is a VERY useful switch and probably
should be added at some point.

DOSKEY

DOSKEY is described well enough in the RBIL.

The point in which it should be invoked is probably very near the point
where I suggested looking for a place to put the code to handle the @
metacommand.

Steve Nickolas wrote:

> I thought I had an account on BTTR but I guess not.

I would think so too.

I did some search on the user list, but didn't find your account.
Feel free to ask me (or ecm) for an account:
https://www.bttr-software.de/forum/contact.php

--
Robert Riebisch