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. >> If MS-DOS (3.x) had support for linking >> the redirector interface with block devices, CD/DVD drivers would >> probably >> be written as DOS block devices, reporting impossible values when asked >> for a (FAT-specific) BPB. > > 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. >> The major problem seems that the redirector interface was designed for >> network redirectors, not for any kind of local non-FAT filesystem >> driver. > > 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... 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). Unrelated: I don't see why this should require duplicating any code. While it would need new code for the actual interface, why should I duplicate any code? > 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? > As said - my guess is that you would only simplify life > for non-FAT drivers a bit. On the other hand, you might > only complicate the kernel a bit either, so the pro and > contra of your suggestion are both relatively small...? 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. 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. 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
