Roy Shea roy@cs.hmc.edu writes:
Resubmission of a bare bones bits implementation.
There is no bits.dll on any Windows version I've checked. Where does this dll come from?
Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard:
Roy Shea roy@cs.hmc.edu writes:
Resubmission of a bare bones bits implementation.
There is no bits.dll on any Windows version I've checked. Where does this dll come from?
It is an extra download, but requires a WGA check.
Howdy,
On Thu, Sep 27, 2007 at 02:55:40PM +0200, Stefan D?singer wrote:
Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard:
Roy Shea roy@cs.hmc.edu writes:
Resubmission of a bare bones bits implementation.
There is no bits.dll on any Windows version I've checked. Where does this dll come from?
It is an extra download, but requires a WGA check.
Argh! My bad. I just finished looking into this a bit more and here is my current understanding.
You can download "bits" from Microsoft, but I don't think you are going to get a bits.dll out of it. The dll that I'm working on is intended to stand in for the collection of dlls available at http://support.microsoft.com/?kbid=923845, although most Windows users should already have the dlls:
Qmgr.dll -> Very old version of bits that appears to be heading towards deprecation.
Bitsprx2.dll -> Base version of bits that I'm trying to implement for wine.
Bitsprx3.dll -> Version 2.0 of bits adding features to the base version (gotta love the off by one numbering scheme!).
Bitsprx4.dll -> Newest extensions to bits available on some systems.
As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the "prx" in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems.
My understanding of proxies is that they allow "cross-apartment access" to a COM object. Ideally, I'd like to first get in process support of bits (CLSCTX_INPROC_SERVER object instantiation), and then worry about support across apartments.
I am new to both COM and Wine and I may be a bit off in my understanding of some of these points. I would love any advice on how to get my current code in shape for Wine. In particular, should I provide a full proxy version of bits and resubmit it as Bitsprx2.dll or should I introduce basic functionality first, perhaps through bits.dll or something else, and then jump in on the proxy code.
Thanks for the advice! -Roy
Roy Shea roy@cs.hmc.edu writes:
As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the "prx" in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems.
The only way to avoid confusion and problems is for your dll to have the same name, and behave the same way, as the Windows one.
-
Alexandre Julliard -
Roy Shea -
Stefan Dösinger