August 2015 - Wine-Devel - list.winehq.org

Re: Prep for Wineconf - testing

by Matt Durgavich

I hack on Wine for Mac. Anything special someone wants? -Matt > On Aug 31, 2015, at 7:18 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > > I believe I answered these questions off-list but here are the answers > so others know them too and can participate. > > On Mon, 27 Jul 2015, Jeremy White wrote: > [...] >> 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. > > To clarify the idea is to do nothing else while a test is running (and > obviously only run one test at a time). > > >> I seem to recall that Francois needed cooperation from Alexandre to run >> that experiment - is that right? > > This is configured in testbot/lib/WineTestBot/Config.pm which Git > currently indicates has the following settings: > > $MaxRevertingVMs = 1; > $MaxRevertsWhileRunningVMs = 1; > $MaxActiveVMs = 2; > > This indicates that we can have two active VMs, which means one running > a test and the other idle, or two tests running simultaneously, or one > test running while another VM is being reverted. > > But it's possible the settings on the winehq.org server are different. > Only Alexandre has access to that machine. If so, then I guess the > experiment would call for trying the following settings: > > $MaxRevertingVMs = 1; > $MaxRevertsWhileRunningVMs = 0; > $MaxActiveVMs = 1; > > I'm a bit skeptical that it would make much of a difference. > > >> 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. > > Patches accepted. > > >> And I don't see any for Mac :-(. > > I should buy a Mac but I don't really have the time... > Too bad we don't have any Wine Mac developers! > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > La terre est une bêta...

Aug. 31, 2015

Re: Prep for Wineconf - testing

by Francois Gouget

I believe I answered these questions off-list but here are the answers so others know them too and can participate. On Mon, 27 Jul 2015, Jeremy White wrote: [...] > 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. To clarify the idea is to do nothing else while a test is running (and obviously only run one test at a time). > I seem to recall that Francois needed cooperation from Alexandre to run > that experiment - is that right? This is configured in testbot/lib/WineTestBot/Config.pm which Git currently indicates has the following settings: $MaxRevertingVMs = 1; $MaxRevertsWhileRunningVMs = 1; $MaxActiveVMs = 2; This indicates that we can have two active VMs, which means one running a test and the other idle, or two tests running simultaneously, or one test running while another VM is being reverted. But it's possible the settings on the winehq.org server are different. Only Alexandre has access to that machine. If so, then I guess the experiment would call for trying the following settings: $MaxRevertingVMs = 1; $MaxRevertsWhileRunningVMs = 0; $MaxActiveVMs = 1; I'm a bit skeptical that it would make much of a difference. > 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. Patches accepted. > And I don't see any for Mac :-(. I should buy a Mac but I don't really have the time... Too bad we don't have any Wine Mac developers! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

Aug. 31, 2015

Re: RFC: New dependency on FFmpeg?

by Francois Gouget

On Fri, 21 Aug 2015, Michael Stefaniuc wrote: [...] > > See also: https://bugs.winehq.org/show_bug.cgi?id=31836 > gstreamer is unusable for Wine due to it relying on glib and that is > broken since glib-2.32.0: > https://bugs.winehq.org/show_bug.cgi?id=30557 > > The way forward is to replace winegstreamer too. I think a better way forward would be to fix the issue with GLib (either from the GLib side or the Wine one) and to upgrade winegstreamer to a non-obsolete version of GStreamer. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.

Aug. 31, 2015

Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

by Martin Storsjö

On Fri, 28 Aug 2015, Alexandre Julliard wrote: > Martin Storsjo <martin(a)martin.st> writes: > >> Since MSVC 2015/Windows 10, the C runtime has now been split into two >> parts, ucrtbase, which is the generic C runtime which is now considered >> a system component, and vcruntimeX which is specific to the compiler >> version. >> >> Even if this DLL only has a fraction of the functions of the full >> msvcrt/ucrtbase, it still requires almost all the object files from >> msvcrt. > > It would be better to isolate the corresponding code so that we don't > need all the files. That would indeed be the best. For some functions (like memcmp/memcpy/memmove/memset and such) it's pretty straightforward, but for others it does pull in most of the internals of the msvcrt implementation. One example: _purecall and _set_purecall_handler (currently implemented in exit.c). The _purecall implementation uses _amsg_exit which in turn uses _cprintf (console.c), _MSVCRT_app_type (data.c) and DoMessageBox, which uses _MSVCRT_mbstowcs (mbcs.c). Second example: MSVCRT__get_unexpected (cpp.c), using msvcrt_get_thread_data (thread.c), which uses MSVCRT_locale (locale.c). So unless it's a really simple function, it ends up pulling in most of the msvcrt internals. For the real implementation, I'd guess it uses most things from ucrtbase, instead of having a separate full crt state within both DLLs. But I'm not sure I'm ready to take on such a challenge. // Martin

