March 2005 - Wine-devel - list.winehq.org

Re: msi:Fix Typelib Registration
by Huw D M Davies 28 Mar '05

28 Mar '05

On Mon, Mar 28, 2005 at 10:39:48AM -0600, Aric Stewart wrote: > make sure the GUID of the typelib we are registering matches the guid > requested from MSI. if not search the given typelib file to find the > typelib requested to register. > > > Index: dlls/msi/action.c > =================================================================== > RCS file: /home/wine/wine/dlls/msi/action.c,v > retrieving revision 1.105 > diff -u -r1.105 action.c > --- dlls/msi/action.c 28 Mar 2005 14:17:52 -0000 1.105 > +++ dlls/msi/action.c 28 Mar 2005 16:33:23 -0000 > @@ -4097,7 +4101,39 @@ > continue; > } > > + guid = load_dynamic_stringW(row,1); > res = LoadTypeLib(package->files[index].TargetPath,&ptLib); > + ITypeLib_GetLibAttr(ptLib, &attr); > + CLSIDFromString(guid, &clsid); > + if (!IsEqualGUID(&clsid,&attr->guid)) > + { > + static const WCHAR fmt[] = {'%','s','\\','%','i',0}; > + int i; > + int sz; > + > + TRACE("Initial match failure\n"); > + > + sz = strlenW(package->files[index].TargetPath)+4; > + sz *= sizeof(WCHAR); > + > + for (i = 2; i < 10; i++) > + { > + path = HeapAlloc(GetProcessHeap(),0,sz); > + sprintfW(path,fmt,package->files[index].TargetPath, i); > + TRACE("trying %s\n", debugstr_w(path)); > + res = LoadTypeLib(path,&ptLib); > + ITypeLib_GetLibAttr(ptLib, &attr); > + CLSIDFromString(guid, &clsid); > + if (IsEqualGUID(&clsid,&attr->guid)) > + break; > + HeapFree(GetProcessHeap(),0,path); > + res = E_FAIL; > + > + } > + } > + else > + path = strdupW(package->files[index].TargetPath); > + > if (SUCCEEDED(res)) > { > LPWSTR help; This doesn't look right. Maybe you need to enumerate through the typelib resources here. What information are you actually given? You're also leaking ITypeLibs and TLIBATTRs Huw.

1 0

Re: [dlls/msi/*] Strncpy elimination.
by Jakob Eriksson 28 Mar '05

28 Mar '05

Good thing you sent these patches. I was just thinking, should I dig in? :-) Peter Berg Larsen wrote: >I have been checking the usage of strncpy, replacing where apropriate with >a memcpy or lstrcpyn[AW]. The first raw diff was 100kb, so there is bound >to be one or two slips. These are the first batch which I found to be >obvious, correct, and didnt need a special comment. Note with correct I >mean if there was a \0 bug before then it still there. > >Changelog: > Janitorial Task: Check the usage of strncpy/strncpyW. > >Index: dlls/msi/action.c >=================================================================== >RCS file: /home/wine/wine/dlls/msi/action.c,v >retrieving revision 1.104 >diff -u -r1.104 action.c >--- dlls/msi/action.c 24 Mar 2005 21:01:38 -0000 1.104 >+++ dlls/msi/action.c 26 Mar 2005 09:40:49 -0000 >@@ -922,7 +922,7 @@ > while (*ptr == ' ') ptr++; > len = ptr2-ptr; > prop = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); >- strncpyW(prop,ptr,len); >+ memcpy(prop,ptr,len*sizeof(WCHAR)); > prop[len]=0; > ptr2++; > >@@ -942,7 +942,7 @@ > len -= 2; > } > val = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); >- strncpyW(val,ptr2,len); >+ memcpy(val,ptr2,len*sizeof(WCHAR)); > val[len] = 0; > > if (strlenW(prop) > 0) >Index: dlls/msi/dialog.c >=================================================================== >RCS file: /home/wine/wine/dlls/msi/dialog.c,v >retrieving revision 1.9 >diff -u -r1.9 dialog.c >--- dlls/msi/dialog.c 24 Mar 2005 15:09:31 -0000 1.9 >+++ dlls/msi/dialog.c 26 Mar 2005 09:40:51 -0000 >@@ -131,7 +131,7 @@ > ret = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); > if( !ret ) > return ret; >- strncpyW( ret, p, len ); >+ memcpy( ret, p, len*sizeof(WCHAR) ); > ret[len-1] = 0; > return ret; > } >Index: dlls/msi/format.c >=================================================================== >RCS file: /home/wine/wine/dlls/msi/format.c,v >retrieving revision 1.8 >diff -u -r1.8 format.c >--- dlls/msi/format.c 16 Mar 2005 11:31:35 -0000 1.8 >+++ dlls/msi/format.c 26 Mar 2005 09:40:51 -0000 >@@ -252,7 +252,7 @@ > *key = HeapAlloc(GetProcessHeap(),0,i*sizeof(WCHAR)); > /* do not have the [] in the key */ > i -= 1; >- strncpyW(*key,&(*mark)[1],i); >+ memcpy(*key,&(*mark)[1],i*sizeof(WCHAR)); > (*key)[i] = 0; > > TRACE("Found Key %s\n",debugstr_w(*key)); > > > >

3 3

Re: [libs/wine/*] Strncpy elimination.
by Alexandre Julliard 28 Mar '05

28 Mar '05

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Janitorial Task: Check the usage of strncpy/strncpyW. You can't use lstrcpynA in the libs/ directory, you have to stick to Unix APIs. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: DDRAW: Surface locking patch, take 2
by Matthew Mastracci 28 Mar '05

28 Mar '05

Matthew Mastracci wrote: > This patch (correctly) fixes the locking problems in SimCity 3000. We > now check to see if the blit src and dest are the same surface and, if > so, we make sure to lock the surface only once and, in the case of > BltFast, re-adjust the surface pointers. This patch also makes sure the > surfaces are correctly unlocked if a bad rectangle is passed. > > ChangeLog > Correctly lock and unlock surface for a single-surface Blt() and > BltFast() call. I'm just pinging the list ot see if there's any reason why this patch hasn't been applied yet. AFAIK, it takes into account all the feedback received so far. Let me know how I can fix it if there is an issue. :) Matt.

2 1

Re: dbghelp: better module support
by Eric Pouech 28 Mar '05

28 Mar '05

Eric Pouech a écrit : > minidumps now contain more accurate information about modules, > especially information that will allow when reloading a minidump in a > debugger to check whether we're using the right modules (ELF & PE) > implemented also check for this information in SymFindFileInPath > A+ Please use this version instead (the previous had an un-wanted statement) A+ -- Eric Pouech

1 0

dbghelp: small fixes
by Eric Pouech 28 Mar '05

28 Mar '05

this patch fixes a couple of bugs in dbghelp A+ -- Eric Pouech

1 0

Re: OLE32, compositemoniker: remove function prototypes, make functions static
by James Hawkins 28 Mar '05

28 Mar '05

On Mon, 28 Mar 2005 14:48:40 +0900, Mike McCormack <mike(a)codeweavers.com> wrote: > > There's more work like this to be done. Anybody want to help out? > > Mike > > ChangeLog: > * remove function prototypes, make functions static Candidate for a janitorial project? :) -- James Hawkins

2 1

Re: Implementation of EnumMoniker and Partial impl on MkParseDisplayName
by Mike McCormack 28 Mar '05

28 Mar '05

Hi Jeff, Jeff Latimer wrote: > This is the first installment of the implementation of > MkParseDisplayName. I would like feed back on style and usage. > > I think the implementation of the EnumMoniker interface looks ok. > Comments appreciated. I like that you've taken the time to write a test case! I don't know alot about monikers, but seeing that you've tested it gives me confidence... The following comments are a crash course in Wine programming... > +/*********************************************************************** > + * EnmumMoniker_Next > + */ > +HRESULT WINAPI EnumMonikerImpl_Next(IEnumMoniker* iface, ULONG celt, IMoniker** rgelt, ULONG * pceltFetched) > +{ > +// DWORD i; > +// ULONG ref; We avoid C++ comments in Wine code to keep compatability with older compilers. > + EnumMonikerImpl *This = (EnumMonikerImpl *)iface; > + TRACE("(%p) currentPos %d Tablastindx %d\n",This, (int)This->currentPos, (int)This->TabLastIndx); > + ULONG i; You declared "i" above, but commented it out. Try avoid putting dead code in comments. If code isn't compiled, it will become stale and confuse people. > + rc = CoGetMalloc(1, (LPMALLOC *) &ppMalloc); > if (!(IsValidInterface((LPUNKNOWN) pbc))) > return E_INVALIDARG; > + usernamelen = (int) lstrlenW(szUserName); // overall string len > + > > + if (szUserName[char_cnt] == (WCHAR) '@') { // This is a progid not a file name That's alot of casts. I don't think you really need that many, do you? > + /* retrieve the requested number of moniker from the current position */ > + for(i=0;((This->currentPos < This->TabLastIndx) && (i < celt));i++) > + rgelt[i]=(IMoniker*)This->TabMoniker[This->currentPos++].pmkObj; Better to avoid tabs... and too many brackets. A space or two extra in the for( i=0; (This->... might make things look better. > + if (szUserName[char_cnt] == '/' || > + szUserName[char_cnt] == '?' || > + szUserName[char_cnt] == '<' || > + szUserName[char_cnt] == '>' || > + szUserName[char_cnt] == '*' || > + szUserName[char_cnt] == '|' || > + szUserName[char_cnt] == ':') Maybe that can be shortened to : if (strchr("/?<>*|:",szUserName[char_cnt])) > + todo_wine { ok(hr==0x800401e4, "MkParseDisplayName - Progid not implemented hr=%08x\n", (int) hr); } 0x800401e4 is defined as MK_E_SYNTAX. It would be clearer to use the define rather than a number. %08lx is probably what you want instead of casting hr to (int) to get rid of the printf parameter type warning. > + > + IBindCtx_Release(pbc); > + > + /* A bad drive */ > + static const WCHAR wszDisplayName2[] = {'1',':','s','i','d',':', > '2','0','D','0','4','F','E','0','-','3','A','E','A','-','1','0','6','9','-','A','2','D','8','-','0','8','0','0','2','B','3','0','3','0','9','D',':',0}; Again, for compatability, we avoid inline declarations, even though gcc can deal with them fine. Mike

1 0

Re: Two small scrollbar fixes
by Alexandre Julliard 28 Mar '05

28 Mar '05

Rein Klazes <wijn(a)wanadoo.nl> writes: > dlls/user : scroll.c > dlls/user/tests : win.c > > - GetScrollRange should return an empty range, both upper and lower > limit zero, if the window has no scrollbars (msdn); > - GetScrollInfo's return value is FALSE if the window has no scrollbars; This breaks the message test: msg.c:2761: Test failed: GetScrollInfo error 5 msg.c:2761: Test failed: GetScrollInfo error 5 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Add a stdole2 typelib
by Huw D M Davies 28 Mar '05

28 Mar '05

On Sun, Mar 27, 2005 at 11:43:34PM -0500, Vincent Béron wrote: > Robert, Huw: Do you have something else to add before this one goes in, > or is Wine ready for it? > > Huw: I had to name the enum at line 181, else I'd get a SIGSEGV in widl. > Would you mind trying to make it accept > > typedef enum { > foo > } BAR; > > instead of > > typedef enum BAR { > foo > } BAR; > > please? Hi Vincent, Sorry I got distracted with other things before I had a chance to finish off the work on stdole2. I'll see if I can knock up something to get these typedefs to work. One remaining issue is the dispinterface FontEvents that is part of coclass StdFont and yet is not defined until right at the end of the typelib. There isn't a clean way to do this in idl and still maintain the original order of the typeinfos - it's clear that the native stdole2 is generated by a program rather than from idl. I guess we could introduce a Wine specific attribute that allows us to hack around this... Huw.

1 0