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

Re: [PATCH 11/11] appelp: Add tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26546 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

July 31, 2013

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)

by Alexandre Julliard

Caibin Chen <tigersoldi(a)gmail.com> writes: > There are at least 3 more interfaces to be implemented, should I put > them in richole.c as well? For now, yes. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2013

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)

by Caibin Chen

There are at least 3 more interfaces to be implemented, should I put them in richole.c as well? 2013/7/31 Alexandre Julliard <julliard(a)winehq.org>: > Caibin Chen <tigersoldi(a)gmail.com> writes: > >> Hi Alexandre, >> >> I think it make sense to have a separate file for ITextDocument. It >> will be used in txtsrv.c and richole.c (See patch 4). If it's WINE's >> convention to not have separate files for separate implementations, I >> can merge the txtrng.[ch] and txtsel.[ch] that introduced in patch 2 >> and 3 into txtdoc.[ch] > > It's already defined and used in richole.c. If at some point it becomes > too large it can be moved to a different file, but introducing a new > file and then removing that stuff from richole.c makes a mess of the > history. > > -- > Alexandre Julliard > julliard(a)winehq.org

July 31, 2013

Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.

by Stefan Dösinger

Am 2013-07-31 16:01, schrieb Christian Costa: > AFAIK no. My localization is french and I get english messages. Any > idea how I can check that? Should be ok then. > The parsing code handles missing null byte as well as both > unix/dos text formats but maybe I can just simplify it by using > strtok_r and assume dos format with null byte. Is there any reason why the format would change? > I'm afraid this is the only solution. AFAIK there is no option > that disable this warning. As far as my reserch goes, D3DCompileShader() is d3dx9's function and d3dcompiler.dll only has D3DCompile(), is that correct? If so, parsing the warnings is probably the least bad option. The obvious alternative is to ignore the mix of builtin d3dx9 and native d3dcompiler - but at some point we may want to write the same warnings from our d3dcompiler and the problem returns. In either case, please write some tests that demonstrate that d3dx9 does not generate those warnings.

July 31, 2013

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)

by Alexandre Julliard

Caibin Chen <tigersoldi(a)gmail.com> writes: > Hi Alexandre, > > I think it make sense to have a separate file for ITextDocument. It > will be used in txtsrv.c and richole.c (See patch 4). If it's WINE's > convention to not have separate files for separate implementations, I > can merge the txtrng.[ch] and txtsel.[ch] that introduced in patch 2 > and 3 into txtdoc.[ch] It's already defined and used in richole.c. If at some point it becomes too large it can be moved to a different file, but introducing a new file and then removing that stuff from richole.c makes a mess of the history. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2013

Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()

by Bruno Jesus

On Wed, Jul 31, 2013 at 10:21 AM, Thomas Faber <thfabba(a)gmx.de> wrote: > On 2013-07-31 02:48, Bruno Jesus wrote: >> + ok(!getsockopt(sock, SOL_SOCKET, SO_TYPE, (char *) &socktype, &size), "getsockopt failed with %d\n", >> + WSAGetLastError()); > > It's not guaranteed that getsockopt is called before WSAGetLastError > here. (in fact the latter will be evaluated first with most practically > used calling conventions) > So this needs a variable. I see, thanks. Unfortunately previous patches already introduced that in 5 other places. If the patch is not commited today I'll change all older issues and send a new version fixing this. If the patch is commited today I'll send another patch fixing the 6 places. > Best, > Thomas Best wishes, Bruno

July 31, 2013

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)

by Caibin Chen

Hi Alexandre, I think it make sense to have a separate file for ITextDocument. It will be used in txtsrv.c and richole.c (See patch 4). If it's WINE's convention to not have separate files for separate implementations, I can merge the txtrng.[ch] and txtsel.[ch] that introduced in patch 2 and 3 into txtdoc.[ch] 2013/7/31 Alexandre Julliard <julliard(a)winehq.org>: > Caibin Chen <tigersoldi(a)gmail.com> writes: > >> Thanks Jacek for reviewing. This time I send all the changes I have in >> 4 patches to make it clear that ReTxtDoc is reused between txtsrv.c >> and richole.c >> - Suppressed Patch 97331 >> - Change log from try 2: >> - follow COM naming convention >> - move ReTxtDoc definition to header, removed >> ReTxtDoc_get_ITextDocument() function >> - remove COM aggregation test for ITextDocument, only test >> ITextService supports querying for the interface. >> >> --- >> dlls/riched20/Makefile.in | 1 + >> dlls/riched20/tests/txtsrv.c | 10 ++ >> dlls/riched20/txtdoc.c | 270 +++++++++++++++++++++++++++++++++++++++++++ >> dlls/riched20/txtdoc.h | 51 ++++++++ >> dlls/riched20/txtsrv.c | 6 + > > Please avoid adding too many source files. In particular, if you have to > add new headers and define objects there, it's a sign that things should > be grouped in the same file. That's even more true for ITextDocument > that already exists. > > -- > Alexandre Julliard > julliard(a)winehq.org

July 31, 2013

Re: d3dx9: Replace M_PI by its D3DX equivalent

by Alexandre Julliard

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > What is the problem with patch: > http://source.winehq.org/patches/data/97500 > > M_PI is never used in D3DX (moreover it is deprecated in C99) It's used all over the place, and we have portability macros for it. There's no reason to avoid it. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2013

Re: kernel32: Fix parameters checking for GetVolumePathName()

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -1813,6 +1821,8 @@ BOOL WINAPI GetVolumePathNameW(LPCWSTR filename, LPWSTR volumepathname, DWORD bu > volumepathname[3] = 0; > return TRUE; > } > + > + SetLastError(ERROR_FILENAME_EXCED_RANGE); > return FALSE; This doesn't really make sense as a general error. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2013

Re: [PATCH 1/4] riched20: Basic ITextDocument implementation for ITextServices (try 3)

by Alexandre Julliard

Caibin Chen <tigersoldi(a)gmail.com> writes: > Thanks Jacek for reviewing. This time I send all the changes I have in > 4 patches to make it clear that ReTxtDoc is reused between txtsrv.c > and richole.c > - Suppressed Patch 97331 > - Change log from try 2: > - follow COM naming convention > - move ReTxtDoc definition to header, removed > ReTxtDoc_get_ITextDocument() function > - remove COM aggregation test for ITextDocument, only test > ITextService supports querying for the interface. > > --- > dlls/riched20/Makefile.in | 1 + > dlls/riched20/tests/txtsrv.c | 10 ++ > dlls/riched20/txtdoc.c | 270 +++++++++++++++++++++++++++++++++++++++++++ > dlls/riched20/txtdoc.h | 51 ++++++++ > dlls/riched20/txtsrv.c | 6 + Please avoid adding too many source files. In particular, if you have to add new headers and define objects there, it's a sign that things should be grouped in the same file. That's even more true for ITextDocument that already exists. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2013

Re: Possibility of adding a new patch status

by Vincent Povirk

> Wouldn't these two points simply earn a 'Rejected' status and/or some kind of comment on the wine-devel list? Applying a "Rejected" status would require looking at the patch. But it could be nice to have a status that means "I will not even read a patch from this person to do this specific thing without substantial changes that are not being made." >> * He thinks there's a good chance you'll revise the patch without his intervention, and is waiting to see if that happens. > > This is good, but only if an error is obvious or more research yields a better means of doing the proposed action. But again, a 'Revision needed' status would help clarify the situation in this case. But maybe revision isn't needed. Determining that would require reviewing the patch. >> * The patch is difficult to review, and he's putting it off. > > There are some statuses (e.g. 'needs splitting) to counteract this. But patches are/can be difficult to review. Again, a status such as 'Not yet reviewed' would help. > >> * He's travelling and does not have access to a machine that can successfully run the Wine test suite, and he thinks the patch might break the >>tests. > A 'Not yet reviewed' status or similar would probably be best. But "Not yet reviewed" is what "New" is supposed to be. The problem is there are situations where patches are never reviewed and no one is told why.

July 31, 2013

Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.

by Christian Costa

Hi Stefan, 2013/7/31 Stefan Dösinger <stefandoesinger(a)gmail.com> > Hi, > > Am 31.07.2013 um 09:10 schrieb Christian Costa <titan.costa(a)gmail.com>: > > + if (!(strstr(line_out, "warning X3206:") && > strstr(line_out, "implicit truncation of vector type"))) > + line_out += line_size; > > msvc localizes compiler errors and warnings. Are you sure d3dcompiler.dll > doesn't do that? > AFAIK no. My localization is french and I get english messages. Any idea how I can check that? > > Wrt the parsing code, wouldn't it be nicer to use strtok_r to split the > buffer into separate lines? > The parsing code handles missing null byte as well as both unix/dos text formats but maybe I can just simplify it by using strtok_r and assume dos format with null byte. > I am not sure that parsing the errors and warnings like that is a good > thing, but I don't know d3dx9 and d3dcompiler well enough to give a final > judgement on that. > > I'm afraid this is the only solution. AFAIK there is no option that disable this warning. Cheers Christian

July 31, 2013

Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()

by Thomas Faber

On 2013-07-31 02:48, Bruno Jesus wrote: > + ok(!getsockopt(sock, SOL_SOCKET, SO_TYPE, (char *) &socktype, &size), "getsockopt failed with %d\n", > + WSAGetLastError()); It's not guaranteed that getsockopt is called before WSAGetLastError here. (in fact the latter will be evaluated first with most practically used calling conventions) So this needs a variable. Best, Thomas

July 31, 2013

Re: po: Add English (Canada) resource [Take 2]

by Ken Sharp

Please disregard this patch. I missed a couple of words and with those corrected en_CA.po becomes identical to en.po (except that "serialisation" is fuzzy) and Wine defaults to that anyway for Canadian English. Will re-submit if there are any changes (just noticed -able/-eable). Will keep an eye on the English translations. On 30/07/13 22:37, Ken Sharp wrote: > - Re-based to latest git > - Removed all the fuzzies thanks to http://www.etymonline.com/index.php > > Turns out all the -ise/-ize words used in Wine are of Latin origin anyway. > > > -------- Original Message -------- > Subject: po: Add English (Canada) resource > Date: Mon, 22 Jul 2013 19:28:51 +0100 > From: Ken Sharp <kennybobs(a)o2.co.uk> > To: wine-patches(a)winehq.org > > Canadian English follows some British/French rules but not others. > > I have left some of the -ise/-ize words fuzzy because: > > "the etymological convention that verbs derived from Greek roots are > spelled with -ize and those from Latin with -ise is preserved in that > practice." > http://en.wikipedia.org/wiki/Canadian_english#Spelling_and_dictionaries > > I tried looking for the origins of the words and I couldn't get any. The > non-fuzzies are correct. > > With British, US and Canadian I believe all the English variations (used > in Wine) are covered, except Philippines (follows US rules). > > >

July 31, 2013

Re: [PATCH] d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader.

by Stefan Dösinger

Hi, Am 31.07.2013 um 09:10 schrieb Christian Costa <titan.costa(a)gmail.com>: > + if (!(strstr(line_out, "warning X3206:") && strstr(line_out, "implicit truncation of vector type"))) > + line_out += line_size; msvc localizes compiler errors and warnings. Are you sure d3dcompiler.dll doesn't do that? Wrt the parsing code, wouldn't it be nicer to use strtok_r to split the buffer into separate lines? I am not sure that parsing the errors and warnings like that is a good thing, but I don't know d3dx9 and d3dcompiler well enough to give a final judgement on that.

July 31, 2013

RE: Possibility of adding a new patch status

by Hugh McMaster

Hi Vincent, You raise some very good points. On Wednesday, 31 July 2013 2:53 AM, Vincent Povirk wrote: >I think I've seen patches stay in the "New" state in the following cases: > * He's convinced you do not have the ability to write a patch he would accept. (There's a common pattern where people will take feedback and >attempt to revise their patch to account for it, but not really understand the feedback or how to apply it. The only way to get an acceptable >patch in this situation would be to do the work for the submitter.) > * He's convinced you're taking a completely wrong approach. (And generally someone has explained this in reply to a previous revision of that >patch.) Wouldn't these two points simply earn a 'Rejected' status and/or some kind of comment on the wine-devel list? > * He thinks there's a good chance you'll revise the patch without his intervention, and is waiting to see if that happens. This is good, but only if an error is obvious or more research yields a better means of doing the proposed action. But again, a 'Revision needed' status would help clarify the situation in this case. > * The patch is difficult to review, and he's putting it off. There are some statuses (e.g. 'needs splitting) to counteract this. But patches are/can be difficult to review. Again, a status such as 'Not yet reviewed' would help. > * He's travelling and does not have access to a machine that can successfully run the Wine test suite, and he thinks the patch might break the >tests. A 'Not yet reviewed' status or similar would probably be best.

July 31, 2013

RE: Possibility of adding a new patch status

by Hugh McMaster

On Tuesday, 30 July 2013 9:04 PM, Ken Sharp wrote: >There's also "Pending". Hi Ken, Yes, I know about the 'Pending' status. The patches page describes this status in two ways: 1. The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. 2. Waiting for feedback from the main developer in that area. Both are quite different. Perhaps these should be split with different labels as well - particularly as the first requires revisions, while the second implies that the patch may be accepted as is. Anyway, to come back to the point, leaving a patch as 'New' is problematic. 'Pending' is more informative, yet perhaps not descriptive enough to cover patches that stay as 'New' over a 24-hour patch cycle.

July 31, 2013

d3dx9: Replace M_PI by its D3DX equivalent

by Nozomi Kodama

Hello What is the problem with patch http://source.winehq.org/patches/data/97500 M_PI is never used in D3DX. Nozomi

July 31, 2013

d3dx9: Replace M_PI by its D3DX equivalent

by Nozomi Kodama

What is the problem with patch: http://source.winehq.org/patches/data/97500 M_PI is never used in D3DX (moreover it is deprecated in C99) Nozomi

July 31, 2013

Re: msxml3: Unescape '&' back to '&' in attribute value

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26523 Your paranoid android. === W2KPROSP4 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPPROSP2 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W2K3R2SESP2 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WVISTAX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W2K8SE (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W7PROX64 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === TEST64_W7SP1 (32 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WXPX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === WVISTAX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === W7PROX64 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) === TEST64_W7SP1 (64 bit saxreader) === saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & ) saxreader.c:2334: Test failed: len 30 (L" attr_value A & & "), expected 29 ( attr_value A & & )

July 31, 2013

Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()

by Austin English

On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > You forgot the patch. -- -Austin

July 31, 2013

Re: kernel32/tests: Improve GetVolumePathNameA tests

by Bruno Jesus

Please ignore this patch, I understand that as is it will not be commited. On Tue, Jul 30, 2013 at 3:30 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Erich Hoover contacted me about a patch he sent months ago related to > GetVolumePathNameA. He developed a better test infrastructure using a > for loop instead of multiple repetitions of test lines. This patch > will make it easier for him to rebase and send his tests and function > implementation later. > > I used the same approach from [1] by decomposing the "todo_wine" in > winetest_start_todo("wine") and winetest_end_todo("wine"). > > http://source.winehq.org/source/programs/cmd/tests/batch.c#L292 -- universe* god::bigbang (void); //and then it all began...

July 30, 2013

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.

by Matteo Bruni

2013/7/30 Rico Schüller <kgbricola(a)web.de>: > Hi Matteo, > > please see the attached patch. > > > On 25.07.2013 16:13, Matteo Bruni wrote: >> >> 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >>> >>> --- >>> dlls/d3dx9_36/tests/shader.c | 308 >>> +++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 308 insertions(+) >>> >> >> This is okay, but as a followup can you add some tests with mixed-type >> structs? Something like: >> >> struct >> { >> float f; >> int i; >> bool b; >> }; >> >> If you have already written tests of this kind, I'd like to know what >> does the compiler do in this case :) >> > Single variables could only have the tested types (I was not able to > generate other conversions than bool->bool, int->int, int->float, > bool->float, float->float). But I found a way to do it with structs and > there I found some issues. Hence this has to be fixed in wine, too. Thanks > for the nice question. :-) > > Basically you got these for the struct: > 1. D3DXRS_FLOAT4: if one variable is used as float or a float variable is > used or an int variable is used as bool (the compiler may do some > optimization), else #2 > 2. D3DXRS_BOOL: if a bool variable is used as bool (in an if clause), else > #3 > 3. D3DXRS_INT4 > > It looks like you could only do it that way with unused variables. I'm not > sure if this makes sense at all. Why would someone set an unused variable? > Maybe I missed something? Do you know anything else? > It does make some sense, although this is not what I expected. Also, I'm getting different results... If I understand correctly your test, all the fields of a structure share the same registerset. Which is silly, since AFAIU each member of the structure has a separate D3DXCONSTANT_DESC in the constant table, both on disk and in memory, there is no point the compiler should force the same registerset for all the struct members. Under the constraint of forcing all the members in the same registerset, the "conversion rules" you mention make sense. In SM3 an if bool can be replaced by an if_comp with a float register and a rep/loop, which is controlled by an integer constant, can be emulated via loop unrolling (although I'm not sure how the compiler can possibly do that for the shader in your testcase). These are also pretty much the only use cases of bool and int constants and there are no int or bool "non-constant" registers so essentially no other type conversion is possible. You can check the plain text output from fxc to see how those constants are used in the shader code and how did the compiler manage to convert those constants from one type to another. I tried to compile your HLSL shader myself (I had to disable optimization though, otherwise compilation fails) and, assuming the text output of fxc matches what actually ends up in the shader bytecode, in general I'm getting different struct members in different registersets. E.g. snbf gets allocated to c6-c9 and b8. FWIW, I used fxc from the June 2010 DirectX SDK, on Windows 7. I'm not sure why my results are different from yours. Or am I misunderstanding the test? BTW, what needs to be fixed in Wine? I couldn't see anything obvious by reading the test. Cheers, Matteo. > Cheers > Rico

July 30, 2013

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.

by Rico Schüller

Hi Matteo, please see the attached patch. On 25.07.2013 16:13, Matteo Bruni wrote: > 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >> --- >> dlls/d3dx9_36/tests/shader.c | 308 >> +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 308 insertions(+) >> > > This is okay, but as a followup can you add some tests with mixed-type > structs? Something like: > > struct > { > float f; > int i; > bool b; > }; > > If you have already written tests of this kind, I'd like to know what > does the compiler do in this case :) > Single variables could only have the tested types (I was not able to generate other conversions than bool->bool, int->int, int->float, bool->float, float->float). But I found a way to do it with structs and there I found some issues. Hence this has to be fixed in wine, too. Thanks for the nice question. :-) Basically you got these for the struct: 1. D3DXRS_FLOAT4: if one variable is used as float or a float variable is used or an int variable is used as bool (the compiler may do some optimization), else #2 2. D3DXRS_BOOL: if a bool variable is used as bool (in an if clause), else #3 3. D3DXRS_INT4 It looks like you could only do it that way with unused variables. I'm not sure if this makes sense at all. Why would someone set an unused variable? Maybe I missed something? Do you know anything else? Cheers Rico

July 30, 2013

Re: Possibility of adding a new patch status

by Vincent Povirk

