On Fri, 11 Jan 2002 00:04:59 +0100, Richard Zidlicky wrote: > On Thu, Jan 10, 2002 at 10:00:33PM +0100, Thierry Godefroy wrote: > > > I don't use the non-directory device driver IOT implement the CDROM device > > driver (which will indeed be a "legal" SMSQ/E directory device driver): I use > > a FAKE non-directory device driver so to intercept the long filename, store > > its address in a safe place for later use by the actual directory device > > driver (here, the CDROM one), and then replace it (changing the address > > passed by and back to the IOSS in A0) by a truncated filename; > > this seems slightly risky to me; the fact that QDOS/SMSQ did never save/ > restore A0 when calling the driver open routine is no guarantee this will > stay so forever. You are depending on undocumented behaviour..
NOT AT ALL !!! This is perfectly documented: the documentation for the IOSS (see the QDOS/SMS reference manual) DOES says that A0 must stay unchanged or at least be restored if the device driver did not recognize its own device in the name during an open call, and it also says that this is because A0 is reused after by the other device drivers. > why this complication? The IOSS will be of very little help for you, all > "facilites" it provides are usefull only for very limited filesystems > like the original MDV one. Instead it limits unnecessarily 'key' and > uses valuable drive definition blocks which are still very limited > resource. I NEED to implement it as a legal directory device driver for a few reason: at the user (and utility programmers) level, you must register it so or the device (here cdr1_) will never be found as a mass storage (e.g. in QPAC2 or Cueshell). At the driver programming level, I will use (although differently than TT does) the slave blocks for caching (in fact caching will occur ONLY when less than a CD-R data block (=2048 bytes) read is requested). > You get the mangled display of filenames in QPAC channels menu but this > can be only an intermediate solution, Whatever way you choose to implement a long filename driver, you simply CAN'T support fully existing utilities which make the assumption that the 36 chars limit applies to all devices ! Moreover the truncated filename will not be "mangled" (it will just have 4 alphanumeric characters at the end) > anyway clean methods have to be > defined to get the name of open channels (if it is regarded usefull > enough feature). This already exists as a TRAP #3 call in SMSQ/E and will actually return the long filename with my method. Anyway I think that the best thing now (well, in fact in 7 months, when I will be back to France) is to implement the driver the way I feel like and release it. Then anyone will have the possibility to criticize the way it was implemented, and the opportunity to change it himself (it will be open source)... ;-) QDOS/SMS forever ! Thierry.
