Charles Davis wrote:
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cdavis@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?
I have another idea that, unlike my previous one, might actually work. What if the server kept track of which UNIX device files belonged to which device objects? Then, when the server gets a request to open a device, it could back the associated file object with a real FD object coming from the UNIX device. Mountmgr could call the server with the path to the UNIX device file it wants to associate to its device objects. Do you think that will work? IRP_MJ_CREATE doesn't seem to be implemented in ntoskrnl, so I'm going to assume that going the IRP_MJ_CREATE route won't work--or at least will require substantial work.