Aug. 31, 2015

Re: [PATCH 2/4] ntdll: Fix read_directory_getdirentries().

by Matteo Bruni

2015-08-31 21:09 GMT+02:00 Ken Thomases <ken(a)codeweavers.com>: > On Aug 28, 2015, at 2:56 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> >> We could swap the "." and ".." entries with the first two entries >> returned from getdirentries(), in the same vein as >> read_directory_getdents(). That should work but I'm not sure it's much >> of an improvement overall. > > Yikes! I just had a look at read_directory_getdents(). It uses a static variable to store the information needed to know if it should enumerate ".." or a real entry. That's terrible. It's not thread safe. It's not even safe against enumerating two directories item by item in alternation. Actually it should be safe for both. About thread safety, check NtQueryDirectoryFile(), the various read_directory_* helpers are protected by the "dir_section" critical section. BTW notice that fd is opened by changing the current directory with fchdir(). As for the enumerating multiple directories by alternation, look at the last_dir_id checks and related code. Yes, all this is not nice by any means. >> I'm attaching a v2 of the patch with your points addressed. > >> + /* Store the updated position in the fd. */ >> + if (i == OFF_MAX - 2 || i == OFF_MAX - 1) >> + { >> + i = lseek( fd, i, SEEK_SET ); >> + } >> + else >> + { >> + lseek( fd, restart_pos, SEEK_SET ); >> + if (bytes_left != bytes_read) >> + wine_getdirentries( fd, data, bytes_read - bytes_left, &restart_pos ); >> } > > Hmm. This raises another problem. I knew about it, but had forgotten. You can't rely on getdirentries() reading a specified number of entries (or bytes) and leaving the file position such that the next read will resume with the next entry. > > On some file systems, getdirentries() reads entries from the directory in whole blocks. It may read fewer entries than the supplied buffer could hold if it couldn't fit all of the next block's worth of entries into the buffer. On the affected file systems, getdirentries() will always leave the file position on a multiple of the block size and there's nothing you can do to change that. (This is CodeWeavers bug 12271, FYI.) > > So, that last call to wine_getdirentries() won't do what you hope. And, in general, there's no good way to make read_directory_getdirentries() leave the file position in a place such that it can resume at the next entry it would have enumerated. > > This is a nasty problem. Sorry to have wasted your time working on this before remembering this fundamental flaw. Eh, right, that's real nasty. No problem, I should have realized that too. > It may be that the only reliable fix that can be implemented in ntdll is to use a directory index as the file position, after all. Except that we'd never use that as the place to read from. Instead, we'd always seek to the beginning and read entries, throwing away any that were before the index stored in the file position. Of course, this causes tons of redundant reading of directory entries. I think I'll try this just in case, as a sort of "experiment", even though it doesn't seem to be the correct way forward overall. > Alexandre had a vague suggestion for a different approach in a previous thread <https://www.winehq.org/pipermail/wine-devel/2014-February/102688.html> that I didn't entirely follow. Part of it seems to have been to read the whole directory listing into memory when it is first requested (or a restart is requested) and then return entries from this cache on subsequent calls. His scheme may have required additional support from the server to track metadata for handles. I don't know how reads of the same handle in multiple processes would be coordinated. > > Perhaps he can be persuaded to describe the solution he has in mind more fully. Or, if you can understand what he wrote in that previous thread better than I, you can try your hand at it. Uh, I didn't recall this wine-devel thread at all but I'm sure I followed it back then. FWIW my understanding pretty much matches yours and I see why that would be the "right" fix. I guess I'll just try to implement Alexandre's suggestion and see what happens. Expect either a new set of patches or some kind of request for help from me in the somewhat near future :P > -Ken Thanks again for the feedback!

