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

Re: [1/2] winefile: Remove unimplemented menu entries.
by James McKenzie March 30, 2011

March 30, 2011

On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: > They unnecessarily clutter the GUI and are unlikely to ever be implemented. > --- > > As discussed on wine-devel. > I still left Rename and Create Directory because they are basic > functions that should really be there (but I won't implement them). Thank you Francois. These should only be brought back with a full implementation of the underlying code, if it is really needed. James McKenzie

1 0

Re: semi-obsolete audio drivers
by Andrew Eikum March 30, 2011

March 30, 2011

On 03/30/2011 09:23 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew, > > [good news, esp. the time-line] Let's hope I can stick to it :-P. It's looking good, though. >>OSSv4 (complete) > Do you specifically use OSS *v4* functions not available earlier? > (I'm not familiar with OSS4, even though I consult their docu online > and hope that what they write also applies to my machine with OSS v3 (Ubuntu)). I wrote it following the OSSv4 spec and using an OSSv4 implementation, so I suspect it won't work on OSSv3. I thought about supporting OSSv3, but I think it's not worth the effort -- that's a really old version that, when written, didn't support multiple clients simultaneously, had no mixer, etc. OSSv4 has a lot of features that make the driver much simpler. Further, I think only Linux is still stuck on OSSv3. I looked at a number of other operating systems, mostly BSDs and Solaris, and they all use OSSv4 by default. So I think Linux users should be covered by ALSA or PulseAudio (or perhaps JACK), and the much-more-pleasant OSSv4 is available for BSDs and Solaris. If a Linux user really wants OSS, I think they should probably upgrade to OSSv4 anyway. I could look at making it OSSv3 compatible, but I just think it's not worth the effort of supporting such an old and cantankerous API. Andrew

1 0

semi-obsolete audio drivers
by Joerg-Cyril.Hoehle＠t-systems.com March 30, 2011

March 30, 2011

Hi, you may have noticed that I've always sent patches for the 3 audio drivers that I consider current and mostly up to date: + winealsa + wineoss + winecoreaudio and never for one of the other ones which I consider obsolete. - winejack - wineesd - winenas Sometimes I've been wondering whether I should include and take care of winejack too, although I've neither the jack development package nor do I know or use any software that uses Jack. As for the others, I really consider them obsolete and never look at them. This is not entirely satisfactory, as I've been blaming (in thoughts) the one or other developer who in the past fixed a bug in one of the drivers without fixing the same bug in the other ones... Code continues to diverge... What do you think? - Why did people submit patches to one driver only when a short glance shows that the same bug is in the other cloned drivers too? - Is WineJack "current" and worth some effort? - Let the others continue to decay? - Remove them from git? Please don't shout for maintenance by others too early: how much time do *you* invest in making Wine better? Regards, Jörg Höhle

2 1

Re: [PATCH 1/6] winmm: Check callback flags prior to opening a driver.
by Marvin March 30, 2011

March 30, 2011

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=10217 Your paranoid android. === WXPPROSP3 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K3R2SESP2 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === WVISTAADM (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K8SE (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PRO (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (64 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR

1 0

Re: [06/10] msi: Accept whitespace-only property values on the command line.
by Marvin March 30, 2011

March 30, 2011

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=10214 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Re: [02/10] msi/tests: Get rid of workarounds for win9x test failures.
by Marvin March 30, 2011

March 30, 2011

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=10212 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Rico Schüller March 30, 2011

March 30, 2011

Forwarding to the list. Am 28.03.2011 20:47, schrieb David Laight: >> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > > David > My example wasn't very well chosen. So conversation (casts) between the different types is necessary. It was meant the way to reuse some of the code. Because I think ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetFloatArray could share a lot of code. This will probably be the same for ID3DXConstantTable_SetBoolArray. Cheers Rico

1 0

Re: [01/10] msi: Ignore invalid upgrade codes in the PublishProduct action.
by Marvin March 30, 2011

March 30, 2011

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=10211 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6052: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Travis Athougies March 30, 2011

March 30, 2011

>> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > Exactly. Which is why I am not ever casting int pointers to float pointers as Rico suggested. Instead I'm looping through the array and casting each int to a float, which should invoke the machinery necessary to convert from the bit representation of an int to that of a float. > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > If I'm casting ints to floats (and not int pointers to float pointers) I don't see how this could be an issue. Travis -- Travis Athougies

1 0

[RFC] dinput: Length can actually be 0.
by Vincent Pelletier March 30, 2011

March 30, 2011

(Sorry for sending to wine-patches initially, it was intended for wnie-devel.) This fixes force feedback devices slamming for 10ms at full strength, as attack is an absolute value, not a factor of effect level. Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure which combination) cause the effect to be not played (possibly played with 0- level) on devices using the Linux iforce driver. This is the reason of the comment in the code. But to other drivers, such as hid-ff, this code causes the device to jump as full strength, which was reported (to me directly) for example when playing "Live for Speed"[1] with a steering wheel having strong force feedback (Logitech G27). My question: Is it acceptable to risk some regression for iforce driver (until bug is identified) to fix other devices ? I guess iforce devices also suffer from the too-strong attack/fade effect. [1] http://www.lfs.net (demo available, I didn't try it) --- dlls/dinput/effect_linuxinput.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c index fbc5994..0154f49 100644 --- a/dlls/dinput/effect_linuxinput.c +++ b/dlls/dinput/effect_linuxinput.c @@ -606,13 +606,12 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( else env = NULL; if (peff->lpEnvelope == NULL) { - /* if this type had an envelope, reset it - * note that length can never be zero, so we set it to something minuscule */ + /* if this type had an envelope, reset it */ if (env) { - env->attack_length = 0x10; - env->attack_level = 0x7FFF; - env->fade_length = 0x10; - env->fade_level = 0x7FFF; + env->attack_length = 0; + env->attack_level = 0; + env->fade_length = 0; + env->fade_level = 0; } } else { /* did we get passed an envelope for a type that doesn't even have one? */ -- 1.7.4.1

2 1

today's git failed to build for me
by Susan Cragin March 30, 2011

March 30, 2011

I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

3 2

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.
by David Adam March 29, 2011

March 29, 2011

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

1 0

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.
by Roderick Colenbrander March 29, 2011

March 29, 2011

I'm not sure if the only value error wglMakeCurrent should return is INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid context? The return value may be similar, but don't remember for sure. Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.
by Roderick Colenbrander March 29, 2011

March 29, 2011

The fact that a pixel format is not set on the physDev doesn't necessarily mean it is invalid, it just means SetPixelFormat wasn't called on it. Though slightly earlier in wglMakeCurrent we already catch that situation when compare the pixel format of the context and the hdc. Is there not something better for which we could check? Is the drawable of the physDev perhaps something to check for? (I have no idea in what state the physDev is after a destroy window; should we be able to enter x11drv at all? perhaps this should be handled inside the gdi32 code, just a thought) Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: wldap32: Accept a NULL value in ldap_set_option.
by Marvin March 29, 2011

March 29, 2011

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=10187 Your paranoid android. === WNT4WSSP6 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059 === W2KPROSP4 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059

1 0

Re: mshtml: Fixed node leak in HTMLEventObj
by Alexandre Julliard March 29, 2011

March 29, 2011

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 March 29, 2011

March 29, 2011

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 March 29, 2011

March 29, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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 March 28, 2011

March 28, 2011

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