I think I've seen patches stay in the "New" state in the following cases: * He's convinced you do not have the ability to write a patch he would accept. (There's a common pattern where people will take feedback and attempt to revise their patch to account for it, but not really understand the feedback or how to apply it. The only way to get an acceptable patch in this situation would be to do the work for the submitter.) * He's convinced you're taking a completely wrong approach. (And generally someone has explained this in reply to a previous revision of that patch.) * He thinks there's a good chance you'll revise the patch without his intervention, and is waiting to see if that happens. * The patch is difficult to review, and he's putting it off. * He's travelling and does not have access to a machine that can successfully run the Wine test suite, and he thinks the patch might break the tests. But I'm guessing based on imperfect memory, so I could be wrong.

July 30, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Qian Hong

Forgot to say, as described in the last post, this patch doesn't kill the culprit, please reject the patch, thanks.

July 30, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Qian Hong

Hello Nikolay, On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > This could be some a different bug, and putting exception handler around it > is not necessary a right solution. Good catch, I think you are right. I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after ImmDestroyContext(), the latter frees the input method context if the call successes, but the former try to access the IMC. I have a test case show that in some case native ImmDestroyContext() fails but builtin ImmDestroyContext() success: https://testbot.winehq.org/JobDetails.pl?Key=26499&log_206=1#k206 That is why Office die on Wine but live on Windows, ImmDestroyContext() fails so following ImmLockIMC()/ImmUnLockIMC()/ImmGetIMCCSize() are safe, but on Wine ImmDestroyContext() success and free the memory of the IMC, and... Boom! --- snip --- Call imm32.ImmDestroyContext(08a29b28) ret=3927e447 Ret imm32.ImmDestroyContext() retval=00000001 ret=3927e447 /* success, free the IMC (hIMC == 0x08a29b28) */ Call imm32.ImmLockIMC(08a29b28) ret=09ea2c54 /* would die sooner or later ... */ Ret imm32.ImmLockIMC() retval=08a29b2c ret=09ea2c54 ... Call imm32.ImmGetIMCCSize(00000008) ret=09ea3545 /* 0x00000008 comes from hIMC->IMC.hPrivate, unfortunately hIMC is freed... */ --- snip --- I need more tests to figure out what is the necessary and sufficient conditions to make ImmDestroyContext fails. Thanks for the help! -- Regards, Qian Hong - http://www.winehq.org

July 30, 2013

Call for Windows tests

by Bruno Jesus

Hi, I'm looking for help to test WSAEnumProtocols, I need to collect more information about the values returned from different versions of windows, especially 7 and 8. If you can help please download the file below, unzip, run the .bat and send me back the result.txt file (sources included). http://influenza.blog.br/wsa.zip There is no need to answer to the list. Virustotal.com scan: http://bit.ly/1catW4a Thanks in advance, Bruno

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> You shouldn't check the version, but the actual problem (i.e. the size >> of the offending type). Also please avoid unnecessary changes. > > The offending type is toff_t, it's size is either 32 or 64-bit depending > on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. > So I don't see how checking for the size of toff_t makes it possible to > differentiate between 3.x, 4.x and broken 4.x headers. You can test TIFF_UINT64_T or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > You shouldn't check the version, but the actual problem (i.e. the size > of the offending type). Also please avoid unnecessary changes. The offending type is toff_t, it's size is either 32 or 64-bit depending on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. So I don't see how checking for the size of toff_t makes it possible to differentiate between 3.x, 4.x and broken 4.x headers. -- Dmitry.

July 30, 2013

Re: Possibility of adding a new patch status

by Ken Sharp

There's also "Pending". On 30/07/13 04:16, Hugh McMaster wrote: > Hi everyone, > > Wine patches currently have a status described in http://source.winehq.org/patches, yet for patches with the status of 'New', the status becomes confusing. > > The legend describes 'New' status as "Patch not even looked at yet, there's still hope...". This is ideal for new patches submitted within that 24-hour commit cycle. > > But I'm finding it difficult to follow patches that remain with a status of 'New' for longer than the 24-hour patch cycle. Obviously, on the weekend, patches are held over till Monday, so a longer lead-time is expected. During weekdays, however, it is unclear what is happening with some patches. This, ultimately, raises the question of timeliness. > > Has the patch been looked at? If it has, the status often describes what action was taken - committed, rejected, superseded, etc. This is fine, but some patches remain with a status of 'New'. > > Experience has told me that patches remaining with a status of 'New' are incorrect in some way. But this is not always the case. > > If the patch is incorrect, but close to being accepted, the patch's status should reflect this, by changing to something like "Revision needed". Of course, the "Rejected" status is also appropriate, depending on the severity of coding error. > > Also, there are likely to be many times when the maintainer has not had time to evaluate some patches. This means the patch is not new (i.e. recently submitted), but is awaiting review. Once again, I believe the patch status should reflect this situation. The status could be "Not yet reviewed". > > In summary, the 'New' status should be reserved for patches that are actually new. > > Just some thoughts. > > > >

July 30, 2013

Re: [1/2] msxml3: Implement IMXAttributes_removeAttributes()

by Jacek Caban

Hi Nikolay, On 07/30/13 12:42, Nikolay Sivov wrote: > + dst = &This->attr[index]; > + src = &This->attr[index+1]; > + > + memmove(dst, src, This->length-index-1); *sizeof(*dst) Cheers, Jacek

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined >> >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. >> >> >> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real >> >> version. So for instance libtiff 3.9.7 has it defined to 20120922, >> >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate >> >> between 3.x and 4.x at compile time. >> > >> > I see that this patch is now marked as 'pending'. Are my arguments not >> > clear enough? >> >> You shouldn't check the version, but the actual problem (i.e. the size >> of the offending type). Also please avoid unnecessary changes. > > What changes do you consider as unnecessary? For instance, changing tsize_t when the problem is with toff_t. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013

Re: [2/2] wininet: Handle NULL input string in str_to_buffer.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26482 Your paranoid android. === WXPX64 (64 bit http) === http.c:4661: Test failed: 4832: expected status 100 got 10 http.c:4661: Test failed: 4876: expected status 100 got 40 http.c:4634: Test failed: ar->dwResult = 0, expected 1 http.c:4661: Test failed: 4885: expected status 70 got 100 http: unhandled exception c0000005 at 0000000000495D94

July 30, 2013

Re: [1/2] wininet: Ignore INTERNET_FLAG_NO_CACHE_WRITE only for GET requests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26481 Your paranoid android. === WXPX64 (32 bit http) === http.c:4588: Test failed: 4759: expected status 100 got 10 http.c:4588: Test failed: 4803: expected status 100 got 40 http.c:4561: Test failed: ar->dwResult = 0, expected 1 http.c:4588: Test failed: 4812: expected status 70 got 100 http: unhandled exception c0000005 at 7722EDEA

July 30, 2013

Re: [2/2] iphlpapi: Add partial support for the module classes in GetExtendedTcpTable and GetExtendedUdpTable.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26480 Your paranoid android. === WVISTAX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 7596A09A === W7PROX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 77E03915 === WVISTAX64 (64 bit iphlpapi) === Timeout === W7PROX64 (64 bit iphlpapi) === No test summary line found

July 30, 2013

Re: [1/2] iphlpapi: Add support for the listener and connection classes in GetExtendedTcpTable.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26479 Your paranoid android. === WVISTAX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 7596A09A === WVISTAX64 (64 bit iphlpapi) === Timeout

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined > >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. > >> > >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real > >> version. So for instance libtiff 3.9.7 has it defined to 20120922, > >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate > >> between 3.x and 4.x at compile time. > > > > I see that this patch is now marked as 'pending'. Are my arguments not > > clear enough? > > You shouldn't check the version, but the actual problem (i.e. the size > of the offending type). Also please avoid unnecessary changes. What changes do you consider as unnecessary? -- Dmitry.

July 30, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Jacek Caban

On 07/29/13 17:55, Caibin Chen wrote: >> +struct tagReTxtDoc { >> + IUnknown *outerObj; >> + ME_TextEditor *editor; >> + ITextDocument iTextDocumentIface; >> +}; >> >> Do you really need a separated structure for that? Wouldn't adding ITextDocument implementation to ITextServicesImpl be enough? > This structure will be used in both ITexstServicesImpl and > IRichEditOleImpl(richole.c). For now IRichEditOleImpl has its own > implementation(stub) of ITextDocument and ITextSelection. A stub of > ITextSelection is needed before removing IRichEditOleImpl's own > implementation and use the separate one. > There are already several patches that are ready for review once this > patch get submitted. I see, assuming that substantial part of the implementation may really be shared between those objects, that makes sense. Bellow is review of the remaining part of the patch: +struct tagReTxtDoc { + IUnknown *outerObj; + ME_TextEditor *editor; + ITextDocument iTextDocumentIface; +}; Please follow http://wiki.winehq.org/COMGuideline about naming convention (*_iface names). +ITextDocument *ReTxtDoc_get_ITextDocument(ReTxtDoc *document) +{ + TRACE("(%p)\n", document); + return &document->iTextDocumentIface; +} Full declaration of ReTxtDoc in a header (so you don't need such helper) would be cleaner, IMO. new file mode 100644 index 0000000..02579b2 --- /dev/null +++ b/dlls/riched20/txtdoc.h How about using an existing header? Thanks, Jacek

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. >> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real >> version. So for instance libtiff 3.9.7 has it defined to 20120922, >> 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate >> between 3.x and 4.x at compile time. > > I see that this patch is now marked as 'pending'. Are my arguments not > clear enough? You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013

Re: [PATCH 1/2] ntdll: Implement NtQuerySystemInformation class 0x37

by James Eder

On Mon, Jul 29, 2013 at 5:29 PM, Chris Moeller <kode54(a)gmail.com> wrote: > > You should add a FIXME() for the SystemNumaHighestNodeNumber case since you are not implementing the full behavior. QEMU may be able to emulate NUMA so that may be worth a look (although the man page sucks on the topic). It's been a while since I looked at this stuff but it seems to me you need to have server or pro editions of Windows for it to be supported reasonably. Of course there's no reason for such limitations in Wine (if the hardware is present) but you may need to be aware of such things when running tests on Windows. If I recall there were licensing hoops to jump through if more than one CPU socket was involved. -- Jim

July 30, 2013

Possibility of adding a new patch status

by Hugh McMaster

Hi everyone, Wine patches currently have a status described in http://source.winehq.org/patches, yet for patches with the status of 'New', the status becomes confusing. The legend describes 'New' status as "Patch not even looked at yet, there's still hope...". This is ideal for new patches submitted within that 24-hour commit cycle. But I'm finding it difficult to follow patches that remain with a status of 'New' for longer than the 24-hour patch cycle. Obviously, on the weekend, patches are held over till Monday, so a longer lead-time is expected. During weekdays, however, it is unclear what is happening with some patches. This, ultimately, raises the question of timeliness. Has the patch been looked at? If it has, the status often describes what action was taken - committed, rejected, superseded, etc. This is fine, but some patches remain with a status of 'New'. Experience has told me that patches remaining with a status of 'New' are incorrect in some way. But this is not always the case. If the patch is incorrect, but close to being accepted, the patch's status should reflect this, by changing to something like "Revision needed". Of course, the "Rejected" status is also appropriate, depending on the severity of coding error. Also, there are likely to be many times when the maintainer has not had time to evaluate some patches. This means the patch is not new (i.e. recently submitted), but is awaiting review. Once again, I believe the patch status should reflect this situation. The status could be "Not yet reviewed". In summary, the 'New' status should be reserved for patches that are actually new. Just some thoughts.

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > There's a TIFF_VERSION define that seems to have been renamed to > > TIFF_VERSION_CLASSIC in 4.0. > > > > It doesn't make sense to do the check at runtime, given we're only > > going to link to one of the versions. > > TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined > to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. > > Unfortunately TIFFLIB_VERSION define reflects the date, not the real > version. So for instance libtiff 3.9.7 has it defined to 20120922, > 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate > between 3.x and 4.x at compile time. I see that this patch is now marked as 'pending'. Are my arguments not clear enough? -- Dmitry.

July 30, 2013

GetNumaHighestNodeNumber tests

by Chris Moeller

Here is a basic stand-alone test program, which I should probably learn how to implement into the standard testing array. On my test Windows 7 system with a single processor (4 cores), it outputs the following: Testing NtQuerySystemInformationSystemNumaHighestNodeNumber = 0x37, ...): ... with invalid size returned c0000004 ... with valid size returned 0, HighestNodeNumber = 0, ResultLength = 4 Testing GetNumaHighestNodeNumber: ... returned 1, HighestNodeNumber = 0

July 29, 2013

[PATCH 2/2] kernel32: Implement GetNumaHighestNodeNumber

by Chris Moeller

July 29, 2013

[PATCH 1/2] ntdll: Implement NtQuerySystemInformation class 0x37

by Chris Moeller

July 29, 2013

[PATCH 0/2] Implement basic GetNumaHighestNodeNumber

by Chris Moeller

This patch against HEAD does the following in two parts: Part 1) Implements NtQuerySystemInformation class 0x37, which I have given the name SystemNumaHighestNodeNumber, since that appears to be all it does. It currently is limited to simulating a single node system, and returns the correct error status if queried with too small a return buffer. Part 2) Implements GetNumaHighestNodeNumber based on the above interface, and behaves just like a Windows 7 32-bit kernel32.dll does in case of errors in that function.

July 29, 2013

Re: kernel32: Correct log on / logon (noun / verb)

by Austin English

On Wed, Jul 24, 2013 at 4:37 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > Evening Winos, > > Attached is a patch to correct some winerr messages. Specifically change a > noun to a verb, and update the .po files with it. > > Firstly, could you take a look and point out any obvious errors I may have > made? > > I have marked some of the translations fuzzy because it's not clear if the > original translator realised that this should have been the verb and not the > noun. A quick look through the translations on Wikipedia suggests that most > languages do use different terms for the noun and the verb. > > https://cs.wikipedia.org/wiki/Login > https://de.wikipedia.org/wiki/Login_(Informationstechnik) > https://es.wikipedia.org/wiki/Login > and so on. > > Some of these listings seem to use completely different words to the current > translation in Wine so I wouldn't dare make a guess. For logon/log on, at least from an American viewpoint, your change is correct. > Secondly, what do people think about the use of "Can't" as opposed to > "Cannot"? I have not made the change in the patch but I'm wondering if > people think that this should be done. Can't is informal and as my old > English teacher would say, "Can't is not a word!" It is, but being pedantic > "cannot" is probably the better choice. I assume Windows uses "can't" seen > as it listed in winerror.mc. Can't is definitely informal, but cannot seems a bit too formal for the strings that are currently in en.po, imo. I don't have a strong preference on this, though.

July 29, 2013

Re: [1/1] kernel32: Implemented basic NUMA functions to replace the stubs

by Matteo Bruni

2013/7/30 Chris Moeller <kode54(a)gmail.com>: > > On Jul 29, 2013, at 11:22 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > >> 2013/7/29 Chris Moeller <kode54(a)gmail.com>: >>> without looking very deeply into the CRT source code. >> >> You're talking about MS source code, right? That makes you tainted for >> contributing to Wine at >> the very least for C runtime-related code :( >> If you haven't looked into any other source code, this patch might be >> okay (barring other issues, I haven't read the patch at all). At least >> http://wiki.winehq.org/DeveloperFaq#head-fed5011434f62ae1a88baebfb8193a37ea… >> seems to suggest so. > > I did not look at any CRT source code to determine how to implement the functionality of this patch. I only looked at CRT source code to determine why the CRT was crashing in the first place. The HighestNode function popping a warning in my wine logs should have been hint enough to discover that function was stubbed. > > I actually determined how these functions worked by testing their behavior against a working system, and also with the aid of another developer, who pointed out a handy Win32 function for retrieving a suitable value for the free memory check. That's probably fine, although as a general rule you should stay as far as possible from Microsoft's source code. Cheers, Matteo.

July 29, 2013

Re: [1/1] kernel32: Implemented basic NUMA functions to replace the stubs

by Detlef Riekenberg

Hi Chris. Welcome to Wine. > Main changes from HEAD: > 1) Implements GetNumaHighestNodeNumber which simulates a typical single node system. > 2) Implements GetNumaNodeProcessorMask which returns the global processor affinity mask for node 0, otherwise returns an error. > 3) Implements GetNumaAvailableMemoryNode which returns available physical memory for node 0, otherwise returns an error. The hacks from the codeweavers Wine tree are not in the main tree, because they are hacks. Wine has either a stub or proper implementation with tests. For your changes: - SetLastError(0) is wrong. lasterror is only valid on a failure. (Exceptions are very very rare) - Most implementations in kernel32.dll use functions provides by ntdll.dll With grep, you will find numa support in dlls/ntdll/nt.c - Make the patches as small as possible: Only one implementation per Patch. - Please add tests and run them on Windows. Ask here, if you need help. (Wine has a testbot for approved developer) Thanks for improving Wine. -- By by ... Detlef

July 29, 2013

Re: [PATCH] Ignore MotionNotify when XI2 is handling mouse motion

by Alexandre Julliard

Josef Schimke <sgtcapslock(a)lavabit.com> writes: > Hello, > > When XInput2 takes over the mouse, regular MotionNotify events continue to be > handled alongside it. This causes the cursor to erratically skip around when > the slower method (X11 input) tries to reposition the cursor while XInput2 is > already handling future events. We want to process MotionNotify to resync the cursor position, XInput events are not enough. -- Alexandre Julliard julliard(a)winehq.org

July 29, 2013

Re: [1/1] kernel32: Implemented basic NUMA functions to replace the stubs

by Matteo Bruni

2013/7/29 Chris Moeller <kode54(a)gmail.com>: > without looking very deeply into the CRT source code. You're talking about MS source code, right? That makes you tainted for contributing to Wine at the very least for C runtime-related code :( If you haven't looked into any other source code, this patch might be okay (barring other issues, I haven't read the patch at all). At least http://wiki.winehq.org/DeveloperFaq#head-fed5011434f62ae1a88baebfb8193a37ea… seems to suggest so.

July 29, 2013

Re: How to get involved in Windows Store API implement?

by Stefan Dösinger

Hi, Am 29.07.2013 um 15:33 schrieb 中川祥 <matyapiro31(a)gmail.com>: > I do not know much about the store apps development. > What is Windows.winmd? Do I need disassemble it and create wine version ?If I need C++,I wouldn't do. First of all, don't disassemble Windows DLLs. Wine will not accept your code if you do that. Use black-box tests to find out how APIs work. > Is there any planning to support them? What is your goal? Run applications from the Windows store? I don't know about the legal status of the Windows store. Is it possible from a legal and technical point of view to take an application from the Windows store and run it on a computer that doesn't have the Windows store installed? I'd expect copy protection schemes to prevent you from that, backed up by legal terms that prevent you from taking an app out of the Windows store and run it in a different environment.

July 29, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Caibin Chen

Hi Jacek, Thanks for your review. I really appreciate it :) 2013/7/29 Jacek Caban <jacek(a)codeweavers.com>: > You sent the patch during code freeze, when it couldn't be committed, so > it probably didn't get enough attention. Now is the right time to resubmit. Does that means I should resend the patch to the mail list? > It doesn't really make sense to test COM aggregation on every interface > implemented by an object. The valuable part of the test is that > ITextDocument should be supported, but there is probably a better place > to put this test. Sure I can remove the aggregation tests. > +struct tagReTxtDoc { > + IUnknown *outerObj; > + ME_TextEditor *editor; > + ITextDocument iTextDocumentIface; > +}; > > Do you really need a separated structure for that? Wouldn't adding ITextDocument implementation to ITextServicesImpl be enough? This structure will be used in both ITexstServicesImpl and IRichEditOleImpl(richole.c). For now IRichEditOleImpl has its own implementation(stub) of ITextDocument and ITextSelection. A stub of ITextSelection is needed before removing IRichEditOleImpl's own implementation and use the separate one. There are already several patches that are ready for review once this patch get submitted. Thanks Caibin

July 29, 2013

Re: NtCreateFile fails

by Marcus Meissner

