- wine-devel - winehq.org

Re: psapi/tests: Don't check for exact value (try 7)
by Marvin 20 Sep '15

20 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16805 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 No test summary line found === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 No test summary line found

2 1

Wine test update
by Jeremy White 20 Sep '15

20 Sep '15

We reviewed my list of interesting test bot vm failures: https://www.winehq.org/~jwhite/latest.html and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. The following glorious people volunteered to work on one or more of these issues: Andrew, Alexandre, Aric, Francois, Huw, Stefan, Piotr, Jacek, Qian, Hans, and Sebastian, and I've emailed Bruno to ask him to look into one. Cheers, Jeremy

2 1

Winsock 2
by Christopher Harrington 20 Sep '15

20 Sep '15

I'm looking at trying to implement some of the Winsock 2 stubs, namely WSALookupServiceBegin/Next/End. I'm probably only going to implement enough of it that my target binary will stop bailing out with "out of memory". I suspect the app is using it to resolve DNS... Am I stepping on anyone's toes? If not, can someone point me at the right place to look for where wine is currently doing DNS lookups so I can reuse that non-broken code? Thank you in advance. -Chris Harrington

3 4

Changes for Wine on Debian
by Kyle Auble 20 Sep '15

20 Sep '15

Hi everyone, I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now. Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons. When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself. - Kyle

4 8

RFC - oleaut32: Cope with invalid icon data
by Bruno Jesus 19 Sep '15

19 Sep '15

While testing bug [1] I noticed that invalid data is sent to OLEPictureImpl_LoadIcon. This patch is meant to resist these kind of issues and makes the game goes on a little further until other crash. I'm sending this as RFC because I don't know then icon structure but my tests seem very straight forward from what I can guess from the function. [1] https://bugs.winehq.org/show_bug.cgi?id=21012 Thanks in advance and best regards, Bruno

1 0

No release this week
by Alexandre Julliard 18 Sep '15

18 Sep '15

Hey guys, Because of WineConf, it looks like I won't be able to make a release today. And since I'll be taking some vacation next week, I plan to release 1.7.52 on Friday two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: TRACE fixes. (try 2)
by Henri Verbeet 18 Sep '15

18 Sep '15

