Hi,
On 31 May 2021, at 22:41, Eric Auer wrote:
You say, OK, you can hook a INT 2Fh in your application. But
why the application programmer should hook some interrupts?
The book "DOS Internals" by Geoff Chappell
(https://www.geoffchappell.com/notes/dos/internals/index.htm) has a good
discussion on the matter in Section "Logical Drive Mapping", Page 633ff.
INT 2Fh Function 4a00h has never been documented by Microsoft and even
Microsoft has missed to used that API in "MSD" and "Windows 3x"
(according to the book it even can "hang" Windows).
That is never has been officially documented by Microsoft might be a
reason that most programmers don't know about it.
Because by design, the kernel is what knows when you want to
ask the user to change disks, so it is straightforward that
the kernel has to call (a place hookable by) the app if it
wants to give the app a chance to show a message about that.
Just disabling the whole feature because you do not like the
direction of data flow is a somewhat unusual solution, but
again, I suggest that you make a TSR to disable the message.
A TSR hooking INT 2Fh (4a00h) would disable the message, but will create
the situation where write access that (maybe by accident) is directed to
drive B: will end up accessing drive A:, causing potential data loss.
It would be better to have a solution where the user could disable the
logical drive B:, so that access to drive B: will result in a proper
error code being returned to the application. Most applications can
handle an error code given back.
Without support from the kernel it might be possible to manipulate the
DPB (Drive Parameter Block) to remove or invalidate drive B:, or write a
TSR that hooks INT 13h and terminates all access to B: with an error
return code. Both solutions are "hacks" and brittle. Support for
disabling the logical drive B: in the DOS kernel would be more clean,
IMHO.
Greetings
Carsten
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
