ntdll/cdrom : implement CDROM_Verify to work on Mac Os

maury loïc lmaury at gmail.com
Sat Jan 1 05:07:09 CST 2011

On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie
<jjmckenzie51 at earthlink.net>wrote:

> On 12/31/10 1:50 PM, Charles Davis wrote:
>> On 12/31/10 1:11 PM, Ken Thomases wrote:
>>> I should add that this patch seem correct to me.  It couldn't hurt to get
>>> Charles Davis's input, of course.
>> I agree, for now. He should at least put a comment in to the effect of
>> "if we got this far, there's already media in the drive."
> That was the point I was trying to get to.  Based on Ken's comment below,
> the device is temporary and only exists for the time period that the device
> is in use.
>  MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is to check if the
>>> media has changed.  The Linux and FreeBSD implementations basically just
>>> check if there's media in the drive.  On Mac OS X, the BSD device file just
>>> plain doesn't exist unless and until there's media mounted.  There's no
>>> permanent BSD device file for the drive itself.  So, if CDROM_Verify() is
>>> called, which requires that the BSD device file is opened and thus is
>>> present, that by itself implies that there's media in the drive.  Therefore,
>>> CDROM_Verify() should just return success.
>> Makes sense. But the 'right' way to implement this on Mac OS is to ask
>> DiskArbitration to tell us when the media changes. (In fact, the right
>> way to implement this elsewhere is to ask udev or hald the same thing.)
>> Then we can return STATUS_VERIFY_REQUIRED (as documented) when the media
>> actually has changed. For now, though, Loïc's patch is OK.
> Is this going to be changed sometime in the future to work per the
> documentation?
>  AJ wants to eventually move some (all?) of the disk/CD/DVD/storage
>> IOCTLs into mountmgr anyway, where Wine's fake storage drivers are
>> hosted. Mountmgr already has infrastructure in place to talk to DA on
>> Mac OS and to hald on Linux/FreeBSD, so doing this the 'right' way will
>> be much easier there.
> This is a good point.  Maybe the effort should be to move the code over to
> mountmgr.sys rather than implement and have to move it later.
> And I am aware what the process is, I was asking general questions based on
> what the comments were in the patch.  Basically, the comments did not make
> sense to me and I was asking for clarification.  That was provided by both
> Ken and Charles' comments.
> James McKenzie
Hello Mr.McKenzie and Wine community,

Happy new years.

In fact, I don't try to resolve the SCSI command ioctl, to support the
I have just modified the CDROM_Verify(), because I thought, this function
verify if the media is present in the device.

Here my reasoning :

in dll/ntdll/cdrom.c, we are in the function CDROM_DeviceIoControl().

get_parent_device() is called to get the device and Wine try to open the

For what I understood,  Mac Os will create an entry object into the I/O
who represent our device, (the device exist at boot time or when it is

get_parent_device() will find the object, and store the name of device.

After the device is found, Wine try to open it.

In the case of IOCTL_*_CHECK_VERIFY request, CDROM_Verify is called, In this
function, we already know we have a valid device,
in use, but if the device is present, the media is present too, we can not
have a file descriptor to a device, without
media present.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110101/b0125d3b/attachment.htm>

More information about the wine-devel mailing list