December 2009 - Wine-devel - list.winehq.org

Re: [1/6]user32:SwitchDesktop API Implementation (try 2)
by Vitaliy Margolen 13 Dec '09

13 Dec '09

shanmukha sainath addepalli wrote: > Hi, > > These are the series of patches for the Implementation of > SwitchDesktop and OpenInputDesktop API in user32.dll. SwitchDesktop > API is useful for switching between two desktops. Multi desktop > applications use this API functionality to switch between desktops. > Each patch have to be atomic - it should compile on it's own and work. This and other patches in your series won't compile / work. > + SERVER_START_REQ( switch_desktop ) Here you depend on a service call that's not yet defined. Wine will not compile this way. Vitaliy.

1 0

Interfacing with AppDB database
by Sean Hodges 13 Dec '09

13 Dec '09

Hey all, I'm hoping to write an application that interfaces with the AppDB database. Can anyone point me in the direction of who I can contact over this? There appears to be no Web service or obvious way to query AppDB beyond navigating the site itself. Could you CC me in any replies as well, as I'm not subscribed to this list. Thanks, Sean

3 2

Re: mshtml: Implement IHTMLImgElement get_Name
by Paul Vriens 13 Dec '09

13 Dec '09

On 12/13/2009 12:11 PM, Alistair Leslie-Hughes wrote: > + ok_(__FILE__,line) (!lstrcmpW(sNameImage, tmp), "expected '%s' got '%s'\n", wine_dbgstr_w(sNameImage), wine_dbgstr_w(tmp)); Hi Alistair, Could you use strcmp_wa instead of lstrcmpW as that function is not present on Win9x/WinMe? -- Cheers, Paul.

1 0

meaning of "Hardware" field in bugzilla?
by Dan Kegel 13 Dec '09

13 Dec '09

Does "mac" mean "powerpc mac only"? I rather thought it meant "apple macintosh", regardless of cpu. I ask because Austin has just gone through and changed lots of "mac" bugs to "pc" even though the bugs were on Intel macs, which just seems wrong.

8 8

Sound concerns
by Maarten Lankhorst 12 Dec '09

12 Dec '09

Hi all, I believe most oconcerns about OpenAL have been addressed. One of the open questions was whether midi and wave would be synced. And I think the most likely answer is that they aren't, even on windows. On windows winmm midi drivers use winmm timeGetTime or QueryPerformanceCounter for DirectMusic. Sample accurate wave is used to sync with midi, by using exclusive mode or the asio model. If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl Cheers, Maarten.

3 5

Re: [3/3] winex11.drv: Use the old method to delete the desktop window.
by Alexandre Julliard 11 Dec '09

11 Dec '09

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd, XClientMessageEvent *event ) > HMENU hSysMenu; > POINT pt; > > + if (hwnd == GetDesktopWindow()) > + { > + /* The desktop window does not have a close button that we can > + * pretend to click. Therefore, we simply send it a close command. */ > + PostMessageW( hwnd, WM_X11DRV_DELETE_WINDOW, 0, 0 ); > + return; > + } You could just as well send the WM_SYSCOMMAND directly. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WineD3D: Frontbuffers are always onscreen
by Henri Verbeet 11 Dec '09

11 Dec '09

2009/12/10 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -6304,7 +6304,7 @@ HRESULT create_primary_opengl_context(IWineD3DDevice *iface, IWineD3DSwapChain * ... > - swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; > + swapchain->context[0]->render_offscreen = surface_is_offscreen(target); This will introduce a warning, surface_is_offscreen() takes an IWineD3DSurface pointer. > - > - swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; ... > + if(swapchain->context[0]) > + { > + swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; > + } That's pretty ugly, couple of points: - It doesn't make sense for "render_to_fbo" to be TRUE for a swapchain without back buffer. - Setting "render_offscreen" is really the responsibility of the context_create() call, similar to create_primary_opengl_context(). - The line is actually wrong, the relevant context has been setup to render to the front buffer, so "render_offscreen" should always be FALSE, even if there is a back buffer.

2 6

Valgrind errors: 893 leaks, 105 conditional depends on uninit, 63 invalid read, 12 invalid write, ...
by Dan Kegel 11 Dec '09

11 Dec '09

Here's a more detailed breakdown of the current valgrind warnings when running the wine test suite as of yesterday, with the ntdll/heap warnings suppressed (as they will be from now on): 1 --25396-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting 1 vex x86->IR: unhandled instruction bytes: 0xFB 0xC3 0x0 0x0 2 Source and destination overlap 3 Use of uninitialised value of size 4 4 Invalid read of size 1 4 Invalid write of size 4 4 Unhandled exception: illegal instruction 5 Unhandled exception: page fault on write 7 Unhandled exception: page fault on read 7 Invalid free() / delete / delete[] 8 Invalid write of size 1 14 Syscall param writev(vector[...]) points to uninitialised byte(s) 19 Invalid read of size 4 40 Invalid read of size 2 105 Conditional jump or move depends on uninitialised value(s) 893 X bytes are definitely lost I think *all* the remaining invalid write errors are bogus, either they're in GetDIBits, in a video driver, or in the stack backtracing code. All of the remaining invalid free errors are in the oleaut32 vartype test: Invalid free() / delete / delete[] at notify_free (heap.c:255) by RtlFreeHeap (heap.c:1748) by SysFreeString (oleaut.c:194) by test_VarBstrFromDate (vartype.c:4910) by func_vartype (vartype.c:6276) by run_test (test.h:535) by main (test.h:585) Address 0x7f0a1560 is not stack'd, malloc'd or (recently) free'd for which I've filed http://bugs.winehq.org/show_bug.cgi?id=20992

1 0

UNC Pathname handling
by Alexandre Hardy 11 Dec '09

11 Dec '09

Hi, I have written a patch to add basic UNC pathname support which tries to handle UNC pathnames according to the MSDN spec. The patch satisfies some of the UNC pathname tests for GetLongPathNameA, but is actually intended to fix GetLongPathNameW. I am not entirely satisfied with the patch, and would appreciate some comments. Some issues: 1) Paths prefixed by '\\?\' require GetLongPathName to handle strings of length 32767. I don't like the fact that the patch creates two such large strings on the local stack, should the memory be dynamically allocated only when needed? 2) The handling of shares \\hostname\C$ is implemented, but no other shares are handled. And even in this case, only the host on which wine is executed is handled, no other hosts are handled. I have read that Windows 7 disables this share by default. So should wine be handling this particular URL, or should more general sharing be implemented? The patch is included as an attachment to this message. Kind regards Alexandre -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

2 16

Re: shdocvw: Fix test for non-english IE MUI (try 2)
by Nicolas Le Cam 11 Dec '09

11 Dec '09

2009/12/11 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > shdocvw: Fix test for non-english IE MUI > > Best Regards > Alistair Leslie-Hughes > > > > Hi Alistair, - ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); + if (PRIMARYLANGID(LANGIDFROMLCID(GetThreadLocale())) == LANG_ENGLISH) + ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); + else /* Non-English cannot be blant. */ + ok(sName!=NULL, "get_Name return a NULL string.\n"); Did you mean blank ? -- Nicolas Le Cam

1 0