November 2009 - Wine-Devel - list.winehq.org

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Paul Vriens

On 11/24/2009 02:41 PM, Alexandre Hardy wrote: > The MSDN: > http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx > states that GetLongPathNameW returns the length of the string > required to hold the pathname if the buffer is too small to hold > the path. In the case where the buffer is too small, the filename > should not be stored in the buffer. > > This ensures that the buffer is not written to (for UNC pathnames) > if the buffer is not large enought to store the path. > > Kind regards > Alexandre > Hi Alexandre, Patches should go to wine-patches unless your asking for some guidance or comments. This one should also be accompanied with some tests. -- Cheers, Paul.

Nov. 28, 2009

Re: New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > Pie's in the oven, time for another winetricks release. > Could it be possible to "fix" mdac as well? Because of wine now having a more or less stubbed oledb32.dll, apps that need mdac don't run properly anymore. Simple solution is to set oledb32 to native, before the mdac installer is started, (and leave it to native afterwards) Could that be added to winetricks?

Nov. 27, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: > +static INT > +DATETIME_GetText (DATETIME_INFO *infoPtr, INT count, LPWSTR dst) > +{ > + WCHAR buf[80]; > + int i; > + > + if(!count) return 0; > + > + dst[0] = 0; > + for (i = 0; i < infoPtr->nrFields; i++) > + { > + DATETIME_ReturnTxt(infoPtr, i, buf, sizeof(buf)/sizeof(buf[0])); > + if ((strlenW(dst) + strlenW(buf)) <= count) > + strcatW(dst, buf); > + else break; > + } > + return strlenW(dst); > +} > I don't think it's a right way. You probably should use window text instead updating it on every change, see how GetWindowText is implemented. > @@ -674,6 +675,10 @@ static void test_wm_set_get_text(void) > ret = SendMessage(hWnd, WM_GETTEXT, sizeof(buff), (LPARAM)buff); > ok(strcmp(buff, a_str) != 0, "Expected text not to change, got %s\n", buff); > > + GetSystemTime(&stime); > + sprintf(time, "%d.%d.%d", stime.wDay, stime.wMonth, stime.wYear); > + ok(!strcmp(buff, time), "Expected %s, got %s\n", time, buff); > + > DestroyWindow(hWnd); > } > Test is definitely wrong. You can't expect DD.MMMM.YYYY pattern here, it's locale dependent.

Nov. 27, 2009

windows shutdown process

by Vincent Povirk

In order to find the correct fix for bug 18753, I've been examining the shutdown process on Windows. I have written a program that logs the messages sent to it, and I've run it on Windows 7. What I found was that a shutdown produces the following sequence of events: * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION message. We return 1, allowing the session to end. * We get another 0x3b message, which leads to a WM_ENDSESSION. * Nothing else happens, but for some reason the program exits. I added a trace after the message loop returns to see if the program gets a WM_QUIT. It doesn't. Apparently, my test program was killed. I tried changing the window proc so that it loops infinitely when it gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown". (Naturally, it responds the same way if I return 0 from WM_QUERYENDSESSION.) This leads me to believe that Windows 7, when shutting down, immediately kills any process that returns from a WM_ENDSESSION message. Does that seem sane? I've posted my test program (source code and .exe file) at http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if other Windows versions behave the same way Windows 7 does. -- Vincent Povirk

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Austin English

On Fri, Nov 27, 2009 at 8:42 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> All >>> >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. You should check that yourself in git before e-mailing everyone in wine-devel about it... -- -Austin

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Michael Stefaniuc

James, James McKenzie wrote: > Nikolay Sivov wrote: >> James McKenzie wrote: >>> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >>> methods to avoid using window handle directly caused the tooltips popups >>> to stop functioning in e-Sword. >>> >>> Has this been corrected in later Wine releases? I am at wine-1.1.14 >>> with integrating the EM_FORMATRANGE patch. >>> >>> Thank you. >>> >>> James McKenzie >>> >> Did you file a bug report got that? >> >> > Nikolay: > > I don't want to file a bug report if it is already fixed. I'll continue > to work forward and see if the bug still exists. If it does, the report > goes in. wine-1.1.14 is pretty old. There are 109 commits since then that touch riched20; see the output of the below command for the details: git log wine-1.1.14..origin dlls/riched20/ bye michael

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

Nikolay Sivov wrote: > James McKenzie wrote: >> All >> >> Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost >> methods to avoid using window handle directly caused the tooltips popups >> to stop functioning in e-Sword. >> >> Has this been corrected in later Wine releases? I am at wine-1.1.14 >> with integrating the EM_FORMATRANGE patch. >> >> Thank you. >> >> James McKenzie >> > Did you file a bug report got that? > > Nikolay: I don't want to file a bug report if it is already fixed. I'll continue to work forward and see if the bug still exists. If it does, the report goes in. James McKenzie

Nov. 27, 2009

Re: Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by Nikolay Sivov

James McKenzie wrote: > All > > Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost > methods to avoid using window handle directly caused the tooltips popups > to stop functioning in e-Sword. > > Has this been corrected in later Wine releases? I am at wine-1.1.14 > with integrating the EM_FORMATRANGE patch. > > Thank you. > > James McKenzie > Did you file a bug report got that?

Nov. 27, 2009

Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning

by James McKenzie

All Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost methods to avoid using window handle directly caused the tooltips popups to stop functioning in e-Sword. Has this been corrected in later Wine releases? I am at wine-1.1.14 with integrating the EM_FORMATRANGE patch. Thank you. James McKenzie

Nov. 27, 2009

Re: [4/4] ntdll: partially support HEAP_DISABLE_COALESCE_ON_FREE, allows us to detect use-after-free

by Dan Kegel

Don't apply this one yet, just found a problem with it. On Tue, Nov 24, 2009 at 6:20 PM, Dan Kegel <dank(a)kegel.com> wrote: > This adds something like support for > HEAP_DISABLE_COALESCE_ON_FREE. > If the GlobalFlags registry entry has the > 200000 bit set, freed blocks are set > aside for a while rather than immediately > being released for reuse. This allows > us to poison them and check for use-after-free > or double-free errors, and report them as heap corruption. > > If you're running Valgrind, you get an immediate error > and stack trace for any of these heap corruption events, > which was the motivation for the patch series. > But the patches are useful even without valgrind. > > The number of blocks kept out of circulation is > 5000 by default, but can be set via an environment > variable. It ought to have a limit on number of bytes, > too, but this seemed enough for the moment. >

Nov. 27, 2009