July 2004 - Wine-devel - list.winehq.org

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Mike Hearn 23 Jul '04

23 Jul '04

CCing to wine-devel as the original reply will be forwarded soon too by Jeroen .. On Fri, 2004-07-23 at 17:58 +0200, Jeroen Janssen wrote: > I had a short look at the 'world of com' patch, and it looks like there > is something in there that implements the IRemUnknown stuff. Is there > any easy way to determine if/how this can be 'ported' to the current wine? The "world of dcom" patch used to apply to WineHQ but it may not these days. Mike did a recent merge of it a month or two ago, maybe he has the latest copy? As to actually merging it into CVS, I'm not sure that's a good idea anymore. There's a lot of duplication there and we understand the code Marcus wrote better than Oves. Marcus is still a part of the project, whereas Ove basically isn't anymore. I think some of it is usable, and some of it is not, but merging it isn't a simple "make it apply cleanly and submit" I'm afraid.

2 1

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Robert Shearman 23 Jul '04

23 Jul '04

Jeroen Janssen wrote: > Robert Shearman wrote: > >> Jeroen Janssen wrote: >> >>> Hello, >>> >>> I'm mailing the both of you with a small (com) example attached. >>> >>> It is a client/server/proxystub example (with binaries), so you need to >>> /RegServer the server and regsvr32 the proxy. >>> >>> Now I first manually start the server in a seperate console and then I >>> manually start the client. >>> >>> I modified the client to look for input, so there are basically two >>> paths >>> in the client: >>> >>> * you press: 1 <enter>; the normal path, goes OK >>> hr = >>> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_ICalculate,(void**) >>> >>> &pICalculate); >>> >>> * you press: 2 (or something else) <enter>; the other path, FAILURE >>> hr = >>> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_IUnknown,(void**) >>> >>> &pIUnknown); >>> hr = pIUnknown->QueryInterface(IID_ICalculate, (void **) &pICalculate); >>> >>> Now either there is something wrong with my sample, or there is >>> something >>> wrong in wine that causes this to fail. >>> >>> Can you verify that the client code path is ok (the very few above >>> mentioned lines that differentiate in scenario 1,2). If the client >>> code is >>> ok, then any idea what is actually causing the problem? >> >> >> >> Yes, I can see the problem. What happens with native OLE is that the >> IUnknown part of the object is handled by the proxy manager. What >> this basically means is that it is translated into IRemUnknown >> (remote unknown) calls that will do the appropriate thing. However, >> this is currently not implemented on Wine. >> I'm not sure we (Mike and I) will have time to properly implement >> this, but I could maybe write a quick hack for you sometime over the >> weekend. > > > Ok, thanks for this explanation (that explains why this is not working > yet on wine). > > I had a short look at the 'world of com' patch, and it looks like > there is something in there that implements the IRemUnknown stuff. Is > there any easy way to determine if/how this can be 'ported' to the > current wine? As Mike said, some of it is usable and some of it isn't. Try applying the patch, but YMMV - I ran the patch for a while and it seemed to cause more problems than it solved, particularly in IE. In particular, I don't think the IRemUnknown stuff will be merged as is, because I think the way it is implemented in the patch is not the way it is implemented in Windows (there is only one IRemUnkown interface per apartment) and we only want to write this code once! Rob

1 0

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen 23 Jul '04

23 Jul '04

Forwarding this to the wine-devel mailinglist..... Robert Shearman wrote: > Jeroen Janssen wrote: > >> Hello, >> >> I'm mailing the both of you with a small (com) example attached. >> >> It is a client/server/proxystub example (with binaries), so you need to >> /RegServer the server and regsvr32 the proxy. >> >> Now I first manually start the server in a seperate console and then I >> manually start the client. >> >> I modified the client to look for input, so there are basically two >> paths >> in the client: >> >> * you press: 1 <enter>; the normal path, goes OK >> hr = >> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_ICalculate,(void**) >> >> &pICalculate); >> >> * you press: 2 (or something else) <enter>; the other path, FAILURE >> hr = >> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_IUnknown,(void**) >> >> &pIUnknown); >> hr = pIUnknown->QueryInterface(IID_ICalculate, (void **) &pICalculate); >> >> Now either there is something wrong with my sample, or there is >> something >> wrong in wine that causes this to fail. >> >> Can you verify that the client code path is ok (the very few above >> mentioned lines that differentiate in scenario 1,2). If the client >> code is >> ok, then any idea what is actually causing the problem? > > > Yes, I can see the problem. What happens with native OLE is that the > IUnknown part of the object is handled by the proxy manager. What this > basically means is that it is translated into IRemUnknown (remote > unknown) calls that will do the appropriate thing. However, this is > currently not implemented on Wine. > I'm not sure we (Mike and I) will have time to properly implement > this, but I could maybe write a quick hack for you sometime over the > weekend. Ok, thanks for this explanation (that explains why this is not working yet on wine). Btw, is it ok to forward this information to the mailinglist too? (I didn't want to sent the example attachment to everyone on the mailinglist, but this discussion seems interesting enough to have the "conclusion" posted on the wine development mailinglist. I had a short look at the 'world of com' patch, and it looks like there is something in there that implements the IRemUnknown stuff. Is there any easy way to determine if/how this can be 'ported' to the current wine? --- Jeroen

1 0

Building DLLs and other Qs
by Peter Riocreux 23 Jul '04

23 Jul '04

Before I get onto my questions I would just like to say: This mail is not intended to start a flame war ---------------------------------------------- It is intended in a spirit of understanding what is the current status. First the quick question - I want to install a built-from-CVS wine on multiple Fedora Core 1 machines. I can't find a spec file anywhere to make an RPM with - should I just pinch one from a FC1 Wine package, or is anyone maintaining a set of package-build scripts (RPM, dpkg, etc.)? Now the more complicated and possibly flame-inducing question. While looking round the source tree for a spec file I noticed that all the WINE DLLs seem to end up as .dll.so files. I assume this is because the native platform's gcc can't build a real DLL, so it is wrapped up as a .so and wine (the binary) loads them as such and them does a connect-the-dots exercise to make it look to the application as if it loaded a real DLL. My understanding is that a cross-compiled gcc would build real DLLs, and as wine is able to load them when given them, would there be any advantage to building them with a cross-compiling toolchain if one were available. I am thinking here of perhaps some kind of loading speed improvement (unlikely to be significant if any) or maybe some perverse custom installer that looks for specifically named files in specific places on the filesystem it sees. If there is no advantage, could the converse be true - that there would be some benefit to wrapping native DLLs in a .so shell for speed improvement - perhaps analysing the DLL on load is very hard work and if this were done once and the result saved as a .so ..... Peter

3 2

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen 23 Jul '04

23 Jul '04

> From: Mike Hearn <mike(a)navi.cx> >> Maybe my 'real' problem is that based upon the logging, I also see a >> CFProxy Unhandled interface for the first interface that the client is >> trying to access (but I need to know more about how COM/wine deals with >> this). > > Are you sure you're using COM right? I have also written an outproc > server test and it works OK - at least I've been able to marshal a Hello > World RPC across. Well, it seems to work ok on Windows, so there must be something 'ok' about it. Also, I did not write the application myself. I'm just trying to get it run under wine. I am not sure, but there seems to be a difference in the outproc handling of the CoCreateInstance call? This goes ok: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, IID_IX, (void**)&pIX) ; However this seems to go wrong?: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, __uuidof(IUnknown), (void**)&pIUnknown); hr = pIUnknown->QueryInterface(IID_IX, (void **)&pIX); Summary: If you perform a CoCreateInstance for IUnknown (outproc), you get back the classfactory instead of the proxy to the object itself? Maybe you can check this behaviour? (I don't know exactly if this is indeed what seems to wrong or that I might have made a mistake with the simple test program). > Me and Rob are starting to scrape together a plan, I think, and as part of > working on other apps we're fixing bits as we go, but it's a long long > road we have ahead of us. Any help would certainly be welcome. Well, I'm trying get this application running with wine, I don't know what else I might walk into, but I surely hope to do some contributions to wine in the process. --- Jeroen Janssen

