DOS ain't dead

I've released DOSLFN 0.42. It fixes FreeDOS disk corruption using FDNPKG to install some packages; uses LANG environment variable, removing l option; and works on some 386 clones (removes use of undocumented setalc instruction).

> I've released DOSLFN 0.42.
> It fixes FreeDOS disk corruption using FDNPKG to install some
> packages; uses LANG environment variable, removing
> l option; and works on some 386 clones (removes use of
> undocumented setalc instruction).

Good. However, will the FD fix have any negative impact on other DOSes, i.e. performance degradation?

---
MS-DOS forever!

> Good. However, will the FD fix have any negative impact on other DOSes,
> i.e. performance degradation?

Not in MS-DOS (in my admittedly limited test); didn't try anything else. (I suspect other DOSes perform the flush internally.)

> > Good. However, will the FD fix have any negative impact on other DOSes,
> > i.e. performance degradation?
>
> Not in MS-DOS (in my admittedly limited test); didn't try anything else.
> (I suspect other DOSes perform the flush internally.)

I traced the int 25h and int 26h handlers of lMS-DOS (based on MS-DOS v4.00) and didn't notice any point at which buffers are queried, flushed, or updated. The request is just passed directly to the device driver. There is some code for the "secondary cache" which I disabled.

As another note, MS-DOS Debug explicitly calls int 21h function 0Dh both before and after calling int 25h or int 26h.

---
l

Just wondering: is it possible that all reported file system corruptions were
for FAT12/FAT16 disks?

Because - as I understand it - the FAT32 disk read mechanism (INT21 AX=7305) has
protection against the supposed bug, while FAT16 (INT25/26) has not.

> Just wondering: is it possible that all reported file system corruptions
> were for FAT12/FAT16 disks?

No, I was using FAT32, and didn't actually test the older functions.

> I've released DOSLFN 0.42.
> It fixes FreeDOS disk corruption using FDNPKG to install some
> packages; uses LANG environment variable, removing
> l option; and works on some 386 clones (removes use of
> undocumented setalc instruction).

BTW int21,7302 fails with AX=1 return on Win95 RTM.
Ref: https://github.com/tyomitch/tyomitch.github.io/com...bb49b0cb81d7502e21836d7657f84a7384df022d3bR7299

original post in russian: https://habr.com/ru/articles/526382/

> BTW int21,7302 fails with AX=1 return on Win95 RTM.

Turns out he contacted me when he originally wrote that, but at that time Wengier had talked to Henrik, who had sort-of taken the project back, so I did nothing, and promptly forgot about it. Since it hasn't come up again it can't be all that critical... (Besides, probably better off not using that version of Win95.)