On Mon, Jul 29, 2013 at 04:02:03PM +0200, Mislav Blazevic wrote: > First of all, pardon my ignorance, I am new to wine and winapi. > > I am trying to implement apphelp.dll and I ran into issues with > NtCreateFile: It always returns 0xc0000103, STATUS_NOT_A_DIRECTORY, and I > am not sure what that means. Here is code: > > /* This function is not in API, but written for internal use */ > HANDLE WINAPI SdbOpenFile( LPCWSTR path, PATH_TYPE type ) > { > /* SNIP */ > if (type == DOS_PATH) > if (!RtlDosPathNameToNtPathName_U(path, &str, NULL, NULL)) > return NULL; > InitializeObjectAttributes(&attr, &str, OBJ_CASE_INSENSITIVE, NULL, NULL); > status = NtCreateFile(&file, GENERIC_READ | SYNCHRONIZE | > FILE_READ_ATTRIBUTES, > &attr, &io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, > FILE_OPEN, FILE_DIRECTORY_FILE, NULL, 0); > /* SNIP */ > return file; > } > > Function is called like this: > > WCHAR szFileName[1024] = {0}; > ExpandEnvironmentStringsW(L"%SystemRoot%\\sample.sdb", szFileName, 1024); > // for testing purposes > SdbOpenFile(szFileName, DOS_PATH); > > Compiled with winegcc. > I am sure that C:\windows\sample.sdb exists. What am I doing wrong? Try printing out the expanded string. It will probably just print "C" L"string" does not work to specify WCHAR*, as the Linux L"" strings are differently sized than the Windows L"" strings. Ciao, Marcus

July 29, 2013

Re: NtCreateFile fails

by Nikolay Sivov

On 7/29/2013 18:02, Mislav Blazevic wrote: > First of all, pardon my ignorance, I am new to wine and winapi. > > I am trying to implement apphelp.dll and I ran into issues with > NtCreateFile: It always returns 0xc0000103, STATUS_NOT_A_DIRECTORY, > and I am not sure what that means. Here is code: > > /* This function is not in API, but written for internal use */ > HANDLE WINAPI SdbOpenFile( LPCWSTR path, PATH_TYPE type ) > { > /* SNIP */ > if (type == DOS_PATH) > if (!RtlDosPathNameToNtPathName_U(path, &str, NULL, NULL)) > return NULL; > InitializeObjectAttributes(&attr, &str, OBJ_CASE_INSENSITIVE, NULL, NULL); > status = NtCreateFile(&file, GENERIC_READ | SYNCHRONIZE | > FILE_READ_ATTRIBUTES, > &attr, &io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, > FILE_OPEN, FILE_DIRECTORY_FILE, NULL, 0); > /* SNIP */ > return file; > } > > Function is called like this: > > WCHAR szFileName[1024] = {0}; > ExpandEnvironmentStringsW(L"%SystemRoot%\\sample.sdb", szFileName, > 1024); // for testing purposes > SdbOpenFile(szFileName, DOS_PATH); > > Compiled with winegcc. > I am sure that C:\windows\sample.sdb exists. What am I doing wrong? Probably you don't nee****d FILE_DIRECTORY_FILE if it's not a directory?

July 29, 2013

NtCreateFile fails

by Mislav Blazevic

First of all, pardon my ignorance, I am new to wine and winapi. I am trying to implement apphelp.dll and I ran into issues with NtCreateFile: It always returns 0xc0000103, STATUS_NOT_A_DIRECTORY, and I am not sure what that means. Here is code: /* This function is not in API, but written for internal use */ HANDLE WINAPI SdbOpenFile( LPCWSTR path, PATH_TYPE type ) { /* SNIP */ if (type == DOS_PATH) if (!RtlDosPathNameToNtPathName_U(path, &str, NULL, NULL)) return NULL; InitializeObjectAttributes(&attr, &str, OBJ_CASE_INSENSITIVE, NULL, NULL); status = NtCreateFile(&file, GENERIC_READ | SYNCHRONIZE | FILE_READ_ATTRIBUTES, &attr, &io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_OPEN, FILE_DIRECTORY_FILE, NULL, 0); /* SNIP */ return file; } Function is called like this: WCHAR szFileName[1024] = {0}; ExpandEnvironmentStringsW(L"%SystemRoot%\\sample.sdb", szFileName, 1024); // for testing purposes SdbOpenFile(szFileName, DOS_PATH); Compiled with winegcc. I am sure that C:\windows\sample.sdb exists. What am I doing wrong?

July 29, 2013

How to get involved in Windows Store API implement?

by 中川祥

I do not know much about the store apps development. What is Windows.winmd? Do I need disassemble it and create wine version ?If I need C++,I wouldn't do. Is there any planning to support them?

July 29, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Jacek Caban

Hi Caibin, On 07/29/13 01:52, Caibin Chen wrote: > Hi, > > It has been 2 weeks since I sent this patch[1]. It's still new status > in the patches list. I'm working on following patches based on it. I > appreciate your reviews and will work on the patch to get it > submitted. You sent the patch during code freeze, when it couldn't be committed, so it probably didn't get enough attention. Now is the right time to resubmit. + /* COM aggregation on ITextDocument */ + hr = IUnknown_QueryInterface(unk_obj.inner_unk, &IID_ITextDocument, (void**)&textdoc); + ok(hr == S_OK, "QueryInterface for IID_ITextDocument failed: %08x\n", hr); + refcount = ITextDocument_AddRef(textdoc); + ok(refcount == unk_obj.ref, "CreateTextServices just pretends to support COM aggregation\n"); + refcount = ITextDocument_Release(textdoc); + ok(refcount == unk_obj.ref, "CreateTextServices just pretends to support COM aggregation\n"); + refcount = ITextDocument_Release(textdoc); It doesn't really make sense to test COM aggregation on every interface implemented by an object. The valuable part of the test is that ITextDocument should be supported, but there is probably a better place to put this test. + +struct tagReTxtDoc { + IUnknown *outerObj; + ME_TextEditor *editor; + ITextDocument iTextDocumentIface; +}; Do you really need a separated structure for that? Wouldn't adding ITextDocument implementation to ITextServicesImpl be enough? Thanks, Jacek

July 29, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Caibin Chen

Hi, It has been 2 weeks since I sent this patch[1]. It's still new status in the patches list. I'm working on following patches based on it. I appreciate your reviews and will work on the patch to get it submitted. Regards, Caibin [1] http://source.winehq.org/patches/data/97331 2013/7/18 Caibin Chen <tigersoldi(a)gmail.com>: > Anybody reviewing this patch? It's almost all stubs, so although it's > long, it shouldn't be hard to review > > 2013/7/15 Caibin Chen <tigersoldi(a)gmail.com>: >> (Retry with real name in mail. The name in the patch is already my real name) >> >> This patch implements a standalone stub of ITextDocument. The stub is >> currently used in txtsrv.c and will replace the stub in richole.c >> >> --- >> dlls/riched20/Makefile.in | 1 + >> dlls/riched20/tests/txtsrv.c | 16 ++- >> dlls/riched20/txtdoc.c | 282 +++++++++++++++++++++++++++++++++++++++++++ >> dlls/riched20/txtdoc.h | 46 +++++++ >> dlls/riched20/txtsrv.c | 6 + >> 5 files changed, 350 insertions(+), 1 deletion(-) >> create mode 100644 dlls/riched20/txtdoc.c >> create mode 100644 dlls/riched20/txtdoc.h

July 28, 2013

[1/1] kernel32: Implemented basic NUMA functions to replace the stubs

by Chris Moeller

Main changes from HEAD: 1) Implements GetNumaHighestNodeNumber which simulates a typical single node system. 2) Implements GetNumaNodeProcessorMask which returns the global processor affinity mask for node 0, otherwise returns an error. 3) Implements GetNumaAvailableMemoryNode which returns available physical memory for node 0, otherwise returns an error. This much of the behavior was observed based on a single processor (4 cores) Windows 7 system. These functions are utilized by the synchronization and threading primitives incorporated in the MSVC 2012 and newer C and C++ runtime libraries. concrt.h/Concurrency::critical_section, which is used by both std::mutex and std::thread, will throw an exception the moment the object is locked if GetNumaHighestNodeNumber fails, and there are at least a few examples of software which don't bother to catch this exception and thus crash, such as the alpha version of Cube World, and certain versions of the foo_wave_seekbar component for the foobar2000 audio player. The associated scheduling code appears to make use of GetNumaNodeProcessorMask as well to control how many threads are allowed to spin up at once, or so I guess without looking very deeply into the CRT source code.

July 28, 2013

Re: [PATCH 3/5] d3dx9: Add support for structs to ID3DXConstantTable.

by Rico Schüller

Hi Matteo, On 25.07.2013 16:12, Matteo Bruni wrote: > 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >> --- >> dlls/d3dx9_36/shader.c | 79 >> ++++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 77 insertions(+), 2 deletions(-) >> > > So there was actually a logic (an insane one, but yeah...). Have you > found any game actually using this? No, I haven't found a game which uses this. I also haven't specifically tried a lot of games for this. > > Annoying question: have you checked if it's the same with newer d3dx9 > dlls (e.g. d3dx9_43)? It still looks to me like buggy behavior and it > might be that MS fixed that in later d3dx9 versions. > This is not blocking the patch of course. > Yes, the results are the same with d3dx9_43.dll and with d3dx9_36.dll. Yeah, the behavior looks really buggy, but who knows why it works that way... Cheers Rico

July 28, 2013

Re: Windows 7 64-bit?

by Rosanne DiMesio

On Fri, 26 Jul 2013 22:49:55 +0100 Ken Sharp <kennybobs(a)o2.co.uk> wrote: > > > On 26/07/13 19:42, Rosanne DiMesio wrote: > > But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. > > This is a real pain. Was it intentional or a bug that's slipped in? > > I believe it was taken away after the AppDB was hacked a couple of years ago. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 27, 2013

Re: Windows 7 64-bit?

by Ken Sharp

On 26/07/13 19:42, Rosanne DiMesio wrote: > But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. This is a real pain. Was it intentional or a bug that's slipped in?

July 26, 2013

Re: Windows 7 64-bit?

by Rosanne DiMesio

On Fri, 26 Jul 2013 16:47:36 +0100 Ken Sharp <kennybobs(a)o2.co.uk> wrote: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting… > > No; letting it through was my mistake. This was actually the third time he submitted it. The previous two times I caught it and told him to select a valid distro, but I missed it this time. I realized it after I had approved it and have already deleted the whole entry. The user who keeps submitting it is marketing(a)smartpixel.com, so I doubt this is anything more than a ploy to improve his site's search engine ranking. But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 26, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > There's a TIFF_VERSION define that seems to have been renamed to > TIFF_VERSION_CLASSIC in 4.0. > > It doesn't make sense to do the check at runtime, given we're only > going to link to one of the versions. TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time. -- Dmitry.

July 26, 2013

Re: Windows 7 64-bit?

by André Hentschel

Am 26.07.2013 17:47, schrieb Ken Sharp: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting… > > Ask him what he really wanted to choose.

July 26, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Vincent Povirk

There's a TIFF_VERSION define that seems to have been renamed to TIFF_VERSION_CLASSIC in 4.0. It doesn't make sense to do the check at runtime, given we're only going to link to one of the versions.

July 26, 2013

Windows 7 64-bit?

by Ken Sharp

I have to ask: Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting…

July 26, 2013

Re: gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Alexei Svitkine

Sorry, I wasn't subscribed to wine-patches and the first two mails only went through to wine-devel, but didn't get through to wine-patches. On Fri, Jul 26, 2013 at 2:04 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 7/26/2013 08:48, Alexei Svitkine wrote: > > > > > On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine < > alexei.svitkine(a)gmail.com> wrote: > >> Don't let the gdi32 driver allocate memory in the dplayx region. >> >> Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 >> >> The issue is that the dplayx code in wine needs to allocate some >> memory at a static address (0x50000000) and loading the Mac native gdi >> driver ends up using that part of the address space. >> >> This patch fixes that by reserving that part of memory while the >> display driver is initialized and releasing it after. >> >> --- >> dlls/gdi32/driver.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> > Please stops resending this. Looks like dplay should be fixed to not > depend on that reserved address area. > >

July 26, 2013

Re: gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Nikolay Sivov

On 7/26/2013 08:48, Alexei Svitkine wrote: > > > > On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine > <alexei.svitkine(a)gmail.com <mailto:alexei.svitkine(a)gmail.com>> wrote: > > Don't let the gdi32 driver allocate memory in the dplayx region. > > Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 > > The issue is that the dplayx code in wine needs to allocate some > memory at a static address (0x50000000) and loading the Mac native gdi > driver ends up using that part of the address space. > > This patch fixes that by reserving that part of memory while the > display driver is initialized and releasing it after. > > --- > dlls/gdi32/driver.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > Please stops resending this. Looks like dplay should be fixed to not depend on that reserved address area.

July 26, 2013

Re: gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Alexei Svitkine

On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine <alexei.svitkine(a)gmail.com > wrote: > Don't let the gdi32 driver allocate memory in the dplayx region. > > Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 > > The issue is that the dplayx code in wine needs to allocate some > memory at a static address (0x50000000) and loading the Mac native gdi > driver ends up using that part of the address space. > > This patch fixes that by reserving that part of memory while the > display driver is initialized and releasing it after. > > --- > dlls/gdi32/driver.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) >

July 26, 2013

Re: gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Alexei Svitkine

On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine <alexei.svitkine(a)gmail.com > wrote: > Don't let the gdi32 driver allocate memory in the dplayx region. > > Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 > > The issue is that the dplayx code in wine needs to allocate some > memory at a static address (0x50000000) and loading the Mac native gdi > driver ends up using that part of the address space. > > This patch fixes that by reserving that part of memory while the > display driver is initialized and releasing it after. > > --- > dlls/gdi32/driver.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) >

July 25, 2013

Re: Need help with debugging a directx9 game crashing

by Ken Thomases

On Jul 25, 2013, at 2:11 PM, Qian Hong wrote: > On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases <ken(a)codeweavers.com> wrote: >> I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. >> >> There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. >> >> There may not be any solution other than reporting the issue to the game developer. > > Hmm, thanks a lot for the great analysis :) > I've just sent a message to someone in the game company, not sure if > they care :) I suppose another possibility is that Wine is returning a value to the game which is causing it to take a code path it never takes on Windows and it's only this code path which results in the game reading the uninitialized variable. In that case, there's still a game bug, but we may be able to work around it by changing Wine. It's going to be really hard to figure out, though, without cooperation from the game developers. -Ken

July 25, 2013

Re: Need help with debugging a directx9 game crashing

by Qian Hong

On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. > > There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. > > There may not be any solution other than reporting the issue to the game developer. Hmm, thanks a lot for the great analysis :) I've just sent a message to someone in the game company, not sure if they care :) -- Regards, Qian Hong - http://www.winehq.org

July 25, 2013

Re: Need help with debugging a directx9 game crashing

by Ken Thomases

Hi Qian, On Jul 25, 2013, at 11:53 AM, Qian Hong wrote: > On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases <ken(a)codeweavers.com> wrote: >> Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. > > You are right, thanks! Increasing the size of the array helps, the > minimum working size I found is 588, I've attach the patch and the > backtrace to Bug 34125. > > In my hack, I let: > + char dummy[588]; > + memset(dummy, 0x55, sizeof(dummy)); > + dummy[4] = 0x88; > + dummy[5] = 0x77; > + dummy[6] = 0x66; > + dummy[7] = 0x55; > /* why 584 doesn't work? */ > > And I get a crashing like: > Unhandled exception: page fault on read access to 0x55667788 in 32-bit code I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. There may not be any solution other than reporting the issue to the game developer. -Ken

July 25, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.

by Austin English

I had filed a bug with Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=459820 On Jul 25, 2013 5:31 PM, "Vincent Povirk" <madewokherd(a)gmail.com> wrote: > I have no opinion on this sort of work-around (it should work afaict, > and I haven't found any other places where we currently use toff_t), > but did you file a bug with whatever distro has such broken headers? > > >

July 25, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I have no opinion on this sort of work-around (it should work afaict, > and I haven't found any other places where we currently use toff_t), > but did you file a bug with whatever distro has such broken headers? As far as I can see it's not a distro problem, it's a libtiff bug. > Actually, this will be a problem on libtiff 3.x, where toff_t really > is supposed to be 32-bit. Yes, it will be broken for libtiff3, I haven't looked yet how to detect a libtiff version at compile and run time, if you know how to do that please let me know. -- Dmitry.

July 25, 2013

Re: Need help with debugging a directx9 game crashing

by Qian Hong

Hi Ken, On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. You are right, thanks! Increasing the size of the array helps, the minimum working size I found is 588, I've attach the patch and the backtrace to Bug 34125. In my hack, I let: + char dummy[588]; + memset(dummy, 0x55, sizeof(dummy)); + dummy[4] = 0x88; + dummy[5] = 0x77; + dummy[6] = 0x66; + dummy[7] = 0x55; /* why 584 doesn't work? */ And I get a crashing like: Unhandled exception: page fault on read access to 0x55667788 in 32-bit code I've also hack wined3d/directx.c in a similar way, the minimum size is 592: + char dummy[592]; + memset(dummy, 0xee, sizeof(dummy)); + dummy[8] = 0xdd; + dummy[9] = 0xcc; + dummy[10] = 0xbb; + dummy[11] = 0xaa; /* why 584 and 588 doesn't work ? */ The crashing is like: Unhandled exception: page fault on read access to 0xaabbccdd in 32-bit code When combining the d3d9 hack and the wined3d hack, the behavior is the same to d3d9 hack only. I'll see how far I can get from here, also I'm open to any suggestion and appreciate to any help! Thanks again. -- Regards, Qian Hong - http://www.winehq.org

July 25, 2013

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 3)

by Ken Thomases

On Jul 25, 2013, at 10:49 AM, Charles Davis wrote: > Try 3: Don't advertise WGL_EXT_swap_control if vsync is disabled. Looks good. Thanks, Ken

July 25, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.

by Vincent Povirk

Actually, this will be a problem on libtiff 3.x, where toff_t really is supposed to be 32-bit.

July 25, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.

by Vincent Povirk

I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers?

July 25, 2013

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)

by Ken Thomases

On Jul 25, 2013, at 9:57 AM, Ken Thomases wrote: > If vsync is disallowed, the corresponding functions are left as NULL in the OpenGL function table, so clients may crash if WGL_EXT_swap_control is advertised. Well, this part is wrong. They won't crash because opengl32 protects against that, but still we shouldn't advertise it if support for it is disabled. -Ken

July 25, 2013

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)

by Ken Thomases

On Jul 24, 2013, at 9:41 PM, Ken Thomases wrote: > On Jul 24, 2013, at 9:34 PM, Charles Davis wrote: > >> Try 2: Don't duplicate a constant string; we might need to add more legacy >> extensions. (Hopefully not. ;) > > Thanks for making that change. Looks good to me. Actually, on further thought I realize that we shouldn't be advertising WGL_EXT_swap_control unconditionally. It should be controlled by the AllowVerticalSync registry setting / allow_vsync variable. See load_extensions(). If vsync is disallowed, the corresponding functions are left as NULL in the OpenGL function table, so clients may crash if WGL_EXT_swap_control is advertised. Regards, Ken

July 25, 2013

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.

by Matteo Bruni

2013/7/24 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/tests/shader.c | 308 > +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 308 insertions(+) > This is okay, but as a followup can you add some tests with mixed-type structs? Something like: struct { float f; int i; bool b; }; If you have already written tests of this kind, I'd like to know what does the compiler do in this case :)

July 25, 2013

Re: [PATCH 3/5] d3dx9: Add support for structs to ID3DXConstantTable.

by Matteo Bruni

2013/7/24 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/shader.c | 79 > ++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 77 insertions(+), 2 deletions(-) > So there was actually a logic (an insane one, but yeah...). Have you found any game actually using this? Annoying question: have you checked if it's the same with newer d3dx9 dlls (e.g. d3dx9_43)? It still looks to me like buggy behavior and it might be that MS fixed that in later d3dx9 versions. This is not blocking the patch of course.

July 25, 2013