3 2

building COM client/server with proxy using winelib & widl?
by Jeroen Janssen 23 Jul '04

23 Jul '04

Hello, I was wondering whether there is a wine COM client/server application that makes use of winelib & widl (to generate a proxy/stub dll). Apparently I'm missing some #defines in wine's rpcproxy.h in order to be able build the proxy/stub dll? For instance: PROXYFILE_LIST_START PROXYFILE_LIST_END REFERENCE_PROXY_FILE It seems that these defines are present in the rpcproxy.h included with MinGW? I googled for it and found http://www.cs.up.ac.za/courses/EPE210/software/MinGW-1.1/include/rpcproxy.h On a side note can widl generate proxy/stub code yet? --- Jeroen Janssen

2 1

about wine dsound
by Magnus Olsen 23 Jul '04

23 Jul '04

HI My name are Magnus Olsen (call GreatLord at reactos channel) I am one of reactos devlooper I we are now trying get the sound working in reactos. I did start to port over wine dsound and find out it did have it own api layer, to get dsound guid, and other stuff. I did rewrite to thuse part to get it working under windows. Yes wine dsound with some modifaction are now working in windows. we need now do some modifaction to wine winmm get it windows / reactos compatible. the GetDeviceID in Dsound get the value from the windows / reactos system register now. and it works under windows 2k / XP write a api layer betwin dsound api call to WaveInMessage and WaveOutMessage DRV_QUERYDSOUNDGUID 100% support for windows and reactos) DRV_QUERYDSOUNDDESC 80% support for windows and reactos need to figut how to get some data from windows api) DRV_QUERYDSOUNDIFACE 0% force dsound to software emulation mode until I or some else fix it for windows or reactos

1 0

Re: Check Server Version From Client Dlls
by Andreas Mohr 23 Jul '04

23 Jul '04

Hi, On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote: > > Changelog: > Check server version from x11drv, kernel32 and user32 to prevent > mismatches of installed dlls. Slight overkill, I'd say. Why not do: if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ... if (ver != SERVER_PROTOCOL_VERSION) MESSAGE( "Error: server version mismatch.\n" "Your %s binary was not upgraded correctly\n" "or the wrong wineserver is still running.\n", dll_name ); return (ver == SERVER_PROTOCOL_VERSION); Greetings, Andreas Mohr

3 5

Re: PATCH: controls/menu.c case ranges
by Alexandre Julliard 22 Jul '04

22 Jul '04

Marcus Meissner <marcus(a)jet.franken.de> writes: > Another try on fixing the case range problems (WORD is unsigned, > HBMMENU_CALLBACK is -1, so out of range of the switch). I think this is revealing a deeper problem with that code, the magic value check should be done against the whole handle, not just the low word. -- Alexandre Julliard julliard(a)winehq.org

2 1

too many functions in msvcrt20.dll?
by Chipzz 22 Jul '04

22 Jul '04

I was looking at porting a small subset of msvcrt80.dll, and so I took a look at msvcrt20.dll. I first used a disassembler to get a list of the functions in the native windows dll, ran a script over that, and then ran another script over msvcrt20.spec. Much to my surprise, the wine implementation has more(!!) functions than the native dll. So, I was wondering, this screws up the index of these functions in the list, right? Does that index actually matter? The diff between the 2 files is attached. With kr, Chipzz AKA Jan Van Buggenhout -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

2 1