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 niave 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
> 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!I don't think it has been done before. However, as a rule of thumb, Wine is split up according to the Windows DLL (and with minimizing the extra function exported per DLL. 0 is a good value). So, if you know well the Windows API, this will help you reducing the call graph to the Windows API and to the internal symbols of one module (read DLL). That would a much better target for a call graph anyway.> 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 installationregarding DDE, there are a few milestones to achieve first: - interprocess window management (which is currently under progress, but not finished) - interprocess DDE message exchange (this shouldn't be harder than the rest of the interprocess message management), except perhaps for the house keeping - then finish the implementation of local/DDEML (and fix bugs) Alexandre works on item 1&2, and I have worked recently a lot on items 2&3, so I don't think it's worth spending too much time on DDEML regarding NetDDE nothing has been done so far, so you can start implementing your own stuff regarding COM, Ove has started working on the interprocess mechanisms, but will require lots of efforts too, so a helping hand may be desired (Ove ?) regarding DCOM, nothing has been done so far... however, it would perhaps be a good idea to share the underlying networked IPC of DCOM and NetDDE. Base it on RPC ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
On 14 Aug 2001 phi@icon.co.za 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 niave idea of implementing COM via DCOM - > it would be almost transparent, slower but less "dangerous").It would not have to be slower. In real Windows, local interprocess COM and networked COM (DCOM) both does use the same marshalling layer on top of MS's RPC layer (rpcrt4.dll and rpcss.exe). The only difference here is that rpcrt4 uses loadable modules for the various transports it can support. One such module supports the TCP/IP-based RPC that everyone knows DCOM can use - and there's probably another module that only supports local (same-host) messaging, but is optimized for that, by using shared memory where possible. (That is probably what the CLSCTX_LOCAL_SERVER transport use.) It would actually be really nice if someone would implement rpcrt4's marshalling support, i.e. its Ndr* entry points (heavily used by the marshalling proxies and stubs that MS's IDL compiler, midl.exe, creates). Even if someone only implemented standard DCE RPC and whatever marshalling standard DCE RPC supports, it'd still go a long way towards interprocess COM and DCOM support, and help my efforts when I get to the "cleanup" stage (as right now I'm ignoring rpcrt4 and doing really bad hacks to get InstallShield up, and I doubt Alexandre would accept that if not done properly using rpcrt4)