Closed tkchia closed 2 years ago
Andrew, do I remember correctly that we already did that?
Your memory must be better than mine, I have no recollection of this topic. Perhaps I should write a test to see what the other DOSes do.
But I suppose @tkchia already has such test?
Yes I guess that's true.
Hello @stsp, hello @andrewbird,
I am currently working on such a test, in a separate tkchia/makefcb
branch in my libi86
project.
See e.g. commit https://github.com/tkchia/libi86/commit/46dbd514d26e3ea124eac9dce3452b93a68a8596 : this commit adds a new _makefcb (
...)
function to libi86
, and also adds a test case for it.
(The parts of the test that check for the correct behaviour are currently disabled with #if 0
, since otherwise the test currently fails, at least on my system...)
Thank you!
Hello @stsp, hello @andrewbird,
The test code for this particular behaviour for int 0x21
, ah
= 0x29
, is now in my libi86
master branch — though the test is disabled for now. Let me know if you would like me to enable the test. Thank you!
Ping. Andrew, have you looked at a test?
@tkchia maybe you can just check fdpp yourself and submit a patch if needed?
Hello @stsp,
@tkchia maybe you can just check fdpp yourself and submit a patch if needed?
Hmm... let me look into doing that. Thank you!
On both MS-DOS 2.11 and MS-DOS 5.0, the "parse filename to FCB" syscall (
int 0x21
, function0x29
), when it encounters an invalid drive letter, will still continue parsing the file name, and return withal
=0xff
andds:si
pointing after the parsed file name.E.g. given an input like
z:foo.bar,baz
— assumingz
is not a valid drive letter — the syscall will returnal
=0xff
andds:si
pointing at the comma.FreeDOS++ should probably do likewise. I have already submitted a proposed patch to the upstream FreeDOS kernel project, at https://github.com/FDOS/kernel/pull/82 .
(Edit: I also submitted another patch upstream at https://github.com/FDOS/kernel/pull/83 which fixes a problem in my earlier patch.)
Thank you!