Re: [PATCH 1/6] scrrun: Store reference count inside IFileSystem3 object

by Piotr Caban

On 07/25/13 14:36, Nikolay Sivov wrote: > On 7/25/2013 16:35, Piotr Caban wrote: >> --- >> dlls/scrrun/filesystem.c | 163 >> +++++++++++++++++++++++++++++++++++------------ >> 1 file changed, 123 insertions(+), 40 deletions(-) > Why do you need this? My bad, I was planning to store some kind of seed inside the object. I'll send a fixed version of these patch series (second patch is also broken). Thanks, Piotr

July 25, 2013

Re: [PATCH 1/6] scrrun: Store reference count inside IFileSystem3 object

by Nikolay Sivov

On 7/25/2013 16:35, Piotr Caban wrote: > --- > dlls/scrrun/filesystem.c | 163 > +++++++++++++++++++++++++++++++++++------------ > 1 file changed, 123 insertions(+), 40 deletions(-) Why do you need this?

July 25, 2013

Re: What to do when an application misuses an API ...

by Michael Casadevall

On Wed, Jul 24, 2013 at 1:22 AM, Damjan Jovanovic <damjan.jov(a)gmail.com <mailto:damjan.jov(a)gmail.com>> wrote: On Wed, Jul 24, 2013 at 4:17 AM, Michael Casadevall <mcasadevall(a)ubuntu.com <mailto:mcasadevall(a)ubuntu.com>> wrote: > Hey all, > I've been working on trying to get Sid Meier's Civilization V (Civ5) up to a > point where it works relatively flawlessly on WINE. The largest issue is > that installing the latest expansion pack has completely hosed the game > under WINE unless some rather ugly workarounds have been taken. > Specifically, the main issue is that Civ5 loads its data files in the order > returned by Find{First,Next}File(), and breaks spectacularly if that order > is disrupted. I documented my findings here: > http://bugs.winehq.org/show_bug.cgi?id=34122 > > As I sat to look at a possible patch, I'm not sure what I can actually do. > Its clearly stated on the MSDN page that the order returned is dependent on > the underlying filesystem, and Googling suggests that while NTFS seems to > always return in a roughly alphabetical order, FAT32 will return by creation > date, and with network drives all bets are off. I was even able to reproduce > similar bugs in Civ5 by launching it from a network drive (which I had > already tested in advance to make sure it returned an odd file order). > FindFirstFile essentially calls down to NtQueryDirectoryFile, which in turn > either calls a system specific syscall or readdir to get a list of files in > a directory. > > My first thought is to extend the underlying read_directory_* functions in > ntdll/directory.c so that they return an alphabetized list (essentially > taking the results from getdents/getdirentries/readdir, sort them, then > returning in the sort order whichever entry is next in line). This would > produce a behavior similar (but not identical) to what is seen when > operating under an NTFS filesystem. > > This approach seems wrong to me, and is further compounded by the fact this > is a bug in an application, and not in WINE specifically; Under the correct > circumstances, Windows will return a "non-sorted" list of files and in those > cases Civilization V breaks. The flipside is that in the most common case, > it works correctly, and furthermore, given how easy it is to assume that > Find*File does return a sorted list, I won't be surprised if this issue has > cropped up elsewhere (figuring out the underlying cause was exceedingly > annoying). Any insight in to what the most correct course of action would be > most appreciated > > I'm perfectly willing to put the legwork in fixing this bug, but I want to > make sure I'm fixing it in a way that will be accepted :-). > > Regards, > Michael > The other possibility to consider is a special FUSE-based filesystem that orders filenames just like Windows does. This filesystem could cache names and perform much better than reading all the directory contents on each FindFirstFile, just like the http://www.brain-dump.org/projects/ciopfs/ provides a performance benefit for case-insensitive filename matching. Regards Damjan (warning, long reply with ASCII art) First, thanks you all for your replies. After these emails, and a long discussion in #winehackers, I grabbed ciopfs's source, thumbed through FUSE's documentation, and tweaked it to return files in the order, and then ensuring that ciopfs passed its test suite and was more or less stable. This was then followed by making a new prefix, installing Steam, and attempting to install Civilization V over it, just to be stied by the fact that ciopfs introduces subtle bugs to running applications. As a test, I built and ran coreutils in a normal ciopfs overlayed directory, and found it failed a large chunk of its test suite (the same exact code worked properly when copied into a normal directory). Furthermore, after sitting down and playing with FUSE for awhile, I'm convinced that its absolutely the wrong way to handle this sort of problem. By definition, anything running through FUSE is going to have a massive performance penalty due to the additional calls from kernelspace-userpsace. For instance, from a syscall perspective, here's what a normal FindFirstFile() looks like +----------------+ | FindFirstFile()| +-------^--------+ | +----------v-----------+ |NtQueryDirectoryFile()| +----------^-----------+ | | |<------------------+Crossing into kernelspace | +--------v-----+ |getdirents64()| +--------^-----+ | +--------v-------+ |Kernel VFS Layer| +--------^-------+ | +-----v-----+ |ext4 driver| +-----------+ (in case this gets screwed up by your mail client: http://paste.ubuntu.com/5909570/) Meanwhile, here's what a simplified call with a FUSE filesystem looks like: +----------------+ | FindFirstFile()| +-------^--------+ | +----------v-----------+ +--------------+ |NtQueryDirectoryFile()| | ciopfs | +----------^-----------+ +--------------+ | ^ ^ | | | |<---Crossing-into-kernelspace+---------+------>| | | | +--------v-----+ | | |getdirents64()| | | +--------+-----+ | | | | | +--------v-------+ | +-v-+ |Kernel VFS Layer| | |VFS| +--------^-------+ | +-^-+ | | | | | +--v-+ +-----v-----+ | |ext4| |FUSE Module|<--------------------------------+ +----+ +-----------+ (http://paste.ubuntu.com/5909572/) Any sort of FUSE module that acts as an overlay for an existing filesystem is looking at a minimum of six roundtrips across kernel/userspace boundaries vs. just the two of a normal filesystem call. Furthermore, from a user perspective, this makes life difficult, as they either must setup FUSE environment, place their prefix on it, make sure FUSE is running when trying to launch a WINE app, etc. Alternatively, WINE would need to grow code to handle this, and now another large chunk of code where things can (and likely will) go wrong, with no obvious answer on why. The more I look at it, the more I see the path to madness. While I don't doubt its possible to ciopfs (or some other FUSE filesystem) to work 100%, the performance penalties are extremely high. The flipside of the coin is I can also see the problem on why hitting Find*Files() with a patch to reorder things is undesirable. So, I decided to step back and look at this problem from a new perspective. I think we're mostly agreed here that the app here is just getting lucky, and is in this case fundamentally broken. I was thumbing through my copy of "The New Old Thing" (an excellent read), and thinking what would be done In the Windows world, assuming that some years down the line, Windows changed something under the hood that broke app compatibility. In the WIndows world, there are three things that can generally be done when app compatilbity is broken: change the core, write a shim, or patch the application. As it exists in WINE today, we can only change our DLLs; patching applications on the fly is a legal quagmire and is fragile. Thus when this ugly case of when an application is broken, we have no good way to correct it. Thus I propose extending WINE During last nights discussion, some work has been done on implementing apphelp.dll which contains the shim database functionality. Said author had no intend on implementing actual shimming in WINE, but as time goes on, I suspect there will be more and more cases where shims would be a more appropriate fix than fixing WINE's core libraries. While I do have an interest in further exploring the possibilities of implementing shimming in WINE, it will likely be a few weeks before I could dedicate the proper time to do so. As such, in the near future, I'll cook up a patch with what I learned hacking on FUSE to reorder the Find*File() results, and post it to the bug, with the hope that it will become the basis of a shim in the near future. Michael (and as an aside, I will see if I can reproduce the bug on a FAT32 install of Windows XP and if so, see if I can get the game developer to fix it)

July 25, 2013

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)

by Ken Thomases

On Jul 24, 2013, at 9:34 PM, Charles Davis wrote: > Try 2: Don't duplicate a constant string; we might need to add more legacy > extensions. (Hopefully not. ;) Thanks for making that change. Looks good to me. Cheers, Ken

July 25, 2013

kernel32: Correct log on / logon (noun / verb)

by Ken Sharp

Evening Winos, Attached is a patch to correct some winerr messages. Specifically change a noun to a verb, and update the .po files with it. Firstly, could you take a look and point out any obvious errors I may have made? I have marked some of the translations fuzzy because it's not clear if the original translator realised that this should have been the verb and not the noun. A quick look through the translations on Wikipedia suggests that most languages do use different terms for the noun and the verb. https://cs.wikipedia.org/wiki/Login https://de.wikipedia.org/wiki/Login_(Informationstechnik) https://es.wikipedia.org/wiki/Login and so on. Some of these listings seem to use completely different words to the current translation in Wine so I wouldn't dare make a guess. Secondly, what do people think about the use of "Can't" as opposed to "Cannot"? I have not made the change in the patch but I'm wondering if people think that this should be done. Can't is informal and as my old English teacher would say, "Can't is not a word!" It is, but being pedantic "cannot" is probably the better choice. I assume Windows uses "can't" seen as it listed in winerror.mc. Thanks all! Ken

July 24, 2013

Re: [PATCH] winemac.drv: Also return the number of pixel formats if the caller didn't supply a PIXELFORMATDESCRIPTOR.

by Ken Thomases

On Jul 23, 2013, at 10:26 PM, Charles Davis wrote: > This is akin to what glxdrv already does, and apparently what Windows > does. It allows the GLView sample from the OpenGL SuperBible to > correctly enumerate pixel formats with the Mac driver. > --- > dlls/winemac.drv/opengl.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/winemac.drv/opengl.c b/dlls/winemac.drv/opengl.c > index 0922371..fb294d1 100644 > --- a/dlls/winemac.drv/opengl.c > +++ b/dlls/winemac.drv/opengl.c > @@ -3281,7 +3281,7 @@ int macdrv_wglDescribePixelFormat(HDC hdc, int fmt, UINT size, PIXELFORMATDESCRI > > TRACE("hdc %p fmt %d size %u descr %p\n", hdc, fmt, size, descr); > > - if (fmt <= 0 || fmt > ret) return ret; > + if (fmt <= 0 || fmt > ret || !descr) return ret; > if (size < sizeof(*descr)) return 0; > > pf = &pixel_formats[fmt - 1]; > -- > 1.7.5.4 Looks good to me. Thanks! -Ken

July 24, 2013

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string.

by Ken Thomases

Hi, On Jul 23, 2013, at 10:26 PM, Charles Davis wrote: > @@ -1226,8 +1227,10 @@ static BOOL init_gl_info(void) > gl_info.glVersion = HeapAlloc(GetProcessHeap(), 0, strlen(str) + 1); > strcpy(gl_info.glVersion, str); > str = (const char*)opengl_funcs.gl.p_glGetString(GL_EXTENSIONS); > - gl_info.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str) + 1); > + gl_info.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str) + > + sizeof(" WGL_EXT_extensions_string WGL_EXT_swap_control")); > strcpy(gl_info.glExtensions, str); > + strcat(gl_info.glExtensions, " WGL_EXT_extensions_string WGL_EXT_swap_control"); As a minor nitpick, I would prefer to avoid that duplicated string literal. Otherwise, looks good to me. Cheers, Ken

July 24, 2013

Re: Need help with debugging a directx9 game crashing

by Ken Thomases

On Jul 24, 2013, at 12:49 PM, Qian Hong wrote: > Hi Ken, > > On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> Instead of enabling the trace, try replacing it with something like: >> >> char dummy[256]; >> memset(dummy, 0x55, sizeof(dummy)); >> >> I bet the crash will change from a read access to 0x00000001 to 0x55555555. >> > > Thanks for the advice, it sounds cool and I learned new things, thank you. > However, it doesn't help in this case, I didn't found any change after > the dummy hack. Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. -Ken

July 24, 2013

Re: [PATCH 4/5] scrrun: Add IFileSystem3::GetTempName implementation

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -174,6 +174,7 @@ BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID reserved ) > case DLL_PROCESS_ATTACH: > DisableThreadLibraryCalls( hinst ); > scrrun_instance = hinst; > + srand(GetTickCount()); You don't want to do that. -- Alexandre Julliard julliard(a)winehq.org

July 24, 2013

Re: Need help with debugging a directx9 game crashing

by Qian Hong

Hi Ken, On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Instead of enabling the trace, try replacing it with something like: > > char dummy[256]; > memset(dummy, 0x55, sizeof(dummy)); > > I bet the crash will change from a read access to 0x00000001 to 0x55555555. > Thanks for the advice, it sounds cool and I learned new things, thank you. However, it doesn't help in this case, I didn't found any change after the dummy hack. > The question is: is it a bug in the game or a bug in Wine where Wine is returning a garbage pointer to the game and the game is innocently dereferencing it? For that, you'd have to trace the execution from the call to d3d9_AddRef() to the crashing point to see what else is called and whether it uses an uninitialized value. > > Of course, another approach would be to run under Valgrind, if you can get it to work. I've run it under Valgrind, there are many outputs, I'm not sure which part of valgrind output is important and which part could be ignore, the output is attached to bug 34125 as well. Quite a lot of output are related to native msvcr80 installed by the app, I tried force using buitlin msvcr80, unfortunately the game doesn't start at all with buitlin msvcr80. I've send one test case (Patch 97446), but there is still other msvcrt bugs after that issue. By the way, the game ship with many native d3dx9_??, and with buitin d3dx9_?? it doesn't start as well. -- Regards, Qian Hong - http://www.winehq.org

July 24, 2013

Re: Need help with debugging a directx9 game crashing

by Qian Hong

On Sat, Jul 20, 2013 at 2:21 AM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Or timing ... Also can you print out refcount there to see if the refcounting is good? Thanks Marcus, yes, I tried replace the TRACE to printf, to my surprise, the magic disappear. In other words, if I replace the TRACE in d3d9_AddRef to FIXME, the crashing would be worked around. However, replacing the TRACE to printf doesn't help. I'm not sure why. by replacing TRACE to printf, I can reproduce the crashing while have a look at the refcounting, it seems good to me. -- Regards, Qian Hong - http://www.winehq.org

July 24, 2013

Re: Need help with debugging a directx9 game crashing

by Qian Hong

Hello, Thanks everyone's help, sorry for delay, I was blocked by something else. I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track down this bug. On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Well, it sounds a bit like some form of memory corruption. Sometimes > WINEDEBUG=warn+heap helps with tracking those down. Thanks Henri, warn+heap doesn't show warning, I've attached to Bug 34125, it shows some HeapSetInformation calls, I don't know if it harms. > Also, I don't suppose the d3d9 object was already destroyed earlier? By reading +d3d9 log, I believe the d3d9 object was not destroyed earlier. -- Regards, Qian Hong - http://www.winehq.org

July 24, 2013

Re: po: Update English (US) resource

by Ken Sharp

Fair enough. I'll send an updated patch after the next bunch of commits. Please disregard this patch. On 24/07/13 16:12, Francois Gouget wrote: > On Mon, 22 Jul 2013, Ken Sharp wrote: > >> Logon/Log on as with the British/neutral patch. >> >> msgid "Can't logon with inter-domain trust account.\n" >> -msgstr "Can't logon with inter-domain trust account.\n" >> +msgstr "Can't log on with inter-domain trust account.\n" > [...] > > I think these fixes should really be applied to the source winerror.mc > file instead. If I remember correctly en_US.po is just a dummy > translation where msgid and msgstr strings should be identical (there > might (with maybe one or two exceptions for things like um -> µm). >

July 24, 2013

Re: po: Update English (US) resource

by Francois Gouget

