March 2011 - Wine-devel - list.winehq.org

Re: mshtml: Fixed node leak in HTMLEventObj
by Alexandre Julliard 29 Mar '11

29 Mar '11

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlevent.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This causes the mshtml:events test to hang for me. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/4] comdlg32: Add implementation of DllRegisterServer/DllUnregisterServer. (resend)
by Alexandre Julliard 29 Mar '11

29 Mar '11

David Hedberg <david.hedberg(a)gmail.com> writes: > @@ -274,3 +277,82 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) > > return CLASS_E_CLASSNOTAVAILABLE; > } > + > +/*********************************************************************** > + * Register/Unregister DLL, based on shdocvw/factory.c > + */ You should use the new IRegistrar mechanism instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: RFC: Remove unimplemented application menus?
by James McKenzie 29 Mar '11

29 Mar '11

On 3/28/11 9:28 AM, André Hentschel wrote: > Am 28.03.2011 17:27, schrieb James McKenzie: >> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>> menus. That is you can see the menu entry but clicking on it only gives >>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>> of iexplore). For instance just for the first two winefile menus none >>>> of the following are implemented: >>>> >>>> File -> Print... >>>> File -> Associate... >>>> File -> Search... >>>> File -> Select Files... >>>> Disk -> Share as... >>>> Disk -> Remove Share... >>>> Disk -> Select Drive... >>>> >>>> >>>> I think such a situation is bad: >>>> * Having tons of unimplemented menus looks amateurish. >>>> * It's very confusing. You see tons of menus except over 50% of them >>>> don't work. So it makes the GUI more complex with no benefit. >>>> * I suspect most of these menus have been unimplemented for years >>>> so there is little hope of seeing them improve any time soon. >>>> * For a number of them it's questionable whether it makes sense to >>>> implement them in Wine at all as they correspond to tasks that >>>> better belong to the native system facilities (Share as for >>>> instance). >>>> * I doubt they serve any significant compatibility purpose. >>>> * In the mean time they generate more work for translators and >>>> translation reviewers. >>>> * It generates more work for anyone checking whether the GUI is >>>> consistent / follows human interface guidelines (wrt. ellipses for >>>> instance). >>>> >>>> So I propose to simply remove unimplemented menus. When / if someone >>>> ever decides to implement some of the corresponding functionality, >>>> adding the corresponding code and GUI bits back should not be too hard. >>>> >>>> Objections? >>>> >>> Good Idea, at least for the year old stub menus (like winefile). >>> For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>> >> I agree. This was proposed as a GOSC project by one of the people. >> There is a thread on Wine Users about these menus being >> 'unimplemented' and how they should be. Would this be a good item for >> a bug report for an Request for Enhancement? > IMHO no, there is no point i think. > PS: is this meant to be also sent to wine-devel? > > Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Sorry, but I hit the reply button and not reply to all when I responded to you. My apologies. James McKenzie

2 6

[GSoC] Message mode pipes proposal
by Bryan Donlan 28 Mar '11

28 Mar '11

