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 ;-)
Obvious reason is obvious. Because they designed the redirector for network redirections, not to access local block devices. > You COULD redesign the whole idea of "DOS block device", > but you COULD also use said "well designed int 2f" ;-). Which doesn't exist. Instead, MS redesigned the whole idea of "DOS character device" for CD/DVD drivers ;-P >>> 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... Okay, I understand this now. >> 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, No it doesn't. It opens filesystems of any DOS block device. The filesystems on Int13 disks just happen to be the default filesystems searched for by the DOS initialization (and, when found, they're linked to a (the first) DOS block device). > This is exactly > what the USBASPI ASPIDISK duo does, although they use > the well-established ASPI interface instead of int2f... Do you know any site where I could get some (technical) information about that well-established interface? >> 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 :-). I just tried the ! command after discovering that ? showed a list of commands (without descriptions as it seems to be usual for Linux software). Christian ------------------------------------------------------------------------------ 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