On 16 September 2015 at 14:39, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > @@ -1243,7 +1243,7 @@ static int context_choose_pixel_format(const struct wined3d_device *device, HDC > unsigned int cfg_count = device->adapter->cfg_count; > unsigned int i; > > - TRACE("device %p, dc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > + TRACE("device %p, hdc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > device, hdc, debug_d3dformat(color_format->id), debug_d3dformat(ds_format->id), > auxBuffers, findCompatible); This isn't wrong, but I'd be more inclined to change the parameter to match the trace than the other way around. > @@ -157,8 +157,8 @@ HRESULT CDECL wined3d_palette_create(struct wined3d_device *device, DWORD flags, > struct wined3d_palette *object; > HRESULT hr; > > - TRACE("device %p, flags %#x, entries %p, palette %p.\n", > - device, flags, entries, palette); > + TRACE("device %p, flags %#x, entry_count %d, entries %p, palette %p.\n", > + device, flags, entry_count, entries, palette); Unsigned values should use %u instead of %d. > @@ -114,7 +114,7 @@ enum wined3d_event_query_result wined3d_event_query_finish(const struct wined3d_ > const struct wined3d_gl_info *gl_info; > enum wined3d_event_query_result ret; > > - TRACE("(%p)\n", query); > + TRACE("(%p, %p)\n", query, device); This isn't wrong per se either, but I'd prefer that as "query %p, device %p.\n" like the rest of wined3d. > @@ -1275,7 +1275,7 @@ static void shader_dump_decl_usage(const struct wined3d_shader_semantic *semanti > break; > > case WINED3D_DECL_USAGE_BLEND_INDICES: > - TRACE("blend"); > + TRACE("indices"); I'd either just leave that the way it is, or change it to "blendindices". In the latter case you'd have to change the one for WINED3D_DECL_USAGE_BLEND_WEIGHT to "blendweight", and the one for WINED3D_DECL_USAGE_TEXCOORD to "texcoord%u" as well. > @@ -2037,8 +2037,8 @@ static HRESULT shader_set_function(struct wined3d_shader *shader, const DWORD *b > unsigned int backend_version; > const struct wined3d_d3d_info *d3d_info = &shader->device->adapter->d3d_info; > > - TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u.\n", > - shader, byte_code, output_signature, float_const_count); > + TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u, type %#x, max_version %d.\n", > + shader, byte_code, output_signature, float_const_count, type, max_version); %d -> %u

1 0

Optimizing synchronization objects
by Daniel Santos 17 Sep '15

17 Sep '15

Alexandre, First off I apologize for the size of this email, I'm trying to keep it as concise as possible. I've been experimenting with ways to optimize synchronization objects and have implemented a promising proof of concept for semaphores using glibc's nptl (posix) semaphore implementation. I posted revision 3 of this today, although I appear to have used the wrong msg id in the --in-reply-to header. :( So my goal is to eventually make similar optimizations for all synchronization objects, or at least those that have demonstrable performance problems. The basic theory of operation is that when a client sends a create_semaphore, the server creates a posix semaphore with a unique name which is passes to the client process so that it can open it locally. This allows the client to perform ReleaseSemaphore without a server call as well as WaitFor(Multiple|Single)Object(s) for cases where the wait condition can be determined to be satisfied without a server call (i.e., either bWaitAll = FALSE and a signalled semaphore is found in the handle list prior to a non-semaphore objects or bWaitAll = TRUE and all handles are signalled semaphores). For all other conditions, it uses a traditional server call. However, it has two problems: 1. It uses glibc's implementation of POSIX semaphores which uses shared memory to share them with other processes, and 2. It uses glibc's implementation of POSIX semaphores which are incompatible across 32- and 64-bit ABI processes. I have not been able to find any more flaws in a case where both program and wineserver are the same ABI. All tests pass and I've added one more (although more tests are clearly needed). Since this implementation only uses sem_trywait (and never sem_wait or sem_timedwait), we don't really even need a full-featured semaphore -- a simple 32- or 16-bit number that's accessed atomically would suffice as a replacement. Although I did plan to eventually explore having a client program block w/o calling the server, the benefit of that is minimal compared to the benefit of being able to avoid the server call for releasing a semaphore and "wait"ing when the semaphore is already available. So now I want to understand the minimum threshold of acceptability in wine for such a mechanism. We discussed this in chat and quite a bit and can I see many possibilities, each with its own particular issues. I'm listing them in order of my personal preference (most preferred first). Option 1: Simple shared memory & roll our own semaphore Similar to what glibc's NPTL semaphores are doing, except that we would only need a single integral value and not even a futex. The obvious downside is that a process can corrupt this memory and cause dysfunction of other processes who also have semaphores in that page. This could be minimized by giving every process their own page that is only shared between the server and the process unless a semaphore in that process is shared with another program, at which time the memory page could be shared with that process as well. Thus, the scope of possible corruption is limited to how far you share the object. In the worse case of memory corruption, the wineserver would either leave a thread of one of these processes hung, release one when it shouldn't be released or determine that the memory is corrupted, issue an error message, set the last error to something appropriate and return WAIT_FAILED. Option 2: System V semaphores On Linux, these are hosted in the kernel, so you can't just accidentally overwrite them. They will be slightly slower than shared memory due to the system call overhead. You probably know them better than I, but at the risk or stating the obvious, the following are their limitations. Their max value on Linux is SHRT_MAX so any request for a higher lMaximumCount would have to be clipped. There are also limits on Linux that can be adjusted by root if needed for some application, but the default is a maximum of 32000 (SEMVMX) total semaphores on the system, 128 (SEMMNI) semaphore sets and a max size of 250 (SEMMSL) semaphores per set. They are also persistent, so if the wine server crashes, they can leave behind clutter. Option 3: Move semaphores completely into the client In this scenario, the wine server can never be exposed to corrupted data. It is very fast when locking can be performed in the client, but very complicated and potentially slower for mixed locks. Calls to WaitForMultipleObjectsEx containing both semaphores and other objects (especially with bWaitAll = TRUE) may require multiple request/reply cycles to complete. The client must successfully lock the semaphores prior to the server calling satisfied on the server-side objects. Here is an optimistic use case that only requires a single request/reply cycle 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which succeeds. 3. Client passes request to server (with semaphore states) and blocks on pipe 4. Server gets value of all server-side objects and determines that the condition can be satisfied, so calls satisfied on all objects 5. Server sends response to client 6. Client wakes up and completes the wait call. Here is a slightly less optimistic case 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which fails on one semaphore. 3. Client rolls back locks on all which had succeeded. 4. Client passes request to server (with semaphore states) 5. Client blocks on the semaphore that was locked and the server pipe 6. Server updates thread status (blocking on native object) 7. Semaphore is signaled and client wakes up 8. Lock is obtained on semaphore that was previously locked 9. Client now calls trywait on remaining semaphores which again succeeds. 10. Client sends update to server and blocks on pipe 11. Server checks all server-side objects, which are all signaled, so calls satisfied on all objects 12. Server updates thread status and notifies client 13. Client wakes up and completes wait call. As you can see this can get more complicated. If the server discovers that an server object isn't signaled it will have to notify the client to rollback the locks and wait for server objects to be ready. So which of these solution is most appealing to you?

4 10

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.
by Henri Verbeet 17 Sep '15

17 Sep '15

On 16 September 2015 at 00:02, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > This patch series fixes several places where glyph table values are > not const, preventing the compiler from placing the table in read-only > memory. > Did you verify this does what you think it does? I suspect you don't really understand const and relocations.

2 5

Prep for Wineconf - testing
by Jeremy White 17 Sep '15

17 Sep '15

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [10/10] msvcirt: Implement strstreambuf::seekoff (resend)
by Piotr Caban 17 Sep '15

17 Sep '15

Hi, On 09/17/15 11:06, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(strstreambuf_seekoff, 16) > streampos __thiscall strstreambuf_seekoff(strstreambuf *this, streamoff offset, ios_seek_dir dir, int mode) > { > - FIXME("(%p %d %d %d) stub\n", this, offset, dir, mode); > - return EOF; > + char *base[3]; > + > + TRACE("(%p %d %d %d)\n", this, offset, dir, mode); > + > + if (dir < 0 || dir > 2 || !(mode & (OPENMODE_in|OPENMODE_out))) > + return EOF; > + /* read buffer */ > + if (mode & OPENMODE_in) { > + base[0] = this->base.eback; > + base[1] = this->base.gptr; > + base[2] = this->base.egptr; The code will be easier to read if you use SEEKDIR_beg, SEEKDIR_cur and SEEKDIR_end instead of its values. > + if (this->base.gptr >= this->base.egptr) > + call_streambuf_underflow(&this->base); According to my testing call_streambuf_underflow should be called always, even so default implementation will just return in this case. I was not really checking it but it looks wrong that you store base table values before underflow is called. Patches 1-9 looks good for me. Thanks, Piotr

1 0

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME
by Henri Verbeet 17 Sep '15

17 Sep '15

On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=39277 > > Side note: I'm pretty sure I've seen this or a similar issue on my > Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it > further at the time, so I'd really like to see this committed :). > This should probably go to winediag then.

2 2

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2)
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16776 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

Re: rsaenh/tests: Adjust length value to pass on Win 10
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16775 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

The fg-xxx VMs now accessible on demand
by Francois Gouget 16 Sep '15

16 Sep '15

So as you may know I run WineTest in a variety of Windows configurations daily (28). The results can be seen on test.winehq.org but the problem is investigating the test failures because most of these configurations cannot be found on the Wine TestBot. I have three options to work around this: * As I mentionned before (1), if you're interested in a specific configuration I may be able to temporarily switch a WineTestBot VM to that configuration. * Another option is to send me an executable to run in the VM and I'll send back the results. * And the new option is that I can now give you VNC access to the VM. Access is open to any Wine developer (i.e. you got a patch accepted in Wine). To get access to the VM contact me on IRC or send me an email and give me the tag of the VM configuration you're interested in (e.g. fg-winxp-lusr). Then I'll start up the VM in the right configuration and send you the address to use to connect to the VM. Of course if I'm asleep or out you may have to wait a bit to get access. Also my uplink is not very fast so expect slow refreshes and some lag. But in the short test I've done it seems to be usable (at least to someone who's used to transatlantic VNC links with an elastic mouse pointer). And for reference here is a list of the available VM configurations. We may not care about some of them, for instance those running the earlier service pack revisions. Let me know if that's the case. Windows 2000 ------------ The French Windows 2000 Professional SP4 installed from an official Microsoft CD. Unless otherwise noted the tests are run in an administrator account. fg-win2000-4sp IE 5.00 SP2 fg-win2000-ie55 = 4sp + IE 5.5 SP2, MSXML3 fg-win2000-ie6 = ie55 + IE 6.0 SP1 fg-win2000-up1 = ie6 + all updates up to 2011/03/21 fg-win2000-uplast = up1 + DirectX 9.0c, WMP 9, .Net 1.1 & 2.0 fg-win2000-rusr = uplast but in a 'Restricted User' account fg-win2000-susr = uplast but in a 'Power User' account Windows XP ---------- I created this VM from the Compaq Windows XP partition of my (former) computer. So this started with a number of extra non-Microsoft applications (blasts from the past: Netscape 7, RealOne Player, etc.). On the one hand this is more representative of what Windows users normally have and on the other the configuration is not as 'straight out of the box' as the other VMs. That may not matter though. fg-winxp-1sp XP SP 1, IE 6.0 SP1, DirectX 8.1 fg-winxp-2sp = 1sp + XP SP2, IE 6.0, DirectX 9.0c, .Net 1.0 SP3 fg-winxp-2spie7 = 2sp + IE 7.0, WMP 10, .Net 1.1 fg-winxp-3sp = 2spie7 + XP SP3, WMP 11, .Net 2.0 SP2 & 3.0 SP2 & 3.5 SP1 fg-winxp-3spie8 = 3sp + IE 8 fg-winxp-last = 3spie8 + all updates up to 2011/09/08 fg-winxp-lusr = last but in a 'Limited User' account Windows 7 --------- Installed from an official English Windows 7 Ultimate CD. Unless otherwise noted the tests are run in an administrator account with Elevated Privileges. fg-win7u64-0sp Base install + French language pack (but still configured for English) fg-win7u64-1sp = 0sp + SP1 fg-win7u64-1spie9(64) = 1sp + IE 9.0, all language packs fg-win7u64-1spie9adm = 1spie9 but no 'Elevated Privileges' fg-win7u64-1spie9usr = 1spie9 but in a 'Standard user' account fg-win7u64-1spie9-ar = 1spie9 but in an Arabic locale fg-win7u64-1spie9-de = 1spie9 but in a German locale fg-win7u64-1spie9-es = 1spie9 but in a Spanish locale fg-win7u64-1spie9-fr = 1spie9 but in a French locale fg-win7u64-1spie9-he = 1spie9 but in a Hebrew locale fg-win7u64-1spie9-ja = 1spie9 but in a Japanese locale fg-win7u64-1spie9-ko = 1spie9 but in a Korean locale fg-win7u64-1spie9-mx = 1spie9 but in a mixed locale (1) https://www.winehq.org/pipermail/wine-devel/2015-September/109252.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

1 0

Re: [PATCH 1/4] xaudio2: Implement IXAudio2SourceVoice frequency functions
by Chris Robinson 16 Sep '15

16 Sep '15

On 09/15/2015 10:25 AM, Andrew Eikum wrote: > @@ -801,14 +802,26 @@ static HRESULT WINAPI XA2SRC_SetFrequencyRatio(IXAudio2SourceVoice *iface, > float Ratio, UINT32 OperationSet) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %f, 0x%x\n", This, Ratio, OperationSet); > + > + EnterCriticalSection(&This->lock); > + > + This->freq_ratio = Ratio; > + This->freq = This->fmt->nSamplesPerSec * Ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; ... > @@ -816,7 +829,16 @@ static HRESULT WINAPI XA2SRC_SetSourceSampleRate( > UINT32 NewSourceSampleRate) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %u\n", This, NewSourceSampleRate); > + > + EnterCriticalSection(&This->lock); > + > + This->fmt->nSamplesPerSec = NewSourceSampleRate; > + This->freq = NewSourceSampleRate * This->freq_ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; > } ... > @@ -2989,7 +3012,7 @@ static BOOL xa2buffer_queue_period(XA2SourceImpl *src, XA2Buffer *buf, ALuint al > buf->offs_bytes += submit_bytes; > > alBufferData(al_buf, src->al_fmt, submit_buf, submit_bytes, > - src->fmt->nSamplesPerSec); > + src->freq); > > alSourceQueueBuffers(src->al_src, 1, &al_buf); > This doesn't strike me as correct. Assuming the SampleRate or FrequencyRatio can be altered in real-time, this will break the OpenAL buffer queue which needs to have the same sample rate on each buffer. SetFrequencyRatio looks like it'd map directly to the AL source's pitch property, while SetSourceSampleRate may be a bit trickier depending on when it's allowed to be called (it'd require stopping the source and clearing the queue, then rebuffering and requeueing the buffers to start where it left off). Also, I notice the OperationSet parameter isn't used. What is that for?

2 1

RFC: Hybrid (wineserver / process-local) native semaphores
by Daniel Santos 16 Sep '15

16 Sep '15

This patch set fixes most performance problems caused by ReleaseSemaphore() and WaitForSingle/MultipleObject(s) making server calls. One victim of this is Star Wars Battlefront (https://bugs.winehq.org/show_bug.cgi?id=29582), where the majority of the CPU time is spent on context switching while the program spams ReleaseSemaphore, WaitForSingle/MultipleObject(s) and GetForgroundWindow, the later of which I made a work-around hack for and that some players have been using. This patch set doubles performance of bug #29582. (When combined with GetForgroundWindow hack the problem is completely resolved.) The patch set works by having the server create a POSIX semaphore object and sharing the key to that object with the client process, enabling the client process to be able to implement ReleaseSemaphore and optimistic-case wait calls (where no blocking is reburied) without a server call. Blocking waits and any wait-multiple that cannot be resolved in the client process (e.g., bWaitAll=TRUE and objects include non-semaphores) is still handled by the server. (Implementing blocking wait calls on the client can yield some performance improvements because a context switch to another thread in the same program won't require swapping out the memory map & such, but I would expect this to be less significant.) However, upon further experimentation, I discovered that POSIX semaphores in glibc are actually implemented using a shared memory page, which may not be acceptable since a bad process can corrupt that page and potentially cause sem_* function calls in the server to fail as well as other client programs fail and/or deadlock. I am working on a System V adaptation, but I thought it would be a good idea to see feedback & comments now. Another problem is that this causes the threadpool test fails at line 1299, where the previous "release all semaphores and wait for callback" test is done in reverse order. I presume this is due to the nature of the linux scheduler being inconsistent with how Windows *happens* to schedule its threads. I have an idea for a fix for this already, but I will still have to dig deeper into it. The code is still in experimental quality (assert(0)s and such) and I've already re-worked the configure.ac stuff, I'm mostly concerned with feedback on the general scheme. Thanks! Daniel

5 46

Re: [PATCH 1/3] oledb32: Add DataConvert support of DBTYPE_VARIANT(NULL) to DBTYPE_DBDATE
by Nikolay Sivov 16 Sep '15

16 Sep '15

If it acts the same for all source variant types it looks like it'd be better to test them all and have this case handled once.

2 1

Re: [3/3] Add period to status bar, dialog box messages (try 2)
by Nikolay Sivov 16 Sep '15

16 Sep '15

On 15.09.2015 11:28, Florian Pelz wrote: > STRINGTABLE > { > - IDS_STATUS_DONE "Done" > + IDS_STATUS_DONE "Done." > IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." > } I don't think it's better really to have punctuation in status bars. Probably messages can live without it, unless they consist of multiple sentences, then last one needs termination too.

2 2

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16750 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0003012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung 16 Sep '15

16 Sep '15

------------------------------ On Wed, Sep 16, 2015 3:45 AM BST Vincent Povirk wrote: >> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? > >Currently, Wine does not have the ability to load pure .NET PE images >in a 64-bit process. > >Ntdll needs to call _CorValidateImage during the loading process. >_CorValidateImage needs to convert the image, in memory, to the >correct architecture. > >It's complicated, and I don't have a solution. Actually you do :-). Using http://madewokherd.nfshost.com/omgsecret/mono-64bit-exe.tar.gz from https://bugs.winehq.org/show_bug.cgi?id=30518 It is a bit dated, but does the job. I was very confused by both of libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll in c:/windows/mono/mono-2.0/bin/ In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll are never used, at the moment. When 64-bit mono loads a .NET PE image which then P/Invoke, it does so P/Invoke to 64-bit dlls.

2 1

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION. (try 2)
by Dmitry Timoshkov 16 Sep '15

16 Sep '15

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > +void X11DRV_FlashWindow( HWND hwnd, BOOL bInvert ) > +{ > + struct x11drv_win_data *data = get_win_data( hwnd ); > + XEvent xev; > + > + if (!data) > + return; > + > + memset( &xev, 0, sizeof(xev) ); > + xev.type = ClientMessage; > + xev.xclient.window = data->whole_window; > + xev.xclient.message_type = x11drv_atom( _NET_WM_STATE ); > + xev.xclient.format = 32; > + xev.xclient.data.l[0] = 1; > + xev.xclient.data.l[1] = XInternAtom( data->display, "_NET_WM_STATE_DEMANDS_ATTENTION", > + False ); > + > + XSendEvent( data->display, DefaultRootWindow( data->display ), False, > + SubstructureNotifyMask, &xev ); > + release_win_data( data ); > +} This can't work, please have a look how XSendEvent is used in other parts of x11drv. -- Dmitry.

1 0

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with UrgencyHint flag.
by Dmitry Timoshkov 16 Sep '15

16 Sep '15

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > This patch only set UrgencyHint flag when the window is minimized. > Because X11 only define UrgencyHint, the specific UI effect is > implemented by WM/DE. Different WM/DE may have different UI effect > which is quite different from Windows. Probably FlashWindow should be implemented with _NET_WM_STATE_DEMANDS_ATTENTION instead. -- Dmitry.

2 1

disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung 16 Sep '15

16 Sep '15

Hi, I am not having any luck trying to disable wow64 temporarily to test 64-bit wine-mono P/invoke . I tried moving syswow64, removing 32-bit wine, moving wow32.dll, etc. It either insists on p/invoking 32-bit dlls, or not recognizing the .net assembly at all. What I like to do is to test a pure 64-bit code-path - starting with neutral .net assembly, p/invoke to 64-bit dll's. This is possible on windows - in fact cmd.exe on win 8 64-bit will refuse to p/invoke to 32-bit dll's. Is there any way of doing this with 64-bit wine and 64-bit wine-mono? Hin-Tak

2 1

Re: [PATCH 3/4] xaudio2: Call OnStreamEnd callback
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16733 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB6EDD4B7D === w1064 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFC549A4B7D

1 0

Re: [PATCH] mshtml: Fixed tests on some Windows versions.
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16726 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 === w1064 (64 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132

1 0

Re: ieframe: Fixed tests on some VMs.
by Marvin 16 Sep '15

16 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16725 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE === w1064 (32 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 === w1064 (64 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182

1 0

Re: [PATCH 7/7] wined3d: remove wined3d_surface_preload
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; You don't need this anymore.

1 0

Re: [PATCH 5/7] wined3d: remove wined3d_volume_from_resource from the public api
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 7fb136d..49ed8db 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2332,6 +2332,7 @@ BOOL volume_prepare_system_memory(struct wined3d_volume *volume) DECLSPEC_HIDDEN > HRESULT wined3d_volume_create(struct wined3d_texture *container, const struct wined3d_resource_desc *desc, > unsigned int level, struct wined3d_volume **volume) DECLSPEC_HIDDEN; > void wined3d_volume_destroy(struct wined3d_volume *volume) DECLSPEC_HIDDEN; > +struct wined3d_volume *wined3d_volume_from_resource(struct wined3d_resource *resource) DECLSPEC_HIDDEN; You never want to use this from inside wined3d. If there are any callers they should use volume_from_resource() instead.

1 0

Re: [PATCH 3/7] wined3d: introduce new wined3d_texture_(un)map functions
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static const struct wined3d_texture_ops texture2d_ops = > { > texture2d_sub_resource_load, > @@ -924,6 +935,8 @@ static const struct wined3d_texture_ops texture2d_ops = > texture2d_sub_resource_validate_location, > texture2d_sub_resource_upload_data, > texture2d_prepare_texture, > + texture2d_sub_resource_map, > + texture2d_sub_resource_unmap, > }; > Please keep the various sub_resource operations together. (I.e., keep texture_prepare_texture last.) You're probably also missing some wined3d_private.h changes here that ended up in the next patch. It doesn't make sense to introduce these without users, so what you'd want to do is e.g. first make the change for d3d10_texture2d_Map(), then for d3d10_texture2d_Unmap(), etc.

1 0

Re: [PATCH 2/7] wined3d: pass a wined3d_box to wined3d_surface_map
by Stefan Dösinger 15 Sep '15

15 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:13 schrieb Riccardo Bortolato: > + hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect ? (const struct wined3d_box *)&box : NULL, flags); Why do you need the cast? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9x41AAoJEN0/YqbEcdMw5H4P/i9IrXL1PHd3pzoSmu2ObeSg rYWjMykbp0rh39JwXioBnMqbOCfneEjCSESHGqChNYQ4ZUHyMa6v8M0SOelvxlsA s9sQDs1YBRreXHTMlJSze4/jkHuOSFPCCiVueYLXsyoPunjER+KielzvICZ7lFYQ MQtHi6VwvUDiZJb7UaU3EeiUz2Drxq/Tki5OOgl+NS0rVQXRrecaA3qimPKEpbpI SkXChNulMWHM5q1cboxfP585R7SX12RnirNH0Wwx5kgv21gnvJGVB4eLirPNeKvA FnYAeGqo0ct3ruY9O77UMQFZTbAfn20Jv1EP4ZD0dAhUaUeSzPKQ9I68f+LYC5tG jiwZ7+8E/ReGWXRWcmHF3gnp3SumFl4RtQl8oz4jcqwoH42+xaaSMn5NDam4Hx0s sImgiqEG1ga7sCTOFUIL3q+0XkCpmXMwsjuBxxdZO1qRzSw9MlSgf1BpGsl3rJUb gHI4E+CsgHgUtP8ANyAPJBEbX87JEZ4SDycPwvgNIPQL84hRi0j+FvTJuJe26SN3 47qorsnjy9i/HrtTZXu613qhB07oMedyowWFRqI4EhRv8aKBUB6efzo8/LVHNU2v Sdfy3iI6d6Z+01sZa7nkdbAxeeASfEJ0tSKYN8ikRe0ahPhbRSFU0aD3/4+smQT6 EHW5Os4oDmiycqCxwogK =PePB -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/7] wined3d: store wined3d_texture and sub_resource_idx in d3d8, d3d9 and ddraw surfaces and volumes
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:13, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index d12805f..d1eebbb 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -193,10 +193,13 @@ struct d3d9_volume > struct d3d9_resource resource; > struct wined3d_volume *wined3d_volume; > struct d3d9_texture *texture; > + struct wined3d_texture *wined3d_texture; > + UINT sub_resource_idx; I'd prefer "unsigned int", but it's not that important. We'll probably want "wined3d_texture" and "sub_resource_idx" before "wined3d_volume". > -void volume_init(struct d3d9_volume *volume, struct d3d9_texture *texture, > - struct wined3d_volume *wined3d_volume, const struct wined3d_parent_ops **parent_ops) DECLSPEC_HIDDEN; > +void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > + const struct wined3d_parent_ops **parent_ops, > + struct wined3d_texture *wined3d_texture, unsigned int sub_resource_idx) DECLSPEC_HIDDEN; Please keep "parent_ops" the last parameter. You don't need the wined3d_volume parameter here. Affects the device_parent calls as well. > @@ -5395,6 +5395,7 @@ HRESULT wined3d_surface_create(struct wined3d_texture *container, const struct w > struct wined3d_surface *object; > void *parent; > HRESULT hr; > + UINT sub_resource_idx = layer * container->level_count + level; This probably doesn't need its own variable. I think it makes sense to split this patch in two, one making the change for volumes, and one making the change for surfaces.

1 0

Re: [PATCH 8/8] d3d11/tests: Add basic test for ID3D11InputLayout.
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1277,4 +1334,5 @@ START_TEST(d3d11) > test_depthstencil_view_interfaces(); > test_create_rendertarget_view(); > test_create_shader_resource_view(); > + test_create_input_layout(); > } I don't think this needs its own test. There will be plenty of places that create input layouts once we start drawing things. If nothing else, d3d10core has the test_il_append_aligned() test that tests some more specific input layout things.

1 0

Re: [PATCH 3/8] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > There's an ugly check if *immediate_context is NULL. It will go away > when we have a stub interface for the immediate context. > --- That usually means the ordering of the patches isn't quite right. :) Although I suppose it's not too bad in this case, but you should at least add some kind of FIXME comment. > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Looking at the associated test, you may have misunderstood what I meant yesterday. If "swapchain_out" is NULL, you're creating a swapchain only to release it right away again. It may be the case that that's correct because of the side effects like the validation of swapchain_desc and potential window messages that end up being sent, but I suspect we should simply skip creating the swapchain.

1 0

regsvr32.exe tests
by Hugh McMaster 15 Sep '15

15 Sep '15

Over the past few weeks I've been sending a number of patches for regsvr32.exe to the wine-patches mailing list. Those patches are the product of a new test suite written for regsvr32.exe. The good news is that all of the tests now pass on Wine. The bad news is that the test suite is not suitable for wine-patches because I haven't been able to produce the test DLLs at runtime. The PE header format is complicated and I'm not too sure what I'm doing. In the meantime, anyone who is interested in the regsvr32.exe tests can download the source and test DLLs from the link below. https://www.dropbox.com/sh/39sytyithd76x97/AAD-FntoMfEvhvrqAnWyW6QJa?dl=0 Any comments on the tests and/or help with the PE header issue etc. are welcome.

1 0

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).
by Jacek Caban 15 Sep '15

15 Sep '15

Hi Dmitry, On 09/02/15 07:44, Dmitry Timoshkov wrote: > + if (member == DISPID_HTTPREQUEST_OPTION) Why can't we use standard, ITypeInfo-based implementation here? > + { > + VARIANT ret_value, option; > + UINT err_pos; > + > + if (!result) result = &ret_value; > + if (!arg_err) arg_err = &err_pos; > + > + VariantInit( &option ); > + VariantInit( result ); > + > + if (flags == DISPATCH_PROPERTYPUT) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > + if (FAILED(hr)) > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > + if (FAILED(hr)) > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + > + return S_OK; I don't think silently returning S_OK is right for not handled flags. Thanks, Jacek

2 9

Re: wined3d: Fix TRACE in shader_dump_decl_usage().
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 11:11, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > case WINED3D_SHADER_RESOURCE_TEXTURE_3D: > - TRACE("_volume"); > + TRACE("_3d"); I think the change makes sense, but it's not really a fix. We can essentially call this whatever we like. Originally this was based on the d3d9 naming where you have "dcl_volume". OpenGL and d3d10+ call these 3D textures.

1 0

Re: [PATCH] ntdll/tests: Skip RtlRandom tests on Windows 10.
by Austin English 15 Sep '15

15 Sep '15

On Mon, Sep 14, 2015 at 12:24 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Windows 10 uses a different algorithm for RtlRandom. > All the tests currently fail and produce tons of spam. > (There's already a similar case for Windows Vista.) > --- > dlls/ntdll/tests/rtl.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 9a4ec48..f42e313 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -739,6 +739,16 @@ static void test_RtlRandom(void) > return; > } > > +/* > + * Windows 10 uses different algorithms, so skip the rest of the tests > + * until that is figured out. Trace output for the failures is about 23 MB! > + */ > + > + if (seed == 0x7fffffc3) { > + skip("Most likely running on Windows 10 which uses a different algorithm\n"); > + return; > + } > + > ok(result == result_expected, > "pRtlRandom(&seed (seed == 0)) returns %x, expected %x\n", > result, result_expected); > -- > 2.5.1 This should probably be win_skip() rather than skip(). -- -Austin

3 2

Re: [2/3] Use quotes around service names in net program.
by Nikolay Sivov 15 Sep '15

15 Sep '15

On 13.09.2015 18:51, pelzflorian(a)pelzflorian.de wrote: Please update resource file only, the rest will be regenerated with appropriate fuzziness (e.g. Russian strings are done wrong, regarding quotation marks).

2 3

Re: [PATCH 4/7] wined3d: replace wined3d_{surface, volume}_(un)map with wined3d_texture_(un)map
by Stefan Dösinger 14 Sep '15

14 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:14 schrieb Riccardo Bortolato: > -HRESULT __cdecl wined3d_surface_map(struct wined3d_surface *surface, > - struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > -void __cdecl wined3d_surface_preload(struct wined3d_surface *surface); The wined3d_surface_preload removal seems premature and should be in patch 7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9yCsAAoJEN0/YqbEcdMwSh0P/1OCyBpwswYeaCD40J6YfpQb 8eXAgQlsbbqWQen6Zw+d0W3ixqJsrUJfnZM6gQu2vBp80RQxSNjuifizy3pJgXzy eHAuEWATtFrkGiyPF6EWjheGW7uM7FRyYt4DRXHCu+W3QnYkbpT0YXw7FhtGsPo2 GP/NzctDeGLwe0qrGyFtrg5WxhOA7RqdGaWIsAeMrcTiUzcS9Hbc0leTfYIJOprL bu5scnmKKobtadAOgB5um9hBSXynQzKLg8zzd5NzQMdqnRFJ3QTdZfw7YBtRpX63 0V6yVFztJgErsibvvyIUpTvGQIqq2KmAMpoDMR3p9NYzPEeyvLStnmqmHn5vZ8ZH KyP35umA552xYFQvxy/aAjttSovkrul7dv9X+W6HYW/HqwwU+XrEgCFHPpEwfM4Z 35i6onuZtrm0tSYdloCkf1hFmzn5R6izUrNvduxf64J7aSNJ3sZ2hYh56gGgSgCC uyJU9kp7SRXy7gBjEnwY95DN1V27v6+LR/VPoi2u5yaM9zAc2mOjzUBErsJSviNq phGCtnDKP6i25ajkIjEcmB9nGq7KIUV7EvgjuGz4hv4jrYtES3WsZYbPfJQs/hai pmPtOeCft7vZLkH/ZfzCx00Wggs0JwloJb5fPxDw1WYKiaq2zjXvL6yHivVqaiGN GqngsuTeKGkated3sg4H =gUhb -----END PGP SIGNATURE-----

1 0

Re: [PATCH 05/10] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet 14 Sep '15

14 Sep '15

On 14 September 2015 at 00:13, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Is "desc" validated or modified in this case? Otherwise you could return a lot earlier. The test doesn't really cover that. > + hr = D3D11CreateDevice(adapter, driver_type, swrast, flags, feature_levels, levels, sdk_version, > + &device, NULL, NULL); > + if (FAILED(hr)) > + { > + WARN("Failed to create a device, returning %#x.\n", hr); > + *device_out = NULL; > + return hr; > + } ... > + > + if (obtained_feature_level) > + *obtained_feature_level = ID3D11Device_GetFeatureLevel(device); > + > + if (immediate_context) > + ID3D11Device_GetImmediateContext(device, immediate_context); This seems odd. Why not just pass these to D3D11CreateDevice()? If you like you can do things like the D3D11CreateDevice() call inside the if. I.e., "if (FAILED(hr = D3D11CreateDevice(...)))". I tend to do that for newer code, older code usually has it on separate lines.

2 2

WineTestBot test coverage
by Francois Gouget 14 Sep '15

14 Sep '15

When setting up the WineTestBot VMs I have tried to make it so we can compare their results across Windows versions so we know if a specific behavior is specific to a given Windows version or was introduced in a specific Windows version. At the same time I tried to diversify the Windows configurations to get better coverage of various locales, particularly when they involve right-to-left text or asian characters, but also to test other aspects like having multiple network cards, two disks, etc. While ideally the WineTestBot would be able to switch each VM between multiple configurations (through the use of snapshots), currently this is not supported. Thus we can only test as many configurations as we have VMs (and Windows licenses). As a result choices have to be made, the coverage is not complete and there may be room for improvement. For instance w7u is configured for Japanese because it's an asian language and I know we have developers who know Japanese. But it turns out a number of test failures are specific to Korean. Ideally we'd have both but there are only two VMs(*) that can be configured for non-English locales and the other one is configured to check for right-to-left issues (previously Arabic and now through Hebrew). Similarly all VMs run the tests with elevated privileges because that's what allows running the maximum number of tests. But this means tests are never tested in unprivileged accounts leading to a bunch of failures when that happens. So should we change the configuration of some of the WineTestBot VMs? Which aspects are the most important? An additional note is that I can relatively easily reconfigure a VM and then switch between that configuration and what we have now. So for instance I could switch the Japanese VM to Korean if a developer needs it to debug things, and then switch it back to Japanese when he's done. Between the timezone delays and WineTestBot's own, the latency would be around a day. So here is a summary of the available configurations. Let me know if there are changes to do: w2000pro IE 6 sp1, DirectX 9.0c, MSXML 4&6, VC 2005/8/10, IPX, AppleTalk, data CD wxppro IE 8, DirectX extras, MSXML 4, VC 2005/8/10, winpcap w2003std IE 8, .Net 2.0 SP2, 3.0 SP2, 3.5 SP2, 4, MSXML 4, VC 2005/8/10. wvista IE 9, .Net 3.5 SP1 & 4.5.1, RMP wvistau64 IE 8, Hebrew, tests on e:, DirectX extras, MSXML 4, VC 2005/10. winpcap w2008s64 IE 9, .Net 4.0, no sound, two network cards w7u IE 11, Japanese, .Net 3.5 & 4.5, VC 2012/13, data CD w7pro64 IE 11, .Net 4.5.1 w8 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w864 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w1064 Edge, DirectX extras Legend: - DirectX extras: This installs some dlls that are not installed by default, for DirectMusic and DirectPlay for instance. - AppleTalk: The AppleTalk network protocol. - IPX: The IPX network protocol. - RMP: The Reliable Multicast Protocol network protocol. Known holes: * No Windows 8 (only Windows 8.1). * No IE 7 configuration. * No IE 10 configuration. * No non-elevated or regular user tests. * Korean locale. Other locales? * No mixed locale (to ensure the tests check the right locale API). (*) Though the locale of the new Windows 10 VM is probably configurable too. So that would be 3 VMs. But do we want to add failures to a VM that already has a lot? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 06/10] dxgi: Set BufferUsage in dxgi_swapchain_GetDesc().
by Henri Verbeet 14 Sep '15

14 Sep '15

Not that DXGI_USAGE_RENDER_TARGET_OUTPUT would necessarily be a bad default, but it's probably better to either just store a copy of the original DXGI_SWAP_CHAIN_DESC structure in the swapchain, and read it again here, or to pass the additional fields to wined3d somehow.

1 0

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin 14 Sep '15

14 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16701 Your paranoid android. === w8 (32 bit win) === win.c:3278: Test failed: message 0118 available === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0006012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === wvistau64 (64 bit win) === win.c:7539: Test failed: transparent window didn't get WM_NCHITTEST message win.c:7540: Test failed: button under static window didn't get WM_LBUTTONUP === w864 (64 bit win) === win.c:1210: Test failed: first call to SetShellWindow(hwnd1) win.c:1212: Test failed: wrong shell window: 0000000000020118 win.c:1249: Test failed: SetShellWindow(hwnd4) win.c:1251: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1254: Test failed: wrong next window for hwnd4: 000000000002010C - expected 0 win.c:1265: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1275: Test failed: wrong next window for hwnd4 after SetWindowPos(): 000000000002010C - expected 0 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Windows 10 available for testing on the WineTestBot
by Francois Gouget 14 Sep '15

14 Sep '15

The WineTestBot now has two new VM hosts to compensate for running fewer tasks per host. More importantly it now has a Windows 10 Home 64 bit VM (w1064). You can submit jobs to it at any time and I made it a base VM so Wine patches that fail on Windows 10 are detected. However you will not find a Windows 10 column on test.winehq.org because about 68 failures and a 24MB report Windows 10 reports are getting thrown away. With over 200 000 lines, the ntdll:rtl failure below is responsible for most of the spam: rtl.c:879: Test failed: test: 0x000000231 RtlUniform(&seed (seed == 79ddd72)) returns b60129c, expected 62bb10ce So some effort will be needed to remedy the situation. As a starting point here is a full WineTest report I collected on a Windows 10 install running on real hardware and a list of the failing tests. http://fgouget.free.fr/tmp/winetest32.report 2 advapi32:security 2 failures 1 cmd:batch 3 crypt32:base64 1 crypt32:chain 1 d2d1:d2d1 8 d3d8:device 4 d3d9:d3d9ex 2 ddraw:ddraw2 2 ddraw:dsurface 8 ddraw:overlay 12 dssenh:dssenh 9 dxgi:device 4 hlink:hlink 28 ieframe:webbrowser 18 kernel32:console 12 kernel32:loader 7 kernel32:locale 1 kernel32:process 1 kernel32:thread 4 kernel32:toolhelp 2 kernel32:volume 5 mmdevapi:capture 6 mmdevapi:render 1 msctf:inputprocessor 30 mshtml:htmldoc 1 mshtml:htmllocation 1 urlmon:protocol 2 msvcrt:locale (English locale) 1 msxml3:httpreq 10 ntdll:pipe 200010 ntdll:rtl 39 ntdll:threadpool 39 ole32:marshal 2 oleaut32:olepicture 3 rpcrt4:server 65 rsaenh:rsaenh 2 secur32:schannel 1 setupapi:devinst 30 shell32:ebrowser 3 shell32:shelllink 7 shell32:shlexec 1 shell32:shlfolder 2 shlwapi:assoc 6 taskschd:scheduler 1 urlmon:misc 12 urlmon:protocol 19 urlmon:uri 27 user32:broadcast 1 user32:class 55 user32:cursoricon 2 user32:monitor 1 user32:dde 6 user32:msg 10 user32:win 15 usp10:usp10 16 wininet:http 4 wininet:internet 4 winmm:midi 2 wintrust:crypt 1 ws2_32:sock 2 wscript.exe:run -- Francois Gouget <fgouget(a)free.fr>

1 0

wined3d public api cleanup
by Riccardo Bortolato 14 Sep '15

14 Sep '15

Here is a follow up on the small fixes I sent the other day. I'm storing the wined3d texture and sub level in the d3dX surfaces/volumes and this allows to go further with the removal of surfaces/volumes from the public api. With these commits I also introduce a temporary function to handle mapping for surfaces and volumes which I hope it will gradually handle more of that eventually delegating only bound checks (and maybe other minor things) to helper functions. Finally the remaining volume-related exported functions are removed. What to do with buffers is still unclear to me. Ciao, Riccardo

3 14

Re: [PATCH] riched20: Implement set all caps(Ctrl+Shift+A) shortcut key.
by Nikolay Sivov 14 Sep '15

14 Sep '15

On 14.09.2015 12:25, Jactry Zeng wrote: > + for (i = 0; i < len; i++) > + { > + WCHAR tmp = bufferW[i]; > + > + if (isalphaW(tmp)) > + { > + if (editor->bCaps) > + bufferW[i] = toupperW(tmp); > + else > + bufferW[i] = tolowerW(tmp); > + } > + } Hi, won't struprW/strlwrW work here? I don't see why isalphaW check is important.

1 0

Re: [2/5](resend/rebased)hidclass.sys: Add USB Descriptor parsing
by Alexandre Julliard 14 Sep '15

14 Sep '15

Aric Stewart <aric(a)codeweavers.com> writes: > + if (!caps->IsRange) > + { > + static char out[30]; > + unsigned int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("0x%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; Having a static buffer defeats the purpose of using wine_dbg_sprintf. > +static void debug_feature(struct feature *feature) > +{ > + if (!feature) > + return; > + TRACE("[\n\t type %s [%i]; %s; %s; %s; %s; %s; %s; %s; %s; %s\n\t %s\n]\n", Please don't put \n in traces, that messes up the output. If you truly need multiple lines, use separate TRACE statements. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 10/10] dxgi/tests: Remove leftover debug comment.
by Marvin 14 Sep '15

14 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16696 Your paranoid android. === w1064 (32 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1134: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1188: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1134: Test failed: Got unexpected hr 0, test 39. device.c:1188: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1188: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [PATCH 09/10] dxgi/tests: Add missing DestroyWindow() call in test_createswapchain().
by Marvin 14 Sep '15

14 Sep '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16695 Your paranoid android. === w1064 (32 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1134: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1188: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1134: Test failed: Got unexpected hr 0, test 39. device.c:1188: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1188: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel