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

[Charles Davis]

Charles Davis wrote:
> Alexandre Julliard wrote:
>> Charles Davis <cdavis at mymail.mines.edu> writes:
>>
>>> OK, thanks. Now I've got this straight. I should do something like
>>> dlls/mountmgr.sys/device.c, where I'd have an NT device like
>>> \Device\CdRom0 (or some such), whose FD I'd pass to the server so that
>>> when NTDLL opens the device and gets its FD, it still has the CD-ROM
>>> device for client-side calls. But when I need to call mountmgr, I open
>>> \Device\CdRom0 (or some such) and pass the IOCTL on to mountmgr. Is that
>>> right? Or am I still missing something?
>> Pretty much, except of course you don't open \Device\CdRom0 yourself,
>> the app does that, and you get a handle to it.
>>
> OK. Actually, I thought of that right as I got your email. Now only one
> thing bothers me. Right now, ntdll does special-casing on DOS devices.
> So, if you open \DosDevices\D: with NtOpenFile() (or equivalently,
> \\.\D: with kernel32.CreateFile), ntdll magically turns that into
> $WINEPREFIX/dosdevices/d::. Then the server opens the file like any UNIX
> file. What I'm guessing you want is for opens of \DosDevices\D: to go to
> \Device\CdRom0 (because \DosDevices\D: is supposed to be an NT symbolic
> link). How then am I supposed to associate a UNIX file with
> \Device\CdRom0? Or, is this not what you want?
OK, I've done some research, and I've figured out that I need to handle
IRP_MJ_CREATE in mountmgr. According to MSDN, this is the major function
code for device open requests. But then how do I associate an FD to the
file handle that gets created afterwards? And is calling the
IRP_MJ_CREATE handler even implemented, or do I have to do that myself, too?