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

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by David D. Hagood

Mike Hearn wrote: > Install it all as Win98 if possible, and native DCOM like this: > > WINEDLLOVERRIDES=ole32,oleaut32,rpcrt4=n wine DCOM98.EXE Well, having done so, and having tried setting all the OLE* and RPC* DLLs to native, I am still having the same problem with that app - so I am forced to conjecture that it is not a direct problem with OLE but some other aspect of the program.

Aug. 8, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Dimitrie O. Paun

On Sat, Aug 07, 2004 at 04:00:25PM -0700, Alexandre Julliard wrote: > Mike Hearn <mike(a)navi.cx> writes: > > > The lack of this confused me for a few minutes, might as well stick it in. > > It's missing because it violates namespace rules. The other debugstr > functions are here for historical reasons but we shouldn't add new ones. Please let's not do this inside of Wine. Clearly, we want to export everthing with the WINE_/wine_ prefix, I'm not debating this. I can also see that we want to be consistent, and that's a good thing -- for all but the debugging API our symbol invokations are far and few in between, and it actually *helps* to see when we call a non-standard API. However, the exact opposite holds for the debugging API: it is the most used API in the source, and it doesn't help to know that it's a Wine API. Having the prefix on every single symbol of this API would not only greatly clutter the code, but I'd also claim it's not the style we should promote. People should try to write portable Win32 code (and here portable is between MS Windows and Wine), and a wine_ prefix is a big bad warning sign. One should be able to grep the sources for wine_ to figure out such places. Hiding them inside mountains of debug calls will not help. Usage of the debug API should not tie the code to Wine, and the source should make it clear. We should promote symbol renaming for Winelib apps (just like we do in Wine today): #define ERR WINE_ERR #define TRACE WINE_TRACE ... Apart for much cleaner code, it's also useful, as I can see many people do: #ifdef WINE # define ERR WINE_ERR # define TRACE WINE_TRACE ... #else # define ERR printf # define TRACE printf ... #endif I have a sentimental attachment to the Wine's debugging API, as it was the first project that I undertook in Wine. It was what "hooked" me in. This may be a small issue, and probably I shouldn't care, but I can't help it. I truely think requiring the WINE_/wine_ prefix inside of Wine for commonly used symbols in the debugging API is not a good direction, and I really hope we can revisit this decision. -- Dimi.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Jacek Caban

Dmitry Timoshkov wrote: >"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > > > >>No, I don't. In my case I need only this: >> >> /* this is where we are coming from */ >>+ ITypeLib2_AddRef((ITypeLib*)pLibInfo); >> ptiRet->pTypeLib = pLibInfo; >> ptiRet->index=count; >> >>but I call ITypeLib_Release in ITypeInfo_Release so I thought I should >>increment ref here too. >> >> > >Then use my test program and possibly add some other test for >typelib reference counting until you get it right. Then submit >a tested patch to wine-patches. > > > Thanks for help. I found my bug and I'll send patch soon. Jacek

Aug. 8, 2004

Re: Problem with ITypeInfo

by Dmitry Timoshkov

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > No, I don't. In my case I need only this: > > /* this is where we are coming from */ > + ITypeLib2_AddRef((ITypeLib*)pLibInfo); > ptiRet->pTypeLib = pLibInfo; > ptiRet->index=count; > > but I call ITypeLib_Release in ITypeInfo_Release so I thought I should > increment ref here too. Then use my test program and possibly add some other test for typelib reference counting until you get it right. Then submit a tested patch to wine-patches. -- Dmitry.

Aug. 8, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by Mike Hearn

On Sat, 2004-08-07 at 16:02 -0500, David D. Hagood wrote: > Yes, I am - I was under the impression that would give a better shot at > compatability since, when there is a mutually exclusive choice between > the 9X and the NT way, Wine tends to follow the NT way. No, 9x mode is recommended. Programs tend to stress the system harder when run in NT mode, they use NT only APIs and such we may not implement and don't get as much testing. > > regression there lately if you use 9x DCOM but I think it's fixed now. > > Easy enough to fix if not. > > So you are suggesting that I attempt to re-install the Win98 DCOM > package? Should I change the ole* overrides to "native,builtin", and if > so, should I do so before or after installing the DCOM package? Should I > also change the Winver to 98, and if so, should I do so for all > programs, just the DCOM installer, or for the DCOM install + Mng6? Install it all as Win98 if possible, and native DCOM like this: WINEDLLOVERRIDES=ole32,oleaut32,rpcrt4=n wine DCOM98.EXE thanks -mike