Aug. 31, 2015

Re: [PATCH 2/4] ntdll: Fix read_directory_getdirentries().

by Ken Thomases

On Aug 28, 2015, at 2:56 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > We could swap the "." and ".." entries with the first two entries > returned from getdirentries(), in the same vein as > read_directory_getdents(). That should work but I'm not sure it's much > of an improvement overall. Yikes! I just had a look at read_directory_getdents(). It uses a static variable to store the information needed to know if it should enumerate ".." or a real entry. That's terrible. It's not thread safe. It's not even safe against enumerating two directories item by item in alternation. > I'm attaching a v2 of the patch with your points addressed. > + /* Store the updated position in the fd. */ > + if (i == OFF_MAX - 2 || i == OFF_MAX - 1) > + { > + i = lseek( fd, i, SEEK_SET ); > + } > + else > + { > + lseek( fd, restart_pos, SEEK_SET ); > + if (bytes_left != bytes_read) > + wine_getdirentries( fd, data, bytes_read - bytes_left, &restart_pos ); > } Hmm. This raises another problem. I knew about it, but had forgotten. You can't rely on getdirentries() reading a specified number of entries (or bytes) and leaving the file position such that the next read will resume with the next entry. On some file systems, getdirentries() reads entries from the directory in whole blocks. It may read fewer entries than the supplied buffer could hold if it couldn't fit all of the next block's worth of entries into the buffer. On the affected file systems, getdirentries() will always leave the file position on a multiple of the block size and there's nothing you can do to change that. (This is CodeWeavers bug 12271, FYI.) So, that last call to wine_getdirentries() won't do what you hope. And, in general, there's no good way to make read_directory_getdirentries() leave the file position in a place such that it can resume at the next entry it would have enumerated. This is a nasty problem. Sorry to have wasted your time working on this before remembering this fundamental flaw. It may be that the only reliable fix that can be implemented in ntdll is to use a directory index as the file position, after all. Except that we'd never use that as the place to read from. Instead, we'd always seek to the beginning and read entries, throwing away any that were before the index stored in the file position. Of course, this causes tons of redundant reading of directory entries. Alexandre had a vague suggestion for a different approach in a previous thread <https://www.winehq.org/pipermail/wine-devel/2014-February/102688.html> that I didn't entirely follow. Part of it seems to have been to read the whole directory listing into memory when it is first requested (or a restart is requested) and then return entries from this cache on subsequent calls. His scheme may have required additional support from the server to track metadata for handles. I don't know how reads of the same handle in multiple processes would be coordinated. Perhaps he can be persuaded to describe the solution he has in mind more fully. Or, if you can understand what he wrote in that previous thread better than I, you can try your hand at it. -Ken

Aug. 31, 2015

Re: Does wine send window messages without waiting apps to reenter userdll?

by Javier Pimás

