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

Re: SHLWAPI ole32 (delay-load of dlls)

by juergen.schmied＠debitel.net

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 >

July 16, 2002

Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc

by Dimitrie O. Paun

On June 5, 2002 08:45 pm, Guy L. Albertelli wrote: > You probably are correct, Dimi. What I did is model the builtin actions on > what the +relay,+message trace of the native showed. The basic problem was > that the GetWindowLong never returned the builtin wndproc address, so we > always did the SetWindowLong again. This disabled the application's own > wndproc and eventually caused the loop. Since the native control never did > the GetWindowLong and did the SetWindowLong only once, that was how I > changed the code. It sounds like you have a much better understanding of > UpDown (and probably some better test cases). Hi Guy, Sorry for my very late reply, but I was away on vacation for over a month now. I've included my version of the fix. Can you please give it a small test run, as I have no test cases for the situation you discovered. TIA, Dimi. Index: dlls/comctl32/updown.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/updown.c,v retrieving revision 1.41 diff -u -r1.41 updown.c --- dlls/comctl32/updown.c 31 May 2002 23:25:44 -0000 1.41 +++ dlls/comctl32/updown.c 16 Jul 2002 12:13:16 -0000 @@ -447,7 +447,7 @@ DWORD dwStyle = GetWindowLongW (infoPtr->Self, GWL_STYLE); RECT budRect; /* new coord for the buddy */ int x, width; /* new x position and width for the up-down */ - WNDPROC baseWndProc, currWndProc; + WNDPROC baseWndProc; CHAR buddyClass[40]; /* Is it a valid bud? */ @@ -477,8 +477,7 @@ /* Note that I don't clear the BUDDY_SUPERCLASS_WNDPROC property when we reset the upDown ctrl buddy to another buddy because it is not good to break the window proc chain. */ - currWndProc = (WNDPROC) GetWindowLongW(bud, GWL_WNDPROC); - if (currWndProc != UPDOWN_Buddy_SubclassProc) { + if (!GetPropA(bud, BUDDY_SUPERCLASS_WNDPROC)) { baseWndProc = (WNDPROC)SetWindowLongW(bud, GWL_WNDPROC, (LPARAM)UPDOWN_Buddy_SubclassProc); SetPropA(bud, BUDDY_SUPERCLASS_WNDPROC, (HANDLE)baseWndProc); } @@ -939,7 +938,7 @@ return temp; default: - if (message >= WM_USER) + if ((message >= WM_USER) && (message < WM_APP)) ERR("unknown msg %04x wp=%04x lp=%08lx\n", message, wParam, lParam); return DefWindowProcW (hwnd, message, wParam, lParam); }

July 16, 2002

Re: __sparc__ not defined with Forte C

by Gregg Mattinson

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

July 16, 2002

Re: SHBrowseForFolderW

by Uwe Bonnes

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

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Dmitry Timoshkov

"Shachar Shemesh" <iglu-web(a)sun.consumer.org.il> wrote: > As far as I can see, the only solution will be to formally seperate wine > from winelib in aims. Wine should support UTF-16, as it handles binaries > that use UTF-16. Winelib should support UTF-32, as that's what the > compilers support. We do nasty workarounds for the wine sources, but do > not require nasty workarounds from the winelib users. Personally I do not consider using explicit unicode strings such as 'f','o',o',0 as nasty workarounds. It's a quite acceptable approach. For the record: until the very recent time Unicode standard had only 65536 defined characters, i.e. UTF16 covered most of the applications requirements. Nowadays it has slightly more, but they are not likely to be used too wide, and there are surrogate pairs for 16-bit unicode. And what's wrong with using Wine internal unicode library and huge number of Win32 APIs dealing with wide (W) characters? As far as I understand it, if Wine would wait till Linux community creates a working unicode implementation we would still had nothing working at hands. Especially taking into account a more wide spreading idea of using UTF8 (i.e. 8-bit unicode) instead of 16 or 32 bit version. It's ugly IMO: and performance is the very first argument. Not to sound offensively, but I don't know (at least) any of the Linux libraries (except glibc) that has (only) unicode APIs, or require usage of 32-bit unicode from client applications, or has a slight idea about code pages. It seems that everyone invents its own wheel, even XFree86 guys invent their own internal unicode support... -- Dmitry.

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Shachar Shemesh

Francois Gouget wrote: >Clumsy but this is the only way. > > >(for Winelib we play tricks with WINE_UNICODE_TEXT but these are not >perfect and must not be used in Wine. That's why they are in an #ifndef >__WINE__ anyway) > > didn't you just spot a serious problem with winelib? As far as I can see, the only solution will be to formally seperate wine from winelib in aims. Wine should support UTF-16, as it handles binaries that use UTF-16. Winelib should support UTF-32, as that's what the compilers support. We do nasty workarounds for the wine sources, but do not require nasty workarounds from the winelib users. Then again, rebutting my own claims, this will break binary compatibility between data files generated with winelib applications and windows applications. Then again, rebutting my own rebuttal, binary compatiblity will not happen without explicit winelib users effort anyways, because of endianity issues. So, after having proven my own claims null and invalid, what are we left with? Shachar

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Francois Gouget

On Tue, 16 Jul 2002, Dmitry Timoshkov wrote: [...] > IMO Wine should not use L prefix at all and explicitly convert ANSI > to unicode when it's needed or use explicit unicode character constants: > static const WCHAR fooW[] = {'f','o','o',0}; > but never L"foo". For character constants, both 'x' and L'x' with work. So it is basically a matter of style/taste. But for Unicode strings, neither "foo" nor L"foo" work: one results in a string with 1 byte character and the other in a string with 4 byte characters the compiler will not perform any conversion. So for Unicode string literals, the only option is as you have shown above: static const WCHAR fooW[] = {'f','o','o',0}; Clumsy but this is the only way. (for Winelib we play tricks with WINE_UNICODE_TEXT but these are not perfect and must not be used in Wine. That's why they are in an #ifndef __WINE__ anyway) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > + LPWSTR lpText = (LPWSTR)lParam; > + lpText[0] = '\0'; > > > Shouldn't it be > > + LPWSTR lpText = (LPWSTR)lParam; > + lpText[0] = L'\0'; > > ? Due to a difference between *nix and win32 unicode character sizes (4 vs. 2 bytes), personally I prefer to avoid such an ambiguity and simply use plain 0 instead. But '\0' will work just fine. IMO Wine should not use L prefix at all and explicitly convert ANSI to unicode when it's needed or use explicit unicode character constants: static const WCHAR fooW[] = {'f','o','o',0}; but never L"foo". -- Dmitry.

July 16, 2002

Re: fix for bug #24

by Andriy Palamarchuk

--- Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello, > > at least the attached patch fixes the problem > described in the summary > of bug #24 (in the description there are some other > problems described > too. That's why i CC wine-devel to let one of the > bugzilla guru's decide > how to proceed with that bug report). First of all, thank you for fixing this very old bug (reported in October 2000)! Taking role of a bugzilla guru :-) With big pleasure closing the bug report. If somebody is interested in this application he should file separate bug reports. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

Re: __sparc__ not defined with Forte C

by Alexandre Julliard

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

July 16, 2002