February 2008 - Wine-Devel - list.winehq.org

Re: More correctly handle the presence of the default ime inputwindow on Ime open and close

by Aric Stewart

Good point, resending. thanks, -aric Dmitry Timoshkov wrote: > "Aric Stewart" <aric(a)codeweavers.com> wrote: > >> diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c >> index 4acbde3..f3ed6f9 100644 >> --- a/dlls/imm32/imm.c >> +++ b/dlls/imm32/imm.c >> @@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM >> notify, LPARAM lParam) >> >> static void ImmInternalSetOpenStatus(BOOL fOpen) >> { >> - TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); >> + TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); > > Wouldn't it be better to change indentation to commonly used 4 spaces > instead of a strange mix of 3 and 4 spaces? >

Feb. 8, 2008

Re: More correctly handle the presence of the default ime inputwindow on Ime open and close

by Dmitry Timoshkov

"Aric Stewart" <aric(a)codeweavers.com> wrote: > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 4acbde3..f3ed6f9 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > > static void ImmInternalSetOpenStatus(BOOL fOpen) > { > - TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); > + TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); Wouldn't it be better to change indentation to commonly used 4 spaces instead of a strange mix of 3 and 4 spaces? -- Dmitry.

Feb. 8, 2008

Re: Fixing make test - progress update

by Jeremy White

> I don't want to spoil your enthusiasm but how does that differ from for example > (old one though) http://test.winehq.org/data/200801301937/#Wine ? The main difference is that I ran it from my Wine tree, and getting it built and ready to go was completely under my control. That is, this is as close to running make test in my tree, but dumping the results to a web site for collation. There is an arguably theoretical difference in that it was built with gcc and my tool chain and is more theoretically identical to a 'make test' run than running a prebuilt winetest.exe. Cheers, Jeremy

Feb. 8, 2008

Re: user32:scroll.c: Compulsory enabling/disabling scrollbars after setting scrollbar`s flags.

by Anatoly Lyutin

Oh, Sorry! It crashes some another scrollbars. :( -- Best regards Anatoly Lyutin.

Feb. 8, 2008

Re: msvcrt: Fix EOF behavior on read from pipe

by Damjan Jovanovic

On Feb 8, 2008 4:31 PM, Dan Kegel <dank(a)kegel.com> wrote: > Nguyễn Thái Ngọc Duy's patch was almost right, he > forgot a test case, and he neglected to move where > EOF is detected for pipes instead of just removing it. > > Should fix http://bugs.winehq.org/show_bug.cgi?id=11187 > > > > The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file) and I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal. Damjan

Feb. 8, 2008

re: [PATCH] msvcrt: Fix early pipe closing

by Dan Kegel

On Sat Feb 2, Nguyễn Thái Ngọc Duy wrote: > Pipes are not like other normal files. If we do not read enough > bytes, it does not mean it reaches EOF > ... fixes broken pipe on git-fetch-pack (MinGW port) This is the same problem as http://bugs.winehq.org/show_bug.cgi?id=11187 so it's my fault. Thanks for the information about git-fetch-pack failing, and for the proposed fix. Before we can commit a fix like yours, we need a test case, so I improved msvcrt/tests/file.c to test EOF on pipes more thoroughly. It shows your patch was almost right. I've fixed up your patch and will send it in. - Dan

Feb. 8, 2008

Re: Fixing make test - progress update

by Reece Dunn

On 08/02/2008, Jeremy White <jwhite(a)codeweavers.com> wrote: > > That data has five test runs and shows clear across > the board failures in msi:install, shell32:shellink, > user32:listbox, and user32:msg. The user32:listbox tests fail everywhere when not run from the dlls/user32/tests directory! I have a patch in wine-patches that is in current git (http://source.winehq.org/git/wine.git/?a=commitdiff;h=01af8501b992896a5fff3…) that fixes those failures. I had a look at the user32:msg failures, but the test results for these on Wine appear to be completely different on different wine versions. I suspect these are down to configuration variations (e.g. X vs. Wine window handling (with focus behaviour) and the like). I haven't had a look at the others yet. - Reece

Feb. 8, 2008

Re: Fixing make test - progress update

by Paul Vriens

Jeremy White wrote: > I believe that we have an easy way > to find out the 'state of the art' wrt to make test. > > That is, my patch + request of a few days ago: > http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html > resulted in a very nice, easy to digest report > http://test.winehq.org/data/20080205/ > Hi Jeremy, I don't want to spoil your enthusiasm but how does that differ from for example (old one though) http://test.winehq.org/data/200801301937/#Wine ? -- Cheers, Paul.

Feb. 8, 2008

Fixing make test - progress update

by Jeremy White

I believe that we have an easy way to find out the 'state of the art' wrt to make test. That is, my patch + request of a few days ago: http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html resulted in a very nice, easy to digest report http://test.winehq.org/data/20080205/ That data has five test runs and shows clear across the board failures in msi:install, shell32:shellink, user32:listbox, and user32:msg. So, we can quickly and easily collate and visually see the make test failures. And, heck, I'm sure that fixing those failures is now a trivial exercise. Now we just need the will. :-/. Not sure how to arrange that, but I think having make test succeed on all systems should be a mandatory requirement for Wine 1.0, so I think we have to work on solving it sooner rather than later. The todo's as I see them are as follows: 1. Revise winetest to not require the 'make dist' step, so that the function of my patch can be implemented more cleanly. 2. Persuade people to run a script on a regular basis so we always have this data. It's trickier than the average bear because the tests require the 'real' console, so you can't just stick it in a headless cron job. Maybe some xauth magic... :-/ 3. (The hard one) Focus in and fix the issues. I'll work on #1 and #2 (although not for a week or two), if everyone else agrees to do #3 <evil grin>. Cheers, Jeremy

Feb. 8, 2008

Re: user32: Implement GetWindowModuleFileName with tests

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: >> + hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); > > After reading MSDN and guessing from the API name shouldn't it > simply fetch GWL_HINSTANCE and call GetModuleFileName on it? And after looking at GetModuleFileNameW implementation, shouldn't it treat hModule == 0 as GetModuleHandle(0) and not be 16-bit specific? Guess this all needs a test case. -- Dmitry.

Feb. 8, 2008