On 5/5/07, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to > NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably > through libusb), and modify ntdll to forward the appropriate reads, > writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file > can handle them. This is the only way that works with .SYS files > out-of-the-box, the others all require a rewrite of the .SYS driver's > functionality. Architecturally, this is the best way, you wouldn't > need to change any code in wine to add a new driver. > > Way 4 is probably the best and I hope it works at some stage, but it's > still a long way off seeing as how NTOSKRNL.EXE itself still isn't in > wine. Correct me if I'm wrong, but you're saying that this approach would enable wine to work with (almost?) any USB device, which has a vendor specific, kernel-mode driver, using the vendor's supplied driver out-of-the-box.
Yes.
Sounds like the best approach to me too. Maybe there are other people out there with the same problem as me, (or simply a desire to get better USB support in to wine) who would be interested in working on this too?
But it's a lot of work, and very few people know how to write Windows drivers. NTOSKRNL.EXE has been around for a year or 2 now, and it still hasn't been accepted into wine. On a brighter note, NDISWRAPPER already works with some USB drivers, so it can't be that hard to do.
Jono
Damjan
