Need ideas about ntoskrnl (WITH ideas)

[Mike McCormack]

Damjan Jovanovic wrote:

> Using int 0x2e and other Linux-specific hacks like
> kernel modules, limits portability of Wine, you'll
> never get it working on Windows itself.

I have no idea why you'd want to port Wine back to Windows to use 
Windows device drivers.

> 4. TYPED HANDLES
> ----------------
> Modify HANDLE to somehow store handle type, or else function pointers to functions used on handles, like reading, writing and ioctl's. NTDLL functions like NtWriteFile(), NtReadFile() and NtDeviceIoControlFile() should use the handle type to demultiplex the I/O request to the correct function. So for example when NtDeviceIoControlFile() is called on a handle of type (say) WINE_HANDLE_USB_SCAN, the function UsbScanDeviceIoControl() is called, when it's called on a handle of type WINE_HANDLE_CDROM then CDROM_DeviceIoControl() is called. It would help too if some generic data (eg. void*) could be associated with each handle, so code managing a handle family could store some internal data there.
> Personally I advise:
> 	struct HandleData {
> 		VOID (*Close)(HANDLE handle);
> 		DWORD (*Ioctl)(HANDLE handle, /* Other DeviceIoControl() parameters */);
> 		DWORD (*Read)(HANDLE handle, LPVOID *buffer, DWORD size);
> 		DWORD (*Write)(HANDLE handle, LPVOID *buffer, DWORD size);
> 		VOID *internalData;
> 	};
> 	#define HANDLE_TO_HandleData(h) ...

Wine used to have function call tables like this about 5 years, and 
typed handles about a year ago.  Those things have been removed on purpose.

You can't store function pointers in the wineserver, as each process may 
have those functions at a different address.

It looks like Alexandre has made the design decision to live with a file 
handle mapping to a single Unix file descriptor a while back.  That 
makes things difficult for people who want to write code to load and use 
device drivers in any consistent fashion.

Mike