Re: [1/3] msxml3/tests: Added IStream tests for IMXWriter
On 06/19/2011 09:31 PM, Thomas Mullaly wrote:
+#define DEFINE_EXPECT(func) \
+static BOOL expect_ ## func = FALSE, called_ ## func = FALSE
+
+#define SET_EXPECT(func) \
+expect_ ## func = TRUE
This seems like macro-overkill. I think a struct/table here may be a
bit cleaner.
+static const CHAR szUtf16BOM[] = {'\xff','\xfe'};
Normal hex here would be more readable.
Re: [3/3] msxml3: Added IStream support to IMXWriter
On 06/19/2011 09:32 PM, Thomas Mullaly wrote:
+static inline void reset_output_buffer(mxwriter *This, LPCSTR encoding)
+{
+xmlOutputBufferClose(This-buffer);
+
+if (encoding)
+This-buffer =
xmlAllocOutputBuffer(xmlFindCharEncodingHandler(encoding));
+else if (!This-dest)
+This-buffer =
xmlAllocOutputBuffer(xmlFindCharEncodingHandler(UTF-16));
+else {
+LPSTR enc = heap_strdupWtoA(This-encoding);
+This-buffer = xmlAllocOutputBuffer(xmlFindCharEncodingHandler(enc));
+heap_free(enc);
+}
+
+This-dest_written = 0;
+}
Libxml2 has the various encodings enum'd out as xmlCharEncoding; better
to pass the enum around and avoid the string comparison. Then you can
use xmlGetCharEncodingHandler() instead of xmlFindCharEncodingHandler().
Disablin xinput2 for now?
Hi, There seem to be regressions in xinput2 support, http://bugs.winehq.org/show_bug.cgi?id=27028 As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? Ciao, Marcus
Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 4)
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=11841 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found
Re: [1/2] d3dx9/test: Add UpdateSemantics test. (try 3)
These two patches look OK to me. On Friday 17 June 2011 14:19:56 Michael Mc Donnell wrote: Removed a superfluous test. Added NULL check before releasing mesh. Changed struct declaration style. Changed the struct declaration style again. Added GetNumBytesPerVertex test Added GetDeclaration tests Added equals check Renamed larger declaration test to overlapping declaration test. Added smaller and larger declarations. Added D3DECL_END() marker check Moved pointer * to new_test_context (nitpick) Added multiple streams test signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation
On 20 June 2011 15:08, Vitaliy Margolen wine-de...@kievinfo.com wrote:
On 06/19/2011 08:15 PM, Austin Lund wrote:
+ ret = wine_server_call( req );
+ shi-Count += reply-handles;
+ len = sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count +
sizeof(ULONG);
+ shi = RtlReAllocateHeap(GetProcessHeap(),
HEAP_ZERO_MEMORY, shi, len);
Please do allocations outside of server call block. And add handling of
failed realloc. Also please double the allocated size, don't reallocate
after each server call.
+ for (i = shi-Count - reply-handles; i shi-Count;
i++) {
+ shi-Handle[i].OwnerPid = reply-pid;
+ }
Please follow file's curly braces style - none for single line blocks, or on
separate line for multi-line blocks.
Thanks for the review. Does this patch address these concerns correctly?
From b4b4310cc28560ea30d1ad6a7961f4c5b443c73a Mon Sep 17 00:00:00 2001
From: Austin Lund austin.l...@gmail.com
Date: Sun, 12 Jun 2011 19:41:18 +1000
Subject: [PATCH 1/2] dlls/ntdll: Add handle count to NtQuerySystemInformation (try 2)
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/ntdll/nt.c | 73 +++
dlls/ntdll/tests/info.c |8 +
2 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c
index f9302c1..5e7a711 100644
--- a/dlls/ntdll/nt.c
+++ b/dlls/ntdll/nt.c
@@ -1655,18 +1655,79 @@ NTSTATUS WINAPI NtQuerySystemInformation(
break;
case SystemHandleInformation:
{
-SYSTEM_HANDLE_INFORMATION shi;
+SYSTEM_HANDLE_INFORMATION *shi;
+HANDLE hSnap = 0;
+
+FIXME(info_class SYSTEM_HANDLE_INFORMATION partial implementation\n);
+
+SERVER_START_REQ( create_snapshot )
+{
+req-flags = SNAP_PROCESS;
+req-attributes = 0;
+if (!(ret = wine_server_call( req )))
+hSnap = wine_server_ptr_handle( reply-handle );
+}
+SERVER_END_REQ;
+
+len = 128;
+shi = RtlAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
+if (shi == NULL)
+return STATUS_NO_MEMORY;
-memset(shi, 0, sizeof(shi));
-len = sizeof(shi);
+for (;;)
+{
+int i, handle_count;
+process_id_t pid;
+
+SERVER_START_REQ( next_process )
+{
+req-handle = wine_server_obj_handle( hSnap );
+req-reset = 0;
+ret = wine_server_call( req );
+handle_count = reply-handles;
+pid = reply-pid;
+}
+SERVER_END_REQ;
+
+if (ret != STATUS_SUCCESS) break;
+
+shi-Count += handle_count;
+while (sizeof(ULONG) + sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count = len)
+{
+len = 2*len;
+shi = RtlReAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, shi, len);
+if (shi == NULL)
+return STATUS_NO_MEMORY;
+
+}
+
+for (i = shi-Count - handle_count; i shi-Count; i++)
+shi-Handle[i].OwnerPid = pid;
+}
+
+len = sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count + sizeof(ULONG);
+shi = RtlReAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, shi, len);
+if (shi == NULL)
+return STATUS_NO_MEMORY;
+
+if ( ResultLength )
+*ResultLength = len;
if ( Length = len)
{
if (!SystemInformation) ret = STATUS_ACCESS_VIOLATION;
-else memcpy( SystemInformation, shi, len);
+else
+{
+memcpy(SystemInformation, shi, len);
+RtlFreeHeap(GetProcessHeap(), 0, shi);
+shi = NULL;
+ret = STATUS_SUCCESS;
+}
}
-else ret = STATUS_INFO_LENGTH_MISMATCH;
-FIXME(info_class SYSTEM_HANDLE_INFORMATION\n);
+else
+ret = STATUS_INFO_LENGTH_MISMATCH;
+
+if (hSnap) NtClose(hSnap);
}
break;
case SystemCacheInformation:
diff --git a/dlls/ntdll/tests/info.c b/dlls/ntdll/tests/info.c
index 2d5c94f..f82bdfd 100644
--- a/dlls/ntdll/tests/info.c
+++ b/dlls/ntdll/tests/info.c
@@ -468,7 +468,7 @@ static void test_query_handle(void)
/* Request the needed length : a SystemInformationLength greater than one struct sets ReturnLength */
status = pNtQuerySystemInformation(SystemHandleInformation, shi, SystemInformationLength, ReturnLength);
-todo_wine ok( status == STATUS_INFO_LENGTH_MISMATCH, Expected
Disablin xinput2 for now?
Hi, There seem to be regressions in xinput2 support I too have experienced various mouse trouble since approx. 1.3.18 on MacOS, using XQuartz 2.5.x or 2.6.1 -- which is much more recent than any of my Ubuntu systems (Lucid). As I've currently little time for regressions, I haven't yet turned that into bug reports (and had always hoped that Wine release N+1 would eventually make things work again). Haegemonia 2 aka. Legions of Iron seems to be fixed as of 1.3.22. Previously, the mouse flickered badly when moved and it moved like crazy along one y/x direction. As of 1.3.22, Black White 2 doesn't react to the mouse anymore. should we packagers turn off xinput2 support for the time being? There's still hope that the situation will stabilize as present bug reports are analyzed and the causes understood. I also hope somebody will update the Wiki pages, e.g. UsefulRegistryKeys to reflect new possibilities. I would believe there are some. The Wiki is the place where I'd expect to find a summary of options and hints for when a program does not work in area Y. I know where to look for some forms of audio trouble, but what do I know about mouse trouble? Before starting git bisect, I'd prefer to try out whether a few registry keys may help with the mouse. Which ones should I try? Regards, Jörg Höhle
Re: [PATCH 2/4] server: Add function to count only valid handles in a process
On 20 June 2011 15:12, Vitaliy Margolen wine-de...@kievinfo.com wrote:
On 06/19/2011 08:15 PM, Austin Lund wrote:
[PATCH 2/4] server: Add function to count only valid handles in a process
This makes no sense. All handles are valid inside wineserver.
When looking at bug 9484 and trying to implement this functionality, I
thought that the next_process call would return the number of open
handles in the process. This is currently incorrect. As it stands
reply-handles is the size of the allocated handle table (which is
currently a power of two times 32) which is information almost totally
irrelevant to anyone wanting handle information using snapshots.
My patch changes this to count the number of open handles. Later
patches I have use this functionality.
I've attached an amendment which just changes the name of the call.
From 106d0784f88d8c50e28e5dcfcebf9f04be68c6fa Mon Sep 17 00:00:00 2001
From: Austin Lund austin.l...@gmail.com
Date: Thu, 16 Jun 2011 12:18:54 +1000
Subject: [PATCH 2/2] server: Add function to count only open handles for a process (try 2)
Reply-To: wine-devel wine-devel@winehq.org
---
server/handle.c | 11 ++-
server/handle.h |1 +
server/process.c |2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/server/handle.c b/server/handle.c
index 2aaec37..35636aa 100644
--- a/server/handle.c
+++ b/server/handle.c
@@ -461,7 +461,7 @@ obj_handle_t enumerate_handles( struct process *process, const struct object_ops
for (i = *index, entry = table-entries[i]; i = table-last; i++, entry++)
{
if (!entry-ptr) continue;
-if (entry-ptr-ops != ops) continue;
+if (ops (entry-ptr-ops != ops)) continue;
*index = i + 1;
return index_to_handle(i);
}
@@ -560,6 +560,15 @@ unsigned int get_handle_table_count( struct process *process )
return process-handles-count;
}
+unsigned int count_open_handles( struct process *process )
+{
+unsigned int i, count;
+i = count = 0;
+while (enumerate_handles(process, NULL, i) != 0)
+count++;
+return count;
+}
+
/* close a handle */
DECL_HANDLER(close_handle)
{
diff --git a/server/handle.h b/server/handle.h
index 821c4ef..6146b7d 100644
--- a/server/handle.h
+++ b/server/handle.h
@@ -53,5 +53,6 @@ extern void close_process_handles( struct process *process );
extern struct handle_table *alloc_handle_table( struct process *process, int count );
extern struct handle_table *copy_handle_table( struct process *process, struct process *parent );
extern unsigned int get_handle_table_count( struct process *process);
+extern unsigned int count_open_handles( struct process *process );
#endif /* __WINE_SERVER_HANDLE_H */
diff --git a/server/process.c b/server/process.c
index c88c89b..c3b0c64 100644
--- a/server/process.c
+++ b/server/process.c
@@ -846,7 +846,7 @@ struct process_snapshot *process_snap( int *count )
ptr-threads = process-running_threads;
ptr-count= process-obj.refcount;
ptr-priority = process-priority;
-ptr-handles = get_handle_table_count(process);
+ptr-handles = count_open_handles(process);
grab_object( process );
ptr++;
}
--
1.7.4.1
Re: GSoC: dinput8 Action Mapping
Because callback doesn't have any string parameters it would be an easy thing to do. I've made an EnumDevicesBySemantics version using A - W calls, but it turned out to be trickier than I thought because the callback function is passed the device interfaces and then the A callback gets W interfaces. I'll send the patches with corrections later today but I really think the implementation for EnumDevicesBySemantics should remain separate right now.
Re: [PATCH 2/2] d3dx9/line: Implemented tests for ID3DXLine's Begin and End methods.
2011/6/18 Charles Welton charles...@gmail.com: --- dlls/d3dx9_36/tests/line.c | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) +srand(time(NULL)); +random = ((FLOAT) rand())/RAND_MAX; /* Random value between 0.0 and 1.0. We're using this later. */ I didn't check why your patch failed with the testbot. Nevertheless, you should avoid to use random values: the tests should be repeatable. Just pick some arbitrary values and use them. Also, for better clarity, you may want to use a different variable for the modified identity matrix (because, at that point, it isn't identity anymore). Maybe you could check the world matrix between ID3DXLine_Begin and ID3DXLine_End too.
Re: Disablin xinput2 for now?
On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. Vitaliy.
Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation
On 06/20/2011 05:28 AM, Austin Lund wrote: Thanks for the review. Does this patch address these concerns correctly? No quite there yet: +SERVER_START_REQ( create_snapshot ) You not checking if this call succeeded or not. +while (sizeof(ULONG) + sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count = len) You don't need a loop to calculate new size. +shi = RtlReAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, shi, len); +if (shi == NULL) +return STATUS_NO_MEMORY; You leaking old shi here. Also why do you need to zero allocated memory if you assigning all of it valid values? Vitaliy.
Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 4)
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote: Fixed function name typo, compiler warnings, code style issues in a fragment of new code and incorrect usage of wcslen in the tests instead of lstrlenW after previous changes. My apologies :). +#define DEADBEEF 0xdeadbeef Please don't do this. Just explicitly use 0xdeadbeef everywhere. +todo_wine ok(ret == 0 GetLastError() == DEADBEEF count = 1, Given (NULL, count, sizeof), +GetRawInputDeviceList should return the number of raw input devices\n); If call succeeded you don't need to check last error. +device_list = malloc(count * sizeof(RAWINPUTDEVICELIST)); Don't use malloc/free in Wine. Use HeapAlloc / HeapFree. +ret = pGetRawInputDeviceList(device_list, count2, sizeof(RAWINPUTDEVICELIST)); +todo_wine ok(ret == (UINT)-1 GetLastError() == ERROR_INSUFFICIENT_BUFFER count2 == count, +Given (device_list, count2 = 0, sizeof), GetRawInputDeviceList should return an error\n); If something fails it's nice to know the error code - you need to print it. For that you need to more GetLastError outside of ok() function call. See other tests as example. +static BOOL get_raw_input_data_wnd_proc_was_called = FALSE; Static variables automatically set to 0 at the start. You don't need to do it explicitly. Vitaliy.
Re: [PATCH 2/3] server: Added server-side raw input function implementations (try 4)
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote:
(see the message in the first part of the patch)
+struct raw_input
+{
+struct listentry;
+unsigned short usage_page;
+unsigned short usage;
+BOOL processed;
+BOOL retrieved;
+RAWINPUT raw;
+
+/* common fields */
+unsigned int type;
+unsigned int message;
+unsigned int flags;
+unsigned int extra_info;
+
+/* mouse fields */
+unsigned int point_x;
+unsigned int point_y;
+unsigned int mouse_data;
+unsigned int cursor_x;
+unsigned int cursor_y;
+
+/* keyboard fields */
+unsigned int vk_code;
+unsigned int scan_code;
+};
Mouse and keyboard fields should be a union to save space.
+#define NUM_RAW_DEVICES (sizeof( raw_devices ) / sizeof( struct raw_device ))
Please use sizeof(array)/sizeof(array[0]) construct instead.
+UINT i, size_in_bytes;
In server please use standard C types (unsigned int in this case).
+/* Currently fake handles are provided, however they are only used for
the GetRawInputDeviceInfo function,
+ thus it should not create any undesirable side effects */
+result[i].hDevice = (HANDLE)raw_devices[i].handle;
This doesn't sound right. What this handle can be used for?
+if (!(raw = malloc( sizeof( *raw ) )))
In server please use mem_alloc() instead.
+/* Unregister a raw input device */
+DECL_HANDLER(unregister_raw_input_device)
I don't see handing of case where device is not found. Should you return
error instead?
+LIST_FOR_EACH( registration_entry, current-process-raw_registered )
+{
+struct raw_registration *registration = LIST_ENTRY(
registration_entry, struct raw_registration, entry );
You can use this instead:
LIST_FOR_EACH_ENTRY( registration, current-process-raw_registered,
struct raw_registration, entry )
+/* Prevent unprocessed raw input entries from being queued indefinitely */
+while (current-process-raw_inputs_len = MAX_RAW_INPUT_QUEUE_LENGTH)
+{
+struct raw_input *head = LIST_ENTRY( list_head(
current-process-raw_inputs ), struct raw_input, entry );
+list_remove( head-entry );
+current-process-raw_inputs_len -= 1;
+free( head );
+}
Looks like you need a circular buffer (an array of fixed size with head and
tail pointers) instead of a list here.
Vitaliy.
Re: Disablin xinput2 for now?
Vitaliy Margolen wine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). -- Alexandre Julliard julli...@winehq.org
Re: shdocvw: Add ITaskbarList2 Interface
2011/6/18 André Hentschel n...@dawncrow.de:
-static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList
*iface, REFIID riid, void **object)
+static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList2
*iface, REFIID riid, LPVOID *ppv)
{
- TRACE(iface %p, riid %s, object %p\n, iface, debugstr_guid(riid),
object);
+ struct taskbar_list *This = impl_from_ITaskbarList2(iface);
+
+ *ppv = NULL;
+
+ if(IsEqualGUID(IID_IUnknown, riid)) {
+ TRACE((%p)-(IID_IUnknown %p)\n, This, ppv);
+ *ppv = This-ITaskbarList2_iface;
+ }else if(IsEqualGUID(IID_ITaskbarList, riid)) {
+ TRACE((%p)-(IID_ITaskbarList %p)\n, This, ppv);
+ *ppv = This-ITaskbarList2_iface;
+ }else if(IsEqualGUID(IID_ITaskbarList2, riid)) {
+ TRACE((%p)-(IID_ITaskbarList2 %p)\n, This, ppv);
+ *ppv = This-ITaskbarList2_iface;
+ }
- if (IsEqualGUID(riid, IID_ITaskbarList)
- || IsEqualGUID(riid, IID_IUnknown))
- {
- IUnknown_AddRef(iface);
- *object = iface;
+ if(*ppv) {
+ IUnknown_AddRef((IUnknown*)*ppv);
return S_OK;
}
- WARN(%s not implemented, returning E_NOINTERFACE\n,
debugstr_guid(riid));
-
- *object = NULL;
+ WARN((%p)-(%s %p) interface not supported\n, This,
debugstr_guid(riid), ppv);
return E_NOINTERFACE;
}
I'm not sure that's really an improvement.
Re: shdocvw: Add ITaskbarList2 Interface
Am 20.06.2011 17:50, schrieb Henri Verbeet:
2011/6/18 André Hentschel n...@dawncrow.de:
-static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList
*iface, REFIID riid, void **object)
+static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList2
*iface, REFIID riid, LPVOID *ppv)
{
-TRACE(iface %p, riid %s, object %p\n, iface, debugstr_guid(riid),
object);
+struct taskbar_list *This = impl_from_ITaskbarList2(iface);
+
+*ppv = NULL;
+
+if(IsEqualGUID(IID_IUnknown, riid)) {
+TRACE((%p)-(IID_IUnknown %p)\n, This, ppv);
+*ppv = This-ITaskbarList2_iface;
+}else if(IsEqualGUID(IID_ITaskbarList, riid)) {
+TRACE((%p)-(IID_ITaskbarList %p)\n, This, ppv);
+*ppv = This-ITaskbarList2_iface;
+}else if(IsEqualGUID(IID_ITaskbarList2, riid)) {
+TRACE((%p)-(IID_ITaskbarList2 %p)\n, This, ppv);
+*ppv = This-ITaskbarList2_iface;
+}
-if (IsEqualGUID(riid, IID_ITaskbarList)
-|| IsEqualGUID(riid, IID_IUnknown))
-{
-IUnknown_AddRef(iface);
-*object = iface;
+if(*ppv) {
+IUnknown_AddRef((IUnknown*)*ppv);
return S_OK;
}
-WARN(%s not implemented, returning E_NOINTERFACE\n,
debugstr_guid(riid));
-
-*object = NULL;
+WARN((%p)-(%s %p) interface not supported\n, This,
debugstr_guid(riid), ppv);
return E_NOINTERFACE;
}
I'm not sure that's really an improvement.
I thought i use the way the webbrowser queryinterface in the same dll is
implemented.
Of course i can change less here.
--
Best Regards, André Hentschel
Re: [PATCH 2/3] server: Added server-side raw input function implementations (try 4)
On 06/20/2011 05:24 PM, Vitaliy Margolen wrote:
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote:
(see the message in the first part of the patch)
+struct raw_input
+{
+struct listentry;
+unsigned short usage_page;
+unsigned short usage;
+BOOL processed;
+BOOL retrieved;
+RAWINPUT raw;
+
+/* common fields */
+unsigned int type;
+unsigned int message;
+unsigned int flags;
+unsigned int extra_info;
+
+/* mouse fields */
+unsigned int point_x;
+unsigned int point_y;
+unsigned int mouse_data;
+unsigned int cursor_x;
+unsigned int cursor_y;
+
+/* keyboard fields */
+unsigned int vk_code;
+unsigned int scan_code;
+};
Mouse and keyboard fields should be a union to save space.
+#define NUM_RAW_DEVICES (sizeof( raw_devices ) / sizeof( struct raw_device
))
Please use sizeof(array)/sizeof(array[0]) construct instead.
+UINT i, size_in_bytes;
In server please use standard C types (unsigned int in this case).
+/* Currently fake handles are provided, however they are only used
for the GetRawInputDeviceInfo function,
+ thus it should not create any undesirable side effects */
+result[i].hDevice = (HANDLE)raw_devices[i].handle;
This doesn't sound right. What this handle can be used for?
+if (!(raw = malloc( sizeof( *raw ) )))
In server please use mem_alloc() instead.
+/* Unregister a raw input device */
+DECL_HANDLER(unregister_raw_input_device)
I don't see handing of case where device is not found. Should you return
error instead?
+LIST_FOR_EACH( registration_entry, current-process-raw_registered )
+{
+struct raw_registration *registration = LIST_ENTRY(
registration_entry, struct raw_registration, entry );
You can use this instead:
LIST_FOR_EACH_ENTRY( registration, current-process-raw_registered,
struct raw_registration, entry )
+/* Prevent unprocessed raw input entries from being queued indefinitely
*/
+while (current-process-raw_inputs_len = MAX_RAW_INPUT_QUEUE_LENGTH)
+{
+struct raw_input *head = LIST_ENTRY( list_head(
current-process-raw_inputs ), struct raw_input, entry );
+list_remove( head-entry );
+current-process-raw_inputs_len -= 1;
+free( head );
+}
Looks like you need a circular buffer (an array of fixed size with head and
tail pointers) instead of a list here.
Vitaliy.
I've updated the patch and replied -
http://www.winehq.org/pipermail/wine-patches/2011-June/103346.html
Re: shdocvw: Add ITaskbarList2 Interface (try 2)
Hello André, On 06/20/2011 10:01 PM, André Hentschel wrote: I should mention that i never added a interface before, neither one that extends an existing one. I want to stub out ITaskbarList3, so i thought i should first start with ITaskbarList2 and see what i'm doing right or wrong. this is a waste of time. Go straight for ITaskbarList3 as that inherits from ITaskbarList2. You would would just duplicate most of the work as you have to change again all the functions to take a ITaskbarList3 instead of a ITaskbarList2. This time i kept the implementation of QueryInterface as much as possible. bye michael
Re: Disablin xinput2 for now?
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard julli...@winehq.org wrote: Vitaliy Margolen wine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26aef7c82910d0b5). Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). -- -Austin
Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 5)
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=11852 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found
Regression today?
I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. wine-1.3.22-255-g4c0c0d3 Should I do a regression test and file a bug, or is it obvious from this? Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ wine natspeak err:service:service_send_start_message service LDragonSvc failed to start fixme:iphlpapi:NotifyAddrChange (Handle 0xc2e91c, overlapped 0xc2e900): stub wine: configuration in '/home/susan/.wine' has been updated. fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:wbem_locator_ConnectServer 0x134288, LROOT\\CIMV2, (null), (null), (null), 0x, (null), (nil), 0xfcea54) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0xfcea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\WMI, (null), (null), (null), 0x, (null), (nil), 0xfcea54) fixme:reg:RegSetKeySecurity :(0x60,4,0xd9ba9c): stub fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$
Re: Regression today?
On Mon, Jun 20, 2011 at 21:00, Susan Cragin susancra...@earthlink.net wrote: I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. wine-1.3.22-255-g4c0c0d3 Should I do a regression test and file a bug, or is it obvious from this? Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ wine natspeak err:service:service_send_start_message service LDragonSvc failed to start fixme:iphlpapi:NotifyAddrChange (Handle 0xc2e91c, overlapped 0xc2e900): stub wine: configuration in '/home/susan/.wine' has been updated. fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:wbem_locator_ConnectServer 0x134288, LROOT\\CIMV2, (null), (null), (null), 0x, (null), (nil), 0xfcea54) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0xfcea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\WMI, (null), (null), (null), 0x, (null), (nil), 0xfcea54) fixme:reg:RegSetKeySecurity :(0x60,4,0xd9ba9c): stub fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, LROOT\\CIMv2, (null), (null), (null), 0x, (null), (nil), 0x10cea5c) susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ A regression test would be most helpful, though it's hard to say without knowing what the problem you're seeing is.. -- -Austin
Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation
On 20 June 2011 23:52, Vitaliy Margolen wine-de...@kievinfo.com wrote:
+ SERVER_START_REQ( create_snapshot )
You not checking if this call succeeded or not.
I've tried to include all the checks in the new patch.
+ while (sizeof(ULONG) +
sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count = len)
You don't need a loop to calculate new size.
I've done this a different way in the new patch which avoids the reallocs.
You leaking old shi here. Also why do you need to zero allocated memory if
you assigning all of it valid values?
Not all of the values are assigned. Only the handle pid is accessible
with the current wineserver protocol. The remainder of the fields are
best set to zero as this is a sane value for these fields to trigger
exceptions and figure out how/when these values are being accessed
(e.g. null pointers or null handles). Later patches, which I have
already sent, try to fill in more of these fields.
From 8e9631f10f5da50792fd4bc825c6f4b0f8ecac5c Mon Sep 17 00:00:00 2001
From: Austin Lund austin.l...@gmail.com
Date: Sun, 12 Jun 2011 19:41:18 +1000
Subject: [PATCH] dlls/ntdll: Add handle count to NtQuerySystemInformation (try 2)
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/ntdll/nt.c | 109 +++---
dlls/ntdll/tests/info.c |8 +---
2 files changed, 103 insertions(+), 14 deletions(-)
diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c
index f9302c1..b460aaa 100644
--- a/dlls/ntdll/nt.c
+++ b/dlls/ntdll/nt.c
@@ -1655,18 +1655,111 @@ NTSTATUS WINAPI NtQuerySystemInformation(
break;
case SystemHandleInformation:
{
-SYSTEM_HANDLE_INFORMATION shi;
+SYSTEM_HANDLE_INFORMATION *shi;
+HANDLE hSnap = 0;
+int handle_count, process_handles, i;
+process_id_t pid;
-memset(shi, 0, sizeof(shi));
-len = sizeof(shi);
+FIXME(info_class SYSTEM_HANDLE_INFORMATION partial implementation\n);
-if ( Length = len)
+SERVER_START_REQ( create_snapshot )
{
-if (!SystemInformation) ret = STATUS_ACCESS_VIOLATION;
-else memcpy( SystemInformation, shi, len);
+req-flags = SNAP_PROCESS;
+req-attributes = 0;
+if (!(ret = wine_server_call( req )))
+hSnap = wine_server_ptr_handle( reply-handle );
}
-else ret = STATUS_INFO_LENGTH_MISMATCH;
-FIXME(info_class SYSTEM_HANDLE_INFORMATION\n);
+SERVER_END_REQ;
+
+if (hSnap == 0) return ret;
+
+handle_count = 0;
+
+for (;;)
+{
+SERVER_START_REQ( next_process )
+{
+req-handle = wine_server_obj_handle( hSnap );
+req-reset = 0;
+ret = wine_server_call( req );
+process_handles = reply-handles;
+}
+SERVER_END_REQ;
+
+if (ret == STATUS_SUCCESS)
+handle_count += process_handles;
+else break;
+}
+
+if (ret != STATUS_NO_MORE_FILES)
+{
+NtClose(hSnap);
+return ret;
+}
+
+len = sizeof(ULONG) + handle_count*sizeof(SYSTEM_HANDLE_ENTRY);
+
+if (len Length)
+{
+NtClose(hSnap);
+ret = STATUS_INFO_LENGTH_MISMATCH;
+break;
+}
+
+shi = RtlAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
+if (shi == NULL)
+{
+NtClose(hSnap);
+ret = STATUS_NO_MEMORY;
+break;
+}
+
+SERVER_START_REQ( next_process )
+{
+req-handle = wine_server_obj_handle( hSnap );
+req-reset = 1;
+ret = wine_server_call( req );
+process_handles = reply-handles;
+pid = reply-pid;
+}
+SERVER_END_REQ;
+
+for (;;)
+{
+if (ret != STATUS_SUCCESS) break;
+
+for (i = 0; i process_handles; i++)
+{
+shi-Handle[shi-Count + i].OwnerPid = pid;
+}
+shi-Count += process_handles;
+
+SERVER_START_REQ( next_process )
+{
+req-handle = wine_server_obj_handle( hSnap );
+req-reset = 0;
+ret = wine_server_call( req );
+process_handles = reply-handles;
+pid = reply-pid;
+}
+SERVER_END_REQ;
+}
+
+NtClose(hSnap);
+
+if (ret != STATUS_NO_MORE_FILES)
+{
+RtlFreeHeap(GetProcessHeap(), 0, shi);
+
Re: Disablin xinput2 for now?
On 06/20/2011 02:31 PM, Austin English wrote: On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulli...@winehq.org wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26aef7c82910d0b5). Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). Can you check how well it works with wine-1.3.19 - before all xinput2 related changes went in? Vitaliy.
Re: Disablin xinput2 for now?
On 06/20/2011 08:36 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). Dinput never perfectly worked before and doesn't work perfectly now. Even native has serious issues in Wine. I've lost track of all the changes you did to mouse/keyboard events, ll hooks, pointer position changes, etc. But it seems to me something broke that was working before. At least did not affect programs as much as it does now. I've seen number of programs/games that were highly sensitive to timing and order of various events. Unfortunately it was impossible to exactly replicate and/or make a test for it. And with dynamic nature of the problem it's a royal PITA to debug. In either case, it seems that what used to more-less work before doesn't work at all. Or has major problems (non-xinput2 code-path). And the new xinput2 code-path while resolving large number of issues, introduced number of other problems. So just disabling xinput2 support in any a binary build won't really help much. Vitaliy.
Re: [PATCH 3/6] dinput: SetActionMap setting the device buffer.
On 06/20/2011 04:06 PM, Lucas Fialho Zawacki wrote:
@@ -1391,9 +1391,24 @@ HRESULT WINAPI
IDirectInputDevice8AImpl_SetActionMap(LPDIRECTINPUTDEVICE8A iface
LPCSTR lpszUserName,
DWORD dwFlags)
{
...
+hr = IDirectInputDevice8_SetActionMap(This-IDirectInputDevice8W_iface,
+diafW, NULL, dwFlags);
You need to call IDirectInputDevice8WImpl_SetActionMap directly here. Also
please don't wrap lines at 80 characters, you can put all that into one
line. And please be consistent with spacing around parentheses - either put
spaces on both sides, or don't put at all.
+memset(dp,0,sizeof(dp));
Please don't needlessly zero structures. You setting most values of it
anyway. And please don't forget spaces after comas.
Otherwise looks really good!
Vitaliy.
Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation
On 06/20/2011 09:36 PM, Austin Lund wrote: On 20 June 2011 23:52, Vitaliy Margolenwine-de...@kievinfo.com wrote: +SERVER_START_REQ( create_snapshot ) You not checking if this call succeeded or not. I've tried to include all the checks in the new patch. +while (sizeof(ULONG) + sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count= len) You don't need a loop to calculate new size. I've done this a different way in the new patch which avoids the reallocs. You leaking old shi here. Also why do you need to zero allocated memory if you assigning all of it valid values? Not all of the values are assigned. Only the handle pid is accessible with the current wineserver protocol. The remainder of the fields are best set to zero as this is a sane value for these fields to trigger exceptions and figure out how/when these values are being accessed (e.g. null pointers or null handles). Later patches, which I have already sent, try to fill in more of these fields. Makes sense. The patch looks good to me. Vitaliy.