On Mon, 22 Jul 2013, Ken Sharp wrote: > Logon/Log on as with the British/neutral patch. > > msgid "Can't logon with inter-domain trust account.\n" > -msgstr "Can't logon with inter-domain trust account.\n" > +msgstr "Can't log on with inter-domain trust account.\n" [...] I think these fixes should really be applied to the source winerror.mc file instead. If I remember correctly en_US.po is just a dummy translation where msgid and msgstr strings should be identical (there might (with maybe one or two exceptions for things like um -> µm). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Be careful of reading health books, you might die of a misprint. -- Mark Twain

July 24, 2013

Re: [PATCH 1/3] msvcrt: Fix _mktemp implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26413 Your paranoid android. === W2KPROSP4 (32 bit file) === file: unhandled exception c0000005 at 7801B5A7 === WXPPROSP2 (32 bit file) === file: unhandled exception c0000005 at 77C2F1C3 === W2K3R2SESP2 (32 bit file) === file: unhandled exception c0000005 at 77BC00A3 === WXPX64 (64 bit file) === Timeout

July 24, 2013

Re: What to do when an application misuses an API ...

by Damjan Jovanovic

On Wed, Jul 24, 2013 at 4:17 AM, Michael Casadevall <mcasadevall(a)ubuntu.com> wrote: > Hey all, > I've been working on trying to get Sid Meier's Civilization V (Civ5) up to a > point where it works relatively flawlessly on WINE. The largest issue is > that installing the latest expansion pack has completely hosed the game > under WINE unless some rather ugly workarounds have been taken. > Specifically, the main issue is that Civ5 loads its data files in the order > returned by Find{First,Next}File(), and breaks spectacularly if that order > is disrupted. I documented my findings here: > http://bugs.winehq.org/show_bug.cgi?id=34122 > > As I sat to look at a possible patch, I'm not sure what I can actually do. > Its clearly stated on the MSDN page that the order returned is dependent on > the underlying filesystem, and Googling suggests that while NTFS seems to > always return in a roughly alphabetical order, FAT32 will return by creation > date, and with network drives all bets are off. I was even able to reproduce > similar bugs in Civ5 by launching it from a network drive (which I had > already tested in advance to make sure it returned an odd file order). > FindFirstFile essentially calls down to NtQueryDirectoryFile, which in turn > either calls a system specific syscall or readdir to get a list of files in > a directory. > > My first thought is to extend the underlying read_directory_* functions in > ntdll/directory.c so that they return an alphabetized list (essentially > taking the results from getdents/getdirentries/readdir, sort them, then > returning in the sort order whichever entry is next in line). This would > produce a behavior similar (but not identical) to what is seen when > operating under an NTFS filesystem. > > This approach seems wrong to me, and is further compounded by the fact this > is a bug in an application, and not in WINE specifically; Under the correct > circumstances, Windows will return a "non-sorted" list of files and in those > cases Civilization V breaks. The flipside is that in the most common case, > it works correctly, and furthermore, given how easy it is to assume that > Find*File does return a sorted list, I won't be surprised if this issue has > cropped up elsewhere (figuring out the underlying cause was exceedingly > annoying). Any insight in to what the most correct course of action would be > most appreciated > > I'm perfectly willing to put the legwork in fixing this bug, but I want to > make sure I'm fixing it in a way that will be accepted :-). > > Regards, > Michael > The other possibility to consider is a special FUSE-based filesystem that orders filenames just like Windows does. This filesystem could cache names and perform much better than reading all the directory contents on each FindFirstFile, just like the http://www.brain-dump.org/projects/ciopfs/ provides a performance benefit for case-insensitive filename matching. Regards Damjan

July 24, 2013

Re: What to do when an application misuses an API ...

by Rico Schüller

Hi Michael, there are several thinks you could check. 1. Could you get a wrong order on winxp/vista/7 by using the default installation on a local FAT32 partition? Or does the order by accident match? If this doesn't reproduce the issue, you may also try the ext2fs driver for windows, as this seems to be allowed too. Does the default installation on a network drive with e.g. ext3 work correctly? I couldn't find anything, that the game has to be on NTFS, so this might be a valid bug to report to the support for the game. The solution might be, that they fix the issue (then we are lucky) or they will only allow NTFS (FAT32) partitions. 2. While we don't know if this will be fixed in 1. in one way or the other, we may try the following. What happens if you use wine and a NTFS or FAT32 partition where the game is on? Does the order match? Maybe the game requires NTFS (and/or FAT32) as file system? Does the NTFS (FAT32) driver handle the order correctly? Maybe it's a bug in the NTFS (FAT32) driver or i might just work by accident? 3. What's the network file system type in your test? Does it work if it is a NTFS (FAT32) file system? I think, changing the Find* functions is bad, as there will most likely an app which depends on the order of the file creation date on FAT32 partitions... It may be worth a try to report it as a bug to the game support, but try to be as close to the system requirements as possible. Cheers Rico On 24.07.2013 04:17, Michael Casadevall wrote: > Hey all, > I've been working on trying to get Sid Meier's Civilization V (Civ5) up > to a point where it works relatively flawlessly on WINE. The largest > issue is that installing the latest expansion pack has completely hosed > the game under WINE unless some rather ugly workarounds have been taken. > Specifically, the main issue is that Civ5 loads its data files in the > order returned by Find{First,Next}File(), and breaks spectacularly if > that order is disrupted. I documented my findings here: > http://bugs.winehq.org/show_bug.cgi?id=34122 > > As I sat to look at a possible patch, I'm not sure what I can actually > do. Its clearly stated on the MSDN page that the order returned is > dependent on the underlying filesystem, and Googling suggests that while > NTFS seems to always return in a roughly alphabetical order, FAT32 will > return by creation date, and with network drives all bets are off. I was > even able to reproduce similar bugs in Civ5 by launching it from a > network drive (which I had already tested in advance to make sure it > returned an odd file order). FindFirstFile essentially calls down to > NtQueryDirectoryFile, which in turn either calls a system specific > syscall or readdir to get a list of files in a directory. > > My first thought is to extend the underlying read_directory_* functions > in ntdll/directory.c so that they return an alphabetized list > (essentially taking the results from getdents/getdirentries/readdir, > sort them, then returning in the sort order whichever entry is next in > line). This would produce a behavior similar (but not identical) to what > is seen when operating under an NTFS filesystem. > > This approach seems wrong to me, and is further compounded by the fact > this is a bug in an application, and not in WINE specifically; Under the > correct circumstances, Windows will return a "non-sorted" list of files > and in those cases Civilization V breaks. The flipside is that in the > most common case, it works correctly, and furthermore, given how easy it > is to assume that Find*File does return a sorted list, I won't be > surprised if this issue has cropped up elsewhere (figuring out the > underlying cause was exceedingly annoying). Any insight in to what the > most correct course of action would be most appreciated > > I'm perfectly willing to put the legwork in fixing this bug, but I want > to make sure I'm fixing it in a way that will be accepted :-). > > Regards, > Michael > > >

July 24, 2013

What to do when an application misuses an API ...

by Michael Casadevall

Hey all, I've been working on trying to get Sid Meier's Civilization V (Civ5) up to a point where it works relatively flawlessly on WINE. The largest issue is that installing the latest expansion pack has completely hosed the game under WINE unless some rather ugly workarounds have been taken. Specifically, the main issue is that Civ5 loads its data files in the order returned by Find{First,Next}File(), and breaks spectacularly if that order is disrupted. I documented my findings here: http://bugs.winehq.org/show_bug.cgi?id=34122 As I sat to look at a possible patch, I'm not sure what I can actually do. Its clearly stated on the MSDN page that the order returned is dependent on the underlying filesystem, and Googling suggests that while NTFS seems to always return in a roughly alphabetical order, FAT32 will return by creation date, and with network drives all bets are off. I was even able to reproduce similar bugs in Civ5 by launching it from a network drive (which I had already tested in advance to make sure it returned an odd file order). FindFirstFile essentially calls down to NtQueryDirectoryFile, which in turn either calls a system specific syscall or readdir to get a list of files in a directory. My first thought is to extend the underlying read_directory_* functions in ntdll/directory.c so that they return an alphabetized list (essentially taking the results from getdents/getdirentries/readdir, sort them, then returning in the sort order whichever entry is next in line). This would produce a behavior similar (but not identical) to what is seen when operating under an NTFS filesystem. This approach seems wrong to me, and is further compounded by the fact this is a bug in an application, and not in WINE specifically; Under the correct circumstances, Windows will return a "non-sorted" list of files and in those cases Civilization V breaks. The flipside is that in the most common case, it works correctly, and furthermore, given how easy it is to assume that Find*File does return a sorted list, I won't be surprised if this issue has cropped up elsewhere (figuring out the underlying cause was exceedingly annoying). Any insight in to what the most correct course of action would be most appreciated I'm perfectly willing to put the legwork in fixing this bug, but I want to make sure I'm fixing it in a way that will be accepted :-). Regards, Michael

July 24, 2013

Re: [PATCH 1/3] d3dx9: Fix initialization of D3DXPC_OBJECTs.

by Rico Schüller

On 23.07.2013 11:46, Rico Schüller wrote: > --- > dlls/d3dx9_36/effect.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > > These may not apply correctly. Sorry for the noise. I'll resend a new version. Cheers Rico

July 23, 2013

Re: [docs] "sgml" is not a valid output format

by Francois Gouget

On Tue, 23 Jul 2013, Frédéric Delanoy wrote: [...] > -ALLFORMATS = html pdf sgml ps txt > +ALLFORMATS = html pdf ps txt 'make sgml' can be used to generate the translated SGML source files for our many documentation translations. So I don't think this patch should be applied. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

July 23, 2013

Re: [docs] "sgml" is not a valid output format

by Frédéric Delanoy

On Tue, Jul 23, 2013 at 5:26 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > --- > Make.rules.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Make.rules.in b/Make.rules.in > index fda8e81..d326247 100644 > --- a/Make.rules.in > +++ b/Make.rules.in > @@ -100,7 +100,7 @@ dummy: > > # Manual Dependencies > > -ALLFORMATS = html pdf sgml ps txt > +ALLFORMATS = html pdf ps txt Please discard this patch ; it seems to be used in the translated guides to generate sgml from english version+po file

July 23, 2013

Re: [1/5] oledb32: Stub for IRowPosition

by Nikolay Sivov

On 7/23/2013 12:55, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=26406 > > Your paranoid android. > > > === WINEBUILD (build) === > Make failed I don't really know why it fails here, probably something to do with idls or something else.

July 23, 2013

Re: [1/5] oledb32: Stub for IRowPosition

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26406 Your paranoid android. === WINEBUILD (build) === Make failed

July 23, 2013

Re: [PATCH 1/2] wined3d: Implement special fog behavior for orthogonal projection matrices.

by Henri Verbeet

On 22 July 2013 20:24, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -3614,10 +3614,19 @@ void wined3d_ffp_get_vs_settings(const struct wined3d_state *state, const struct > & WINED3D_FFP_LIGHT_TYPE_MASK) << WINED3D_FFP_LIGHT_TYPE_SHIFT(i); > } > > + settings->ortho_fog = 0; > if (!state->render_states[WINED3D_RS_FOGENABLE]) > settings->fog_mode = WINED3D_FFP_VS_FOG_OFF; > else if (state->render_states[WINED3D_RS_FOGTABLEMODE] != WINED3D_FOG_NONE) > + { > settings->fog_mode = WINED3D_FFP_VS_FOG_DEPTH; > + > + if (state->transforms[WINED3D_TS_PROJECTION].u.m[0][3] == 0.0f > + && state->transforms[WINED3D_TS_PROJECTION].u.m[1][3] == 0.0f > + && state->transforms[WINED3D_TS_PROJECTION].u.m[2][3] == 0.0f > + && state->transforms[WINED3D_TS_PROJECTION].u.m[3][3] == 1.0f) > + settings->ortho_fog = 1; > + } I'm going to guess "No, because the projection matrix is ignored.", but does this "feature" apply to transformed vertices as well?

July 23, 2013

gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Alexei Svitkine

Don't let the gdi32 driver allocate memory in the dplayx region. Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 The issue is that the dplayx code in wine needs to allocate some memory at a static address (0x50000000) and loading the Mac native gdi driver ends up using that part of the address space. This patch fixes that by reserving that part of memory while the display driver is initialized and releasing it after. --- dlls/gdi32/driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+)

July 23, 2013

Re: [PATCH 2/2] include/ddk: add usbioctl.h

by Ken Sharp

On 22/07/13 19:57, Damjan Jovanovic wrote: > On Mon, Jul 22, 2013 at 6:46 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> On 7/22/2013 22:38, Damjan Jovanovic wrote: >>> >>> Changelog: >>> * add usbioctl.h >>> >>> Damjan Jovanovic >> >> Hi, Damjan. You forgot patches. > > I didn't. Why aren't they showing up? I've sent four patches. Three are showing.

July 22, 2013

Re: [PATCH 2/2] include/ddk: add usbioctl.h

by Damjan Jovanovic

On Mon, Jul 22, 2013 at 6:46 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 7/22/2013 22:38, Damjan Jovanovic wrote: >> >> Changelog: >> * add usbioctl.h >> >> Damjan Jovanovic > > Hi, Damjan. You forgot patches. I didn't. Why aren't they showing up?

July 22, 2013

Re: [PATCH 2/2] include/ddk: add usbioctl.h

by Nikolay Sivov

On 7/22/2013 22:38, Damjan Jovanovic wrote: > Changelog: > * add usbioctl.h > > Damjan Jovanovic Hi, Damjan. You forgot patches.

July 22, 2013

Re: appwiz: Correct Wine Mono installer messages

by Ken Sharp

On 22/07/13 19:39, Vincent Povirk wrote: >> Okay but at the moment, in those languages, a user is currently being told >> Gecko needs to be installed, followed by Gecko needs to be installed. > > Are you sure this isn't caused by needing 32-bit and 64-bit builds of Gecko? > Certain. It's a translation error. http://source.winehq.org/patches/data/97455

July 22, 2013

Re: appwiz: Correct Wine Mono installer messages

by Vincent Povirk

> Okay but at the moment, in those languages, a user is currently being told > Gecko needs to be installed, followed by Gecko needs to be installed. Are you sure this isn't caused by needing 32-bit and 64-bit builds of Gecko?

July 22, 2013

Re: appwiz: Correct Wine Mono installer messages

by Ken Sharp

On 22/07/13 18:37, Alexandre Julliard wrote: > Ken Sharp <kennybobs(a)o2.co.uk> writes: > >> Where the correction is obvious I have done so, but where a full >> translation is needed I have simply removed the incorrect one. This >> will mark that line as untranslated and hopefully someone will see >> that. It will also default to English with the correct message until >> translated. > > That's what fuzzy is for, there's no reason to remove them. > Okay but at the moment, in those languages, a user is currently being told Gecko needs to be installed, followed by Gecko needs to be installed. I'll send a smaller patch correcting the title. Someone else can fix the long message. It should flag someone's attention the two being unequal. It has been this way for at least a year: nobody seems to be taking any notice.

July 22, 2013

Re: appwiz: Correct Wine Mono installer messages

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Where the correction is obvious I have done so, but where a full > translation is needed I have simply removed the incorrect one. This > will mark that line as untranslated and hopefully someone will see > that. It will also default to English with the correct message until > translated. That's what fuzzy is for, there's no reason to remove them. -- Alexandre Julliard julliard(a)winehq.org

July 22, 2013

Wine 1.6 list of deferred patches

by Bruno Jesus

This is the list of (hopefully) all deferred patches for wine 1.6, all authors are in bcc. I hope it's useful for developers. 97187 Deferred Dmitry Timoshkov [3/3] kernel32: GetShortPathName for a non-existent short file name should fail. 97131 Deferred Rosen Diankov [ole32] Bugfix for implicit MTA apartment initialization 97130 Deferred Rosen Diankov [oleaut32] Bugfix patches for marshaling VT_UNKNOWN in SAFEARRAYS 97124 Deferred Maarten Lankhorst [RFC PATCH] loader: allow overriding pthread_create correctly on linux 97119 Deferred Fabian Ebner [PATCH] dinput: Check the message queue in GetDeviceState * 97085 Deferred Dmitry Timoshkov ntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file. 96974 Deferred Stefan Dösinger [PATCH 2/2] wined3d: Avoid calculating 1 / (fog_end - fog_start) in the shader 96961 Deferred Mathis Beer ntdll: make msync() call asynchronous in NtFlushVirtualMemory (try 3.5, alternate version) 96925 Deferred Hans Leidekker server: The token user SID must be present in the default DACL. 96899 Deferred Stefan Dösinger [PATCH 1/5] wined3d: Consolidate d3d_info BOOLs into a flags field 96855 Deferred Alistair Leslie-Hughes oledb32: Add IErrorInfo Support OK 96854 Deferred Alistair Leslie-Hughes msdaps: Add support for ISourcesRowset (try 2) 96831 Deferred Christian Costa [PATCH] d3dxof: Remove LP stuff and rename variables for IDirectXFile methods. 96819 Deferred Nikolay Sivov comctl32: Properly handle repainting for HDF_OWNERDRAW items 96797 Deferred André Hentschel ntdll: Add stub for LdrResolveDelayLoadedAPI and reference it in kernel32 (try 2) 96793 Deferred Christian Costa [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests. 96791 Deferred morphiend msvcrt: add support for _chsize_s 96765 Deferred Christian Costa [PATCH 2/4] d3dxof: Handle float in binary mode and remove code that becomes useless. * this patch was already commited.

July 22, 2013

Re: [PATCH 3/4] d3dx9: Improve ID3DXConstantTable::Set*().

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > +static UINT set(struct ID3DXConstantTableImpl *table, IDirect3DDevice9 *device, struct ctab_constant *constant, > + const void **indata, D3DXPARAMETER_TYPE intype, UINT *size, UINT incol, D3DXPARAMETER_CLASS inclass, UINT index, > + BOOL is_pointer) > +{ > + DWORD (*get_index)(const void **indata, UINT index) = NULL; > + D3DXCONSTANT_DESC *desc = &constant->desc; > + UINT l, i, regcount = 1, regsize = 1, cin = 1, rin = 1, ret, last = 0; > + DWORD tmp; > + > + if (is_pointer) get_index = &get_index_pointer; > + else get_index = &get_index_array; It would be cleaner and easier to follow to have a simple helper with a is_pointer flag, rather than using function pointers with such trivial functions. -- Alexandre Julliard julliard(a)winehq.org

July 22, 2013

Re: msxml3: Defer the conversion of XPath expressions to UTF-8. (try 2)

by Nikolay Sivov

On 7/20/2013 23:37, John Chadwick wrote: > This patch changes the create_selection interface to accept a wide string > instead of an xmlChar string. This is a transitional change, which will be > needed as libxml2's XPath parser is phased out. > > The last submission had a memory leak (sorry, I isolated this change > from some other changes and accidentally axed a heap_free in the > process.) Looks ok, I didn't try tests, but I hope you did.. One thing though: > +static inline WCHAR *heap_strcatW(WCHAR *a, const WCHAR *b) > +{ > + int len = strlenW(a) + strlenW(b); > + WCHAR *c = heap_realloc(a, (len + 1) * sizeof(WCHAR)); > + WCHAR *ptr = c; > + > + while(*ptr) > + ptr++; > + while(*b) > + *(ptr++) = *(b++); > + c[len] = 0; > + > + return c; > +} > + I'm assuming you didn't use strcatW() to avoid one more strlenW()? Even if you don't want to use it for some reason, you don't need first loop cause you already know 'a' length, and second loop is just strcpyW(). Also I suggest to use 'dst', 'src' names for parameters.

July 21, 2013

Re: Need help with debugging a directx9 game crashing

by Ken Thomases

On Jul 19, 2013, at 8:34 AM, Qian Hong wrote: > I was debugging on a popular game [1] [2] (9 GB), it crashes on start. > > +relay,+seh,+tid log show that there are some calls to > wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map / > wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace > to get a new log in details. > > To my surprise, the game doesn't crash anymore with +d3d9 trace! > > After a serials of bisect, I found d3d9_AddRef is the key function > call related to the crashing. If I remove the TRACE statement in line > 71, the game will crash with +d3d9 as well; if I upgrade the TRACE in > 71 to FIXME, the game will not crash even without +d3d9. > > 66 static ULONG WINAPI d3d9_AddRef(IDirect3D9Ex *iface) > 67 { > 68 struct d3d9 *d3d9 = impl_from_IDirect3D9Ex(iface); > 69 ULONG refcount = InterlockedIncrement(&d3d9->refcount); > 70 > 71 TRACE("%p increasing refcount to %u.\n", iface, refcount); > 72 > 73 return refcount; > 74 } > > Further tests show that the simplest hack to avoid crashing is > replacing line 71 to: > FIXME("anything %x\n", 0xdeadbeef); > > I have no idea what the real fix is, any suggestion what is the next > step to debug? > Backtrace on crash: > Wine-dbg>c > Unhandled exception: page fault on read access to 0x00000001 in 32-bit > code (0x0649e6e9). This reminds me of bugs where programs fail to initialize variables before use. So, the variable contains whatever value happened to be left at that stack location by previous calls. The specific behavior of those previous calls can leave different values, so changing seemingly unrelated code changes the crash (or makes it go away). Instead of enabling the trace, try replacing it with something like: char dummy[256]; memset(dummy, 0x55, sizeof(dummy)); I bet the crash will change from a read access to 0x00000001 to 0x55555555. The question is: is it a bug in the game or a bug in Wine where Wine is returning a garbage pointer to the game and the game is innocently dereferencing it? For that, you'd have to trace the execution from the call to d3d9_AddRef() to the crashing point to see what else is called and whether it uses an uninitialized value. Of course, another approach would be to run under Valgrind, if you can get it to work. -Ken

July 21, 2013

Coverity Status

by Marcus Meissner

Hi, For Wine 1.6 we have the following Coverity stats: - 3,648,322 Lines of Code scanned - Defect Density 0.51 - 8321 total defects - 1852 outstanding (unresolved) defects - 1964 dismissed defects - 4505 fixed defects git shortlog wine-1.4..wine-1.6|grep -i Coverity|wc -l 225 Thanks to AmineKhaldi uploading the builds and everyone reviewing and fixing coverity issues :) Ciao, Marcus

July 20, 2013

Re: Another major milestone

by Thomas Spear

mfc.dll (bug 611 IIRC) *cough* :) On Jul 19, 2013 2:23 PM, "Rosanne DiMesio" <dimesio(a)earthlink.net> wrote: > On Fri, 19 Jul 2013 20:14:08 +0200 > Marcus Meissner <marcus(a)jet.franken.de> wrote: > > > > > We noticed too late. ;) > > > > But thats software management life, you always have bugs left over > > when you release. More for 1.6.1 or 1.7.x :) > > > > So maybe now is the time to start thinking about bugs to target for 1.8. > There are longstanding bugs that are not regressions, but they do affect a > lot of apps. > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> > > >

July 19, 2013

Re: Another major milestone

by Rosanne DiMesio

On Fri, 19 Jul 2013 20:14:08 +0200 Marcus Meissner <marcus(a)jet.franken.de> wrote: > > We noticed too late. ;) > > But thats software management life, you always have bugs left over > when you release. More for 1.6.1 or 1.7.x :) > So maybe now is the time to start thinking about bugs to target for 1.8. There are longstanding bugs that are not regressions, but they do affect a lot of apps. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 19, 2013

Re: Need help with debugging a directx9 game crashing

by Marcus Meissner

On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote: > On 19 July 2013 15:34, Qian Hong <fracting(a)gmail.com> wrote: > > Further tests show that the simplest hack to avoid crashing is > > replacing line 71 to: > > FIXME("anything %x\n", 0xdeadbeef); > > > > I have no idea what the real fix is, any suggestion what is the next > > step to debug? > > > Well, it sounds a bit like some form of memory corruption. Sometimes > WINEDEBUG=warn+heap helps with tracking those down. Also, I don't > suppose the d3d9 object was already destroyed earlier? Or timing ... Also can you print out refcount there to see if the refcounting is good? Ciao, Marcus

