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

Re: FindFirstFile/FindNextFile on SMB shares
by Eric Pouech July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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

VirtualQuery problem... maybe
by Max July 16, 2002

July 16, 2002

After 2 weeks debugging between window$ and wine (sigh), I found a different behaviour of VirtualQuery function : The app queries info about some pages in its code (really dunno why....); in PROTECT field of BASIC_MEMORY_INFO, windows returns a 0x20 value (EXECUTE_READ), but wine returns 0x08 (WRITE_COPY), causing app to hang. I guess there's an error somewhere, as the required info belongs to executable code, so at least should be active some EXECUTE flag; btw, my app checks only that the page has not active NO_ACCESS, WRITECOPY and PAGE_GUARD flags, and behaves badly if find one of them. As a check, I only add an *protect = *protect & 0xffff7fff to GetWin32Prot code, taking so off the WRITECOPY flag only, and the app began starting. As I don't know about anything of linux memory protections (sigh), the question is : is there someone with wnough skllls that want to check it ? :-) Regards Max

1 0

Re: Avoid crash
by P. Christeas July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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 July 16, 2002

July 16, 2002

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

Re: SHBrowseForFolderW
by Uwe Bonnes July 16, 2002

July 16, 2002

>>>>> "Jon" == Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: Jon> ChangeLog: Jon Griffiths <jon_p_griffiths(a)yahoo.com> Jon> +dlls/shell32/shell32.spec,dlls/shell32/brsfolder.c Implement Jon> SHBrowseForFolderW Where's the patch? :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0