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

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR
by Shachar Shemesh 17 Jul '02

17 Jul '02

+ LPWSTR lpText = (LPWSTR)lParam; + lpText[0] = '\0'; Shouldn't it be + LPWSTR lpText = (LPWSTR)lParam; + lpText[0] = L'\0'; ? Carl Sopchak wrote: >I found this while trying to get Quicken 2000 Deluxe to run under wine. Q2k >was crashing when adding a new security (stock) if nothing was seleted in the >Asset Class ListBox. (It doesn't do this under "real Win NT"...) It turns >out that Q2k seems to keep processing the value returned by WM_GETTEXT >regardless of the number of characters WM_GETTEXT returns. Since wine's >WM_GETTEXT was not returning a NULL string (='\0'), a subsequent strcpy (or >some such) was choking because the string was not null terminated. > >The attached patch sets the return string to '\0' if LB_GETCURSEL returns >LB_ERR. (Although this behaviour is not specified on msdn.microsoft.com, I >figure it can't hurt, since the program calling WM_GETTEXT should be >expecting the buffer to get changed by the call...) I don't know (and have >not checked) to see if other *_GETTEXT message handlers need to do the >same... > >One last point: I'm fairly new at C coding. If there's a better way to do >what this patch does, feel free to improve upon it... <grin> > >Carl > > >------------------------------------------------------------------------ > >Index: controls/combo.c >=================================================================== >RCS file: /home/wine/wine/controls/combo.c,v >retrieving revision 1.85 >diff -u -r1.85 combo.c >--- controls/combo.c 10 Jul 2002 23:11:28 -0000 1.85 >+++ controls/combo.c 15 Jul 2002 17:02:47 -0000 >@@ -1603,6 +1603,15 @@ > return (LRESULT)n; > } > } >+ /* LB_GETCURSEL returned LB_ERR - truncate string, return zero */ >+ if (unicode) >+ { >+ LPWSTR lpText = (LPWSTR)lParam; >+ lpText[0] = '\0'; >+ } else { >+ LPSTR lpText = (LPSTR)lParam; >+ lpText[0] = '\0'; >+ } > return 0; > } > > >

6 14

Re: winapi update
by Dmitry Timoshkov 17 Jul '02

17 Jul '02

"Patrik Stridvall" <ps(a)leissner.se> wrote: > RCS file: /home/wine/wine/objects/font.c,v > retrieving revision 1.76 > diff -u -u -r1.76 font.c > --- wine/objects/font.c 22 Jun 2002 01:19:29 -0000 1.76 > +++ wine/objects/font.c 16 Jul 2002 21:45:23 -0000 > @@ -2262,7 +2262,7 @@ > resultsW.lpOutString = NULL; > ret = GetCharacterPlacementW(hdc, lpStringW, uCountW, nMaxExtent, &resultsW, dwFlags); > - > +v ^^^^ A typo? -- Dmitry.

1 0

Re: FindFirstFile/FindNextFile on SMB shares
by Eric Pouech 16 Jul '02

16 Jul '02

Mike McCormack a écrit : > > Hi, > > This is patch allows FindFirstFile/FindNextFile on public windows > shares. It is (artificially) limited to the first 7 files, since some > protocol features that allow transfering larger directories are lacking > in my implementation. I think the FS implementation gets more and more awful we need to structure it a bit more (like introducing a real FS driver model in Wine, and then implement several drivers DOS, SMB...) comments are welcome A+

3 2

Re: WSAStartup fix
by Eric Pouech 16 Jul '02

16 Jul '02

Rein Klazes a écrit : > > Hi, > > This fixes a case of stack corruption in "the bat!" email program. > > Windows WSAStartup() (tested with win98 and win2K') doesn't fill in or > use the WSADATA's lpVendorInfo field, and apparently this program has > cut the field from the structure accordingly according to MSDN, this should only be done if version >= 2 is requested IMO, your patch should take care of the version requested before filling the different fields A+

2 1

Re: __sparc__ not defined with Forte C
by Gregg Mattinson 16 Jul '02

16 Jul '02

Alright, makes sense. Since I don't know what you mean by "all compilers," I added a configure test and I will make sure __sparc__ is used everywhere. In regards to the second point (@function vs. 2), something has been bugging me for a while... Why do the .spec.c files have so much assembly code in them? To me, it looks like most of it could be replaced with an array and some creative use of global variables. I'm willing to tackle the task of converting the .spec.c files to use as much C as possible, but I can only test it on sparc. Someone else would have to test it on i386 and with native .dlls Gregg >To: Gregg Mattinson <gm138242(a)opcom-mail.canada.sun.com> >Cc: wine-devel(a)winehq.com >Subject: Re: __sparc__ not defined with Forte C >From: Alexandre Julliard <julliard(a)winehq.com> >Date: 15 Jul 2002 18:49:04 -0700 >User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) >MIME-Version: 1.0 > >Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > >> ChangeLog: dlls/ntdll/signal_sparc.c include/basetsd.h >> include/wine/port.h server/context_sparc.c >> - __sparc__ is not defined with Forte C, but __sparc is defined with both Forte >> and GCC. Same goes for __sun__ > >If __sparc and __sun work for all compilers we should use them >everywhere, no need to try to support other forms. Otherwise it should >be done with a configure test like we do for __i386__. > >> - Forte C doesn't like @function. Replaced it with 2. > >This needs a configure test. A #ifdef SUNPRO_C is almost always the >wrong thing to do. > >-- >Alexandre Julliard >julliard(a)winehq.com

