- Wine-Devel - list.winehq.org

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

> 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 July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

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 July 22, 2004

July 22, 2004

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 July 22, 2004

July 22, 2004

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

daily wine cvs source snapshots?
by Jeroen Janssen July 22, 2004

July 22, 2004

Hello, I was wondering since: 1) wine uses CVS (and not svn with httpwebdav) and 2) CVS doesn't go through the firewall at my work (and possible also not for other people) Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? This makes tracking the latest HEAD possible for people that can't use CVS to access the repository. I know that the CVS repository itself is available, but that sounds a bit overkill to me. best regards, Jeroen Janssen

3 3

Re: devenum
by Marcelo Duarte July 22, 2004

July 22, 2004

Ivan Leo Puoti wrote: > English resources moved to En.rc, language neutral resources moved to Xx.rc, > and italian resources added in It.rc > Licence: LGPL > > Ivan. Ivan, Why you do not leave the neutral resources in the main archive? Greetings, Marcelo

1 0