The LOCK command will be generated by the protect mode FSD or cache as soon their buffers are dirty. The lock request can also be issued by real mode cache programs when their buffers are dirty. A lock request can also come from a MS-DOS-based or Windows-based applications.
The volume tracking layer will only send the first LOCK command to the hardware but it will keep a depth counter for all the LOCK requests. Volume tracking layer will issue an UNLOCK command to the hardware when the LOCK count goes to zero. Volume tracking layer will wait for a predefined time before issuing the unlock to avoid excessive lock/unlock requests to the hardware.
The volume tracking layer will also hook MS-DOS Lock and UnLock IOCtl calls and INT 13 LOCK and UNLOCK requests to properly increase or decrease the LOCK depth counter.
A volume EJECT command can be generated either by an application, the Shell, or by the hardware when the user pushes the eject button.
The volume tracker will issue an INT 15 broadcast for every EJECT command it receives. If INT 15 is returned with a status that suggests that EJECT should not proceed, the command will not be sent to the hardware.
If the INT 15 broadcast is returned without error, the volume tracker will call every FSD that has mounted this media. FSDs are expected to flush their dirty buffers and issue unlocks in response to this request.
After all FSDs have flushed their buffers and have unlocked the volume, the volume tracker will make sure that the depth counter is zero before sending the EJECT command to the hardware.
If depth counter is still non-zero, the volume tracker will pop-up a warning message and will ask the user whether he wishes to continue with the EJECT request. If asked to continue, the volume tracker will issue unlock command and eject the volume.
Note
INT 13 extensions and INT 15 eject broadcast commands are described in detail in a separate document.