From Steve Nickolas@21:1/5 to All on Tue Aug 2 09:28:32 2022
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
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.
(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.)
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
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
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.
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,
MS-DOS 6.x and the COMMAND command
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.
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.
No idea how this could be implemented. None of DOSLITE uses the
functionality of /MSG for anything. Maybe make it a NOP.
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.
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 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.