DOS ain't dead

jadoxa Queensland, Australia, 17.08.2025, 08:05	DOSLFN 0.42 (Announce) Post reply
	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).

Japheth

Germany (South),
18.08.2025, 12:13

@ jadoxa

DOSLFN 0.42

Post reply

> 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!

jadoxa Queensland, Australia, 18.08.2025, 13:27 @ Japheth	DOSLFN 0.42 Post reply
	> 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.)

ecm

Düsseldorf, Germany,
18.08.2025, 14:15

@ jadoxa

DOSLFN 0.42

Post reply

> > 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

tom Germany (West), 23.08.2025, 20:06 @ ecm	DOSLFN 0.42 Post reply
	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.

jadoxa Queensland, Australia, 24.08.2025, 01:48 @ tom	DOSLFN 0.42 Post reply
	> 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.

roytam

29.08.2025, 01:41

@ jadoxa

DOSLFN 0.42

Post reply

> 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/

jadoxa Queensland, Australia, 29.08.2025, 02:34 @ roytam	DOSLFN 0.42 Post reply
	> 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.)

DOSLFN 0.42 (Announce)

DOSLFN 0.42

DOSLFN 0.42

DOSLFN 0.42

DOSLFN 0.42

DOSLFN 0.42

DOSLFN 0.42

DOSLFN 0.42