Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
Dmitry Timoshkov dmi...@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 julli...@winehq.org
Re: riched20: ITextDocument stubs for ITextServices (retry)
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 000..02579b2
--- /dev/null
+++ b/dlls/riched20/txtdoc.h
How about using an existing header?
Thanks,
Jacek
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
Alexandre Julliard julli...@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.
Re: [1/2] iphlpapi: Add support for the listener and connection classes in GetExtendedTcpTable.
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 c005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c005 at 7596A09A === WVISTAX64 (64 bit iphlpapi) === Timeout
Re: [2/2] iphlpapi: Add partial support for the module classes in GetExtendedTcpTable and GetExtendedUdpTable.
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 c005 at 74A19E2F === W2K8SE (32 bit iphlpapi) === iphlpapi: unhandled exception c005 at 7596A09A === W7PROX64 (32 bit iphlpapi) === iphlpapi: unhandled exception c005 at 77E03915 === WVISTAX64 (64 bit iphlpapi) === Timeout === W7PROX64 (64 bit iphlpapi) === No test summary line found
Re: [1/2] wininet: Ignore INTERNET_FLAG_NO_CACHE_WRITE only for GET requests.
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 c005 at 7722EDEA
Re: [2/2] wininet: Handle NULL input string in str_to_buffer.
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 c005 at 00495D94
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@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 julli...@winehq.org
Re: [1/2] msxml3: Implement IMXAttributes_removeAttributes()
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
Re: Possibility of adding a new patch status
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.
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
Alexandre Julliard julli...@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.
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@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 julli...@winehq.org
Call for Windows tests
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
Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.
Forgot to say, as described in the last post, this patch doesn't kill the culprit, please reject the patch, thanks.
Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.
Hello Nikolay, On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov bungleh...@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=26499log_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=0001 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(0008) ret=09ea3545 /* 0x0008 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
Re: Possibility of adding a new patch status
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.
Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller kgbric...@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
diff --git a/dlls/d3dx9_36/tests/shader.c b/dlls/d3dx9_36/tests/shader.c
index 42c1455..be4b9cd 100644
--- a/dlls/d3dx9_36/tests/shader.c
+++ b/dlls/d3dx9_36/tests/shader.c
@@ -5585,6 +5585,436 @@ static const struct registerset_test registerset_test_bigvec_float[] =
0x42800123, 0x43200123, 0x43600123}},
};
+/*
+ * fxc.exe /Tvs_3_0
+ */
+#if 0
+struct {int n; float f; bool b;} sb = {50, 7.6, 1};
+struct {bool b1; float f1; int n1;} sn = {1, 8.3, 51};
+struct {float f2; int n2; bool b2;} snb = {6.1, 53, 0};
+struct {float f3; bool b3; int n3;} sbn = {5.2, 1, 52};
+struct {bool b4; int n4; float f4;} sbnf = {1, 54, 4.3};
+struct {bool b5; int n5; float f5;} sbnf2 = {0, 55, 4.4};
+struct {float f6; bool b6; int n6;} sbnf3 = {8.7, 1, 56};
+float4 main(float4 pos : POSITION) : POSITION
+{
+float4 tmp = 0;
+int i;
+if (sb.b) for (i = 0; i sn.n1; i++) tmp.x += pos.z;
+else if (snb.b2) for (i = 0; i snb.n2; i++) tmp.y += pos.y;
+else if (sbn.b3) for (i = 0; i sbn.n3; i++) tmp.y += pos.y;
+else if (sbnf.b4) for (i = 0; i sbnf.n4; i++) tmp.y += pos.y * sbnf.f4;
+else if (sbnf2.f5) for (i = 0; i sbnf2.n5; i++) tmp.y += pos.y;
+else if (sbnf3.n6)
+{
+tmp.y += pos.y;
+for (i = 0; i sbnf3.n6; i++) tmp.x += pos.x;
+}
+return tmp;
+}
+#endif
+static const DWORD registerset_blob_mixed_struct[] =
+{
+0xfffe0300, 0x0103fffe, 0x42415443, 0x001c, 0x03d7, 0xfffe0300, 0x000a, 0x001c,
+0x0100, 0x03d0, 0x00e4, 0x, 0x0003, 0x013c, 0x014c, 0x0158,
+0x0006, 0x0003, 0x0180, 0x014c, 0x0190, 0x0002, 0x0003, 0x01b8,
+0x01c8, 0x0190, 0x0009, 0x0002, 0x01b8, 0x014c, 0x01f8, 0x00030002,
+0x0003, 0x0220, 0x0230, 0x01f8, 0x00060001, 0x0002, 0x0220, 0x0260,
+0x0290, 0x00060002, 0x0003, 0x02b8, 0x02c8, 0x0290, 0x00030001, 0x0003,
+0x02b8, 0x02f8, 0x0328, 0x0001, 0x0003, 0x034c, 0x035c, 0x038c,
+0x0003, 0x0003, 0x03b4, 0x03c4, 0x6e006273, 0xababab00, 0x0002, 0x00010001,
+0x0001, 0x, 0xabab0066, 0x0003, 0x00010001, 0x0001, 0x, 0xabab0062,
+0x0001, 0x00010001, 0x0001, 0x, 0x00e7, 0x00ec, 0x00fc, 0x0100,
+0x0110, 0x0114, 0x0005, 0x00030001, 0x00030001, 0x0124, 0x, 0x,
+0x, 0x006e6273, 0x62003366, 0x336e0033, 0xababab00, 0x015c, 0x0100, 0x015f,
+0x0114, 0x0162, 0x00ec, 0x0005, 0x00030001, 0x00030001, 0x0168, 0x666e6273,
+0x00346200, 0x6600346e, 0xabab0034, 0x0195, 0x0114, 0x0198, 0x00ec, 0x019b,
+0x0100, 0x0005, 0x00030001, 0x00030001, 0x01a0, 0x3f80, 0x, 0x,
+0x, 0x4258, 0x, 0x, 0x, 0x408a, 0x, 0x,
+0x, 0x666e6273, 0x35620032, 0x00356e00, 0xab003566, 0x01fe, 0x0114, 0x0201,
+0x00ec, 0x0204, 0x0100, 0x0005, 0x00030001, 0x00030001, 0x0208, 0x,
+0x, 0x, 0x, 0x425c, 0x, 0x, 0x, 0x408d,
+0x, 0x, 0x, 0x, 0x, 0x0001, 0x, 0x0037,
+0x, 0x0001, 0x, 0x0004, 0x, 0x0001, 0x, 0x666e6273,
+0x36660033, 0x00366200, 0xab00366e, 0x0296, 0x0100, 0x0299, 0x0114, 0x029c,
+0x00ec, 0x0005, 0x00030001, 0x00030001, 0x02a0, 0x410b, 0x, 0x,
+0x, 0x3f80, 0x,
Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.
2013/7/30 Rico Schüller kgbric...@web.de:
Hi Matteo,
please see the attached patch.
On 25.07.2013 16:13, Matteo Bruni wrote:
2013/7/24 Rico Schüller kgbric...@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
Re: kernel32/tests: Improve GetVolumePathNameA tests
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 00cp...@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...
Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()
On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus 00cp...@gmail.com wrote: You forgot the patch. -- -Austin
