Hello,
On at 2025-02-25 15:52 +0100, tom ehlert via Freedos-devel wrote:
"On current lDOS, loading things into the HMA or UMA makes it so
that only the DOS-internal UPBs and DPBs are allocated within
the Low Memory Area MCB chain. (BIOCODE and DOSDATA are in front
of the first MCB.) They already use lDOS style S MCBs however.
Therefore, the devmark / SD MCB allocated in the LMA is empty."
"On current lDOS": Whatever lDOS is,
lDOS is my latest DOS kernel project (after lRxDOS and lEDR-DOS), based
on the lMS-DOS kernel, derived from the 2024 April free software release
of MS-DOS v4 (under MIT license). Some more advertisement on my web
page: https://pushbx.org/ecm/web/#projects-ldos
it's most likely not a FreeDOS kernel issue.
Never claimed it was a problem when running on FreeDOS. The other reply
I just sent to the list contains a test program that will provoke the
same bug running under any DOS, but the FreeDOS kernel probably won't
create the same condition by itself. Despite the following fdconfig.sys:
device=d:\dosemu\umb.sys
devicehigh=d:\dosemu\ems.sys
SWITCHES=/F
DOS=UMB,high
dosdata=umb
fileshigh=128
lastdrive=Z
rem emufs.sys /all replaces emufs.com
devicehigh=d:\dosemu\emufs.sys /all
devicehigh=d:\dosemu\cdrom.sys
set SHELL_ALLOW_EXIT=1
shellhigh=c:\command.com /e:2048 /p:fdautoem.bat
; stacks=0
The kernel still seems to allocate two devices and some SFTs
(presumably) in the Low Memory Area's SD MCB:
lDebug (2025-02-25)
-ext extlib.eld dm
PSP: 2989
02B4 4D 0008 0022 544 B SD
02B5 46 02B6 000C 192 B 'F' FILES=
02C2 44 02C3 0009 144 B 'D' DEVICE=EMS
02CC 44 02CD 000A 160 B 'D' DEVICE=EMUFS
02D7 4D 0000 0013 304 B
02EB 4D 02EC 269C 154 KiB LDEBUG
2988 5A 2989 7676 473 KiB DEBUGGEE
9FFF 4D 0008 2300 140 KiB SC
C300 4D 0008 02FF 11.9 KiB SD
C301 44 C302 0031 784 B 'D' DEVICE=CDROM
C333 46 C334 01BB 6.9 KiB 'F' FILES=
C4EF 4C C4F0 008F 2.2 KiB 'L' LASTDRIVE=
C57F 53 C580 0080 2048 B 'S' STACKS=
C600 4D 0000 0007 112 B
C608 4D C609 00A9 2.6 KiB COMMAND
C6B2 4D 0000 194C 101 KiB
DFFF 4D 0008 1000 64.0 KiB SC
F000 4D 0000 02D3 11.2 KiB
F2D4 4D 0000 0619 24.3 KiB
F8EE 4D 0000 0090 2.2 KiB
F97F 5A C609 0080 2048 B COMMAND
-
This is running on dosemu2 10e84a9e1 and with the following kernel version:
C:\>callver show
FreeDOS kernel, OEM ID FDh, reports DOS version: 7.10
Internal revision and version: 43 7.10
FreeDOS kernel - GIT (build 2043 OEM:0xfd) [compiled Aug 26 2023]
C:\>
So, the empty SD MCB is never even a possibility on the FreeDOS kernel
it appears. And perhaps even if it would end up empty maybe the kernel
will free the entire memory block instead. lDOS certainly may do that in
the future, but I do think the patch to MEM is still useful.
and whatever UPBs and DPBs and lDOS style S MCBs are: can't be that important.
UPBs (Unit Parameter Blocks) are known to the FreeDOS kernel and the
interrupt list as DDTs (Drive Data Tables), to EDR-DOS as UDSCs (Unit
Descriptors), and to MS-DOS as BDS (Block Data Structure).
In the FreeDOS kernel, 2F.0803 returns the address of the first UPB (and
presumably all of them) as being in segment D9h, which is the DOS data
segment. In MS-DOS v4 they used to be allocated within the msbio segment
at 70h, in a part left resident after init. In lDOS, they're allocated
from the DOS using function 21.48 after the early DOS DS and DOS CS
setup. It is my goal for later to allocate the UPBs and DPBs near the
top of the LMA and eventually relocate them - either to the low end of
the LMA, or to the HMA or UMA if available.
I find it hard to believe that you don't recognise the DOS system data
structure known as DPB (or, DDSC in EDR-DOS).
- MINFO *first_child, *mlist;
+ MINFO *first_child = NULL, *mlist;
can never be wrong.
- end=parent->seg + parent->size;
+ end=parent->seg + parent->size + 1;
so what. might be wrong, but then only the wrong size reported.
should be not important.
It isn't terribly important; the error case I described is about an
empty SD sub-MCB at the end of the SD MCB. It won't be displayed without
this patch, but then again it is empty and no one that I know of ever
creates empty sub-MCBs.
Regards,
ecm
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
