On at 2024-05-03 23:54 -0400, Steve Nickolas via Freedos-devel wrote:
So I've had some thoughts regarding the MS-DOS 4 source drop, regarding
things I'd like to do with the code. I'm not really that good of a
coder and probably would only be able to do some of them myself. (I'd
kill for a 3.3 drop - would obviate a lot of these things! And 5 and
6.2 even more.)
First big issue, and one I can only partially resolve. I'm taking a
strict approach to the contents of the TOOLS folder - want to get rid of
it and replace it with open-source equivalents. That means, most
practically, OpenWatcom 1.9 (there's prolly other options but the more
like MSC it is the less torturous porting is going to be). And the
code's going to need to be dinked as far as possible to roll in Watcom
instead of MSC - that's going to be a major pain in the neck.
As mentioned before, JWasm is probably going to be useful to replace the
MASM v5.10 for this. Me, I'm working with the original toolchain for now
even though it is (free but) closed source.
Some of the code's pretty braindead, too. Especially what looks to have
come from IBM. I mean...house styles vary, but Algolization is still
just hideous-looking. But it goes beyond that - think some of the
utilities are going to need major rewrites. I'm thinking of writing a
new front-end around the FDISK code, but I haven't really been able to
take the code and sort through everything to figure out what parts I'll
need in order for FDISK to...fdisk (and don't know enough about int13,
MBR or FAT to do it my damnself). I was looking into D-Flat, but my
brain melted - might have to write bespoke UI code.
Additionally, the whole "Message Server" thing. (I think the broken
TYPE command when COMMAND.COM is run under FreeDOS is related to this.)
I'd like to have the feature reduced to compatibility only and use good
old-fashioned AH=9 like older DOS versions. It'll probably also iron
out some of the compile issues I've had trying to port the C stuff to
Watcom!
The broken TYPE (and COPY) command in the shell is actually due to the
Extended Attributes functions that the MS-DOS v4.01 kernel "supports".
In fact, these functions are just placeholders that return an empty list
and ignore all writes. I wrote about this to dosemu2 [1], as the TYPE
and COPY commands were broken on dosemu2 redirector drives (even when
running both command.com and the kernel from the MS-DOS release). The
error is the command will (on FreeDOS) display "Extended Error 1" when
trying to display a file using TYPE, or (on MS-DOS on a redirector
drive) "Invalid function - <filename>". I patched command.com in my fork
to not require these functions [2].
Writing of which, I also identicalised the binaries to both MS-DOS v4.00
(matching the original release minus build fixes and encoding problems)
[3] as well as the MS-DOS v4.01 release [4]. I compared the files to the
content of disks found at the Internet Archive [5]. The v4.01 patch
comes from hharte's fork on github [6], but I verified that it matches
the v4.01 release. I also wrote about the process (regarding the v4.00
work) on our forum [7]. The most difficult part involved creating a
small unpacker utility for the select.dat files [8], to allow comparing
the binary differences in the uncompressed data rather than being stuck
with the compressed files.
An error that remains is that on the FreeDOS kernel, commands like "ver
/r" and "mem /p" (using unsupported switches) will not display "Invalid
switch" or "Invalid switch - /p" but rather "Parse Error 3".
After these things are ironed out, I guess the next phase would be,
unless another code drop obviates the effort, to recreate features of
later versions. I've actually done this with some apps. (The obvious
question: Why not use what FreeDOS already has? A: Because I'd like to
have the entirety of the project under a single license - that being the
X license Microsoft and IBM are already using.) High memory support -
big feature of 5.0 - that's a big part of why 5 was considered a _good_
version of DOS and 4 wasn't.
I already added one MS-DOS v5 feature: Device drivers are passed the
maximum valid address that they may allocate [9]. This allows loading
lDebug as a device driver, albeit an lDebug bugfix is also needed [10].
Regards,
ecm
[1]: https://github.com/dosemu2/dosemu2/issues/2206
[2]: https://hg.pushbx.org/ecm/msdos4/rev/cf97c97c1d9b
[3]: https://hg.pushbx.org/ecm/msdos4/shortlog/63a05668c5f3
[4]: https://hg.pushbx.org/ecm/msdos4/rev/51ad27d225a8
[5]: https://archive.org/details/ms-dos-4.00-and-4.01
[6]:
https://github.com/hharte/MS-DOS/commit/7e51e4249ee0e6185b4e3eed9902c5cf786f052a#comments
[7]: https://www.bttr-software.de/forum/forum_entry.php?id=21755
[8]: https://hg.pushbx.org/ecm/msdos4/rev/9a0f75e8c341
[9]: https://hg.pushbx.org/ecm/msdos4/rev/814a8eb71ce4
[10]: https://hg.pushbx.org/ecm/ldebug/rev/6c4bbd544091
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
