OK, so some API exists. But do you know ANY fullscreen DOS application which
properly implements it?
You say, OK, you can hook a INT 2Fh in your application. But why the
application programmer should hook some interrupts? Imagine that you are
creating some spreedshet application or some level editor for your favourite
game. User opens a save file dialog, accidentaly writes B:\STUFF.DAT and
irritating message occurs.
Why should be the high-level programmer be awere of such low-level stuff?
You can say - hey, but why are you trying to save to B:\ ?
But we want well behaved programs. They sould be as much bullet-proof as
possible. I even don't imagine what happens if the keyboard interrupt is
trapped and exclusively treated by application.
The DJ mechanism should be optional and turned off by default, IMO.
---------- Původní e-mail ----------
Od: Eric Auer <e.a...@jpberlin.de>
Komu: freedos-devel@lists.sourceforge.net
Datum: 31. 5. 2021 16:13:05
Předmět: Re: [Freedos-devel] Time to end with diskette DJ system? (aka
famtom drives?)
"
Hello Carsten,
>> INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION
>> AX = 4A00h
...
>> Return: CX = FFFFh to skip "Insert diskette for drive X:" message
> this helps for new applications or applications where we have the
> source, but it does not help with all the existing applications
Given that this API has been there for ages, those existing
applications just have a very long-lived bug by failing to
use the API. However, you could write a tiny TSR which will
hook int 2f and suppress the disk change message, or show it
in a way which is compatible to full screen TUI and GUI apps.
In situations where it is unable to show the message, this
TSR could set appropriate flags to mark B: as not inserted,
or take similar measures to make access to DJ-style B: fail.
I really do not think that this is a job for the kernel itself.
It has been ages since I DELIBERATELY used the DJ mechanism at
all. Normally I just access files on A: and very few apps would
insist on using B: for things unless you explicitly tell them.
So a feature to block the mechanism from ACCIDENTALLY triggering
would be needed even less often than that and a TSR is enough :-)
Regards, Eric
PS: FreeDOS does not include a DRIVER.SYS driver, or feature.
That was a very ancient MS DOS feature which let you override
BIOS based detection of floppy drives and their geometry, see
http://info.wsisiz.edu.pl/~bse26236/batutil/help/DRIVER_S.HTM
Maybe we COULD add a config.sys command instead of a device=...
driver, but I do not know any hardware needing it? Basically, it
tells DOS a BIOS disk drive with any given CHS geometry exists.
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
"
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
