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

Re: Add a WINEVER environment variable
by Andreas Mohr July 23, 2004

July 23, 2004

Hi, I'm afraid I don't like the naming, since it's potentially confusing (plus, it somewhat goes against established rules, "WINE + function"). What about WINEWINVER instead? I for one like it much more. Also, this doesn't take into account that we're also able to set the DOS version. So what would that be called then? WINEVER, too? ;-) WINEWINVER and WINEDOSVER is a much better choice, IMHO. Greetings, Andreas

3 4

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Mike Hearn July 23, 2004

July 23, 2004

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

July 23, 2004

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 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