--- Mike McCormack <mike(a)codeweavers.com> wrote:
I think it might be Alexander, and I think the general suggestion was "avoid changes to the wineserver". Anyone else know?
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.
Wine cannot present a driver interface to the rest of the system, nor to other programs.
Winelibs can.
If you want to get a scanner going, the best way would be to make it work with SANE or V4L,
Sure, please convince every hardware manufacturer in the world to release all the documentation for all their hardware so we can make Linux drivers. There is a reason SANE and V4L only support _some_ (read: few) hardware.
and then get SANE or V4L to work with Wine's still imaging interface. That is much better than getting it to only work in Wine, as other applications will be able to use it via SANE, etc.
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?
This is by design. Alexandre has said time and time again that he considers Wine to be just like any other application on the system; it reads file through the 'nix FS, and through unix file descriptors.
If you still want to loader the Windows driver, go and have a look at ndis wrapper. http://ndiswrapper.sourceforge.net/
If you *still* insist that you're going to load drivers in Wine, then don't be suprised if your patches are quietly dropped, and your requests for help are quietly ignored.
Then don't be surprised if I make it into a commercial project :-). Enough talk, I'm off to code.
Mike
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Damjan Jovanovic wrote:
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?
I assume you mean HWND and HICON. They are not wineserver (kernel32) objects. A HWND is a user32 handle, and an HICON in Wine is a process local pointer. A HKEY is more interesting for the purposes of this discussion, as it is a wineserver object, and it is not tied to a unix fd. That's because you can't use ReadFile and WriteFile on it... Mike
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
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.
I've already got a (somewhat hacky) partial implementation for kernel mode drivers for copy protection drivers, so if you're interested let's try and not duplicate work, I can send what I have ATM to whoever's interested. Ivan.
participants (4)
-
Damjan Jovanovic -
Ivan Leo Puoti -
Mike McCormack -
Rolf Kalbermatter