Hi, >> Character devices can be found by their name and can be >> controlled via IOCTL... In addition, because you pass >> the device name as command line option to CDEX, this way >> is slightly more end user friendly than int2f handlers, >> in particular if you have more than 1 CDROM driver loaded.
> Nothing you couldn't do on a Int2D (AMIS) or a well designed > Int2F interface. You could ask MS why they did things the way they did ;-) >> While both the DOS block device interface and the CDROM >> driver interface are relatively small, they are not as >> similar as you might assume. The latter has various CD >> audio related calls, for example. > Well, some calls might be reserved for FS-specific tasks (such as audio > tracks). Just as function numbers >= 80h are now, but on block instead of > character devices. You COULD redesign the whole idea of "DOS block device", but you COULD also use said "well designed int 2f" ;-). >> You could indeed design some interface which gives block >> based easy access to non-FAT int13 devices, possibly >> duplicating some involved small parts of the kernel... Explanation: If it is in the kernel then you probably want it to give access to kernel functionality. The duplication would only be for the sake of experiment before the interface would be in the kernel itself... > I'm talking about non-FAT DOS block devices. This especially includes > (beside Int13 devices) any SCSI/USB/whatever device that is _not_ > accessible through Int13 (and therefore invisible to usual Int13-only > local filesystem redirectors). As the kernel only opens filesystems which ARE accessible through int13, it would probably be better to design a nice (e.g. int2f) interface OUTSIDE the kernel. There, one driver can give lowlevel block access while others can give redirector / filesystem access. This is exactly what the USBASPI ASPIDISK duo does, although they use the well-established ASPI interface instead of int2f... >> Then you could evaluate how many and which DOS drivers >> for other filesystems would use it, and then based on >> the outcome, some implementation of that interface can >> be put directly into the kernel. > It would be useless outside a kernel, won't it? No, see the USBASPI example. > The pro is that life for the local filesystem redirectors isn't just > simplified (in fact, it isn't - they would need more installation code if > they also want to support MS-DOS or other versions that don't support the > interface), they could act on drives that aren't visible to them on Int13. So does ASPIDISK. > BTW, I tried Mik's smbclient and it seems to work. (Keyboard input at the > smb: \> prompt is uncomfortable, but retrieving files from a MS Windows > 5.1 server works.) Currently requires about 80 KiB when shelling out, but > I assume a DPMI TSR for DOS drive redirection could do better. Sounds good :-) I did not know you could even shell out from it :-). Eric ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
