Moin Mike,

26.11.95 16:42, you wrote a message to Vitus Jensen:

...
 VJ>> I have no problems to read a data CDROM using the code I
 VJ>> posted here the other day. Any switches different between
 VJ>> your and my call to DosOpen? 

 MB> Whether DosOpen() fails with OPEN_FLAGS_DASD asserted if CDFS.IFS 
 MB> is loaded appears to be specific to the version of CDFS.IFS.

I have tried this with 2.30 US and (as I remember) 2.1 GR, no patches on
either version.


 MB>> If you comment out the load of CDFS.IFS in CONFIG.SYS, then no 
 MB>> file system will claim the drive letter created for the CD-ROM 
 MB>> drive by OS2CDROM.DMD, and you can do direct access to it.

 VJ>> You can't lock the device if a filesystem driver is loaded.
 VJ>> But you don't need a lock if you're only reading (who wants
 VJ>> to write to a CDROM?). 

 MB> Technically, what happens when direct access calls are made to a 
 MB> drive letter being actively managed by a file system is that the 
 MB> IFS gets notifications from the DMD about the access attempts, 
 MB> and it can either allow or decline them.  This is handled by a 
 MB> callback process between the IFS and DMD, depending upon the 
 MB> driver capabilities bits.

How did you manage to get information on all that stuff? I would be very
interested in your source!

 MB> Locks can be manageed by the IFS itself if it is set up to do 
 MB> this, but will be handled by the FS Router (a component of the 
 MB> kernel above the IFS) by default.  You are right that a lock is 
 MB> not required for reading unless there is a concurrent writer, 
 MB> which obviously never happens for CD-ROM.

An OPEN on letter 'g:' should result in OPEN UNIT send to OS2CDROM.DMD,
right? Why can't I find any code referring to an IFS-driver in the
DDK-source? Neither open() (which returns directly) nor read does any
callbacks before executing an IORB.


 VJ>> The comments in the source of OS2CDROM.DMD declare a device
 VJ>> with /!DM set won't by allocated. But this flag is never
 VJ>> tested. Perhaps the production code works that way.

 MB> Only OS2DASD.DMD should check the "/!DM" switch.  The comment in 
 MB> the source looks like a consequence of cut and paste from 
 MB> OS2DASD.DMD.
 
Well, OS2DASD.DMD only allocates UIB_TYPE_DISK, so they could have abused this flag.
Did you get all your  knowledge from a freely available source (please name
it!) or is it "just" collected over the years? I'm writing ADDs
so any of that stuff could be very usefull to me.

Tschuesz,
	Vitus 

PIN: 10:1000/100.20
Fido: 2:2474/100.20
Internet: vitus{at}vortex.de

---