Need ideas about ntoskrnl
wine-devel at kievinfo.com
Mon Sep 5 10:49:47 CDT 2005
We need ntoskrnl to run some subset of drivers on wine. Notably cd protection
drivers. They are not a hardware drivers, but a means to access something that
is not accessible from user space. So in a sense ntoskrnl is just a process to
run those drivers in, and send/receive requests to/from those drivers.
You need to keep in mind that this is a kernel level, so some things will not
work, and some things have to work that normally do not in the user space. Also
ntoskrnl for windows _is_ what wineserver for wine.
User space programs talk to these drivers in the following way:
1. At the start up, driver creates symbolic link in "\DosDevices\something".
2. Program calls CreateFile("\\.\something",..) to get a handle to the device.
3. Uses ReadFile/WriteFile/DeviceIoControl on that handle. (For now we need only
DeviceIoControl. Read/Write could be added later.)
Here is a list of the most pressing problem and the way to solve them.
Any ideas and comments will be greatly appreciated, Vitaliy.
1. Open handle to a device - NtCreateFile.
2. Call DeviceIoControl on a device. (This also includes (1) since we need to
know that this is not a cdrom, vxd or something else.)
3. Resolve user space handle to the DEVICE_OBJECT. (Assuming that we don't call
ntoskrnl through wineserver).
Solutions for (1):
1.1. Use a hack to determine that passed name is a device name. (Device names
don't have colon in them).
1.2. Check against all possible names other then device names. (A:..Z:, etc.)
1.3. Try it last if all else fails. (since name spaces don't intersect this
1.4. Use object manager to lookup the name to find out what is it. (Unless we
open all handles using this method it will add one extra wineserver call.)
Solutions for (2):
2.1. Use named pipe to communicate with ntoskrnl process. Pass commands over the
pipe in internal format.
2.2. Use UNIX IPC to talk to ntoskrnl. (pipe, socket, etc.)
2.3. Call wineserver which will call ntoskrnl using 2.1. or 2.2.
2.4. Call wineserver which will call ntoskrnl using proper IoXXX functions from
ntoskrnl to create an IRP. ntoskrnl will process them and notify wineserver
when call is complete.
(This is the most complicated and closer represents what windows does.
There are still a problem communicating to ntoskrnl. It is probably the
way to go in the future. But that will require number of things implemented
which are not trivial.)
Solutions for (2):
MSDN quote: "Note that handles are not used for accessing device objects or
3.1. Use wineserver to resolve handle to some internal identifier and pass it to
3.2. Pass handle and calling process id (pid, global handle, etc.) to ntoskrnl.
ntoskrnl will call wineserver to resolve handle to internal id. (This
handle will have to be either cached, or it will have to be created for
3.3. (requires 2.3. or 2.4.) Wineserver will resolve handle and pass internal id
to ntoskrnl. (Unless we want wineserver do much more than that.)
More information about the wine-devel