[I mistakenly posted this to comp.emulators.ms-windows.wine / wine-users rather than here. Thanks to eric pouech for his reply there. Sorry if you've already seen this there]
Hi,
I've been lurking for a while now with a view to starting work on wine - specifically COM and DCOM. I know some people have started some work and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous").
I've read most of the developer docs and some relevant source but I'm still having problems grokking the interrelationships between different parts of wine and the role(s) of wineserver. I have a general understanding of Win32 from a programatic point of view rather than wine's implementation details. While I'm quite willing to "read the source" there's rather a lot of it :) and rather deep dependencies (even with tags one jumps around for a while trying to understand what does what).
Does anyone have a call graph for wine or a (decent, open-source) program for making one. I've considered Source-Navigator but it seems like the required database would be twice the size of the wine source!
Since (D)COM affects many parts of function and message handling and process address space tampering I considered the less ambitious project of fixing up (Net)DDE first - at least then the all-important Hearts will run networked. Is anyone actively working on that (the source has sporadic updates)? I don't want to start hacking off on a tangent. The different behaviours of win9x and NT will also be a problem since I don't have a real NT installation
Also, what do people use in terms of test-suites? custom win32 apps? free/shareware? While I have quite a few larger apps like Office etc I imagine it's better to try smaller, more specific apps at first. I want to do comparisons and communication with Win95/8 in VMWare and don't really want to _purchase more Win32 apps_ for testing!
Thanks for any experience or insight you might share.
Phillip
Phillip Schmitz wrote:
I've been lurking for a while now with a view to starting work on wine
- specifically COM and DCOM. I know some people have started some work
and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous").
I doubt that DCOM has fewer patent issues than COM.
By the way, here's a good 'executive summary' of com/dcom: http://www.sei.cmu.edu/str/descriptions/com_body.html And here's the official spec (yes, there is one!): http://www.opengroup.org/onlinepubs/009899899/ The above document is actually the "ActiveX" spec, so it covers more than just COM, but that's probably good. I don't know how good it is as an implementor's guide, but it looks promising.
Also, what do people use in terms of test-suites? custom win32 apps? free/shareware? While I have quite a few larger apps like Office etc I imagine it's better to try smaller, more specific apps at first. I want to do comparisons and communication with Win95/8 in VMWare and don't really want to _purchase more Win32 apps_ for testing!
Good question.
There *is* a COM conformance test suite; see http://www.microsoft.com/msj/1298/ntUnix/ntUnixtop.htm I doubt that Microsoft would let Wine developers use it, though.
On the other hand, the Open Group sells COM/DCOM implementations packaged with the interoperability test suite at a "nominal fee"; see http://www.opengroup.org/comsource/datasheet.htm They have released things like Motif as open source in the past... I wonder if they'd be willing to contribute their DCOM or the test suite? That would rock.
Anyone know anyone who works at the Open Group? :-)
- Dan
Phillip Schmitz wrote:
[I mistakenly posted this to comp.emulators.ms-windows.wine / wine-users rather than here. Thanks to eric pouech for his reply there. Sorry if you've already seen this there]
Hi,
I've been lurking for a while now with a view to starting work on wine
- specifically COM and DCOM. I know some people have started some work
and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous").
Ove Kaven of TransGaming is working on out-of-process COM issues right now in the hopes of getting InstallShield V6 installers working. Have a look back at the recent wine-devel archive for more information. If you want to help, one thing that's needed immediately is a reader for older format Typelibs. This is needed so that we can create an appropriate 'proxy' object on the client and 'stub' on the server that can marshall the data for the functions that are getting called.
Check out some of the previous discussions on Wine-devel to learn more about this. Any help you can render on that front would be great!
-Gav
Ove Kaven of TransGaming is working on out-of-process COM issues right now in the hopes of getting InstallShield V6 installers working. Have a look back at the recent wine-devel archive for more information. If you want to help, one thing that's needed immediately is a reader for older format Typelibs. This is needed so that we can create an appropriate 'proxy' object on the client and 'stub' on the server that can marshall the data for the functions that are getting called.
Unless I've totally misunderstood Huw, he's well on his way to having at least one older Typelib read. He's out right now at a wedding, but will hopefully be able to speak more coherently for himself later.
Jer
On Wed, Aug 15, 2001 at 10:02:58PM -0500, Jeremy White wrote:
Ove Kaven of TransGaming is working on out-of-process COM issues right now in the hopes of getting InstallShield V6 installers working. Have a look back at the recent wine-devel archive for more information. If you want to help, one thing that's needed immediately is a reader for older format Typelibs. This is needed so that we can create an appropriate 'proxy' object on the client and 'stub' on the server that can marshall the data for the functions that are getting called.
Unless I've totally misunderstood Huw, he's well on his way to having at least one older Typelib read. He's out right now at a wedding, but will hopefully be able to speak more coherently for himself later.
That's correct. I should be able read at least basic SLTG by the end of next week. Are there other older formats out there?
[Out of interest, does anyone know SLTG stands for?]
Huw.
Gavriel State wrote:
Phillip Schmitz wrote:
[I mistakenly posted this to comp.emulators.ms-windows.wine / wine-users rather than here. Thanks to eric pouech for his reply there. Sorry if you've already seen this there]
Hi,
I've been lurking for a while now with a view to starting work on wine
- specifically COM and DCOM. I know some people have started some work
and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous").
Ove Kaven of TransGaming is working on out-of-process COM issues right now in the hopes of getting InstallShield V6 installers working. Have a look back at the recent wine-devel archive for more information. If you want to help, one thing that's needed immediately is a reader for older format Typelibs. This is needed so that we can create an appropriate 'proxy' object on the client and 'stub' on the server that can marshall the data for the functions that are getting called.
Check out some of the previous discussions on Wine-devel to learn more about this. Any help you can render on that front would be great!
If anyone doesn't know a good reference to look at is the FreeDCE project. I think I read another post saying that Microsoft based their COM/DCOM stuff on DCE .
http://freedce.sourceforge.net/
They have a (typelib) idl compiler too, maybe the "old" MS format is similar to the FreeDCE format..
Daniel Walker
-
Dan Kegel -
Daniel Walker -
Gavriel State -
Huw D M Davies -
Jeremy White -
Phillip Schmitz