Hi, > Recently, ECM submitted a pair updates to the MEM command "fix search_sd > returning an uninitialised pointer if empty SD MCB” > and “fix search_sd omitting last SD sub-MCB if it is empty” the FreeDOS > GitLab Archive. [1]
> As far as I know, there is no upstream project for the MEM command. > I have no doubt the patches are correct and have merged them into a new > “unstable” branch in the project sources. [2] > However like all base programs, the changes should still be verified. > I avoid using C when possible. I much prefer Assembly and Pascal. :-) > The commit comments make a note that are still some remaining issues and > another patch may be needed. > Eventually, I will also need someone to provide a version bump and compiled > binary for the updated version. > Thanks, > Jerome > [1] https://gitlab.com/FreeDOS/base/mem/-/merge_requests/1 > <https://gitlab.com/FreeDOS/base/mem/-/merge_requests/1> > [2] https://gitlab.com/FreeDOS/base/mem/-/tree/unstable?ref_type=heads > <https://gitlab.com/FreeDOS/base/mem/-/tree/unstable?ref_type=heads> "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, it's most likely not a FreeDOS kernel issue. and whatever UPBs and DPBs and lDOS style S MCBs are: can't be that important. - 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. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
