Need ideas about ntoskrnl (WITH ideas)

Damjan Jovanovic dj015 at yahoo.com
Thu Sep 8 13:21:39 CDT 2005



--- Mike McCormack <mike at codeweavers.com> wrote:

> 
> 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.

What if you want to run Windows XP apps on Windows 98?
I used a bad example, any non-Linux OS (FreeBSD,
MacOS, ReactOS) would have the same problem.

> > 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.

You could store arbitrary pointers, usable from wine
itself.

> 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.

Thus our problems arose.

> Mike
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the wine-devel mailing list