Re: Article on wine development strategy
Vincent Povirk wrote: Your model makes bugs that show up in only a few applications very rare. I've added some to your existing model with duct tape. I arbitrarily decided that about 40% of apps would have 1 or 2 unique bugs, in addition to the current ones. You can better model this by just changing the probability distribution of the various bugs and using the alternate method where each bug has an absolute probability of affecting a given app. Then make about 1000 bugs have .05% probability or so, and odds are most of them will only affect one or two apps (if you have 2500 you're modelling) The result is an exponential curve, until about 80% of apps are solved. After that, the curve is linear. This makes a sort of sense. If we do it right, we're likely to fix the bugs that affect a lot of apps before we finish with the ones that affect one or two. Once the major bugs are fixed, Wine and Windows become comparable to a more normal set of different interface implementations: largely compatible, but a few developers will continue finding subtle differences to rely on forever. The rate at which apps hit these differences should be fairly consistent. I do wish I had a better way to do this than tacking it on to the existing stuff. I think I broke pickNextBug, but fortunately that's unused until all apps are solved. If you increased the number of very rare (1 or 2 apps) bugs in a less crappy way, it might show something smoother. I'll try my suggested method now. I have a feeling that in general the exact shape depends mostly on how likely it is for a bug to occur in multiple apps and on how many bugs each app has. If a typical app has only a few bugs (the constants you've chosen imply that it doesn't), things look very nice at the start. If a typical bug affects many apps (the constants you've chosen imply that it does), things look very nice at the end. Yeah, I'll note that whether a typical app has a few bugs or a lot of bugs to start with depends on whether we want to model from the start or from here on out. Thanks, Scott Ritchie
Remote named pipes and stuff.
Hi folks, I'm at SambaXP again, and so of course the cifs Kernel driver folks talked to me about the named pipe implementation. It seems like they are still trying to figure out how this could be implemented in the cleanest way. However, Jeff Layton asked me about a use case, and I have to admit I can't think of one off the top of my head. So, what application do we have that fails to work due to the lack of remote named pipes? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
2009/4/21 Tobias Jakobi liquid.a...@gmx.net:
+struct ps_np2fixup_t {
+unsigned char idx[MAX_FRAGMENT_SAMPLERS]; /* indices to the real
constant */
+GLfloat*const_cache; /* constant cache for fast reloading
(without readback) */
+WORDswz; /* bitfield used to determine if we have to swizzle
the constant */
+WORDnum_consts;
+};
+
- I'm sure I mentioned this before, but please don't add code without using it.
- Why is this in struct ps_compiled_shader? This really looks like
something that should be internal to the backend.
- What is the point of const_cache?
- Writing GLfloat* const_cache; is legal C, but really doesn't make
a lot of sense. The * is part of the declarator rather than the base
type. An example like int* p, q; should make this more obvious.
- swz is redundant. prog-np2Fixup_data-swz (1 i) really isn't
more efficient than idx 1
[PATCH] comctl32/toolbar.c: fix trace info for TOOLBAR_InternalInsertButtonsT
TOOLBAR_DumpTBButton should be invoked over the button currently being
inserted, and not always over the first button.
---
dlls/comctl32/toolbar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c
index cf54df7..851a5cc 100644
--- a/dlls/comctl32/toolbar.c
+++ b/dlls/comctl32/toolbar.c
@@ -1832,7 +1832,7 @@ TOOLBAR_InternalInsertButtonsT(TOOLBAR_INFO *infoPtr, INT
iIndex, UINT nAddButto
for (iButton = 0; iButton nAddButtons; iButton++) {
TBUTTON_INFO *btnPtr = infoPtr-buttons[iIndex + iButton];
-TOOLBAR_DumpTBButton(lpTbb, fUnicode);
+TOOLBAR_DumpTBButton(lpTbb + iButton, fUnicode);
ZeroMemory(btnPtr, sizeof(*btnPtr));
--
1.6.2.254.g84bde
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Am Dienstag, 21. April 2009 23:37:51 schrieb Tobias Jakobi: + unsigned char idx[MAX_FRAGMENT_SAMPLERS]; /* indices to the real constant */ I don't remember how you plan to use the ps_np2fixup_t structure in the ARB backend, but an unsigned char might turn out to be too limited if you end up storing ARB constant numbers in there, since cards can have more than 256 constants. For your GLSL code it is good enough because you just store values from 1-8.
re: Remote named pipes and stuff.
Kai asked: Is there a use case for remote named pipes? http://support.microsoft.com/kb/q238949/ shows that SQL Server supports named pipes as an access method. Some apps or sites might assume that works, and not be able to use TCP/IP for this. Google finds at least three examples of people wanting to used named pipes in previous wine threads: http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/06fbfdfb53a28cbd I'm trying to run a Delphi application on Wine. The application uses BDE to talk to a MSSQL server, but database communication does not work. Enable debugging i see this error message: warn:file:wine_nt_to_unix_file_name LSRVCAF1\\pipe\\sql\\query not found in ...dosdevices/unc warn:ntdll:NtCreateFile L\\??\\UNC\\SRVCAF1\\pipe\\sql\\query not found (c03a) warn:file:CreateFileW Unable to create file LSRVCAF1\\pipe\\sql\ \query (status c03a) Is this UNC pipe supposed to work on Wine? (I think you even replied to that thread :-) http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/e7323dfa94cf3221 I am trying to connect a client with named pipes to a remote server. Using the kernel32 function CreateFile I get the folling message: fixme:file:wine_nt_to_unix_file_name UNC name L\\??\\UNC\\192.168.1.157\\pipe\\Archiv\\Server not supported I am using Wine20040505. Is the anybody out there who can help? To be frank, I am a rooky using wine an Linux, but... ;o) http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/a3d22d752d2d29e6 [Outlook seems to use a named pipe to connect to Exchange: fixme:win32:WaitNamedPipeA \\EXCH_CTL2\pipe\epmapper 0x ] So, there you have it. Databases, Microsoft Exchange, and the like seem to like using remote named pipes. - Dan
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
- I'm sure I mentioned this before, but please don't add code without using it. I'll merge it with one of the other patches then. - Why is this in struct ps_compiled_shader? This really looks like something that should be internal to the backend. No, that's definitely not the case. The struct's data is used both in GLSL and ARB mode (I'll submit the ARB patches later) - so it makes sense to put it into ps_compiled_shader. For ARB mode this is essential since something like the prog_link struct from GLSL doesn't exist there. The original source of this struct is my port of the fixup code to ARB, but introducing the constant packing for GLSL makes more data necessary - data that should be shared. I can post the next patchset for review if you don't believe me ;) - What is the point of const_cache? Reloading the np2fixup constants. Before I was declaring vec2 uniforms to store the tex dimensions. Stefan found out that the compilers are inefficent and map a vec2 to a vec4. So now I'm using vec4s only, but one vec4 is used for two textures. So x and y store width and height of texture i, and z and w store the width and height of texture j. In load_np2fixup_constants I have to use glUniform4fvARB now to set the values of the uniform. I can't simply create a float[4], zero it, set the components that belong to the currently selected texture and upload it, since it might overwrite a texture dimension pair that was previously uploaded. However while writing this, I have another idea to solve this without using the cache. - Writing GLfloat* const_cache; is legal C, but really doesn't make a lot of sense. The * is part of the declarator rather than the base type. An example like int* p, q; should make this more obvious. Your example is bad coding practice IMHO - i would never declare variables with different types on the same line. So your point is that I should write GLfloat *const_cache; Well, at least from my point of view that's purely a matter of taste. :) - swz is redundant. prog-np2Fixup_data-swz (1 i) really isn't more efficient than idx 1 As far as I can see that doesn't do the same.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
However the FX only supports these 256 constants and every other NV card above the FX doesn't need the fixup since ARB_texture_non_power_of_two is supported in hardware. This was my thought when limiting the index array to uchars. I know that you mentioned we could use the fixup code also for older cards, but in this case: even fewer constants. So it doesn't make much sense for me to allow indices greater than 255.
Re: Remote named pipes and stuff.
Hi Kai, However, Jeff Layton asked me about a use case, and I have to admit I can't think of one off the top of my head. So, what application do we have that fails to work due to the lack of remote named pipes? I actually think the clearest use of remote named pipes is actually local named pipes implemented in the kernel. See for example LKCL's many posts and bug reports regarding this. A remote named pipe implementation that happened to work for the local case would be useful for at least Python, as Luke pointed out. But really any application that used named pipes could benefit: our implementation is pretty incomplete. --Juan
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
2009/4/22 Tobias Jakobi liquid.a...@gmx.net: - Why is this in struct ps_compiled_shader? This really looks like something that should be internal to the backend. No, that's definitely not the case. The struct's data is used both in GLSL and ARB mode (I'll submit the ARB patches later) - so it makes sense to put it into ps_compiled_shader. Sure, but it's still internal bookkeeping of the backends. Everything the backend needs from the outside world is the np2_fixup field from struct ps_compile_args. For ARB mode this is essential since something like the prog_link struct from GLSL doesn't exist there. It's not terribly hard to introduce something like that. That could mean adding a handle table to the ARB backend, or expanding prgId to be a pointer, but that's ok. - Writing GLfloat* const_cache; is legal C, but really doesn't make a lot of sense. The * is part of the declarator rather than the base type. An example like int* p, q; should make this more obvious. Your example is bad coding practice IMHO - i would never declare variables with different types on the same line. The point is that writing GLfloat* const_cache; implies the * is part of the type instead of the declarator. C doesn't work that way, it's misleading at best. - swz is redundant. prog-np2Fixup_data-swz (1 i) really isn't more efficient than idx 1 As far as I can see that doesn't do the same. Not in the current code, no. But if you store the index of the fixup parameter instead of the index of the packed uniform the parameter is stored in, you can derive the index of the packed uniform as (idx 1) and the position within that uniform as (idx 1).
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Henri Verbeet wrote: 2009/4/22 Tobias Jakobi liquid.a...@gmx.net: - Why is this in struct ps_compiled_shader? This really looks like something that should be internal to the backend. No, that's definitely not the case. The struct's data is used both in GLSL and ARB mode (I'll submit the ARB patches later) - so it makes sense to put it into ps_compiled_shader. Sure, but it's still internal bookkeeping of the backends. Everything the backend needs from the outside world is the np2_fixup field from struct ps_compile_args. For ARB mode this is essential since something like the prog_link struct from GLSL doesn't exist there. It's not terribly hard to introduce something like that. That could mean adding a handle table to the ARB backend, or expanding prgId to be a pointer, but that's ok. So, is that a suggestion? I don't think that's for me to decide. You should make clear if I should implement it this way or use another approach. From my point of view it makes sense to share the data, so putting this into ps_compiled_shader is my currently best option. But if you say, that the current approach is a no-go - I'll try the pointer-approach. So, how should I do it? - Writing GLfloat* const_cache; is legal C, but really doesn't make a lot of sense. The * is part of the declarator rather than the base type. An example like int* p, q; should make this more obvious. Your example is bad coding practice IMHO - i would never declare variables with different types on the same line. The point is that writing GLfloat* const_cache; implies the * is part of the type instead of the declarator. C doesn't work that way, it's misleading at best. IMHO that's splitting hairs. You could apply the same this for pointer casting, forbidding something like var = (TYPE*)var2; and instead enforce var = (TYPE *)var2; However, const_cache is now gone - so this shouldn't be a problem anymore ;) - swz is redundant. prog-np2Fixup_data-swz (1 i) really isn't more efficient than idx 1 As far as I can see that doesn't do the same. Not in the current code, no. But if you store the index of the fixup parameter instead of the index of the packed uniform the parameter is stored in, you can derive the index of the packed uniform as (idx 1) and the position within that uniform as (idx 1). I don't think I can follow you. I tried some similar approach in the beginning, but it I think it failed if tex1 and tex3 need fixup, but tex2 does not. The approach didn't like holes in the indices. However we can't assume that all texture samples that need fixup are consecutive.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
2009/4/22 Tobias Jakobi liquid.a...@gmx.net: Henri Verbeet wrote: Sure, but it's still internal bookkeeping of the backends. Everything the backend needs from the outside world is the np2_fixup field from struct ps_compile_args. For ARB mode this is essential since something like the prog_link struct from GLSL doesn't exist there. It's not terribly hard to introduce something like that. That could mean adding a handle table to the ARB backend, or expanding prgId to be a pointer, but that's ok. So, is that a suggestion? I don't think that's for me to decide. You should make clear if I should implement it this way or use another approach. From my point of view it makes sense to share the data, so putting this into ps_compiled_shader is my currently best option. But if you say, that the current approach is a no-go - I'll try the pointer-approach. So, how should I do it? A handle table would probably make the most sense. A pointer would work for ARB, but for GLSL that's just extra indirection that isn't really needed. The point is that writing GLfloat* const_cache; implies the * is part of the type instead of the declarator. C doesn't work that way, it's misleading at best. IMHO that's splitting hairs. You could apply the same this for pointer casting, forbidding something like var = (TYPE*)var2; and instead enforce var = (TYPE *)var2; I think that's better, yes. Not in the current code, no. But if you store the index of the fixup parameter instead of the index of the packed uniform the parameter is stored in, you can derive the index of the packed uniform as (idx 1) and the position within that uniform as (idx 1). I don't think I can follow you. I tried some similar approach in the beginning, but it I think it failed if tex1 and tex3 need fixup, but tex2 does not. The approach didn't like holes in the indices. However we can't assume that all texture samples that need fixup are consecutive. Tex fixup parameter for tex1 would have idx 0, the one for tex3 would have idx 1. These would then be packed as PsamplerNP2Fixup0.xy and PsamplerNP2Fixup0.zw.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Henri Verbeet wrote: A handle table would probably make the most sense. A pointer would work for ARB, but for GLSL that's just extra indirection that isn't really needed. Sry, I have to correct myself. It won't work that way. Setting up the data of the np2 fixup data struct is done in shader_generate_glsl_declarations, where I don't have any access to a glsl_shader_prog_link structure. I might not even exist, since the entries of prog_link are all setup by set_glsl_shader_program. Furthermore the np2 fixup data struct doesn't really belong in prog_link, it has nothing to do with the GLSL program object itself but is a feature of the fragment shader. That does not apply to np2Fixup_location, which has to be part of the GLSL object since the uniform locations are based on the program and not the individual components. That is not the case for the np2 fixup data, which is unique to the fragment shader - and doesn't change when creating a different vshader, fshader/pshader combination. Not in the current code, no. But if you store the index of the fixup parameter instead of the index of the packed uniform the parameter is stored in, you can derive the index of the packed uniform as (idx 1) and the position within that uniform as (idx 1). I don't think I can follow you. I tried some similar approach in the beginning, but it I think it failed if tex1 and tex3 need fixup, but tex2 does not. The approach didn't like holes in the indices. However we can't assume that all texture samples that need fixup are consecutive. Tex fixup parameter for tex1 would have idx 0, the one for tex3 would have idx 1. These would then be packed as PsamplerNP2Fixup0.xy and PsamplerNP2Fixup0.zw. OK, I think I have figured out how to get it work. I my previous approach didn't work so well, because I was adressing the uniforms in a different way. I also switched to a uniform array, to make it easier to update the texture dimensions in one go. Fewer GL calls that way.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Henri Verbeet wrote: Tex fixup parameter for tex1 would have idx 0, the one for tex3 would have idx 1. These would then be packed as PsamplerNP2Fixup0.xy and PsamplerNP2Fixup0.zw. OK, forget that as well. Like I replied to Stefan about the uchar thing: The code is only active for FX cards which have a constant limit of 256. (or it could become active for cards below a FX) With the approach without swz, this would mean changing the unsigned char array to a unsigned short one, which would double the size. I tried to keep the whole struct as small as possible, the current size if now 20 bytes (16 bytes for the indices, and 4 bytes for swz and num_consts). Adding the code for ARB would introduce 2 additional bytes (active bitflag, since we can figure out quite well if there are still enough free constants in ARB), but that's it. Performancewise the current approach shouldn't be a problem. I think we should focus on size here, and that's why I don't think changing this will do any good.
Re: [1/2] comctl32/listview: Additional tests for LVM_GETSUBITEMRECT
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov bungleh...@gmail.com
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl32/tests/listview.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/listview.c b/dlls/comctl32/tests/listview.c
index 6f205fd..fba7a01 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -847,6 +847,7 @@ static void test_create(void)
LONG_PTR ret;
LONG r;
LVCOLUMNA col;
+RECT rect;
WNDCLASSEX cls;
cls.cbSize = sizeof(WNDCLASSEX);
ok(GetClassInfoEx(GetModuleHandle(NULL), SysListView32, cls),
GetClassInfoEx failed\n);
@@ -976,6 +977,31 @@ static void test_create(void)
ok(IsWindow(hHeader), Header should be created\n);
ok(hHeader == GetDlgItem(hList, 0), Expected header as dialog item\n);
DestroyWindow(hList);
+
+/* requesting header info with LVM_GETSUBITEMRECT doesn't create it */
+hList = CreateWindow(SysListView32, Test, LVS_REPORT, 0, 0, 100, 100,
NULL, NULL,
+ GetModuleHandle(NULL), 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+rect.left = LVIR_BOUNDS;
+rect.top = 1;
+rect.right = rect.bottom = -10;
+r = SendMessage(hList, LVM_GETSUBITEMRECT, -1, (LPARAM)rect);
+todo_wine
+ok(r != 0, Expected not-null LRESULT\n);
+
+hHeader = (HWND)SendMessage(hList, LVM_GETHEADER, 0, 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+expect(0, rect.left);
+todo_wine {
+expect(0, rect.right);
+expect(0, rect.top);
These first 3 seems to fail on everything from W2K downwards. Could you
have a look?
--
Cheers,
Paul.
Re: [1/2] comctl32/listview: Additional tests for LVM_GETSUBITEMRECT
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov bungleh...@gmail.com
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl32/tests/listview.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/listview.c
b/dlls/comctl32/tests/listview.c
index 6f205fd..fba7a01 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -847,6 +847,7 @@ static void test_create(void)
LONG_PTR ret;
LONG r;
LVCOLUMNA col;
+RECT rect;
WNDCLASSEX cls;
cls.cbSize = sizeof(WNDCLASSEX);
ok(GetClassInfoEx(GetModuleHandle(NULL), SysListView32, cls),
GetClassInfoEx failed\n);
@@ -976,6 +977,31 @@ static void test_create(void)
ok(IsWindow(hHeader), Header should be created\n);
ok(hHeader == GetDlgItem(hList, 0), Expected header as dialog
item\n);
DestroyWindow(hList);
+
+/* requesting header info with LVM_GETSUBITEMRECT doesn't create
it */
+hList = CreateWindow(SysListView32, Test, LVS_REPORT, 0, 0,
100, 100, NULL, NULL,
+ GetModuleHandle(NULL), 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+rect.left = LVIR_BOUNDS;
+rect.top = 1;
+rect.right = rect.bottom = -10;
+r = SendMessage(hList, LVM_GETSUBITEMRECT, -1, (LPARAM)rect);
+todo_wine
+ok(r != 0, Expected not-null LRESULT\n);
+
+hHeader = (HWND)SendMessage(hList, LVM_GETHEADER, 0, 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+expect(0, rect.left);
+todo_wine {
+expect(0, rect.right);
+expect(0, rect.top);
These first 3 seems to fail on everything from W2K downwards. Could
you have a look?
And on one of Vista machines too. So it's only stable for XP and 2k3,
maybe it's better to remove them completely?
Re: [1/2] comctl32/listview: Additional tests for LVM_GETSUBITEMRECT
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov bungleh...@gmail.com
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl32/tests/listview.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/listview.c
b/dlls/comctl32/tests/listview.c
index 6f205fd..fba7a01 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -847,6 +847,7 @@ static void test_create(void)
LONG_PTR ret;
LONG r;
LVCOLUMNA col;
+RECT rect;
WNDCLASSEX cls;
cls.cbSize = sizeof(WNDCLASSEX);
ok(GetClassInfoEx(GetModuleHandle(NULL), SysListView32, cls),
GetClassInfoEx failed\n);
@@ -976,6 +977,31 @@ static void test_create(void)
ok(IsWindow(hHeader), Header should be created\n);
ok(hHeader == GetDlgItem(hList, 0), Expected header as dialog
item\n);
DestroyWindow(hList);
+
+/* requesting header info with LVM_GETSUBITEMRECT doesn't create
it */
+hList = CreateWindow(SysListView32, Test, LVS_REPORT, 0, 0,
100, 100, NULL, NULL,
+ GetModuleHandle(NULL), 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+rect.left = LVIR_BOUNDS;
+rect.top = 1;
+rect.right = rect.bottom = -10;
+r = SendMessage(hList, LVM_GETSUBITEMRECT, -1, (LPARAM)rect);
+todo_wine
+ok(r != 0, Expected not-null LRESULT\n);
+
+hHeader = (HWND)SendMessage(hList, LVM_GETHEADER, 0, 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+expect(0, rect.left);
+todo_wine {
+expect(0, rect.right);
+expect(0, rect.top);
These first 3 seems to fail on everything from W2K downwards. Could
you have a look?
And on one of Vista machines too. So it's only stable for XP and 2k3,
maybe it's better to remove them completely?
I see 2 of those on a Vista box and also on a W2K8 box.
The results are also not consistent. I agree that this makes it a bit
useless for testing purposes.
--
Cheers,
Paul.
Re: [1/2] comctl32/listview: Additional tests for LVM_GETSUBITEMRECT
Paul Vriens wrote:
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00
2001
From: Nikolay Sivov bungleh...@gmail.com
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl32/tests/listview.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/listview.c
b/dlls/comctl32/tests/listview.c
index 6f205fd..fba7a01 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -847,6 +847,7 @@ static void test_create(void)
LONG_PTR ret;
LONG r;
LVCOLUMNA col;
+RECT rect;
WNDCLASSEX cls;
cls.cbSize = sizeof(WNDCLASSEX);
ok(GetClassInfoEx(GetModuleHandle(NULL), SysListView32,
cls), GetClassInfoEx failed\n);
@@ -976,6 +977,31 @@ static void test_create(void)
ok(IsWindow(hHeader), Header should be created\n);
ok(hHeader == GetDlgItem(hList, 0), Expected header as dialog
item\n);
DestroyWindow(hList);
+
+/* requesting header info with LVM_GETSUBITEMRECT doesn't
create it */
+hList = CreateWindow(SysListView32, Test, LVS_REPORT, 0,
0, 100, 100, NULL, NULL,
+ GetModuleHandle(NULL), 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+rect.left = LVIR_BOUNDS;
+rect.top = 1;
+rect.right = rect.bottom = -10;
+r = SendMessage(hList, LVM_GETSUBITEMRECT, -1, (LPARAM)rect);
+todo_wine
+ok(r != 0, Expected not-null LRESULT\n);
+
+hHeader = (HWND)SendMessage(hList, LVM_GETHEADER, 0, 0);
+ok(!IsWindow(hHeader), Header shouldn't be created\n);
+ok(NULL == GetDlgItem(hList, 0), NULL dialog item expected\n);
+
+expect(0, rect.left);
+todo_wine {
+expect(0, rect.right);
+expect(0, rect.top);
These first 3 seems to fail on everything from W2K downwards. Could
you have a look?
And on one of Vista machines too. So it's only stable for XP and 2k3,
maybe it's better to remove them completely?
I see 2 of those on a Vista box and also on a W2K8 box.
The results are also not consistent. I agree that this makes it a bit
useless for testing purposes.
Ok, I'll sent a patch in a couple of hours. I still prefer to return
zero rectangle keeping in mind that all about this special case is
undocumented.
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Am Mittwoch, 22. April 2009 17:37:55 schrieb Tobias Jakobi: However the FX only supports these 256 constants and every other NV card above the FX doesn't need the fixup since ARB_texture_non_power_of_two is supported in hardware. This was my thought when limiting the index array to uchars. I know that you mentioned we could use the fixup code also for older cards, but in this case: even fewer constants. So it doesn't make much sense for me to allow indices greater than 255. I don't think we want to make such an assumption when its just a matter of using a short or an int, especially when we don't have to count single bytes(ps_compiled_shader isn't performance or size critical). E.g. one might run across a strange Intel, Matrox or SGI GL implementation, or somebody might disable some extensions for debugging purposes and fall back to texrect on dx10 cards. (It's kinda annoying when you hit a new bug when debugging something) It is obviously a different story with things like adding extra complicated code for handling vertex texture fetch that will most likely never be used in real life.
Re: [4/4] (Try2) msi/tests: Fix package test when run on a different drive than C:\.
On Wed, Apr 22, 2009 at 12:05 PM, Nicolas Le Cam niko.le...@gmail.com wrote: Try2: Use helper function added in second patch, as suggested by James. This one finally fixes current relative path test to expect correct value. This version isn't using a helper function. Please thoroughly go over your patches before submitting them. Your subject says try2, but I know it's been more than that, so we've seen at least 12-16 emails/patches for this set now. -- James Hawkins
Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader
Am Mittwoch, 22. April 2009 18:39:40 schrieb Henri Verbeet: For ARB mode this is essential since something like the prog_link struct from GLSL doesn't exist there. It's not terribly hard to introduce something like that. That could mean adding a handle table to the ARB backend, or expanding prgId to be a pointer, but that's ok. Just add my 2c. ARB doesn't need a prog_link structure because Vertex and Fragment programs are independent, so it would be bad to add some struct that defines a combination of vertex and pixel shader(and not needed for this patch's purpose). What we'd end up with is a clone of ps_compiled_shader. Probably the best thing is to remove the GLuint prgId from ps_compiled_shader and replace it with a void *backend_priv_data to store per-shader data with backend specific contents. /mode = pedantic
Re: [4/4] (Try2) msi/tests: Fix package test when run on a different drive than C:\.
2009/4/22 James Hawkins trui...@gmail.com: On Wed, Apr 22, 2009 at 12:05 PM, Nicolas Le Cam niko.le...@gmail.com wrote: Try2: Use helper function added in second patch, as suggested by James. This one finally fixes current relative path test to expect correct value. This version isn't using a helper function. Please thoroughly go over your patches before submitting them. Your subject says try2, but I know it's been more than that, so we've seen at least 12-16 emails/patches for this set now. -- James Hawkins Outch sorry about that. I will resubmit right version. You're right, it should be Try7 but as part of the previous series was accepted, except this patch and another one trying to fix test when running on a root drive dir, I did thought creating a new series would erase counters. I'm sorry that you seems upset by that and it won't happen again. Should I resubmit with Try8 as object? Thanks again for your reviews, and sorry for my mistakes, I will pay more attention to what I'm submitting. -- Nicolas Le Cam
Re: [4/4] (Try2) msi/tests: Fix package test when run on a different drive than C:\.
On Wed, Apr 22, 2009 at 12:44 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2009/4/22 James Hawkins trui...@gmail.com: On Wed, Apr 22, 2009 at 12:05 PM, Nicolas Le Cam niko.le...@gmail.com wrote: Try2: Use helper function added in second patch, as suggested by James. This one finally fixes current relative path test to expect correct value. This version isn't using a helper function. Please thoroughly go over your patches before submitting them. Your subject says try2, but I know it's been more than that, so we've seen at least 12-16 emails/patches for this set now. -- James Hawkins Outch sorry about that. I will resubmit right version. You're right, it should be Try7 but as part of the previous series was accepted, except this patch and another one trying to fix test when running on a root drive dir, I did thought creating a new series would erase counters. I'm sorry that you seems upset by that and it won't happen again. Should I resubmit with Try8 as object? Thanks again for your reviews, and sorry for my mistakes, I will pay more attention to what I'm submitting. No, I'm not upset about the subject. It was advice that will help you get your patches accepted. The more times you submit the same patch set with errors, the less likely it is to be accepted. -- James Hawkins
[PATCH 1/2] comctl32/tests: test toolbar separator with uninitialized iString
Trying to add a separator with an invalid pointer in iString to a
toolbar works in Windows, showing that the field is ignored.
---
dlls/comctl32/tests/toolbar.c | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/toolbar.c b/dlls/comctl32/tests/toolbar.c
index 1946095..91a72e0 100644
--- a/dlls/comctl32/tests/toolbar.c
+++ b/dlls/comctl32/tests/toolbar.c
@@ -1300,6 +1300,56 @@ static void test_getstring(void)
DestroyWindow(hToolbar);
}
+static void test_deadbeef(void)
+{
+HWND hToolbar = NULL;
+TBBUTTON buttons[2];
+INT r;
+
+rebuild_toolbar_with_buttons(hToolbar);
+
+ZeroMemory(buttons, sizeof(buttons));
+
+/* Some programs (e.g. Graphmatica 2.0f) forget to initialize the iString
+ * field for separators. If the random bit pattern of this field looks like
+ * a pointer, trying to follow it casues a crash (pagefault). This does not
+ * happen in Windows XP, 2008 or Vista, suggesting that this field is
+ * ignored in Windows in this case. */
+buttons[0].idCommand = 0;
+buttons[0].fsStyle = BTNS_SEP;
+buttons[0].fsState = TBSTATE_ENABLED;
+buttons[0].iString = 0xdeadbeef;
+
+#if 0
+/* It is also possible that a poorly written program doesn't initialize the
+ * iString field of an actual button. Different versions of Windows seem to
+ * operate differently in this case.
+ *+ Windows XP doesn't seem to be bothered in the least
+ *+ Windows 2008 crashes
+ *+ Windows Vista does not crash, but the subsequent TB_ADDBUTTONS
+ * call fails
+ * Since I know of no program that suffers from this particular issue, I'm
+ * commenting out this part of the test for the time being. If it gets
+ * uncommented, the subsequent TB_ADDBUTTONS should be adjusted
+ * appropriately. */
+
+buttons[1].idCommand = 1;
+buttons[1].fsStyle = BTNS_BUTTON;
+buttons[1].fsState = 0;
+buttons[1].iString = 0xdeadbeef;
+#endif
+
+r = SendMessage(hToolbar, TB_ADDBUTTONS, 1, (LPARAM)buttons);
+expect(1, r);
+
+/* TODO: another test that might be worth doing, to get more insight on how
+ * Windows handles things, would be to introduce a separator with
+ * 0xdeadbeef as iString, and then change its style to make into a real
+ * button. */
+
+DestroyWindow(hToolbar);
+}
+
START_TEST(toolbar)
{
WNDCLASSA wc;
@@ -1336,6 +1386,7 @@ START_TEST(toolbar)
test_dispinfo();
test_setrows();
test_getstring();
+test_deadbeef();
PostQuitMessage(0);
while(GetMessageA(msg,0,0,0)) {
--
1.6.2.254.g84bde
[PATCH 2/2] comctl32/toolbar: skip iString field for separators
Some programs (e.g. Graphmatica 2.0f) forget to initialize the iString
field for separators in toolbars. Windows copes with this smoothly,
ignoring the field altogether. Do the same in Wine.
---
dlls/comctl32/toolbar.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c
index c3add77..83098cc 100644
--- a/dlls/comctl32/toolbar.c
+++ b/dlls/comctl32/toolbar.c
@@ -1841,7 +1841,9 @@ TOOLBAR_InternalInsertButtonsT(TOOLBAR_INFO *infoPtr, INT
iIndex, UINT nAddButto
btnPtr-fsState = lpTbb[iButton].fsState;
btnPtr-fsStyle = lpTbb[iButton].fsStyle;
btnPtr-dwData= lpTbb[iButton].dwData;
-if(HIWORD(lpTbb[iButton].iString) lpTbb[iButton].iString != -1)
+if(btnPtr-fsStyle BTNS_SEP)
+btnPtr-iString = -1;
+else if(HIWORD(lpTbb[iButton].iString) lpTbb[iButton].iString != -1)
{
if (fUnicode)
Str_SetPtrW((LPWSTR*)btnPtr-iString,
(LPWSTR)lpTbb[iButton].iString );
--
1.6.2.254.g84bde
[1/7] [wined3d] add ps_np2fixup_t ptr to shader_arb_priv (review)
For review: This patchset implements np2 texcoord fixup in ARB mode. Constants used to store texture dimensions are already packed, using the same data structures like the GLSL packing code. The code is finished and works quite well. It has been tested with Max Payne 2, HL2 and FEAR. All games now work with post-processing effects and anything else that needs NP2 textures on the nvidia FX series. Greets, Tobias -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 0001--wined3d-add-ps_np2fixup_t-ptr-to-shader_arb_priv.patch Description: Binary data
[2/7] [wined3d] shader_generate_arb_declarations: add NP2 fixup code (review)
-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a 0002--wined3d-shader_generate_arb_declarations-add-NP2.patch Description: Binary data
[4/7] [wined3d] implement shader_arb_load_np2fixup_constants (review)
-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a 0004--wined3d-implement-shader_arb_load_np2fixup_constan.patch Description: Binary data
[6/7] [wined3d] force constant reload for NP2 fixup in shader_arb_select (review)
-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a 0006--wined3d-force-constant-reload-for-NP2-fixup-in-sha.patch Description: Binary data
[3/7] [wined3d] shader_hw_sample: add NP2 fixup code (review)
-- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 0003--wined3d-shader_hw_sample-add-NP2-fixup-code.patch Description: Binary data
[7/7] [wined3d] correct now faulty comment (review)
-- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 0007--wined3d-correct-now-faulty-comment.patch Description: Binary data
[5/7] [wined3d] remove comment about np2fixup not implemented for ARB mode (review)
-- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 0005--wined3d-remove-comment-about-np2fixup-not-implemen.patch Description: Binary data
