RFC: ntdll: Implement CDROM_GetInterfaceInfo() on Mac OS (try 2)

Charles Davis cdavis at mymail.mines.edu
Thu Oct 22 13:57:13 CDT 2009


Alexandre Julliard wrote:
> Charles Davis <cdavis at mymail.mines.edu> writes:
> 
>> Now I just need to figure out how to do that. I read the headers and
>> source, and figured out a QUERY_UNIX_DRIVE won't work because it needs a
>> drive letter, and NTDLL isn't supposed to know about drive letters.
>> Maybe we can use the device name by doing something similar to
>> get_parent_device(). But that only works on Mac OS. If we do this for
>> Linux, too, we'll have to figure something else out. Maybe if we fstat()
>> the FD and get its device number, we can use it to find the file system
>> corresponding to it. Something like that could work on Mac OS, too, and
>> there's similar code elsewhere in Wine (in ntdll itself, if I'm not
>> mistaken). Maybe I could even hijack that code for this purpose instead
>> of reinventing the wheel.
> 
> The way it needs to work is basically that opening the device would open
> an NT-style device instead of directly the Unix device. Then you have a
> handle that you can use with mountmgr, and mountmgr can give you an
> appropriate unix fd for calls that are performed on the client side.
> 
Oh, I see. You mean I should open a handle to mountmgr with
NtOpenFile(). That's what I thought. Now I just need to figure out the
right IOCTL. Maybe I need to make one up. And I still don't know how to
specify the correct device to mountmgr. (The answer is "depends on the
IOCTL," so I need to answer the first question before I can answer this
one.)

Another thing I don't quite understand: what good would an FD from the
mountmgr device do? I looked at mountmgr, and I don't see any code for
handing out FDs. No open()s, no sendmsg()s, no nothing. The only
function I see in ntdll for this is server_get_unix_fd(), which is what
we use to get the device FD from the NT CD-ROM device handle, and again
I don't see how that will help. I mean, it's probably something like a
socket or a pipe so all we can do is read and write it. (With sockets,
we have some system IOCTLs, but they're all for controlling the socket
itself.) And that's if there even is one. I looked at wineserver, and it
looks like some file objects don't have to have real FDs behind them. Or
did you have a different FD in mind, one I haven't thought of?

Oh, and you didn't answer my other question. But I have a feeling you
aren't going to even see this part, let alone answer it anytime soon.

Chip





More information about the wine-devel mailing list