wine-devel September 2015

wine-devel@winehq.org

73 participants
180 discussions

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

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page:

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 September 2015