On 02/11/2014 11:36 AM, Jules Richardson wrote:
Incidentally, the 21/0Dh entry in Ralf's list
claims: "This function
writes all modified disk buffers to disk, but does not update the
directory information (that is only done when files are closed or a SYNC
call is issued)". As I'm ensuring that I'm closing any open file before
a disk swap, I think I'm covered, but I'm not sure what it means by a
sync call (in a DOS context).
The 21h/0Dh thing has its roots in CP/M--where, incidentally, it's also
function 0dh (what a coincidence--not!).
The original purpose of 13h/00h was to reset the floppy *controller*,
causing a software-intitated reset and respecify on the 765 (or
equivalent) FDC chip. On many hard drives, it's a no-operation.
At some point, DOS began "hooking" that interrupt also. In earlier
versions of DOS, a control-C at the command prompt would also cause
DOS's memory of what floppy was inserted in the drive to be cleared (a
la CP/M again) Late versions of DOS don't seem to honor that in the
same way.
In CP/M, the whole problem got started because CP/M would build its
allocation bitmap by scanning the disk directory and saving it
("allocation vector"). Swapping disks with files open for writing could
have disastrous consequences if the operating system didn't realize that
the swap had happened. Identifying a particular disk was performed by
checksumming a predetermined number of directory entries after a disk
reset. The system wasn't airtight--it was possible to con fuse it--and
it was an anathema to clever BIOS programmers who thought that they'd
write improved floppy access routines by reading and writing a track at
a time. This eventually resulted in writes being committed immediately
and only reads being track-buffered.
On an OS that I worked on, we got around the problem by polling the
write-protect status of a 5.25" drive; if it suddenly changed, we knew
that a user had removed a floppy. If files were open for writing, we
halted his program until he put the disk back.
--Chuck