Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
to stop this ridiculous discussion: > For now I have in my AUTOEXEC.BAT the line "JOIN B: C:\FREEDOS\JOIN_B\" how about "JOIN B: A:\" or even to hit the 'A' key when you mean the A: drive Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hi Carsten, > 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 would be strange, given that Windows 3 in 386 enhanced mode explicitly manipulates the internal workings of that function, so having a way to mess with it seems required for enhanced mode. My guess would be that this is for being able to have multiple DOS windows open simultaneously in Windows. As DOS is not made to be reentrant, Windows demands that most internal variables are organized in such ways that it can swap them between tasks. Int 2f.4a00 also is documented in RBIL, which is a popular text. > 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. I partially agree. My suggestion would be that the TSR keeps track of which virtual disk is inserted at the moment and just set some "no disk in drive" or similar flag in the DOS drive tables for the time where "B:" is inserted. Yet, if you only disable messages, there is no real problem either: The user would fail to be aware that they were supposed to take one disk out and insert another one, but in the end, they just have two drive letters "secretly" taking turns for accessing the same drive. > 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 While this is in part what I suggest above, the DJ mechanism always accesses the physical BIOS A: drive even while switched to B: When you hook int 13, it sees no difference. So yes, my suggestion would be to mark the floppy as "not inserted" or similar exactly during the periods where the DJ is switched to B: but again this would only be useful to "educate" the user. Without such manipulations, your drive would simply behave like an "automated DJ" and DOS would stick alternating drive letters to your actually unchanged floppy. Greetings, Eric PS: I guess you could create confusion when you have files open on A: and B: simultaneously, but even then, DOS would just silently switch between the "2" virtual (in reality: same) disks as needed. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
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
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hi Laaca, > OK, so some API exists. > But do you know ANY fullscreen DOS application which properly implements it? I can tell you that EDIT and DEFRAG do not, but then it would be your own fault if you ask those to access drive B: when you only have a single floppy drive. I agree that you can simply access B: by accident, so I agree that EDIT and DEFRAG should probably support this API! :-) Yes, you can defrag floppies. You could make a ticket about that request for those 2 apps. What else could be affected? HTMLHELP? I can also tell you that we have support for this since at least 2009, mentioned in context of making the list of bugs and wishes shorter, so apparently apps using it do exist. Plausible examples could be DOSSHELL and WINDOWS 3.x in standard mode, 386enh mode is hard to use with FreeDOS. Interestingly, according to 2004 FreeDOS mail archives, this API is one of those which need special handling for, guess what, Windows 386enh mode ;-) https://sourceforge.net/p/freedos/mailman/freedos-kernel/?viewmonth=200410 https://freedos-kernel.narkive.com/qwpKs9AO/smaller-tour-of-32bit-stuff-in-kernel-optimize-bugs > You say, OK, you can hook a INT 2Fh in your application. But > why the application programmer should hook some interrupts? 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. > 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. Write a bug report about your spreadsheet or level editor ;-) > Why should be the high-level programmer be awere of such low-level stuff? Because hooking the multiplex interrupt 2f is exactly the level at which such things happen. You would not want to mess with internal DOS data structures instead and you would not want the kernel to be able to show graphical messages either :-) > The DJ mechanism should be optional and turned off by default, IMO. Again, I recommend making a TSR for that purpose. Regards, Eric PS: Interestingly, running HELP crashes DOSEMU2 in CPUEMU mode at the moment, by letting CS:IP fall from the end of :? I have not tested DN2, DOSZIP, FDSHELL, FDTUI, BIEW, BLOCEK, DOSHEXED, E3, ELVIS, FREEMACS, MINED, MSEDIT, OSPEDIT, PICO, SETEDIT, TDE, UHEX, VIM, OpenGEM, Ozone, Seal, Arachne, Dillo, Lynx, Links, OpenCP, Foxtype or any games. Please test those. And please tell me which other apps are GUI/TUI and open files. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On 5/31/2021 12:24 PM, Ladislav Lacina wrote: 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. Well, there is an old saying: When you try and make things fool proof, along comes a better fool... The fact that DOS reserves the B: drive for a possibly non-existing second floppy drive goes back to the very first version of DOS and is well documented. And as far as changing the default behavior, you could argue the same for a non-existing A: drive these days. Where do you stop? Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
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 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 = h 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
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On 5/31/2021 3:36 AM, Steve Nickolas wrote: On Mon, 31 May 2021, Mercury Thirteen via Freedos-devel wrote: +1 Personally, I always thought it would be best to have this "phantom drive" feature disabled by default and allow the user to enable it if they need. But that's just me. :) Personally, I'd go with the opposite: behavior compatible with MS-DOS 3.3 ought to be the default because it's what most people would expect from software that has as its primary compatibility target Compaq MS-DOS 3.31 (not sure if that's still accurate, it's certainly been a long time since I checked). +1 Though at some point, the target for FreeDOS was changed to MS-DOS 6.0, which included the changes of 5.0 (which were substantial) as well as the memory management changes of DOS 6.0. But to me, this whole thread is a non-issue. A proper written application will check if it has two (physical) floppy drives and won't give you and error. And if it doesn't, I doubt you get the DOS error message regarding changing disks. And if you are on the command line and select drive B: without having one, oh well... Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
(Although the message was e-mailed to me personally, I was asked to reply to the list, so I did.) On Mon, 31 May 2021, Eric Auer wrote: Hi Steve, That's what DRIVPARM is for. I used to use it on my old Tandy 1000HX because the firmware, being XT-class, reported the A drive as 360K when it was actually 720K. Thanks! First hardware which acually DOES need it :-) I think we do not have DRIVPARM in the kernel yet either? Can't remember. I know I commented on issues running FreeDOS on a Tandy 1000HX, but this was literally 20 years ago. DRIVER.SYS did the same thing but it created a virtual floppy drive with its own letter, and when that drive was accessed, it had DOS ask for a disk swap. Are you sure? Maybe it just was for drives which were not even reported as existing at all by the BIOS, but which were real? It's actually why I used it back in the day. Most of what one would use driver.sys for, honestly, drivparm made redundant. But driver.sys was supported earlier than drivparm. -uso.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On Mon, 31 May 2021, Eric Auer wrote: 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. That's what DRIVPARM is for. I used to use it on my old Tandy 1000HX because the firmware, being XT-class, reported the A drive as 360K when it was actually 720K. DRIVER.SYS did the same thing but it created a virtual floppy drive with its own letter, and when that drive was accessed, it had DOS ask for a disk swap. -uso. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
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 = h 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
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hello Eric, On 31 May 2021, at 14:39, Eric Auer wrote: Hi Mercury, Steve, Carsten and Ladislav: You are all ignoring the fact that you can simply use the already existing API to provide your own, graphical floppy change (or DJ mechanism) dialogue. There is no need to re-invent the wheel! INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION AX = 4A00h CX = h DH = new drive number DL = current drive number Return: CX = h to skip "Insert diskette for drive X:" message Note: called by MS-DOS 5.0+ IO.SYS just before displaying the message "Insert diskette for drive X:" on single-floppy systems Your apps can hook int 2f, function 4a00. If it returns cx=-1 then DOS will assume that you have already asked the user to switch to the new disk. DOS will not show a text message about that and will not wait for keyboard input if you do this. Eric this helps for new applications or applications where we have the source, but it does not help with all the existing applications (possibly closed source). If I understand correctly, the desired effect would be that access to floppy B: without a physical 2nd floppy in the system will return an error to the application instead of the DOS kernel intercepting the access and prompt for a floppy change. This might already be possible with the available drivers/config.sys options. Greetings Carsten ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hi Mercury, Steve, Carsten and Ladislav: You are all ignoring the fact that you can simply use the already existing API to provide your own, graphical floppy change (or DJ mechanism) dialogue. There is no need to re-invent the wheel! INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION AX = 4A00h CX = h DH = new drive number DL = current drive number Return: CX = h to skip "Insert diskette for drive X:" message Note: called by MS-DOS 5.0+ IO.SYS just before displaying the message "Insert diskette for drive X:" on single-floppy systems Your apps can hook int 2f, function 4a00. If it returns cx=-1 then DOS will assume that you have already asked the user to switch to the new disk. DOS will not show a text message about that and will not wait for keyboard input if you do this. Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On Monday, May 31, 2021 6:36 AM, Steve Nickolas usots...@buric.co wrote: > On Mon, 31 May 2021, Mercury Thirteen via Freedos-devel wrote: > >> +1 >> Personally, I always thought it would be best to have this "phantom >> drive" feature disabled by default and allow the user to enable it if >> they need. But that's just me. :) > > Personally, I'd go with the opposite: behavior compatible with MS-DOS 3.3 > ought to be the default because it's what most people would expect from > software that has as its primary compatibility target Compaq MS-DOS 3.31 > (not sure if that's still accurate, it's certainly been a long time since > I checked). > ... Right! I wasn't suggesting FreeDOS change - I get why it was originally done, and that FreeDOS has to do it to mimic the behavior of any other DOS. I simply meant that I've always thought it should be optional, even back in the MS-DOS days.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On Mon, 31 May 2021, Mercury Thirteen via Freedos-devel wrote: +1 Personally, I always thought it would be best to have this "phantom drive" feature disabled by default and allow the user to enable it if they need. But that's just me. :) Personally, I'd go with the opposite: behavior compatible with MS-DOS 3.3 ought to be the default because it's what most people would expect from software that has as its primary compatibility target Compaq MS-DOS 3.31 (not sure if that's still accurate, it's certainly been a long time since I checked). But with that said: 1. Allowing it to be disabled isn't a bad idea. (I'd go with SWITCHES=/B personally, but there's other options too.) 2. One could say that's what something like DRIVER.SYS is supposed to be for...and indeed, a virtual floppy drive created with DRIVER.SYS under MS-DOS or PC-DOS will trigger the "Insert diskette for drive X: and press a key when ready..." prompt, just like the virtual B drive. -uso. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
+1 Personally, I always thought it would be best to have this "phantom drive" feature disabled by default and allow the user to enable it if they need. But that's just me. :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, May 31, 2021 3:46 AM, Carsten Strotmann wrote: > Hi Ladislav, > > On 30 May 2021, at 23:44, Ladislav Lacina wrote: > > > Maybe is a time to consider whether to break the MS-DOS compatibility > > about > > handling the one physical diskette drive as two logical drives - A: > > and B: > > It maybe had some reason in 1982 but now? > > the same reason that was valid in 1982 is still valid today: machines > with only one floppy drive and no harddisk. I have a couple of these > machines where I use FreeDOS on (not only old machines, even some > relatively modern machines where the hard drives have been removed). > > The function is important when working in such environments. > > However it might be possible to introduce a configuration option in > config.sys that disables this function if users wish (or even inhibit > the phantom drive B: by default in case FreeDOS detects at least one > usable hard-drive partition during boot-up). > > Greetings > > Carsten > > 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
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hi Ladislav, On 30 May 2021, at 23:44, Ladislav Lacina wrote: Maybe is a time to consider whether to break the MS-DOS compatibility about handling the one physical diskette drive as two logical drives - A: and B: It maybe had some reason in 1982 but now? the same reason that was valid in 1982 is still valid today: machines with only one floppy drive and no harddisk. I have a couple of these machines where I use FreeDOS on (not only old machines, even some relatively modern machines where the hard drives have been removed). The function is important when working in such environments. However it might be possible to introduce a configuration option in config.sys that disables this function if users wish (or even inhibit the phantom drive B: by default in case FreeDOS detects at least one usable hard-drive partition during boot-up). Greetings Carsten ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
Hi Laaca! > Maybe is a time to consider whether to break the MS-DOS compatibility about > handling the one physical diskette drive as two logical drives - A: and B: ... > You have the physical drive A: only. You write DIR A: ... > > But if you write DIR B: you get this message: > > "Remove diskette in drive A: Insert diskette in drive B:" > > Systems waits for keypress and then displays content of A: You say that this gets ugly while you are in full screen apps. I have good news for you: All DOS have a mechanism which let apps intercept the DJ mechanism handling, so they can show a graphical dialog in that situation :-) Your apps simply have to support it. Alternatively, simply only use A: then you do not get the question to switch to the "DJ virtual" B: either. Regards, Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