Hi, all, >From the GSoC project ideas page, I became interested in the proposal for implementing message-based pipes (see bug: http://bugs.winehq.org/show_bug.cgi?id=17195) The most recent patches to the bug cited above appear to use a separate socketpair for each message sent down the pipe, and must make potentially multiple wineserver calls for each interaction with the pipe. This will clearly begin to have problems once a large number of file descriptors are in the air. While a discussion on #winehackers suggested that implementing message-based pipes efficiently and safely entirely in userspace would be quite difficult, I feel that implementing a _correct_ implementation (regardless of efficiency) would be a practical goal. After creating a correct implementation, work could then be done to improve performance. First, a bit about me: I am a computer science student at the University of Massachusetts, heading into my senior year. I have had a lot of experience with Linux development, somewhat less on the Windows side. I am fluent in English and Japanese, although I doubt Japanese language experience would be helpful for this project :) In previous summer internships I have developed code for interprocess communication; in one instance, I wrote a ring buffer synchronization protocol to transfer data from a Windows user-space program to a real-time process running in kernel-mode (hosted via a third-party Windows real-time HAL). I propose the following overall plan: * First, I will prepare a comprehensive test suite for message-based pipes. Benchmarks would also be prepared to help determine whether optimization is necessary. This will likely borrow from the tests already posted to the bug I linked above. * I will write a wineserver-internal implementation of message-based pipes. That is, all NtReadFile/NtWriteFile() requests would be completely redirected to wineserver; there would be no attempt to expose a file descriptor for the client process to access directly. Wineserver in turn would simply manage a simple, in-memory queue of messages. Although this is unscalable and has a lot of context switch and copying overhead, it is simple, and would allow programs making light usage of message-based pipes to work. It also provides a clear place to hook on a new, faster protocol that requires a custom NtReadFile/NtWriteFile. After this point, I will begin work on optimizing the implementation. Some ideas on how to do this might include: * Implement the pipe using a ring buffer in shared memory. Client processes can then directly access the pipe buffer to pass data without wineserver's involvement. This has the downside that a user-mode process can inadvertently corrupt the pipe's state; this may be acceptable if the effects can be limited to a trashed pipe buffer, instead of crashing unrelated processes. * Implement the pipe using a ring buffer in shared memory, but expose only a read-only file descriptor to client processes. This avoids the corruption issues, but writes must be managed by the server and will incur overhead. * Implement the pipe as a single server-managed socketpair over which shared memory backing files are passed with SCM_RIGHTS, plus a lock (possibly implemented in shared memory using futexes, or by flock on a /dev/shm file). Clients acquire the lock, then MSG_PEEK the socketpair to retrieve an anonymous (unlinked immediately after creation) shared memory file descriptor. The shared memory buffer holds a count of remaining bytes, plus the actual message data. Clients then perform a normal recvmsg() to dequeue the message if they successfully retrieved the entire message. This approach is complex, and it is unclear what the performance impacts of having so many files being thrown around would be. However, it does avoid the context-switch costs and wineserver load that are a problem in the implementations currently on the bug tracker. * Implement a Linux kernel module to implement message-based pipe semantics natively. Although quite efficient, this will only apply to Linux, and may introduce difficulty keeping up with Linux kernel changes in the future. It is also unclear whether distributions and/or upstream Linux maintainers will welcome this approach. I will likely end up trying out several of these approaches and comparing actual performance results. Finally, if time allows, I will also investigate integration with samba, in order to support connecting to named pipes on remote servers. I would appreciate any comments on this proposal prior to actual submission. Thanks, Bryan Donlan

1 0

Re: [PATCH 4/6] mshtml/tests: Added IDocObjectService interface
by Marvin 28 Mar '11

28 Mar '11

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=10180 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\mshtml_test.exe, error 32

1 0

Re: wininet: Port numbers are unsigned (more)
by Dan McDonald 28 Mar '11

28 Mar '11

On 03/28/2011 01:40 PM, André Hentschel wrote: > - static const WCHAR percentD[] = {'%','d',0}; > + static const WCHAR percentD[] = {'%','u',0}; Variable name change may be in order here. Dan

2 1

Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Rico Schüller 28 Mar '11

28 Mar '11

Hi, this and the previous patch (1/5) are doing the same thing? Is there a reason why they could not use the same code base? e.g. ID3DXConstantTable_SetIntArray(iface, device, constant, n, count) { return ID3DXConstantTable_SetFloatArray(iface, device, constant, n, count); } Also I'd prefer if there would be TRACEs in each function. It might be useful to add the RegisterSet in the FIXME for the default case, to see which one is missing in the special case. Cheers Rico Am 27.03.2011 22:22, schrieb Travis Athougies: > --- > dlls/d3dx9_36/shader.c | 37 ++++++++++++++++++++++++++++++------- > 1 files changed, 30 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 4a3caab..874d916 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -847,11 +847,7 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetBoolArray(ID3DXConstantTable* if > > static HRESULT WINAPI ID3DXConstantTableImpl_SetInt(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, D3DXHANDLE constant, INT n) > { > - ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > - > - FIXME("(%p)->(%p, %p, %d): stub\n", This, device, constant, n); > - > - return E_NOTIMPL; > + return ID3DXConstantTable_SetIntArray(iface, device, constant,&n, 1); > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, > @@ -859,9 +855,36 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* ifa > { > ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > > - FIXME("(%p)->(%p, %p, %p, %d): stub\n", This, device, constant, n, count); > + D3DXCONSTANT_DESC desc; > + HRESULT hr; > + UINT i, desc_count = 1; > + float row[4] = {0.0f, 0.0f, 0.0f, 0.0f}; > + > + hr = ID3DXConstantTable_GetConstantDesc(iface, constant,&desc,&desc_count); > + if (FAILED(hr)) > + { > + TRACE("ID3DXConstantTable_GetConstantDesc failed: %08x", hr); > + return D3DERR_INVALIDCALL; > + } > > - return E_NOTIMPL; > + switch (desc.RegisterSet) > + { > + case D3DXRS_FLOAT4: > + for (i = 0; i< count&& i< desc.RegisterCount; i++) > + { > + row[0] = n[i]; > + if (is_vertex_shader(This->desc.Version)) > + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + else > + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + } > + break; > + default: > + FIXME("Can't handle RegisterSets other than D3DXRS_FlOAT4\n"); > + return E_NOTIMPL; > + } > + > + return D3D_OK; > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetFloat(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device,

3 2

Re: [4/4] d3d9: Test depth stencil size mismatches
by Henri Verbeet 28 Mar '11

28 Mar '11

This fails for me on native (Windows 7, Radeon HD 6950): visual.c:11813: Test failed: DS size test: Pixel (2, 2) after clear is 0xff0000, expected 0x000000FF visual.c:11815: Test failed: DS size test: Pixel (31, 31) after clear is 0xff0000, expected 0x000000FF visual.c:11817: Test failed: DS size test: Pixel (32, 32) after clear is 0xff0000, expected 0x000000FF visual.c:11819: Test failed: DS size test: Pixel (63, 63) after clear is 0xff0000, expected 0x000000FF visual.c:11825: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE. visual.c:11832: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE.

2 1

Re: [1/7] urlmon: Removed str_last_of in favor of strnrchrW
by Alexandre Julliard 28 Mar '11

28 Mar '11

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/uri.c | 27 ++++++--------------------- > dlls/urlmon/urlmon_main.h | 14 ++++++++++++++ > 2 files changed, 20 insertions(+), 21 deletions(-) > From 7528b6b58256cba3ef53937e0ff7dbc3593f684a Mon Sep 17 00:00:00 2001 > From: Thomas Mullaly <tmullaly(a)codeweavers.com> > Date: Sun, 20 Mar 2011 16:28:59 -0400 > Subject: urlmon: Removed str_last_of in favor of strnrchrW It's called memrchrW. -- Alexandre Julliard julliard(a)winehq.org

1 0

winmm & concurrency
by Joerg-Cyril.Hoehle＠t-systems.com 28 Mar '11

28 Mar '11

Hi, I've had a hard time finding information about what kind of guarantees MS makes for concurrency in the winmm function set. The best I've found so far is a 2005 blog entry written by Larry Osterman. Concurrency, part way too many2 - Concurrency and the Win32 API set http://blogs.msdn.com/b/larryosterman/archive/2005/03.aspx "I implicated the concurrency issues when I mentioned that all DLLs need to be multi-thread safe [...]" "The Windows MME APIs (waveOutXxx, waveInXxx, mixerXxx, etc) also protect their internal data structures. But they also support callback functions [...]" That's short. If you find anything else, please tell me. The irritating thing about Wine bug #9026 (waveOutReset during waveOutClose) and bug #22978 (MCI_CLOSE) is that they involve no concurrency from the app's POV. In both cases, the app issues a sequence of PlaySound resp. mciSendCommand from a single thread. Concurrency appears as Wine internally makes use of player threads. Regards, Jörg Höhle

1 0