2 1

OLE classes registration
by Andriy Palamarchuk 16 Jul '02

16 Jul '02

While researching bug 853 I found out that OleLoadFromStream fails if the specified OLE class is not registered. Many our OLE classes are not registered. Just submitted a patch to register CLSID_StdFont class which fixes the bug. Should I also add the registry etries for all other OLE classes? Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

2 2

Re: Avoid crash
by P. Christeas 16 Jul '02

16 Jul '02

Dominik Strasser wrote: > I had a crash where This->pTypeInfo was 0. > I didn't investigate the real culprit. > > Changelog: avoid crash on NULL pointer I read your patch; I didn't investigate it either. I think you should put the test inside the ITypeInfo_Release() fn. Your patch may solve this case, but what happens when that fn is mis-called from somewhere else? This is a general matter of programming style. Moreover, you could add some TRACE or warning point. There was a conversation on what to do in such cases (where we could handle a NULL, but M$ may not). I suggest: warn and try to go on..

1 0

Re: SHLWAPI ole32 (delay-load of dlls)
by juergen.schmied＠debitel.net 16 Jul '02

16 Jul '02

The LoadLibrary call comes from the implementation of DelayLoad ;-). ------------x8----------- http://www.microsoft.com/MSJ/1298/win32/win321298.htm When the application runs, a call to a delay-loaded function actually calls the __delayLoadHelper function instead. This function references the special table I mentioned previously, and knows to call LoadLibrary followed by GetProcAddress. Once the address of the delay-loaded function is obtained, __delayLoadHelper fixes up calls to this function so that future calls go directly to the delay-loaded function. Note that other functions in the same DLL will still have to be fixed up the first time you call them. Also, you can specify the /DelayLoad linker switch multiple times, once for every DLL that you want to delay-load. ------------x8----------- juergen Jon Griffiths <jon_p_griffiths(a)yahoo.com> schrieb: > Hi, > > The following (shortened) trace from native SHLWAPI v6 shows that > StrRetToBufA is implemented using LoadLibrary/GetProcAddress to call > CoTaskMemFree, even though ole32 is imported by this version. > > 08073b00:CALL xpshlwapi.790: StrRetToBufA(<unknown, check > return>08073b00 > 08073b00:Call kernel32.LoadLibraryA(70bf2c30 "ole32.dll") > ret=70c29f2a > 08073b00:Ret kernel32.LoadLibraryA() retval=40a99000 ret=70c29f2a > 08073b00:Call kernel32.GetProcAddress(40a99000,70c2a412 > "CoTaskMemFree") ret=70c2a027 > 08073b00:Call ole32.CoTaskMemFree(403979e0) ret=70bfa1e2 > 08073b00:Ret ole32.CoTaskMemFree() retval=00000001 ret=70bfa1e2 > 08073b00:RET xpshlwapi.790: > StrRetToBufA(405c6c3c,00000000,405c6d4c,00000100) retval = 00000000 > ret=4001d283 > > If you still want to link directly in this case, ignore the patch > "SHLWAPI ole32" and apply the one below instead. This one just > removes winreg.h from shlwapi_main.c. > > Cheers, > Jon >

2 1

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR
by Carl Sopchak 16 Jul '02

16 Jul '02

On Monday, July 15, 2002 10:15 pm, wine-devel-request(a)winehq.com wrote: > > If VC does have a "one correct way", while gcc doesn't, shouldn't we > > prefer the VC correct one? > > No - you should the one that is in the C standard. > > > In this case '0' should be ok under ALL circumstances. > (Unless M$ have completely stuffed their compiler) > > > David I'd have to agree with David, that the code should work under all circumstances. So, should this be modified, and another patch submitted? I'd be happy to do that, if it makes life easier... (Reiterating: I'm no C guru, and I know less about unicode, so let me know "the best way", and I'll be happy to change it if needed...) Once again, the code in question: if (unicode) { LPWSTR lpText = (LPWSTR)lParam; lpText[0] = '\0'; } else { LPSTR lpText = (LPSTR)lParam; lpText[0] = '\0'; } return 0; Carl

1 0

Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc
by Dimitrie O. Paun 16 Jul '02

16 Jul '02

On June 5, 2002 12:31 am, Guy L. Albertelli wrote: > Ok, the loop was due to constant setting of the buddy wndproc because the > retrieve of the wndproc did not match. The match failed because the > application > program added a wndproc (its own) to the buddy window. The fix will be > submitted to wine-patches. Hmm, I see. But with this fix, it means that you can not change the wndproc of the buddy once set. This can not be right... Also, you broke the UDM_SETBUDDY. I this the correct fix is to add the flag as a property on the buddy, not on the UpDown... -- Dimi.

3 2