SvarDOS
DR-DOS Task Switcher doesn't work as expected
Just saw an user reported about this in https://www.vogons.org/viewtopic.php?p=1320457#p1320457
I did it the other way around: installed the EDR kernel into a working DR-DOS 7.03. I can confirm that when launching a second task, there is no output on the screen other than that what is typed by the user. The system otherwise seems to be functional. I can switch to the first task by pressing CRTL+TAB. First task window is fully functional.
Also, when in the second task, command line history via UP / DOWN keys seems to be functional. AND when I enter the following in the second task window, MEM actually shows its output: MEM >CON. Also a COMMAND >CON gives me a fully functional second task window.
So my initial guess would be that the standard output is not properly initialized for the program launched as the "main process" of the newly spawned tasks.
Additional info: my tests were done without any memory manager and with taskmgr /s, as the bug was about the task switcher.
Might be related that EDR-DOS has only 3 SFT entries at DOSDATA:00CCh whereas earlier DR-DOS probably had 5 (like MS-DOS). This changed because of the FAT32 and FAT+ extensions to the SFT entry layout.
the size of a single SFT entry is 0x3b bytes, like in OpenDOS 7.01
I don't think this is right. EDR-DOS has an SFT extension for FAT32, not only for FAT+.
I don't think this is right. EDR-DOS has an SFT extension for FAT32, not only for FAT+.
Not sure which field exactly you mean. The fields relevant to FAT32 are still there.
According to the source the SFT in OpenDOS v7.01 is also 0x3b byte: https://hg.pushbx.org/ecm/edrdos/file/28c716330f1b/ibmdos/doshndl.def#l104
Maybe you overlooked that I re-used the IFS bytes?
According to the source the SFT in OpenDOS v7.01 is also 0x3b byte: https://hg.pushbx.org/ecm/edrdos/file/28c716330f1b/ibmdos/doshndl.def#l104
Maybe you overlooked that I re-used the IFS bytes?
Oh yes, I didn't take note of https://github.com/SvarDOS/edrdos/commit/76a987d15014fccef841466908fa2d795bd5fb16 where you changed the SFT layout. MS-DOS v7.10 and FreeDOS also re-use the SFT field for sharer next SFT for their FAT32 extensions, do you mirror that exactly? Could make the FAT32 compatibility of the DR-DOS sharer even worse if you do.
MS-DOS v7.10 and FreeDOS also re-use the SFT field for sharer next SFT for their FAT32 extensions, do you mirror that exactly?
As most as I could. There are some fields used slightly different, if I interpret the FreeDOS struct definition correctly. For example:
ULONG sft_dirsector; /* 1b - Sector containing cluster */
UBYTE sft_diridx; /* 1f - directory index */
while EDR has:
DHNDL_DBLK equ word ptr 1Bh ; 1B - cluster # of dir entry
; (lower 16 bits)
DHNDL_DBLKH equ word ptr 1Dh ; 1D - cluster # of dir entry
; (higher 16 bits)
DHNDL_DCNTLO equ byte ptr 1Fh ; 1F - dir offset # within cluster
...
DHNDL_DCNTHI equ byte ptr 39h ; 39 - dir offset # within cluster
; (higher 8 bits)
The FreeDOS comment speaks of a sector, while the EDR field seems to be the cluster, and the directory index is a 8-bit field instead of the 16-bit field for EDR. Its not that easy to change the meaning of these fields without larger modifications to the EDR code.
Apart from this, the general structure should now very much resemble the FreeDOS SFT.
Could make the FAT32 compatibility of the DR-DOS sharer even worse if you do.
Yes, but I accepted the fact that a new SHARE has to be implemented to fix this the proper way :(.
It seems that the DR-DOS sharer doesn't actually use the field at offset 2Bh in the SFT entry, it seems to always hold all-zeroes in an lDOS flavour EDR-DOS kernel. Tested using the sharer from The DR-DOS/OpenDOS Enhancement Project site as mirrored in https://pushbx.org/ecm/download/edrdos/share.zip on a diskette image attached to dosemu2 (ie a block device to the drdos kernel).
Parts of https://pushbx.org/ecm/test/20250423/drshare.txt commented:
FreeCom version 0.87 - GNUC - XMS_Swap [Feb 21 2025 23:30:19]
SEEKEXT 1.21: high loaded using 416 byte, on multiplex 00h.
emufs: redirector enabled
Welcome to dosemu2!
Build 2.0pre9-dev-20240420-1892-g6a2f4f527
C:\>drshare
SHARE R2.02 File sharing support.
Copyright (c) 1988,1996 Caldera, Inc. All rights reserved.
C:\>dir a:
Volume in drive A is FOO
Volume Serial Number is 0000-0000
Directory of A:\
LDEBUG COM 82,432 08-19-22 12:09p
FDKERNEL SYS 78,150 05-19-22 10:30a
COMMAND COM 85,480 05-19-22 10:30a
UPXKERN SYS 53,008 05-19-22 9:10p
QUIT COM 91 05-19-22 9:13p
KERNEL SYS 78,696 08-19-22 12:09p
AUTOEXEC BAT 0 05-19-22 9:14p
LDDEBUG COM 73,728 08-19-22 12:09p
INT3 COM 6 05-19-22 9:35p
LDEBUG SLD 293 08-19-22 12:09p
CONF1 SYS 33 05-20-22 3:16p
CONF2 SYS 33 05-20-22 3:16p
CONF3 SYS 33 05-20-22 3:16p
CONF4 SYS 33 05-20-22 3:16p
LDEBUG~1 SLD 108 05-20-22 3:40p
EMPTY EXE 0 05-21-22 3:34p
EMPTY COM 0 05-21-22 3:34p
EMPTY BIN 0 05-21-22 3:34p
LDEBUG3 COM 62,464 05-21-22 3:34p
KERNEL COM 82,880 05-24-22 11:54a
20220525 SLD 292 08-19-22 12:09p
TESTPL COM 6,144 05-27-22 9:23p
TESTPL BIN 1,458 05-27-22 9:23p
TEST SYS 1,664 05-25-22 11:49p
TEST2 SYS 1,532 05-27-22 9:23p
BIG 53,360 05-26-22 2:18p
REPACK SYS 1,532 05-27-22 7:31p
OOKERNEL SYS 46,426 05-27-22 9:23p
CONFIG SYS 59 07-19-22 2:32p
IO SYS 125,960 08-19-22 12:09p
MSDOS SYS 99 08-19-22 12:09p
TESTSH2 COM 1,024 02-14-25 9:11p
TSR COM 4,222 12-05-24 11:34a
33 file(s) 841,240 bytes
0 dir(s) 609,280 bytes free
C:\>ldebug
-a
2890:0100 mov ax, 3d00
2890:0103 mov dx, 200
2890:0106 int 21
2890:0108 push ax
2890:0109 mov ax, 3d00
2890:010C mov dx, 200
2890:010F int 21
2890:0111 push ax
2890:0112 int3
2890:0113 nop
2890:0114
-e 200 "a:ldebug.com" 0
-t
AX=3D00 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0103 NV UP EI PL ZR NA PE NC
2890:0103 BA0002 mov dx, 0200
-
AX=3D00 BX=0000 CX=0000 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0106 NV UP EI PL ZR NA PE NC
2890:0106 CD21 int 21
-
AX=0005 BX=0000 CX=0000 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0108 NV UP EI PL ZR NA PE NC
2890:0108 50 push ax
-d psp:18+ax l 1
2890:0010 - 03 .
-d ri31s:cc
F15A:00C0 - 00 00 0D 01 ....
F15A:00D0 03 00 04 00 02 00 00 C0-40 36 00 70 00 00 00 4B [email protected]
F15A:00E0 70 97 5A 00 00 00 00 00-00 00 00 00 00 00 00 00 p.Z.............
F15A:00F0 00 00 41 55 58 20 20 20-20 20 20 20 20 00 00 00 ..AUX ...
F15A:0100 00 00 00 E0 9F 00 00 15-00 00 00 00 00 00 00 00 ................
F15A:0110 00 00 00 00 00 00 00 00-00 00 00 00 00 0C 00 02 ................
F15A:0120 00 00 D3 40 1B 00 70 00-00 00 4B 70 97 5A 00 00 [email protected]..
F15A:0130 00 00 00 00 00 00 00 00-00 00 00 00 00 43 4F 4E .............CON
F15A:0140 20 20 20 20 20 20 20 20-00 00 00 00 ....
-d ri31s:cc+6 l 4b
F15A:00D0 04 00 02 00 00 C0-40 36 00 70 00 00 00 4B [email protected]
F15A:00E0 70 97 5A 00 00 00 00 00-00 00 00 00 00 00 00 00 p.Z.............
F15A:00F0 00 00 41 55 58 20 20 20-20 20 20 20 20 00 00 00 ..AUX ...
F15A:0100 00 00 00 E0 9F 00 00 15-00 00 00 00 00 00 00 00 ................
F15A:0110 00 00 00 00 00 00 00 00-00 00 00 00 00 .............
-d ri31s:cc+6 +4bl 4b
F15A:0110 - 0C 00 02 ...
F15A:0120 00 00 D3 40 1B 00 70 00-00 00 4B 70 97 5A 00 00 [email protected]..
F15A:0130 00 00 00 00 00 00 00 00-00 00 00 00 00 43 4F 4E .............CON
F15A:0140 20 20 20 20 20 20 20 20-00 00 00 00 00 00 E0 9F ........
F15A:0150 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
F15A:0160 00 00 00 00 00 00 00 00- ........
This was just to test we have the right SFT entry size.
-d ptr[ri31s:cc]+6 l 4b
010D:0000 01 00-00 00 20 40 40 00 00 27 .... @@..'
010D:0010 01 02 00 24 61 13 55 00-42 01 00 00 00 00 00 00 ...$a.U.B.......
010D:0020 00 00 00 00 00 00 4C 44-45 42 55 47 20 20 43 4F ......LDEBUG CO
010D:0030 4D 00 00 00 00 00 00 90-28 D4 18 00 00 00 00 00 M.......(.......
010D:0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
010D:0050 00 - .
-dd ptr[ri31s:cc]+6+2b l 4
header 0 1 5 9 D 123456789ABCDEF0
010D:0030 00000000 - ....
All-zeroes at this point. This could be just the terminator at the end of a chain though.
-t
AX=0005 BX=0000 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0109 NV UP EI PL ZR NA PE NC
2890:0109 B8003D mov ax, 3D00
-
AX=3D00 BX=0000 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=010C NV UP EI PL ZR NA PE NC
2890:010C BA0002 mov dx, 0200
-
AX=3D00 BX=0000 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=010F NV UP EI PL ZR NA PE NC
2890:010F CD21 int 21
-
AX=0006 BX=0000 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0111 NV UP EI PL ZR NA PE NC
2890:0111 50 push ax
-d psp:18+ax l 1
2890:0010 - 04 .
-d ptr[ri31s:cc]+6+4b l 4b
010D:0050 01 00 00 00 20 40 40-00 00 27 01 02 00 24 61 .... @@..'...$a
010D:0060 13 55 00 42 01 00 00 00-00 00 00 00 00 00 00 00 .U.B............
010D:0070 00 4C 44 45 42 55 47 20-20 43 4F 4D 00 00 00 00 .LDEBUG COM....
010D:0080 00 00 90 28 DE 18 00 00-00 00 00 00 00 00 00 00 ...(............
010D:0090 00 00 00 00 00 00 00 00-00 00 00 00 ............
-dd ptr[ri31s:cc]+6+2b l 4
header 0 1 5 9 D 123456789ABCDEF0
010D:0030 00000000 - ....
-dd ptr[ri31s:cc]+6++4b+2b l 4
header 0 4 8 C 0123456789ABCDEF
010D:0070 - 00000000 ....
Both are all-zeroes.
-d ptr[ri31s:cc]+6 l 4b
010D:0000 01 00-00 00 20 40 40 00 00 27 .... @@..'
010D:0010 01 02 00 24 61 13 55 00-42 01 00 00 00 00 00 00 ...$a.U.B.......
010D:0020 00 00 00 00 00 00 4C 44-45 42 55 47 20 20 43 4F ......LDEBUG CO
010D:0030 4D 00 00 00 00 00 00 90-28 D4 18 00 00 00 00 00 M.......(.......
010D:0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
010D:0050 00 - .
-t
AX=0006 BX=0000 CX=0000 DX=0200 SP=FFFA BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0112 NV UP EI PL ZR NA PE NC
2890:0112 CC int3
-. pop bx
-. mov ah, 3e
-. int 21
-. pop bx
-. mov ah, 3e
-. int 21
Close the two process handles.
-t=100
AX=3D00 BX=0005 CX=0000 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0103 NV UP EI PL ZR NA PE NC
2890:0103 BA0002 mov dx, 0200
-
AX=3D00 BX=0005 CX=0000 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0106 NV UP EI PL ZR NA PE NC
2890:0106 CD21 int 21
-r al 2#0_010_0_000
Next, open with DENY-WRITE / READ-ONLY.
-t
AX=0005 BX=0005 CX=0000 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0108 NV UP EI PL ZR NA PE NC
2890:0108 50 push ax
^Cd ptr[ri31s:cc]+6+2b l 4'^C
-d psp:18+ax l 1
2890:0010 - 03 .
-t
AX=0005 BX=0005 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0109 NV UP EI PL ZR NA PE NC
2890:0109 B8003D mov ax, 3D00
-
AX=3D00 BX=0005 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=010C NV UP EI PL ZR NA PE NC
2890:010C BA0002 mov dx, 0200
-
AX=3D00 BX=0005 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=010F NV UP EI PL ZR NA PE NC
2890:010F CD21 int 21
-r al 2#0_010_0_000
DENY-WRITE again.
-t
AX=0006 BX=0005 CX=0000 DX=0200 SP=FFFC BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0111 NV UP EI PL ZR NA PE NC
2890:0111 50 push ax
-d psp:18+ax l 1
2890:0010 - 04 .
-d ptr [ri31s:CC]+6 l 4B
010D:0000 01 00-20 00 20 40 40 00 00 27 .. . @@..'
010D:0010 01 02 00 24 61 13 55 00-42 01 00 00 00 00 00 00 ...$a.U.B.......
010D:0020 00 00 00 00 00 00 4C 44-45 42 55 47 20 20 43 4F ......LDEBUG CO
010D:0030 4D 00 00 00 00 00 00 90-28 D4 18 00 00 00 00 00 M.......(.......
010D:0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
010D:0050 00 - .
-d ptr [ri31s:CC]+6 + 4B l 4B
010D:0050 01 00 20 00 20 40 40-00 00 27 01 02 00 24 61 .. . @@..'...$a
010D:0060 13 55 00 42 01 00 00 00-00 00 00 00 00 00 00 00 .U.B............
010D:0070 00 4C 44 45 42 55 47 20-20 43 4F 4D 00 00 00 00 .LDEBUG COM....
010D:0080 00 00 90 28 DE 18 00 00-00 00 00 00 00 00 00 00 ...(............
010D:0090 00 00 00 00 00 00 00 00-00 00 00 00 ............
-dd ptr [ri31s:CC]+6 + 4B + 2B l 4
header 0 4 8 C 0123456789ABCDEF
010D:0070 - 00000000 ....
-dw ptr [ri31s:CC]+6 + 4B + 33 l 2
header 0 2 4 6 8 A C E 0123456789ABCDEF
010D:0080 18DE - ..
-dd ptr [ri31s:CC]+6 + 2B l 4
header 0 1 5 9 D 123456789ABCDEF0
010D:0030 00000000 - ....
-dw ptr [ri31s:CC]+6 + 33 l 2
header 0 1 3 5 7 9 B D F 123456789ABCDEF0
010D:0030 -18D4 ..
-
The next SFT fields are both all-zeroes, the MFT reference fields are different (but close).
The next SFT fields are both all-zeroes, the MFT reference fields are different (but close).
Great! I am still struggling if using the IFS field makes compatibility better or worth (as you might have noticed, its currently in a separate branch). But considering all circumstances I think its better to use them. Things like a working TASKMGR and compatibility to FreeDOS / MS-DOS 7.1 should outweigt the chance of breaking some stuff relying on the IFS fields in my opinion.
Sadly these changes do not make SCANDISK work for FAT32 partitions yet. Might have to do with the DHNDL_DBLK field still not fully compatible, or anything not connected to it at all, as there are also differences in other data structures.
I am currently searching for a convinient way to "log" the DOS system calls made by SCANDISK (register values etc.) to a file (probably with combining the key wait calls etc. by giving a repeat count instead of thousands of them logged). Then I can compare the calls SCANDISK does between MS-DOS 7.1 and the EDR kernel.
Knowing that DRSHARE does not use the field is good, but does not eliminate the fact that there is no free SHARE implementation compatible with the EDR kernel. So this would still be nice to have :)
The next SFT fields are both all-zeroes, the MFT reference fields are different (but close).
Great! I am still struggling if using the IFS field makes compatibility better or worth (as you might have noticed, its currently in a separate branch). But considering all circumstances I think its better to use them. Things like a working TASKMGR and compatibility to FreeDOS / MS-DOS 7.1 should outweigt the chance of breaking some stuff relying on the IFS fields in my opinion.
Would be interesting whether SFT layout alone makes a difference for taskmgr or only if you change the 3 entries at DOSDATA:00CCh to 5 entries as well.
Sadly these changes do not make SCANDISK work for FAT32 partitions yet. Might have to do with the DHNDL_DBLK field still not fully compatible, or anything not connected to it at all, as there are also differences in other data structures.
The EDPB looks different, I think one of the fields is extended to 32-bits in MS-DOS by adding an "upper word" to it and in EDR-DOS a "new dword" is added instead to hold the entire 32 bits. The 21.73 functions to get EDPBs mangles it to match the MS-DOS layout but the internal structure differs. Could be scandisk accesses the underlying EDPBs.
I am currently searching for a convinient way to "log" the DOS system calls made by SCANDISK (register values etc.) to a file (probably with combining the key wait calls etc. by giving a repeat count instead of thousands of them logged). Then I can compare the calls SCANDISK does between MS-DOS 7.1 and the EDR kernel.
Interc3 may be of interest. Mentioned here: https://www.bttr-software.de/forum/forum_entry.php?id=20502
Knowing that DRSHARE does not use the field is good, but does not eliminate the fact that there is no free SHARE implementation compatible with the EDR kernel. So this would still be nice to have :)
Yes, indeed.
Interc3 may be of interest. Mentioned here: https://www.bttr-software.de/forum/forum_entry.php?id=20502
Thanks! With this tool I was able to find the cause of the failing SCANDISK. See https://github.com/SvarDOS/edrdos/issues/124#issuecomment-2827380654