SvarDOS
INT 21h AX=7300h is not properly implemented in EDR-DOS kernel
I have found out this code does not work with the EDR-DOS kernel. Tested it working properly in MS-DOS 8 (unofficial), ROM-DOS 7.1 and FreeDOS 1.4
The snippet comes from Eric Auer's source code (public domain):
mov ax,7300h ; get a FAT32 property
mov dl,0 ; current drive
mov cl,1 ; "dirty-buffers flag"
int 21h
cmp ax,7300h ; AX still unchanged?
jz oldkernel
; ignore the actual results of int 21.7300 (AL, AH)
mov byte [kern32],1 ; kernel has FAT32 support
oldkernel:
SvarDOS latest, that uses EDR-DOS kernel, fails on it. The erratic condition can be quickly tested with the attached WHICHFAT.COM program by Eric Auer.
I have found other software that relies on this call to find out if the kernel does support fat 32 or not. So it would be important to have it properly working.
Hi! Thanks for pointing this out. Function AX=7300 is not implemented at all, so WHICHFAT seems to interpret this as a FAT16 only kernel.
Tested it working properly in MS-DOS 8 (unofficial), ROM-DOS 7.1 and FreeDOS 1.4
Are you sure it runs on FreeDOS as intended? FreeDOS does not seem implement this specific call either.
So if WHICHFAT returns FAT32 support under FreeDOS, it looks like either the program misinterprets the FreeDOS result, or FreeDOS returns no proper error condition. Whatever it is, WHICHFAT indicating FAT32 support under FreeDOS seems to be accidential (or I did not find where AX=7300 is implemented).
I am rather busy currently with work related stuff, and will not be able to deal with this before the end of the month. Feel free to dig a little deeper in the meantime :)
Hi, thank you for your answer,
I re-tested it against FreeDOS 1.4 boot disk and indeed, it works, reporting FAT32. It is the official 1.4 FreeDOS 1.44 MB boot floppy disk. It seems to me it was some commit added rather lately, between 2023 and 2025 if we follow Eric´s code comments and my finding.
I also tested an OEM version of DR-DOS 7.03 from Dell, and it has this function implemented and reports correctly. So it must have been added sometime during the development phase between DR-DOS/OpenDOS 7.01 and 7.03.
Note that the following program will not report FAT32 kernel on OpenDOS 7.01 nor Enhanced DR-DOS due to the missing int 21h AX=7300h function. However, whenever it gets implemented it will report it.
Tested working on MS-DOS 6.22, MS-DOS 7.10, MS-DOS 8, ROM-DOS 7.1, DR-DOS 7.03, and FreeDOS 1.4. This program is rather small at only 743 bytes
DOSCHECK is Public Domain Software. Binary release only.
Ignacio F. Gully DOSCHECK's author
DOSCHECK - Reports Long File Name (LFN) status and FAT32 DOS kernel support. Version 1.02 (21 August 2025) - Copyright (C) Ignacio F. Gully
Purpose: A Long File Name (LFN) API supports file names up to 255 characters long, which is indeed much more than the default 8.3 that DOS uses.
FAT32 is a file system that overcomes the limits of FAT16 allowing for
volumes up to 2 terabytes with a sector size of 512 bytes. The maximum
FAT32 volume size is 16 TB with a sector size of 4,096 bytes. The maximum
possible size for a file on a FAT32 volume is 4 GB minus 1 byte.
Syntax: DOSCHECK
Errorlevel (return code):
1 = LFN active. 10 = FAT32 supported by kernel.
11 = Both LFN and FAT32 are active and supported.
Example: DOSCHECK > NUL
LFN support on one drive does not imply LFN support on all drives. dosemu2 mfs redirector, MSW 95/98/Me, and doslfn may provide LFN support, but if one drive supports LFNs other drives on the same system may be restricted to SFNs.
Also, considering that EDR-DOS is misdetected by this 21.7300 check, trying a different 21.73 subfunction instead or in addition may be smarter.
Are you sure it runs on FreeDOS as intended? FreeDOS does not seem implement this specific call either.
Look at the default branch of this switch: https://github.com/boeckmann/freedos_kernel/blob/a40e3a71c27b3eeefd29ebcd4c34d42f9930ea0c/kernel/inthndlr.c#L413
It sets the DOS error code 0001h, so the check succeeds because it only checks for ax != 7300h.
LFN support on one drive does not imply LFN support on all drives. dosemu2 mfs redirector, MSW 95/98/Me, and doslfn may provide LFN support, but if one drive supports LFNs other drives on the same system may be restricted to SFNs.
Yes, I know, thanks. I am only checking here that LFN is active for the current drive.
Also, considering that EDR-DOS is misdetected by this 21.7300 check, trying a different 21.73 subfunction instead or in addition may be smarter.
Yes, I could certainly do that, but the purpose here was to improve the EDR kernel and have a way to test it, which will make several older programs work properly, like WHICHFAT (posted above).