I've been working on a still image implementation for wine / ReactOS for a while now, and I've only recently realised how impossible it is in wine at the moment...
wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into wine, and if so, when?
wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet).
So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature?
And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)?
Thank you Damjan
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
On Thu, Dec 29, 2005 at 12:46:48AM -0800, Damjan Jovanovic wrote:
I've been working on a still image implementation for wine / ReactOS for a while now, and I've only recently realised how impossible it is in wine at the moment...
wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into wine, and if so, when?
If it can be ported to the WINE framework ... Feel free to submit patches ...
wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet).
So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature?
I would say only if we can make sure it works continously.
What does STI provide? Access to digital cameras and scanners?
Ciao, Marcus
Marcus Meissner wrote:
What does STI provide? Access to digital cameras and scanners?
IIRC, STI.dll is the API for scanners, and STI_CI is the API for digital cameras.. (STI being STill Image, and STI_CI being STill Image Capture Instrument or something close to that)..
On Thu, Dec 29, 2005 at 09:57:47AM -0600, Tom Spear (aka Dustin Navea) wrote:
Marcus Meissner wrote:
What does STI provide? Access to digital cameras and scanners?
IIRC, STI.dll is the API for scanners, and STI_CI is the API for digital cameras.. (STI being STill Image, and STI_CI being STill Image Capture Instrument or something close to that)..
In this case those should be implemented on top of sane and libgphoto2 I suspect. :)
Ciao, Marcus
--- "Tom Spear (aka Dustin Navea)" speeddymon@gmail.com wrote:
Marcus Meissner wrote:
What does STI provide? Access to digital cameras
and scanners?
IIRC, STI.dll is the API for scanners, and STI_CI is the API for digital cameras.. (STI being STill Image, and STI_CI being STill Image Capture Instrument or something close to that)..
No, STI.DLL handles every still image device, the "CI" in STI_CI.DLL stands for "class installer". Class installers are plugins SETUPAPI calls during device installation to do custom installation steps.
__________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
On 12/30/05, Damjan Jovanovic dj015@yahoo.com wrote:
No, STI.DLL handles every still image device, the "CI" in STI_CI.DLL stands for "class installer". Class installers are plugins SETUPAPI calls during device installation to do custom installation steps.
Do you suggest that Wine sync with ROS setupapi dll ?
Tom
--- Tom Wickline twickline@gmail.com wrote:
On 12/30/05, Damjan Jovanovic dj015@yahoo.com wrote:
No, STI.DLL handles every still image device, the
"CI"
in STI_CI.DLL stands for "class installer". Class installers are plugins SETUPAPI calls during
device
installation to do custom installation steps.
Do you suggest that Wine sync with ROS setupapi dll ?
Absolutely!
Tom
__________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
--- Tom Wickline twickline@gmail.com wrote:
On 12/30/05, Damjan Jovanovic dj015@yahoo.com wrote:
Absolutely!
could you do the merge ?
I've persuaded the ReactOS developers to relicence NEWDEV.DLL to LGPL, so this weekend I'll try get the ReactOS SETUPAPI.DLL and NEWDEV.DLL to build on wine-0.9.4.
If everything goes well, my new year's gift to wine will be a large set of patches for SETUPAPI, NEWDEV, and STI.
Tom
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Damjan Jovanovic wrote:
I've been working on a still image implementation for wine / ReactOS for a while now, and I've only recently realised how impossible it is in wine at the moment...
wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into wine, and if so, when?
I don't think it is planned. It is a question of showing a demand for the code and then someone taking the effort to merge the necessary parts.
wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet).
What does NEWDEV do?
So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature?
Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit them and then hope someone will come along and implement the necessary parts of NEWDEV or convince the ReactOS developers to re-license it.
And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)?
What documentation do you need? ncalrpc is just like any other transport - you just need to specify the right format for the endpoint and the RPC runtime does the work of opening it for you. Local methods are also straightforward. It just means that no remoting information is generated for it. This is typically used when the convenient form of the function has types incompatible with the RPC runtime. You can use a remote form with the call_as attribute to allow you to write a translating proxy/stub function to call the remote function. See dlls/oleaut32/usrmarshal.c.
Robert Shearman wrote:
What does NEWDEV do?
It's the driver installation wizard that pops up when the system detects a new device.
Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit them and then hope someone will come along and implement the necessary parts of NEWDEV or convince the ReactOS developers to re-license it.
Both, newdev and setupapi are LGPL in ReactOS.
- Thomas
--- Robert Shearman rob@codeweavers.com wrote:
Damjan Jovanovic wrote:
I've been working on a still image implementation
for
wine / ReactOS for a while now, and I've only
recently
realised how impossible it is in wine at the
moment...
wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under
the
right (LGPL) licence; are we planning on including
it
into wine, and if so, when?
I don't think it is planned. It is a question of showing a demand for the code and then someone taking the effort to merge the necessary parts.
wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's
latest
SVN version of it is a little closer to what I
need,
but can we include GPL code in wine? (I've asked
the
developers to relicense it under the LGPL for us,
but
they haven't gotten back to me yet).
What does NEWDEV do?
Called through rundll32.exe from umpnpmgr, it does all the user-interface aspects of device installation. All those screens you see in Windows, where you select a device category (eg. Mouse), then click "Next", then you see a list of manufacturers and their devices and that "Have disk" button, and then you select one and click "Next" and it carries on - all that is done by NEWDEV.DLL.
So what should I do - submit my STI.DLL and
STI_CI.DLL
into wine now, even though they won't be usable for
a
good while - or wait for wine to mature?
Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit them and then hope someone will come along and implement the necessary parts of NEWDEV or convince the ReactOS developers to re-license it.
And does anyone know any good documentation for writing COM out-of-process servers (that use
ncalrpc
transport and have some [local] methods)?
What documentation do you need? ncalrpc is just like any other transport
- you just need to specify the right format for the
endpoint and the RPC runtime does the work of opening it for you. Local methods are also straightforward. It just means that no remoting information is generated for it. This is typically used when the convenient form of the function has types incompatible with the RPC runtime. You can use a remote form with the call_as attribute to allow you to write a translating proxy/stub function to call the remote function. See
dlls/oleaut32/usrmarshal.c.
It seems you can't do the following - Microsoft's MIDL specifically forbids specifying binding handles for COM interfaces (so wine's widl must be broken, because it does allow it): [ object, implicit_handle(handle_t bindingHandle) ] interface IStillImage { .... }
So how else do you control which RPC binding handle is used in marshalling a particular COM interface?
-- Rob Shearman
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Damjan Jovanovic wrote:
Called through rundll32.exe from umpnpmgr, it does all the user-interface aspects of device installation. All those screens you see in Windows, where you select a device category (eg. Mouse), then click "Next", then you see a list of manufacturers and their devices and that "Have disk" button, and then you select one and click "Next" and it carries on - all that is done by NEWDEV.DLL.
That doesn't seem appropriate for Wine. We need to think hard about which way would be easiest for a user to use a scanner, etc. driven by STI. My opinion is that this functionality should be somehow integrated into winecfg.
And does anyone know any good documentation for writing COM out-of-process servers (that use
ncalrpc
transport and have some [local] methods)?
What documentation do you need? ncalrpc is just like any other transport
- you just need to specify the right format for the
endpoint and the RPC runtime does the work of opening it for you. Local methods are also straightforward. It just means that no remoting information is generated for it. This is typically used when the convenient form of the function has types incompatible with the RPC runtime. You can use a remote form with the call_as attribute to allow you to write a translating proxy/stub function to call the remote function. See
dlls/oleaut32/usrmarshal.c.
It seems you can't do the following - Microsoft's MIDL specifically forbids specifying binding handles for COM interfaces (so wine's widl must be broken, because it does allow it):
Yes, it is on my TODO list to improve the error detection in widl.
[ object, implicit_handle(handle_t bindingHandle) ] interface IStillImage { .... }
This doesn't make sense at all because COM interfaces don't use binding handles, but instead use the abstract IRpcChannelBuffer concept.
So how else do you control which RPC binding handle is used in marshalling a particular COM interface?
I think you can control which transport this uses, but it isn't really necessary unless you are remoting across a network. What are you trying to do?
Damjan Jovanovic wrote:
So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature?
It's likely somebody will have some comments on your code or Alexandre will require you to change the way things are done before he accepts it into Wine.
With this in mind, you should submit what you have early to get feedback on it. You should also attempt to break it up into smaller seperate, independent parts where possible.
For example, if you've changed include/sti.h, you could submit those changes first, as they're low risk and should be applied without any trouble. Same for any other improvements to Wine that makes sense on their own.
Some people are working on a driver framework for Wine, so you might want to consult with them about the best way to share that framework.
Mike
-
Damjan Jovanovic -
Marcus Meissner -
Mike McCormack -
Robert Shearman -
Thomas Weidenmueller -
Tom Spear (aka Dustin Navea) -
Tom Wickline