Aug. 8, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Mike Hearn

On Sat, 2004-08-07 at 16:00 -0700, Alexandre Julliard wrote: > It's missing because it violates namespace rules. The other debugstr > functions are here for historical reasons but we shouldn't add new > ones. OK, I suspected that might be the case but inside of Wines code why do we have to prefix things with wine? For Winelib (ie external) source I can understand that, but we already know there are no conflicts inside Wine.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Dmitry Timoshkov

"jack" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -3265,6 +3266,7 @@ > return NULL; > } > *ppTypeInfoImpl = (ITypeInfoImpl*)ITypeInfo_Constructor(); > + pTypeLibImpl->ref++; Are you sure you need this piece of the patch? It causes the following test program to fail: #define COBJMACROS #include <stdarg.h> #include <stdio.h> #include <assert.h> #include "windef.h" #include "winbase.h" #include "oleauto.h" static void load_type_lib(LPCWSTR type_lib) { ITypeLib *iface; TLIBATTR *pTLibAttr; HRESULT hResult; ULONG ref_count; // DWORD dwWritten; printf("Loading: \"%ws\"\n", type_lib); hResult = LoadTypeLib(type_lib, &iface); printf("LoadTypeLib() = %08lx\n", hResult); assert(hResult == S_OK); hResult = ITypeLib2_GetLibAttr(iface, &pTLibAttr); printf("GetLibAttr() = %08lx\n", hResult); assert(hResult == S_OK); // fflush(stdout); // WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), pTLibAttr, sizeof(*pTLibAttr), &dwWritten, NULL); // printf("\n\n"); ITypeLib2_ReleaseTLibAttr(iface, pTLibAttr); ref_count = ITypeLib2_Release(iface); printf("ITypeLib2_Release() = %lu\n", ref_count); assert(ref_count == 0); } int main(void) { // load_type_lib(L"olepro32.dll"); // load_type_lib(L"msvbvm60.dll"); load_type_lib(L"stdole32.tlb"); return 0; } -- Dmitry.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Jacek Caban

Dmitry Timoshkov wrote: >"jack" <jack(a)itma.pwr.wroc.pl> wrote: > > > >>@@ -3265,6 +3266,7 @@ >> return NULL; >> } >> *ppTypeInfoImpl = (ITypeInfoImpl*)ITypeInfo_Constructor(); >>+ pTypeLibImpl->ref++; >> >> > >Are you sure you need this piece of the patch? It causes the following >test program to fail: > > > No, I don't. In my case I need only this: /* this is where we are coming from */ + ITypeLib2_AddRef((ITypeLib*)pLibInfo); ptiRet->pTypeLib = pLibInfo; ptiRet->index=count; but I call ITypeLib_Release in ITypeInfo_Release so I thought I should increment ref here too. Thanks, Jacek

Aug. 8, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > The lack of this confused me for a few minutes, might as well stick it in. It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones. -- Alexandre Julliard julliard(a)winehq.org

Aug. 7, 2004

Re: Take monospace fonts into account in default font selectionalgorithm.

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > On Sat, 2004-08-07 at 23:16 +0900, Dmitry Timoshkov wrote: >> This can't work because instead of logical boolean results you compare >> binary flags which are different: >> >> #define FT_FACE_FLAG_FIXED_WIDTH ( 1L << 2 ) >> >> #define MONO_FONT 0x08 > > You are right. I will watch out for this in future! Here is a fixed > patch. The correct way to compare booleans in C is to invert them, i.e. instead of (a == b) use (!a == !b). You must not rely on booleans being always 0 or 1. -- Alexandre Julliard julliard(a)winehq.org

Aug. 7, 2004