Chkdskx and Formatx work on NT 4.0.
The FormatEx function in FMIFS.DLL is prototyped like this:
VOID FormatEx( PWCHAR DriveRoot,
DWORD MediaFlag,
PWCHAR Format,
PWCHAR Label,
BOOL QuickFormat,
DWORD ClusterSize,
PFMIFSCALLBACK Callback );
The arguments are actually pretty self-explanatory. The callback function is used by FormatEx to communicate with its caller. The definition of PFMIFSCALLBACK is:
typedef BOOLEAN (__stdcall *PFMIFSCALLBACK)(
CALLBACKCOMMAND Command,
DWORD SubAction,
PVOID ActionInfo );
The callback function takes three arguments, interpreting the first one as a command argument that indicates what FormatEx is trying to communicate. I've made the command an enumerated type and filled in the table of roughly 16 commands with the ones that are used during typical FormatEx and Chkdsk operation. For example, one command is OUTPUT, which a callback function can respond to by intepreting the third parameter (ActionInfo) as a pointer to string and displaying the string on the screen. Another command type is a PROGRESS command. The ActionInfo parameter is a pointer to a DWORD that the callback interprets as a precentage. Thus, in a long format process the FMIFS client can keep the user informed of progress via a progress dialog or text print-outs.
The Chkdsk command's definition follows a similar convention:
VOID Chkdsk( PWCHAR DriveRoot,
PWCHAR Format,
BOOL CorrectErrors,
BOOL Verbose,
BOOL CheckOnlyIfDirty,
BOOL ScanDrive,
PVOID Unused2,
PVOID Unused3,
PFMIFSCALLBACK Callback );
Chkdsk's arguments are also self-explanatory and you can see that the exact same callback definition is used for Chkdsk.
You might think at this point that FMIFS is where the file system on-disk structure knowledge is located. However, FMIFS is itself a client of other libraries that contain knowledge about specific file system formats. For example, UFAT.DLL is the library that actually "knows" about FAT on-disk layout so it can perform FAT formatting or consistency checking operations. UNTFS.DLL is where NTFS information is located. You'll note that both the Chkdsk and FormatEx FMIFS functions take file system type string parameters. FMIFS simply takes the file system string and creates a DLL name by placing a 'U' in front of it and a '.DLL' at the end: U<file system>.DLL. It then attempts to load the DLL of that name and calls Chkdsk or Format functions that the DLL is expected to export. UNTFS.DLL and UFAT.DLL rely on two other libraries, ULIB.DLL and IFSUTIL.DLL, to provide some low-level utility functions, like converting a DOS drive name to an NT-native version, and reading and writing from/to a disk. Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive.
This hierarchical arrangment makes it easy for Microsoft to add new file system types to the system without having to write custom verions of the file system management tools. They simply write a DLL for the new file system type and make the management tools (like Explorer) aware of the new format name.