Ok, that should be 39182 <https://bugs.winehq.org/show_bug.cgi?id=39182>. I downloaded wine source applied the patch and compiled (first time I ever do that), but the output of the test didn't change. On Sun, Aug 30, 2015 at 5:36 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Thanks for providing the testcase. It indeed looks like a wine bug. Would > you > mind to open a bug report on bugs.winehq.org with your testcase and > explanation? > Feel free to add me as CC. > > The following quick & dirty hack fixes the issue (but will very likely > break > other stuff): http://ix.io/kx0 > > Does it also help for your app? > > Regards, > Sebastian > > On 28.08.2015 17:52, Javier Pimás wrote: > > I wrote a small test which I attach here, very small program where you > can > > see if WndProc is called from WaitMessage. It fails, which I think shows > > what I doubted is actually happening. Tested in the old 1.6.2 wine and > also > > in 1.7.50. > > > > Cheers! > > > > On Wed, Aug 26, 2015 at 11:29 AM, Sebastian Lackner < > sebastian(a)fds-team.de> > > wrote: > > > >> On 26.08.2015 16:04, Sebastian Lackner wrote: > >>> If you are concerned that WaitMessage immediately dispatches the > >> messages, > >>> Wine doesn't do that. Processing of window messages is only done in the > >>> context of GetMessage and PeekMessage, no matter if its a "queued" or > >>> "non-queued" message. In fact Wine doesn't really make a difference > >> between > >>> the two, it just assigns specific internal message numbers for > non-queued > >>> messages. To identify those the the highest bit (0x80000000) is set. > >> > >> After reading the last part again I noticed that I wasn't really very > >> precise, > >> because I somehow already assumed that you are talking about non-queued > >> messages > >> caused by SetWindowPos and things like that. Those are implemented using > >> internal > >> messages in Wine, and might be affected by the "bugs" mentioned in the > >> last mail. > >> > >> Besides that its of course also possible to send other non-queued > messages > >> directly with SendMessage and similar functions. But in this case the > >> answer would > >> be the same: WaitMessage does not dispatch them immediately, they are > >> processed > >> during a call to PeekMessage or GetMessage. > >> > >> Regards, > >> Sebastian > >> > >> > > > > > > > > > > > > -- Javier Pimás Ciudad de Buenos Aires

Aug. 31, 2015

Re: po: Update German translation.

by Julian Rüger

You're welcome to whip up a patch that fixes these cases. ;) It's never wrong to be thorough and precise, but the most important thing is consistency, imho. (Feel free to ask me off-list if you run into trouble.) Best, Julian Am Montag, den 31.08.2015, 13:29 +0200 schrieb Florian Pelz: > Hi, > > On 08/31/2015 12:05 PM, Julian Rüger wrote: > > Hi Florian, > > > > I omitted the hyphen on purpose (for consistency). > > There are a few other instances of "Wine foo" without hyphen, and even: > > > > #: uninstaller.rc:29 > > msgid "Wine Application Uninstaller" > > msgstr "Wine Anwendungsentferner" > > > > I think this is a kind of 50-50 case, where it's okay either way. > > > > According to [1], omitting the hyphen is incorrect as per the official > spelling. That said, this part of the official orthography has never > quite caught on. I don't know if Wine cares about following official > orthography. > > (Sorry that nit-picking is my only contribution to Wine so far. I hope > I'll have time to do more in the future. So far I'm mostly lurking.) > > Best regards, > Florian > > [1] https://de.wikipedia.org/wiki/Leerzeichen_in_Komposita

Aug. 31, 2015

Re: [PATCH 6/7] dxgi: Store parents in textures.

by Henri Verbeet

On 31 August 2015 at 13:17, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > The idea of this patch and the next one is to avoid using > wined3d_surface in dxgi and friends. So yeah, it makes it harder to > get the d3d11 texture from the wined3d surface because it won't be > necessary to do that any more. > In itself that's fine. > The way I split the patches seems reasonable to me to avoid making too > many changes at once. > The way things are split between 114101/114105/114106 mostly just adds noise. I.e., folding the swapchain.c changes in this patch into 114101 makes that patch simpler, and folding the (dxgi) device.c changes from this patch into the next one gets rid of the temporary wined3d_surface_get_container() function without making that patch significantly more complicated. You can still (trivially) set the surface parent to NULL at the end of the series, although you should probably do the same for volumes in that case.

Aug. 31, 2015

Re: po: Update German translation.

by Florian Pelz

Hi, On 08/31/2015 12:05 PM, Julian Rüger wrote: > Hi Florian, > > I omitted the hyphen on purpose (for consistency). > There are a few other instances of "Wine foo" without hyphen, and even: > > #: uninstaller.rc:29 > msgid "Wine Application Uninstaller" > msgstr "Wine Anwendungsentferner" > > I think this is a kind of 50-50 case, where it's okay either way. > According to [1], omitting the hyphen is incorrect as per the official spelling. That said, this part of the official orthography has never quite caught on. I don't know if Wine cares about following official orthography. (Sorry that nit-picking is my only contribution to Wine so far. I hope I'll have time to do more in the future. So far I'm mostly lurking.) Best regards, Florian [1] https://de.wikipedia.org/wiki/Leerzeichen_in_Komposita

Aug. 31, 2015