July 19, 2013

Re: Another major milestone

by Marcus Meissner

On Fri, Jul 19, 2013 at 06:32:32PM +0100, Ken Sharp wrote: > > > On 19/07/13 15:00, Rosanne DiMesio wrote: > >On Thu, 18 Jul 2013 16:55:42 -0500 > >Jeremy White <jwhite(a)codeweavers.com> wrote: > > > >>Alright folks, I have to confess that the 1.6 release came and I didn't > >>immediately get up and dance. > >> > >>In fact, a new Wine release was almost...boring. > >> > > > >What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. > > > > http://bugs.winehq.org/show_bug.cgi?id=24611 was added two days ago. > *shrugs* We noticed too late. ;) But thats software management life, you always have bugs left over when you release. More for 1.6.1 or 1.7.x :) Ciao, Marcus

July 19, 2013

Re: Another major milestone

by Ken Sharp

On 19/07/13 15:00, Rosanne DiMesio wrote: > On Thu, 18 Jul 2013 16:55:42 -0500 > Jeremy White <jwhite(a)codeweavers.com> wrote: > >> Alright folks, I have to confess that the 1.6 release came and I didn't >> immediately get up and dance. >> >> In fact, a new Wine release was almost...boring. >> > > What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. > http://bugs.winehq.org/show_bug.cgi?id=24611 was added two days ago. *shrugs*

July 19, 2013

Re: [docs] winelib: Use proper entity escaping for '&','<' and '>'

by Frédéric Delanoy

On Fri, Jul 19, 2013 at 5:50 PM, Julian Rüger <jr98(a)gmx.net> wrote: > Hi Frédéric, > >> - $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $< | $(WRC) -N $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ >> + $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $lt; | $(WRC) -N $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ > > looks like you forgot the "&". > > Best, > Julian Good catch, thanks. Sending updated version. Frédéric

July 19, 2013

Re: [2/2] gdiplus: Store graphics clipping region in device coordinates.

by Vincent Povirk

> It works just fine in the samples I have here, why would it break? If the rotation is a multiple of 90 degrees, the upper-left corner will not be the same point, but you're not making any attempt to use a different corner for the origin of your rectangle. If the rotation is something like 45 degrees, the result can't be expressed as a RectF.

July 19, 2013

Re: [2/2] gdiplus: Store graphics clipping region in device coordinates.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I'm curious what happens if the world transform has some rotation. It > seems like transform_rectf would break in that case. It works just fine in the samples I have here, why would it break? -- Dmitry.

July 19, 2013

Re: [docs] winelib: Use proper entity escaping for '&','<' and '>'

by Julian Rüger

Hi Frédéric, > - $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $< | $(WRC) -N $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ > + $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $lt; | $(WRC) -N $(WRCFLAGS) $(WINELIB_FLAGS) -o $@ looks like you forgot the "&". Best, Julian

July 19, 2013

Re: Another major milestone

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > On Fri, Jul 19, 2013 at 09:00:30AM -0500, Rosanne DiMesio wrote: >> On Thu, 18 Jul 2013 16:55:42 -0500 >> Jeremy White <jwhite(a)codeweavers.com> wrote: >> >> > Alright folks, I have to confess that the 1.6 release came and I didn't >> > immediately get up and dance. >> > >> > In fact, a new Wine release was almost...boring. >> > >> >> What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. > > Either we are good :) > > Or we should have reminded and called for this kind of tagging and bug squashing work. I think working from the regressions list is more productive (and we have made some good progress there). -- Alexandre Julliard julliard(a)winehq.org

July 19, 2013

Re: [1/2] windowscodecs: Add a test for global GIF palette exposed by recent Windows versions.

by Vincent Povirk

The series looks good to me.

July 19, 2013

Re: [1/4] wincodecs: Added IWICBitmapClipper stub

by Vincent Povirk

This series looks good to me.

July 19, 2013

Re: [2/2] gdiplus: Store graphics clipping region in device coordinates.

by Vincent Povirk

I'm curious what happens if the world transform has some rotation. It seems like transform_rectf would break in that case.

July 19, 2013

Re: Another major milestone

by Marcus Meissner

On Fri, Jul 19, 2013 at 09:00:30AM -0500, Rosanne DiMesio wrote: > On Thu, 18 Jul 2013 16:55:42 -0500 > Jeremy White <jwhite(a)codeweavers.com> wrote: > > > Alright folks, I have to confess that the 1.6 release came and I didn't > > immediately get up and dance. > > > > In fact, a new Wine release was almost...boring. > > > > What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. Either we are good :) Or we should have reminded and called for this kind of tagging and bug squashing work. Ciao, Marcus

July 19, 2013

Re: Need help with debugging a directx9 game crashing

by Henri Verbeet

On 19 July 2013 15:34, Qian Hong <fracting(a)gmail.com> wrote: > Further tests show that the simplest hack to avoid crashing is > replacing line 71 to: > FIXME("anything %x\n", 0xdeadbeef); > > I have no idea what the real fix is, any suggestion what is the next > step to debug? > Well, it sounds a bit like some form of memory corruption. Sometimes WINEDEBUG=warn+heap helps with tracking those down. Also, I don't suppose the d3d9 object was already destroyed earlier?

July 19, 2013

Re: Another major milestone

by Rosanne DiMesio

On Thu, 18 Jul 2013 16:55:42 -0500 Jeremy White <jwhite(a)codeweavers.com> wrote: > Alright folks, I have to confess that the 1.6 release came and I didn't > immediately get up and dance. > > In fact, a new Wine release was almost...boring. > What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 19, 2013

Need help with debugging a directx9 game crashing

by Qian Hong

Hello, I was debugging on a popular game [1] [2] (9 GB), it crashes on start. +relay,+seh,+tid log show that there are some calls to wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map / wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace to get a new log in details. To my surprise, the game doesn't crash anymore with +d3d9 trace! After a serials of bisect, I found d3d9_AddRef is the key function call related to the crashing. If I remove the TRACE statement in line 71, the game will crash with +d3d9 as well; if I upgrade the TRACE in 71 to FIXME, the game will not crash even without +d3d9. 66 static ULONG WINAPI d3d9_AddRef(IDirect3D9Ex *iface) 67 { 68 struct d3d9 *d3d9 = impl_from_IDirect3D9Ex(iface); 69 ULONG refcount = InterlockedIncrement(&d3d9->refcount); 70 71 TRACE("%p increasing refcount to %u.\n", iface, refcount); 72 73 return refcount; 74 } Further tests show that the simplest hack to avoid crashing is replacing line 71 to: FIXME("anything %x\n", 0xdeadbeef); I have no idea what the real fix is, any suggestion what is the next step to debug? Thanks in advance! Environment: Wine 1.6-rc5 Ubuntu 12.04.2 LTS gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) The installer ship with native d3dx9_40.dll Backtrace on crash: Wine-dbg>c Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x0649e6e9). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0649e6e9 ESP:0033cc60 EBP:00000000 EFLAGS:00210206( R- -- I - -P- ) EAX:00000001 EBX:19b871e0 ECX:00000000 EDX:00000000 ESI:23f420b0 EDI:23f4f20c Stack dump: 0x0033cc60: 80004005 19c0e0c0 00000000 19b871e0 0x0033cc70: 00000000 23f420b0 23f4f1f0 19b871e0 0x0033cc80: 00000018 00000040 0000001c 00000000 0x0033cc90: 0a9101df 00000020 00000034 7bc34159 0x0033cca0: 00110064 ffffffff 0033ccd8 7bc34d2d 0x0033ccb0: 00000000 0000000c 00000010 00000001 Backtrace: =>0 0x0649e6e9 in kg3dengine (+0x16e6e9) (0x00000000) 0x0649e6e9: movl 0x0(%eax),%ecx [1] http://jx3.xoyo.com/download [2] http://jx3.client.cdn.kingsoft.com/JXOnline3-v3.0.4.4980/JXOnline3-v3.0.4.4… -- Regards, Qian Hong - http://www.winehq.org

July 19, 2013

Re: Another major milestone

by Michael Stefaniuc

On 07/19/2013 01:40 PM, Marcus Meissner wrote: > On Thu, Jul 18, 2013 at 04:55:42PM -0500, Jeremy White wrote: >> Alright folks, I have to confess that the 1.6 release came and I didn't >> immediately get up and dance. >> >> In fact, a new Wine release was almost...boring. >> >> I think we have to consider that a major milestone in of itself. New, >> useful releases are just a matter of course for us now. >> >> Woohoo! Now I'm dancing <grin>. > > I keep hearing "Considering that it took you 15 years for 1.0 you are grinding > them out really fast now" ;) Soon he'll want us to do 6 or even 3 months time based releases! ;) bye michael

July 19, 2013

Re: Another major milestone

by Marcus Meissner

On Thu, Jul 18, 2013 at 04:55:42PM -0500, Jeremy White wrote: > Alright folks, I have to confess that the 1.6 release came and I didn't > immediately get up and dance. > > In fact, a new Wine release was almost...boring. > > I think we have to consider that a major milestone in of itself. New, > useful releases are just a matter of course for us now. > > Woohoo! Now I'm dancing <grin>. I keep hearing "Considering that it took you 15 years for 1.0 you are grinding them out really fast now" ;) Ciao, Marcus

July 19, 2013

Re: riched20: Add tests for ITextRange interface.

by Caibin Chen

Can you explain what benefits can we get from merging these two tests? To me it only make them hard to read. 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: > On 7/19/2013 00:15, Caibin Chen wrote: >> >> What files do you mean to merge? txtsrv.c and richole.c or >> test/richole.c and test/richole.c? > > Tests of course. Another solution is to create ITextService instance in > richole.c and run > range tests or whatever tests you need on it. It's a couple of lines to add. > >> >> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>> >>> On 7/19/2013 00:04, Caibin Chen wrote: >>>> >>>> The ITextRange objects are returned by ITextDocument_Range() method. >>>> Both IRichEditOle and ITextService supports ITextDocument interface. >>>> Currently we don't have ITextDocument support in ITextService. my >>>> another patch[1] is to add ITextDocument interface support in >>>> ITextService. >>> >>> I see, then maybe it's better to merge two existing files first. >>> >>>> [1]. http://www.winehq.org/pipermail/wine-patches/2013-July/125258.html >>>> >>>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>> >>>>> On 7/18/2013 23:36, Caibin Chen wrote: >>>>>> >>>>>> ITextRange will be used in both richole.c and txtsrv.c. I'm planning >>>>>> to add more tests in it. I think it makes more sense to have one test >>>>>> file for each interface, which improves the readability of tests. >>>>> >>>>> That's usually done for implementation, but not for the tests. What >>>>> does >>>>> it >>>>> mean it will be used in both files by the way? >>>>> >>>>>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>>>> >>>>>>> On 7/18/2013 20:28, Caibin Chen wrote: >>>>>>>> >>>>>>>> Add tests for start and end point, setting and getting text. >>>>>>>> --- >>>>>>>> dlls/riched20/tests/Makefile.in | 3 +- >>>>>>>> dlls/riched20/tests/txtrng.c | 343 >>>>>>>> ++++++++++++++++++++++++++++++++++++++++ >>>>>>>> 2 files changed, 345 insertions(+), 1 deletion(-) >>>>>>>> create mode 100644 dlls/riched20/tests/txtrng.c >>>>>>> >>>>>>> You could just use existing file, richole.c fits I think. >>>>>>> >

July 19, 2013

Re: riched20: Add tests for ITextRange interface.

by Nikolay Sivov

On 7/19/2013 00:15, Caibin Chen wrote: > What files do you mean to merge? txtsrv.c and richole.c or > test/richole.c and test/richole.c? Tests of course. Another solution is to create ITextService instance in richole.c and run range tests or whatever tests you need on it. It's a couple of lines to add. > > 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 7/19/2013 00:04, Caibin Chen wrote: >>> The ITextRange objects are returned by ITextDocument_Range() method. >>> Both IRichEditOle and ITextService supports ITextDocument interface. >>> Currently we don't have ITextDocument support in ITextService. my >>> another patch[1] is to add ITextDocument interface support in >>> ITextService. >> I see, then maybe it's better to merge two existing files first. >> >>> [1]. http://www.winehq.org/pipermail/wine-patches/2013-July/125258.html >>> >>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>> On 7/18/2013 23:36, Caibin Chen wrote: >>>>> ITextRange will be used in both richole.c and txtsrv.c. I'm planning >>>>> to add more tests in it. I think it makes more sense to have one test >>>>> file for each interface, which improves the readability of tests. >>>> That's usually done for implementation, but not for the tests. What does >>>> it >>>> mean it will be used in both files by the way? >>>> >>>>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>>> On 7/18/2013 20:28, Caibin Chen wrote: >>>>>>> Add tests for start and end point, setting and getting text. >>>>>>> --- >>>>>>> dlls/riched20/tests/Makefile.in | 3 +- >>>>>>> dlls/riched20/tests/txtrng.c | 343 >>>>>>> ++++++++++++++++++++++++++++++++++++++++ >>>>>>> 2 files changed, 345 insertions(+), 1 deletion(-) >>>>>>> create mode 100644 dlls/riched20/tests/txtrng.c >>>>>> You could just use existing file, richole.c fits I think. >>>>>>

July 19, 2013

Another major milestone

by Jeremy White

Alright folks, I have to confess that the 1.6 release came and I didn't immediately get up and dance. In fact, a new Wine release was almost...boring. I think we have to consider that a major milestone in of itself. New, useful releases are just a matter of course for us now. Woohoo! Now I'm dancing <grin>. Cheers, Jeremy

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Caibin Chen

What files do you mean to merge? txtsrv.c and richole.c or test/richole.c and test/richole.c? 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: > On 7/19/2013 00:04, Caibin Chen wrote: >> >> The ITextRange objects are returned by ITextDocument_Range() method. >> Both IRichEditOle and ITextService supports ITextDocument interface. >> Currently we don't have ITextDocument support in ITextService. my >> another patch[1] is to add ITextDocument interface support in >> ITextService. > > I see, then maybe it's better to merge two existing files first. > >> >> [1]. http://www.winehq.org/pipermail/wine-patches/2013-July/125258.html >> >> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>> >>> On 7/18/2013 23:36, Caibin Chen wrote: >>>> >>>> ITextRange will be used in both richole.c and txtsrv.c. I'm planning >>>> to add more tests in it. I think it makes more sense to have one test >>>> file for each interface, which improves the readability of tests. >>> >>> That's usually done for implementation, but not for the tests. What does >>> it >>> mean it will be used in both files by the way? >>> >>>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>> >>>>> On 7/18/2013 20:28, Caibin Chen wrote: >>>>>> >>>>>> Add tests for start and end point, setting and getting text. >>>>>> --- >>>>>> dlls/riched20/tests/Makefile.in | 3 +- >>>>>> dlls/riched20/tests/txtrng.c | 343 >>>>>> ++++++++++++++++++++++++++++++++++++++++ >>>>>> 2 files changed, 345 insertions(+), 1 deletion(-) >>>>>> create mode 100644 dlls/riched20/tests/txtrng.c >>>>> >>>>> You could just use existing file, richole.c fits I think. >>>>> >

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Nikolay Sivov

On 7/19/2013 00:04, Caibin Chen wrote: > The ITextRange objects are returned by ITextDocument_Range() method. > Both IRichEditOle and ITextService supports ITextDocument interface. > Currently we don't have ITextDocument support in ITextService. my > another patch[1] is to add ITextDocument interface support in > ITextService. I see, then maybe it's better to merge two existing files first. > > [1]. http://www.winehq.org/pipermail/wine-patches/2013-July/125258.html > > 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 7/18/2013 23:36, Caibin Chen wrote: >>> ITextRange will be used in both richole.c and txtsrv.c. I'm planning >>> to add more tests in it. I think it makes more sense to have one test >>> file for each interface, which improves the readability of tests. >> That's usually done for implementation, but not for the tests. What does it >> mean it will be used in both files by the way? >> >>> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>>> On 7/18/2013 20:28, Caibin Chen wrote: >>>>> Add tests for start and end point, setting and getting text. >>>>> --- >>>>> dlls/riched20/tests/Makefile.in | 3 +- >>>>> dlls/riched20/tests/txtrng.c | 343 >>>>> ++++++++++++++++++++++++++++++++++++++++ >>>>> 2 files changed, 345 insertions(+), 1 deletion(-) >>>>> create mode 100644 dlls/riched20/tests/txtrng.c >>>> You could just use existing file, richole.c fits I think. >>>>

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Caibin Chen

The ITextRange objects are returned by ITextDocument_Range() method. Both IRichEditOle and ITextService supports ITextDocument interface. Currently we don't have ITextDocument support in ITextService. my another patch[1] is to add ITextDocument interface support in ITextService. [1]. http://www.winehq.org/pipermail/wine-patches/2013-July/125258.html 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: > On 7/18/2013 23:36, Caibin Chen wrote: >> >> ITextRange will be used in both richole.c and txtsrv.c. I'm planning >> to add more tests in it. I think it makes more sense to have one test >> file for each interface, which improves the readability of tests. > > That's usually done for implementation, but not for the tests. What does it > mean it will be used in both files by the way? > >> >> 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>> >>> On 7/18/2013 20:28, Caibin Chen wrote: >>>> >>>> Add tests for start and end point, setting and getting text. >>>> --- >>>> dlls/riched20/tests/Makefile.in | 3 +- >>>> dlls/riched20/tests/txtrng.c | 343 >>>> ++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 345 insertions(+), 1 deletion(-) >>>> create mode 100644 dlls/riched20/tests/txtrng.c >>> >>> You could just use existing file, richole.c fits I think. >>> >

July 18, 2013

Re: Patches I maintain

by Nozomi Kodama

Hello for this one, I have a patch in my tree. I will send it after my patches for the spherical harmonics. Nozomi >Hi Roland, > >I'm not exactly sure what your goal is... but there is a rule one patch per mail only! There is likely no chance to get something like that mixture committed. > >You may have a look here: >http://wiki.winehq.org/SubmittingPatches > > >On 18.07.2013 01:23, Roland Haeder wrote: > >+HRESULT D3DXCreatePolygon(LPDIRECT3DDEVICE9 device, float length, UINT sides, LPD3DXMESH *mesh, LPD3DXBUFFER adjacency) > >Well this looks a little bit wrong. You may have a look here http://msdn.microsoft.com/en-us/library/windows/desktop/bb172785%28v=vs.85%… . Don't copy and paste it. A patch which by accident works, is not something which should be applied at all. There are several issues alone in that line. > >Cheers >Rico

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Nikolay Sivov

On 7/18/2013 23:36, Caibin Chen wrote: > ITextRange will be used in both richole.c and txtsrv.c. I'm planning > to add more tests in it. I think it makes more sense to have one test > file for each interface, which improves the readability of tests. That's usually done for implementation, but not for the tests. What does it mean it will be used in both files by the way? > > 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 7/18/2013 20:28, Caibin Chen wrote: >>> Add tests for start and end point, setting and getting text. >>> --- >>> dlls/riched20/tests/Makefile.in | 3 +- >>> dlls/riched20/tests/txtrng.c | 343 >>> ++++++++++++++++++++++++++++++++++++++++ >>> 2 files changed, 345 insertions(+), 1 deletion(-) >>> create mode 100644 dlls/riched20/tests/txtrng.c >> You could just use existing file, richole.c fits I think. >>

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Caibin Chen

