Mike McCormick wriote:
I'll point out to you once again that Wine is not the right place to implement drivers. Drivers that are loaded in the kernel in Windows also belong in the kernel in Linux, not in Wine.
I don't care about Windows kernel drivers, just replicating the interface to them from user space software so that user-space drivers (which are abundant in Windows) can work.
In the case of video capturing through avicap32 and most probably quartz too, we would be talking about "installable" drivers (loaded with winmm.OpenDriver) which reside in user space. It's the same driver interface used for audio drivers (alsa, oss, etc) and image companders (IC).
I think it would be a good idea to add a winev4l driver into winmm so that quartz and avicap/vfw could make use through a standard interface and adding new capture interfaces would be possible without the need to hack into avicap or quartz at all.
Have a look at the work that Maarten Lankhorst is doing on Web cameras ... he's doing things the right way.
You can continue trying to modify CreateFile, ReadFile, WriteFile etc. to make it work, but you'll realize sooner or later that a handle is tied to a unix fd.
In fact, it's tied to an "object" in wineserver: what fd would HWINDOW and HICON represent?
Mike was refering to handles returned by CreateFile only. It is the interface to create kernel device driver instances under Windows and consequently wineserver would need to be involved somehow. HWINDOW and such while handles too, are completely different objects and managed by independent object managers both in Windows and Wine.
A clean implementation for kernel driver support would need to support all kernel driver API interfaces through wineserver somehow, a nightmare both for performance and implementation reasons.
Rolf Kalbermatter