ITextRange will be used in both richole.c and txtsrv.c. I'm planning to add more tests in it. I think it makes more sense to have one test file for each interface, which improves the readability of tests. 2013/7/18 Nikolay Sivov <bunglehead(a)gmail.com>: > On 7/18/2013 20:28, Caibin Chen wrote: >> >> Add tests for start and end point, setting and getting text. >> --- >> dlls/riched20/tests/Makefile.in | 3 +- >> dlls/riched20/tests/txtrng.c | 343 >> ++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 345 insertions(+), 1 deletion(-) >> create mode 100644 dlls/riched20/tests/txtrng.c > > You could just use existing file, richole.c fits I think. >

July 18, 2013

Re: riched20: Add tests for ITextRange interface.

by Nikolay Sivov

On 7/18/2013 20:28, Caibin Chen wrote: > Add tests for start and end point, setting and getting text. > --- > dlls/riched20/tests/Makefile.in | 3 +- > dlls/riched20/tests/txtrng.c | 343 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 345 insertions(+), 1 deletion(-) > create mode 100644 dlls/riched20/tests/txtrng.c You could just use existing file, richole.c fits I think.

July 18, 2013

Re: riched20: ITextDocument stubs for ITextServices (retry)

by Caibin Chen

Anybody reviewing this patch? It's almost all stubs, so although it's long, it shouldn't be hard to review 2013/7/15 Caibin Chen <tigersoldi(a)gmail.com>: > (Retry with real name in mail. The name in the patch is already my real name) > > This patch implements a standalone stub of ITextDocument. The stub is > currently used in txtsrv.c and will replace the stub in richole.c > > --- > dlls/riched20/Makefile.in | 1 + > dlls/riched20/tests/txtsrv.c | 16 ++- > dlls/riched20/txtdoc.c | 282 +++++++++++++++++++++++++++++++++++++++++++ > dlls/riched20/txtdoc.h | 46 +++++++ > dlls/riched20/txtsrv.c | 6 + > 5 files changed, 350 insertions(+), 1 deletion(-) > create mode 100644 dlls/riched20/txtdoc.c > create mode 100644 dlls/riched20/txtdoc.h

July 18, 2013

Re: Patches I maintain

by Rico Schüller

Hi Roland, I'm not exactly sure what your goal is... but there is a rule one patch per mail only! There is likely no chance to get something like that mixture committed. You may have a look here: http://wiki.winehq.org/SubmittingPatches On 18.07.2013 01:23, Roland Haeder wrote: > +HRESULT D3DXCreatePolygon(LPDIRECT3DDEVICE9 device, float length, UINT sides, LPD3DXMESH *mesh, LPD3DXBUFFER adjacency) Well this looks a little bit wrong. You may have a look here http://msdn.microsoft.com/en-us/library/windows/desktop/bb172785%28v=vs.85%… . Don't copy and paste it. A patch which by accident works, is not something which should be applied at all. There are several issues alone in that line. Cheers Rico

July 18, 2013

Re: winedev: Add doc for winedbg symbol_picker option

by Frédéric Delanoy

On Thu, Jul 18, 2013 at 12:48 AM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > --- > en/winedev-debugger.sgml | 21 +++++++++++++++++++++ > 1 files changed, 21 insertions(+), 0 deletions(-) > Please discard this. It has been committed a long time ago. Sorry (again) for the noise. Frédéric

July 17, 2013

Re: Manpage patch, please review

by Julian Rüger

> >> i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI > > > > So, do you think I should leave it? To the average reader, CLI should be > > clearer. I thought it was a typo at first. ;) > > I'd leave it. Anyone else? Ironically, in the existing German translation it says CLI. > >>> Should paths be bold or italic/underlined? > >> > >> Not sure, are there other guidelines out there we can use? > > > > Anyone else? > > Did Frédérics recent patches handle that? I can't really tell, although there are a few occurrences that look similar, like -outputs the data either in a standard \fB.bin\fR formatted binary +outputs the data either in a standard \fI.bin\fR formatted binary If nobody else speaks up, I'll give it a shot, maybe leave out the CUI/CLI part for now. Thanks, André!

July 17, 2013

Re: Manpage patch, please review

by André Hentschel

Am 17.07.2013 22:19, schrieb Julian Rüger: >> Frédéric has done it quite good, because it's committed :) >> Further you can't compile Wine in 64-bit mode on 32-bit that easily, and you can't run it, your version doesn't handle that. > > Naturally. But yeah, I guess not everyone knows that, good point. > >>> CUI -> CLI: >>> According to Google and Wikipedia, CLI is more common. >> >> i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI > > So, do you think I should leave it? To the average reader, CLI should be > clearer. I thought it was a typo at first. ;) I'd leave it. Anyone else? >>> Should paths be bold or italic/underlined? >> >> Not sure, are there other guidelines out there we can use? > > Anyone else? Did Frédérics recent patches handle that?

July 17, 2013

Re: Manpage patch, please review

by Julian Rüger

> Frédéric has done it quite good, because it's committed :) > Further you can't compile Wine in 64-bit mode on 32-bit that easily, and you can't run it, your version doesn't handle that. Naturally. But yeah, I guess not everyone knows that, good point. > > CUI -> CLI: > > According to Google and Wikipedia, CLI is more common. > > i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI So, do you think I should leave it? To the average reader, CLI should be clearer. I thought it was a typo at first. ;) > > Should paths be bold or italic/underlined? > > Not sure, are there other guidelines out there we can use? Anyone else? Best, Julian

July 17, 2013

Re: ieframe: Use SHANDLE_PTR in IWebBrowserApp::get_HWND.

by Thomas Faber

Sorry, should have replied to this. These tests shouldn't even run on 2000, already seen e.g. in http://www.winehq.org/pipermail/wine-devel/2013-April/099536.html http://www.winehq.org/pipermail/wine-devel/2012-November/097823.html Let me know if there's any issues. Thanks, Thomas On 2013-07-14 13:04, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=26282 > > Your paranoid android. > > > === W2KPROSP4 (32 bit webbrowser) === > webbrowser.c:2631: Test failed: expected GetOverridesKeyPath > webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON > webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD > webbrowser.c:3076: Test failed: doc_disp == NULL > webbrowser: unhandled exception c0000005 at 004033D1

July 16, 2013

Re: Manpage patch, please review

by André Hentschel

Am 16.07.2013 19:59, schrieb Julian Rüger: > Hi all! > > While working on the translation of the (main) manpage, I noticed a few > issues in the English version and started working on a patch. That was > quite some time ago, I had little spare time lately and didn't get > around to finish and send it in. So I figured I just take what I have > now and ask you guys for comments. I appreciate any remarks or > suggestions. > > Thanks, > Julian > > Notes: > > I had a change similar to Frédéric's, mentioning wine can run 64-bit > programs now. He was quicker and I like his wording better. I had > something like "[...]or Win64 executable (if your version of wine was > compiled with 64-bit support)." > I guess that would be more confusing to people using their distro's wine > packages and people compiling their own wine know that anyway. > Do you agree or do you think it's better to be more specific? Frédéric has done it quite good, because it's committed :) Further you can't compile Wine in 64-bit mode on 32-bit that easily, and you can't run it, your version doesn't handle that. > CUI -> CLI: > According to Google and Wikipedia, CLI is more common. i'd say that's analogue to IMAGE_SUBSYSTEM_WINDOWS_CUI > -.BR @bindir@/wineserver , > +.IR @bindir@/wineserver , > and following, similar changes: > > This is the way it is formatted in the wineserver manpage. I noticed > there is no uniform style across our manpages, so we should have a > guideline. > Should paths be bold or italic/underlined? Not sure, are there other guidelines out there we can use?

July 16, 2013

Manpage patch, please review

by Julian Rüger

Hi all! While working on the translation of the (main) manpage, I noticed a few issues in the English version and started working on a patch. That was quite some time ago, I had little spare time lately and didn't get around to finish and send it in. So I figured I just take what I have now and ask you guys for comments. I appreciate any remarks or suggestions. Thanks, Julian Notes: I had a change similar to Frédéric's, mentioning wine can run 64-bit programs now. He was quicker and I like his wording better. I had something like "[...]or Win64 executable (if your version of wine was compiled with 64-bit support)." I guess that would be more confusing to people using their distro's wine packages and people compiling their own wine know that anyway. Do you agree or do you think it's better to be more specific? CUI -> CLI: According to Google and Wikipedia, CLI is more common. -.BR @bindir@/wineserver , +.IR @bindir@/wineserver , and following, similar changes: This is the way it is formatted in the wineserver manpage. I noticed there is no uniform style across our manpages, so we should have a guideline. Should paths be bold or italic/underlined?

July 16, 2013

Re: loader: Indicate wine can run 64-bit apps in manpage

by Frédéric Delanoy

On Tue, Jul 16, 2013 at 4:57 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > --- > loader/wine.man.in | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) Please ignore this patch: I accidentally resent it. Sorry about the noise. Frédéric

July 16, 2013

Re: po: Update Turkish translation (second try)

by Francois Gouget

-<<<<<<< HEAD -"PO-Revision-Date: 2013-07-13 04:49+0200\n" -======= -"PO-Revision-Date: 2013-07-04 00:10+0200\n" ->>>>>>> 598685e6c5992355de35b4345e91eb4e50b9f07e +"PO-Revision-Date: 2013-07-13 05:00+0200\n" [...] -#: attrib.rc:27 cmd.rc:322 +#: attrib.rc:27 cmd.rc:325 These look wrong: there is currently no conflict in the checked-in PO file and there should not be any line-number changes in the patch. So it won't apply to the current Git repository. Something must have happened when you rebased or generated the diff. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

July 16, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Qian Hong

On Mon, Jul 15, 2013 at 7:02 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > This looks like a better approach, yes Sorry, this approach doesn't work as I expected, further investigation show that posted messages would be processed before input messages, msdn confirms it: --- quote --- If no filter is specified, messages are processed in the following order: Sent messages Posted messages Input (hardware) messages and system internal events Sent messages (again) WM_PAINT messages WM_TIMER messages --- quote --- msdn also said: To retrieve input messages before posted messages, use the wMsgFilterMin and wMsgFilterMaxparameters. However, even we can change the filter in our test, native Popup WndProc still receive posted messages before input message because it has its own message loop and we can't (and of cause we shouldn't) change it. This situation run out of my head, I can't find any easy way to fix it, I doubt if there is any way better than the original patch (patch 97161, pending). I'm open to any suggestion, thanks! If no better solution I hope patch 97161 is acceptable. -- Regards, Qian Hong - http://www.codeweavers.com

July 16, 2013

Re: ntdll: Tests for RtlHashUnicodeString()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +#include "ddk/wdm.h" > > Please don't do that, this breaks compilation with PSDK headers. If you need > > some specific definitions, types or API prototypes - replicate them in the test > > itself. > What breaks exactly? The fact that PSDK doesn't have DDK headers by > default or something specific about this particular header? If it's a > missing header I don't see a problem with installing DDK. Also kernel32 > tests have include from ddk subdir too and I don't even have this header > installed with DDK 7.something, is it broken for you too? Yes, it's the missing ddk subdirectory which breaks things. Installing a DDK was never a requirement for compiling Wine tests under Windows, and I hope there will never be one. The only kernel32 test that has #include "ddk/..." is volume.c, that can't be an excuse to adding more broken tests, it's better to fix volume.c instead. I'd suggest to try compiling Wine tests under Windows with a PSDK compiler using Wine and PSDK headers as a simple exercise. Once this works, try to add DDK headers as another complexity level, then decide whether you really would like to add another hoop to jump through. Compilation with a PSDK tool chain and PSDK headers is an extremely valuable thing for testing, it would be a pity to lose it. -- Dmitry.

July 16, 2013

Re: ntdll: Tests for RtlHashUnicodeString()

by Nikolay Sivov

On 7/16/2013 09:47, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> +#include "ddk/wdm.h" > Please don't do that, this breaks compilation with PSDK headers. If you need > some specific definitions, types or API prototypes - replicate them in the test > itself. What breaks exactly? The fact that PSDK doesn't have DDK headers by default or something specific about this particular header? If it's a missing header I don't see a problem with installing DDK. Also kernel32 tests have include from ddk subdir too and I don't even have this header installed with DDK 7.something, is it broken for you too?

July 16, 2013

Re: ntdll: Tests for RtlHashUnicodeString()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +#include "ddk/wdm.h" Please don't do that, this breaks compilation with PSDK headers. If you need some specific definitions, types or API prototypes - replicate them in the test itself. -- Dmitry.

July 16, 2013

Re: riched20: ITextDocument stubs for ITextServices

by Frédéric Delanoy

On Sun, Jul 14, 2013 at 3:50 AM, Tiger Soldier <tigersoldi(a)gmail.com> wrote: > This patch implements a standalone stub of ITextDocument. The stub is > currently used in txtsrv.c and will replace the stub in richole.c > You have to use your real name when submitting patches to wine-patches. Frédéric

July 15, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > On Fri, Jul 12, 2013 at 3:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Adding sleeps to work around timing issues is usually suspicious, > > Hello, how about this one? This looks like a better approach, yes (make sure to fix your tab size before submitting though, the indentation is messed up). -- Alexandre Julliard julliard(a)winehq.org

July 15, 2013

Re: How to configure C++ implements in wine?

by Charles Davis

On Jul 15, 2013, at 1:00 AM, 中川祥 wrote: > I'm working at User Access Logging API for Windows8. > It need C++ style coding. > How can I solve it? Those aren't C++ classes. Those are MOF classes. They're used with WMI. I'm sure you've seen how we implement WMI (cf. dlls/wbemprox). They do not need to be written in C++. Chip

July 15, 2013

How to configure C++ implements in wine?

by 中川祥

I'm working at User Access Logging API<http://msdn.microsoft.com/en-us/library/windows/desktop/hh437524(v=vs.85).a…> for Windows8. It need C++ style coding. How can I solve it?

July 15, 2013

Re: [docs 2/3] winedev: Use hyphen in bitness

by Frédéric Delanoy

On Sun, Jul 14, 2013 at 7:41 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > en/winedev-architecture.sgml | 56 ++++++++++++++++++++++---------------------- > en/winedev-debugger.sgml | 10 ++++---- > en/winedev-kernel.sgml | 24 +++++++++---------- > en/winedev-multimedia.sgml | 36 ++++++++++++++-------------- > 4 files changed, 63 insertions(+), 63 deletions(-) > - (an int is 16 bit in 16-bit and 32 bits in 32-bit, pointers > + (an int is 16-bit in 16-bit and 32-bits in 32-bit, pointers This part sounds a bit weird... also, one is in plural with the other is in singular form. Probably would benefit from a sentence reorganization. Frédéric

July 14, 2013

Re: ieframe: Use SHANDLE_PTR in IWebBrowserApp::get_HWND.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26282 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2631: Test failed: expected GetOverridesKeyPath webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3076: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 004033D1

July 14, 2013

Re: po: Tweak the French 'broadcast' and 'unicast' translations.

by Frédéric Delanoy

On Sat, Jul 13, 2013 at 12:36 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Fri, 12 Jul 2013, Frédéric Delanoy wrote: > [...] >> The "grand dictionnaire terminologique" >> (http://gdt.oqlf.gouv.qc.ca/Resultat.aspx) gives > > The thing is this dictionary is not actually French... it's Québécois. > One of the differences is that Québécois is a lot more strict about not > using English words, ever. Well it's not only this dictionary which tells that. I've seen it used in other dictionaries and networking books too. > > [...] >> BTW to broadcast = diffuser > > And also 'télédiffuser', 'émettre', 'transmettre', 'annoncer', > 'téléviser', 'émission', etc. > >> I may agree with unicast but the "diffusion" and "multidiffusion" seem OK to me > > It's the opposite for me. At least I can recognise that 'monodiffusion' > being a made up word it must have something to do with networking. But > just plain 'diffusion' can be used in so many contexts.. Well the context of networking is pretty clear here: networking (netstat/ipconfig/...), certainly not television... Frédéric

July 13, 2013

Re: po: Tweak the French 'broadcast' and 'unicast' translations.

by Francois Gouget

On Fri, 12 Jul 2013, Frédéric Delanoy wrote: [...] > The "grand dictionnaire terminologique" > (http://gdt.oqlf.gouv.qc.ca/Resultat.aspx) gives The thing is this dictionary is not actually French... it's Québécois. One of the differences is that Québécois is a lot more strict about not using English words, ever. [...] > BTW to broadcast = diffuser And also 'télédiffuser', 'émettre', 'transmettre', 'annoncer', 'téléviser', 'émission', etc. > I may agree with unicast but the "diffusion" and "multidiffusion" seem OK to me It's the opposite for me. At least I can recognise that 'monodiffusion' being a made up word it must have something to do with networking. But just plain 'diffusion' can be used in so many contexts.. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

July 12, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Qian Hong

On Fri, Jul 12, 2013 at 3:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Adding sleeps to work around timing issues is usually suspicious, Hello, how about this one? -- Regards, Qian Hong - http://www.codeweavers.com

July 12, 2013

Re: po: Tweak the French 'broadcast' and 'unicast' translations.

by Frédéric Delanoy

On Fri, Jul 12, 2013 at 10:29 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > This is particularly true among programmers/network admins.. (who use a lot > of technical and english terms) but casual users also tend to reject the > always-translate-into-french idea. Quoting an article that made me laugh so > hard I bookmarked it : > > "Arrivé sur le World Wide Web, je me connecte à un proxy quand Mac OS X > m'informe par l'intermédiaire d'une pop-up qu'une opération de phishing > pourrait bien être en cours. Dans le même temps, j'ai l'impression que ma > zone de swap sature : une nouvelle fois, je vais devoir dumper la base de > données sur laquelle je travaille [..] puis rebooter ma machine. <snip>" > > becomes > > "Arrivé sur la Toile d'araignée mondiale, je me connecte à un serveur > mandataire quand mon système d'exploitation exclusif m'informe par > l'intermédiaire d'une fenêtre intruse qu'une opération de filoutage pourrait > bien être en cours. Dans le même temps, j'ai le sentiment que ma zone de > permutation sature : une nouvelle fois, je vais devoir clicher la base de > données sur laquelle je travaille [..] puis réamorcer ma machine." > > [If you don't laugh, you should at least be smiling now] Well that's an extreme case, but often people use English (a.k.a. franglais) when not necessary to be seen as "cool", e.g. meeting has a perfectly usable French translation, "réunion". The above looks more like automatic google translation. Frédéric

July 12, 2013

Re: po: update Simplified Chinese translation

by Qian Hong

Thanks Francois. On Fri, Jul 12, 2013 at 10:41 PM, Francois Gouget <fgouget(a)free.fr> wrote: > | Colon > | * Software localization: Use English colon (:) in Software > | localization. A single byte space should be left between the > | English colon and the subsequent characters (Chinese full-width > | punctuation marks are excluded). > > For documentation they say to use a double byte colon. So it seems like > our PO files should actually be using single-byte colons everywhere. > Does this make sense? I'm fine with replacing existent double byte colon to single byte one in the Simplified Chinese translation of Wine UI, CC'ed previous Wine Simplified Chinese major translator. If no opposition I would suggest to follow the Microsoft's Simplified Chinese Style Guide. -- Regards, Qian Hong - http://www.winehq.org

July 12, 2013

Re: po: Tweak the French 'broadcast' and 'unicast' translations.

by GOUJON Alexandre

On 07/12/2013 07:30 PM, Frédéric Delanoy wrote: > On Fri, Jul 12, 2013 at 4:33 PM, Francois Gouget <fgouget(a)free.fr> wrote: >> --- >> >> Surprisingly enough (for me) the existing translations match the term >> used in Microsoft's Terminology file: >> "broadcast address" -> "adresse de diffusion" >> "broadcast" -> "diffusion" >> "multicast" -> "multidiffusion" >> "unicast" -> "monodiffusion" >> >> https://www.microsoft.com/Language/en-US/Terminology.aspx >> >> But I still don't think they're good translations. I find 'diffusion' >> way too general and vague. Reading it I would certainly not make the >> link with broadcast, even in the domain of networking. Similarly I don't >> think 'monodiffusion' would be readily understood. >> >> So I'm more enclined to follow Wikipedia which uses the untranslated >> terms as the title of their French articles: > Well they're just untranslated... you said it > > The "grand dictionnaire terminologique" > (http://gdt.oqlf.gouv.qc.ca/Resultat.aspx) gives > broadcast -> diffusion (générale) > multicast -> multidiffusion / diffusion groupée (beurk) > monocast -> envoi individuel > > http://glossaire.traduc.org/ (used for manpages/howtos) gives > broadcast -> diffusion > multicast -> multidiffusion > unicast -> unicast > > BTW to broadcast = diffuser > > I may agree with unicast but the "diffusion" and "multidiffusion" seem OK to me And that's why some french people (including me) prefer taking their networking (Cisco and the like) exam in english rather than in their native language : sentences look Google-translated and their meaning is unclear until you "think" in english. This is particularly true among programmers/network admins.. (who use a lot of technical and english terms) but casual users also tend to reject the always-translate-into-french idea. Quoting an article <http://www.clubic.com/actualite-298446-haro-phishing-place-filoutage.html> that made me laugh so hard I bookmarked it : "Arrivé sur le World Wide Web, je me connecte à un proxy quand Mac OS X m'informe par l'intermédiaire d'une pop-up qu'une opération de phishing pourrait bien être en cours. Dans le même temps, j'ai l'impression que ma zone de swap sature : une nouvelle fois, je vais devoir dumper la base de données sur laquelle je travaille [..] puis rebooter ma machine. <snip>" becomes "Arrivé sur la Toile d'araignée mondiale, je me connecte à un serveur mandataire quand mon système d'exploitation exclusif m'informe par l'intermédiaire d'une fenêtre intruse qu'une opération de filoutage pourrait bien être en cours. Dans le même temps, j'ai le sentiment que ma zone de permutation sature : une nouvelle fois, je vais devoir clicher la base de données sur laquelle je travaille [..] puis réamorcer ma machine." [If you don't laugh, you should at least be smiling now] As to know whether you should keep them untranslated or not, I think you should translate them anyway because translating basically means 'using native words to describe and understand what was written in an other language' so use the "frenchiest" version of each word .. but that's only my point of view which is of course, debatable.

July 12, 2013

Re: po: Tweak the French 'broadcast' and 'unicast' translations.

by Frédéric Delanoy

On Fri, Jul 12, 2013 at 4:33 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > > Surprisingly enough (for me) the existing translations match the term > used in Microsoft's Terminology file: > "broadcast address" -> "adresse de diffusion" > "broadcast" -> "diffusion" > "multicast" -> "multidiffusion" > "unicast" -> "monodiffusion" > > https://www.microsoft.com/Language/en-US/Terminology.aspx > > But I still don't think they're good translations. I find 'diffusion' > way too general and vague. Reading it I would certainly not make the > link with broadcast, even in the domain of networking. Similarly I don't > think 'monodiffusion' would be readily understood. > > So I'm more enclined to follow Wikipedia which uses the untranslated > terms as the title of their French articles: Well they're just untranslated... you said it The "grand dictionnaire terminologique" (http://gdt.oqlf.gouv.qc.ca/Resultat.aspx) gives broadcast -> diffusion (générale) multicast -> multidiffusion / diffusion groupée (beurk) monocast -> envoi individuel http://glossaire.traduc.org/ (used for manpages/howtos) gives broadcast -> diffusion multicast -> multidiffusion unicast -> unicast BTW to broadcast = diffuser I may agree with unicast but the "diffusion" and "multidiffusion" seem OK to me

July 12, 2013

Re: po: Some Franch translation tweaks.

by Francois Gouget

On Fri, 12 Jul 2013, Frédéric Delanoy wrote: > On Fri, Jul 12, 2013 at 1:16 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > --- > > po/fr.po | 14 ++++++++------ > > 1 file changed, 8 insertions(+), 6 deletions(-) > > There's a typo in the commit message (you probably spotted it already). Yes. I hate when that happens. > > msgstr "" > > "PAUSE affiche un message à l'écran demandant à l'utilisateur d'appuyer sur " > > -"une touche.\n" > > +"une\n" > > +"touche.\n" > > This is probably not needed Most usage messages and the PAUSE one in particular, wrap at 80-columns so that words are not cut in the middle. I'd much prefer if the wrapping was done in software but in the meantime we have to do it by hand. So here I'm just trying to follow that rule. > > msgid "Drive Mapping" > > -msgstr "Assignation de lecteur" > >+msgstr "Dossier cible" > > Are you sure about this one? Maybe the original should be changed as > well in this case... Yes I think it should but the English strings are kinda frozen right now. Otherwise I'd propose 'Target folder'. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

July 12, 2013

Re: po: update Simplified Chinese translation

by Francois Gouget

I'll take this opportunity to note that Microsoft's Simplified Chinese Style Guide says: | Colon | * Software localization: Use English colon (:) in Software | localization. A single byte space should be left between the | English colon and the subsequent characters (Chinese full-width | punctuation marks are excluded). For documentation they say to use a double byte colon. So it seems like our PO files should actually be using single-byte colons everywhere. Does this make sense? http://download.microsoft.com/download/4/c/a/4ca95933-3496-4793-9d77-a89b60… As an additional not, I don't think this is grounds for rejecting this patch given that it is consistent with existing translations. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

July 12, 2013

Re: po: Some Franch translation tweaks.

by Frédéric Delanoy

On Fri, Jul 12, 2013 at 1:16 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > po/fr.po | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) There's a typo in the commit message (you probably spotted it already). > msgstr "" > "PAUSE affiche un message à l'écran demandant à l'utilisateur d'appuyer sur " > -"une touche.\n" > +"une\n" > +"touche.\n" This is probably not needed > msgid "Drive Mapping" > -msgstr "Assignation de lecteur" >+msgstr "Dossier cible" Are you sure about this one? Maybe the original should be changed as well in this case... Frédéric

July 12, 2013

Re: po: Fix the French DEL, ERASE, RD and RMDIR usage messages.

by Frédéric Delanoy

On Fri, Jul 12, 2013 at 12:34 PM, Francois Gouget <fgouget(a)free.fr> wrote: > msgid "DEL <filename> deletes a file or set of files.\n" > -msgstr "DEL <fichiers> efface un fichier ou un groupe de fichiers.\n" > +msgstr "DEL <fichier> efface un fichier ou un groupe de fichiers.\n" "fichiers" indicate it can be any number of files, replacing by the singular form doesn't (one may think only one file is deletable per command) If you absolutely want the same singular ou plural form, the English msgid it what should be changed instead IMO Same remark for your ERASE diff hunk. Regards, Frédéric

July 12, 2013

Re: po: Fix some typography and linefeed issues in the Turkish translation.

by Volkan Gezer

2013/7/12 Francois Gouget <fgouget(a)free.fr>: > On Thu, 11 Jul 2013, Volkan Gezer wrote: > [...] >> Thank you for modifications. I think the only problem is: >> >> #: cryptui.rc:38 >> msgid " to " >> -msgstr " bitişi: " >> +msgstr " bitişi " >> >> which we should keep ":" for a meaningful sentence structure. Hasan >> should also correct me if I am wrong. > > Ok. That seems a bit strange but probably less strange than the way the > code builds this string :-( It seems it does it does it this way to put > parts of it in bold. > It would be nice to have the complete string, but anyway this is also not a problem :). > I've added an exception for it and I'm resending the rest of the patch. > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Stolen from an Internet user: > "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

July 12, 2013

Re: po: update Simplified Chinese translation

by Jactry Zeng

Thanks Qian Hong! I sent a newer: http://source.winehq.org/patches/data/97285 -- Regards, Jactry Zeng

July 12, 2013

Re: po: update Simplified Chinese translation

by Qian Hong

#: winerror.mc:3016 -#, fuzzy msgid "Unknown interface.\n" -msgstr "不明来源。\n" +msgstr "未知界面。\n" Please keep persistent for the translation of 'interface'. Here 'Unknown interface.' is used with RPC_S_UNKNOWN_IF, should be translate to '接口' as well as other place. #: winecfg.rc:260 msgid "Voice output device:" -msgstr "" +msgstr "语言输出设备：" #: winecfg.rc:261 msgid "Input device:" @@ -12313,7 +12281,7 @@ msgstr "输入设备：" #: winecfg.rc:262 msgid "Voice input device:" -msgstr "" +msgstr "语音输入设备：" Please keep persistent for the translation of 'voice', it seems like a typo here, one translated to 语言 while the other translated to '语音'. #: winerror.mc:186 msgid "Sharing violation.\n" -msgstr "" +msgstr "非法共享。\n" #: winerror.mc:191 -#, fuzzy msgid "Lock violation.\n" -msgstr "位置。\n" +msgstr "非法锁定。\n" #: winerror.mc:696 -#, fuzzy msgid "Cancel violation.\n" -msgstr "信息。\n" +msgstr "非法取消。\n" The above three reference to: ERROR_SHARING_VIOLATION （共享冲突？） ERROR_LOCK_VIOLATION （锁冲突？） ERROR_CANCEL_VIOLATION （？） http://support.microsoft.com/kb/316609/en-us http://support.microsoft.com/kb/2698155/en-us http://support.microsoft.com/kb/155011/en-us I'm not sure your translation is correct, they are tricky to translate, for ERROR_CANCEL_VIOLATION, even the original English version is hard to understand :( maybe keep the English version is not a bad idea if there is no better alternative so far. Thanks for the work! On Fri, Jul 12, 2013 at 8:09 PM, Jactry Zeng <jactry92(a)gmail.com> wrote: > > > > -- Regards, Qian Hong - http://www.winehq.org

July 12, 2013

po: update Simplified Chinese translation

by Jactry Zeng

July 12, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Qian Hong

On Fri, Jul 12, 2013 at 7:11 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > do { > sleeping; > } while (sent_msg match received_msg or slept too long) typo, should be: while (sent_msg does not match received_msg && haven't sleep too long) -- Regards, Qian Hong - http://www.codeweavers.com

July 12, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Qian Hong

Hello, Thanks for the feedback. On Fri, Jul 12, 2013 at 3:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Adding sleeps to work around timing issues is usually suspicious, > particularly since the code is already supposed to wait. You'd have to > explain why that's not sufficient. Trying to explain why the sleeping in the while loop is not sufficient: The attached patch do two things: 1. - { INPUT_KEYBOARD, {{0}}, {VK_F10, 0}, FALSE, FALSE }, + { INPUT_KEYBOARD, {{0}}, {VK_F10, 0}, TRUE, FALSE }, Change the expected bMenuVisible from FALSE to TRUE in a passed test ( test 19 ) If the original test is correct, then after I change FALSE to TRUE, it should fail now. 2. Added some trace on sleeping time. The test result is here: https://testbot.winehq.org/JobDetails.pl?Key=26260 Looking at the test result, some times test 19 failed as expected, some times test 19 passed, such as https://testbot.winehq.org/JobDetails.pl?Key=26260&log_207=1#k207 --- snip --- test 19: Are we going to sleep? test 19: total sleeped time: 0 WARNING! sleeped time is zero! --- snip --- The reason that total sleeping time equal to zero is, (menu_tests[19].bMenuVisible == bMenuVisible) is true at the beginning, so the while loop is totally skipped, and we get a fake passed test result. Due to the above reason, a better while loop is as below: do { if (elapsed > 200) break; elapsed += 20; Sleep(20); } while (menu_tests[i].bMenuVisible != bMenuVisible) However, even that is not sufficient. For some complex test, (menu_tests[19].bMenuVisible == bMenuVisible) could become true after receiving the first input message but before receiving the last input message, so we get a fake passed test result as well. That is why I add a Sleep(100) after the while loop. Does my explaining make sense? I have another idea: 1. counting the amount of the received messages in the WndProc callback: case WM_KEYDOWN: case WM_KEYDOWN: case WM_SYSKEYDOWN: /* case WM_MOUSEMOVE: */ // Don't count WM_MOUSEMOVE case WM_LBUTTONDOWN: case XXX: case YYY: ... received_msg++; 2. and counting the amount of sent messages in send_key and click_menu, such like: static void send_key(WORD wVk) { .... sent_msg++; } 3. finally change the while loop to: do { sleeping; } while (sent_msg match received_msg or slept too long) Would you want me submit this version? Thanks for reviewing. -- Regards, Qian Hong - http://www.codeweavers.com

July 12, 2013

Re: ole32: Tests for CLSIDFromProgID() and ProgIDFromCLSID() regarding activation context

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26261 Your paranoid android. === W2KPROSP4 (32 bit compobj) === compobj: unhandled exception c0000005 at 00000000

July 12, 2013

Re: cmd: Fix a usage message: the % must be doubled for FOR variables. (resend)

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > The usage message was in fact documenting an old Wine bug. > --- > > The attempt did not apply, probably because I had other changes in my > tree. Hopefully this one will work. > > > I'm reluctant to change messages at this stage as it's going to cause > fuzzying of the translations, but given that this message is plain wrong > I think it's warranted. I'd suggest to simply remove the sentence, and remove it in translations too so that we don't need to invalidate all of them. -- Alexandre Julliard julliard(a)winehq.org

July 12, 2013

Re: po: Fix some typography and linefeed issues in the Turkish translation.

by Francois Gouget

On Thu, 11 Jul 2013, Volkan Gezer wrote: [...] > Thank you for modifications. I think the only problem is: > > #: cryptui.rc:38 > msgid " to " > -msgstr " bitişi: " > +msgstr " bitişi " > > which we should keep ":" for a meaningful sentence structure. Hasan > should also correct me if I am wrong. Ok. That seems a bit strange but probably less strange than the way the code builds this string :-( It seems it does it does it this way to put parts of it in bold. I've added an exception for it and I'm resending the rest of the patch. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

July 12, 2013

Re: wbemprox: Implement Win32_OperatingSystem.LocalDateTime. (try 2)

by Sylvain Petreolle

De : Bruno Jesus <00cpxxx(a)gmail.com> À : wine-devel(a)winehq.org; spetreolle(a)yahoo.fr >Envoyé le : Jeudi 11 juillet 2013 17h14 >Objet : Re: wbemprox: Implement Win32_OperatingSystem.LocalDateTime. (try 2) > > >On Thu, Jul 11, 2013 at 11:19 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: >> --- >> dlls/wbemprox/builtin.c | 30 ++++++++++++++++++++++++++++++ >> 1 file changed, 30 insertions(+) >> >> diff --git a/dlls/wbemprox/builtin.c b/dlls/wbemprox/builtin.c >> index 9e2369a..5b7674e 100644 >> --- a/dlls/wbemprox/builtin.c >> +++ b/dlls/wbemprox/builtin.c > >> @@ -1774,6 +1778,31 @@ static WCHAR *get_lastbootuptime(void) >> + >> + GetLocalTime(&st); >> + Status = GetTimeZoneInformation(&tzi); >> + >> + if(Status == TIME_ZONE_ID_INVALID) return NULL; > >Aren't you leaking ret here? Maybe you could swap this check with the >memory allocation. >You are right. I will post a new version. >> + sprintfW( ret, fmtW, st.wYear, st.wMonth, st.wDay, st.wHour, st.wMinute, st.wSecond, st.wMilliseconds * 1000, -Bias); > >Is it ok for the + sign to the fixed in the format? >The + sign ensures that the sign appears with positive and negative bias. TZ=America/New_York wine wmic os get localdatetime TZ=Europe/Berlin wine wmic os get localdatetime Best wishes, >Bruno > > Kind regards, Sylvain Petreolle

July 12, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > Hello, > > This patch is marked as pending, is there anything I can improve? Did > the test results in [1] and [2] help? Adding sleeps to work around timing issues is usually suspicious, particularly since the code is already supposed to wait. You'd have to explain why that's not sufficient. -- Alexandre Julliard julliard(a)winehq.org

July 11, 2013

Re: wbemprox: Implement Win32_OperatingSystem.LocalDateTime. (try 2)

by Bruno Jesus

On Thu, Jul 11, 2013 at 11:19 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: > --- > dlls/wbemprox/builtin.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/dlls/wbemprox/builtin.c b/dlls/wbemprox/builtin.c > index 9e2369a..5b7674e 100644 > --- a/dlls/wbemprox/builtin.c > +++ b/dlls/wbemprox/builtin.c > @@ -1774,6 +1778,31 @@ static WCHAR *get_lastbootuptime(void) > + > + GetLocalTime(&st); > + Status = GetTimeZoneInformation(&tzi); > + > + if(Status == TIME_ZONE_ID_INVALID) return NULL; Aren't you leaking ret here? Maybe you could swap this check with the memory allocation. > + sprintfW( ret, fmtW, st.wYear, st.wMonth, st.wDay, st.wHour, st.wMinute, st.wSecond, st.wMilliseconds * 1000, -Bias); Is it ok for the + sign to the fixed in the format? Best wishes, Bruno

July 11, 2013

Re: po: Czech - corrected omission of some newline marks

by Alexandre Julliard

Pavel Borecki <pavel.borecki(a)gmail.com> writes: > @@ -3060,7 +3122,7 @@ > > #: hhctrl.rc:62 winhlp32.rc:31 > msgid "&Print..." > -msgstr "&Tisknout..." > +msgstr "&Tisknout" Please keep the three dots, that's apparently the standard. -- Alexandre Julliard julliard(a)winehq.org

July 11, 2013

Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.

by Qian Hong

Hello, This patch is marked as pending, is there anything I can improve? Did the test results in [1] and [2] help? Thanks for any feedback! [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 On Wed, Jul 3, 2013 at 2:45 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > Hello, > > Current menu test code may hide some failure tests [1], with the attached > patch, all failure tests could be detected [2]. > > > [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 > [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 > > > --- > dlls/user32/tests/menu.c | 1 + > 1 file changed, 1 insertion(+) > > > > > -- Regards, Qian Hong - http://www.codeweavers.com

July 10, 2013

Re: winmm: Standardize and simplify two error messages.

by Andrew Eikum

On Wed, Jul 10, 2013 at 10:42:05AM +0200, Francois Gouget wrote: > We don't have a MIDI Mapper configuration applet so don't tell the user to use it. > --- > > Or if we do, how does one get to it? I did not find anything in > winecfg.exe, nor in control.exe (the Control Panel). > > -MIDIERR_NODEVICE, "The current MIDI Mapper setup refers to a MIDI device that is not installed on the system. Use MIDI Mapper to edit the setup." I think it's meant to refer to the "MIDI Mapper" device, which is configurable through the registry: http://wiki.winehq.org/MIDI I think your change is clearly an improvement. Andrew

July 10, 2013

Re: Should we translate the prompt

by Frédéric Delanoy

On Mon, Jul 8, 2013 at 12:16 PM, Francois Gouget <fgouget(a)free.fr> wrote: > On Sun, 7 Jul 2013, Jactry Zeng wrote: > [...] >> msgid "%1? (Yes|No)\n" > [...] >> When I discuss this with Qian Hong, he give a better idea. We may can just >> make the origin text more apropos, just like: >> msgid "%1? (Y)es|(N)o\n" > > I think this would look odd in English and that the original string is > better. Note the shortcuts/hotkeys are dependent on the "Yes key" and "No key", so they should be kept consistent e.g. in French #: cmd.rc:318 xcopy.rc:40 msgctxt "Yes key" msgid "Y" msgstr "O" #: cmd.rc:319 xcopy.rc:41 msgctxt "No key" msgid "N" msgstr "N" #: cmd.rc:354 msgid " (Yes|No)" msgstr " (Oui|Non)" Similar for File, Directory, etc. #: xcopy.rc:43 msgctxt "File key" msgid "F" msgstr "F" #: xcopy.rc:44 msgctxt "Directory key" msgid "D" msgstr "R" Frédéric

July 10, 2013