July 2013 - Wine-Devel - list.winehq.org

[1/1] kernel32: Implemented basic NUMA functions to replace the stubs

by Chris Moeller

Main changes from HEAD: 1) Implements GetNumaHighestNodeNumber which simulates a typical single node system. 2) Implements GetNumaNodeProcessorMask which returns the global processor affinity mask for node 0, otherwise returns an error. 3) Implements GetNumaAvailableMemoryNode which returns available physical memory for node 0, otherwise returns an error. This much of the behavior was observed based on a single processor (4 cores) Windows 7 system. These functions are utilized by the synchronization and threading primitives incorporated in the MSVC 2012 and newer C and C++ runtime libraries. concrt.h/Concurrency::critical_section, which is used by both std::mutex and std::thread, will throw an exception the moment the object is locked if GetNumaHighestNodeNumber fails, and there are at least a few examples of software which don't bother to catch this exception and thus crash, such as the alpha version of Cube World, and certain versions of the foo_wave_seekbar component for the foobar2000 audio player. The associated scheduling code appears to make use of GetNumaNodeProcessorMask as well to control how many threads are allowed to spin up at once, or so I guess without looking very deeply into the CRT source code.

July 28, 2013

Re: [PATCH 3/5] d3dx9: Add support for structs to ID3DXConstantTable.

by Rico Schüller

Hi Matteo, On 25.07.2013 16:12, Matteo Bruni wrote: > 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >> --- >> dlls/d3dx9_36/shader.c | 79 >> ++++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 77 insertions(+), 2 deletions(-) >> > > So there was actually a logic (an insane one, but yeah...). Have you > found any game actually using this? No, I haven't found a game which uses this. I also haven't specifically tried a lot of games for this. > > Annoying question: have you checked if it's the same with newer d3dx9 > dlls (e.g. d3dx9_43)? It still looks to me like buggy behavior and it > might be that MS fixed that in later d3dx9 versions. > This is not blocking the patch of course. > Yes, the results are the same with d3dx9_43.dll and with d3dx9_36.dll. Yeah, the behavior looks really buggy, but who knows why it works that way... Cheers Rico

July 28, 2013

Re: Windows 7 64-bit?

by Rosanne DiMesio

On Fri, 26 Jul 2013 22:49:55 +0100 Ken Sharp <kennybobs(a)o2.co.uk> wrote: > > > On 26/07/13 19:42, Rosanne DiMesio wrote: > > But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. > > This is a real pain. Was it intentional or a bug that's slipped in? > > I believe it was taken away after the AppDB was hacked a couple of years ago. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 27, 2013

Re: Windows 7 64-bit?

by Ken Sharp

On 26/07/13 19:42, Rosanne DiMesio wrote: > But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. This is a real pain. Was it intentional or a bug that's slipped in?

July 26, 2013

Re: Windows 7 64-bit?

by Rosanne DiMesio

On Fri, 26 Jul 2013 16:47:36 +0100 Ken Sharp <kennybobs(a)o2.co.uk> wrote: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting… > > No; letting it through was my mistake. This was actually the third time he submitted it. The previous two times I caught it and told him to select a valid distro, but I missed it this time. I realized it after I had approved it and have already deleted the whole entry. The user who keeps submitting it is marketing(a)smartpixel.com, so I doubt this is anything more than a ploy to improve his site's search engine ranking. But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. -- Rosanne DiMesio <dimesio(a)earthlink.net>

July 26, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > There's a TIFF_VERSION define that seems to have been renamed to > TIFF_VERSION_CLASSIC in 4.0. > > It doesn't make sense to do the check at runtime, given we're only > going to link to one of the versions. TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43. Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time. -- Dmitry.

July 26, 2013

Re: Windows 7 64-bit?

by André Hentschel

Am 26.07.2013 17:47, schrieb Ken Sharp: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting… > > Ask him what he really wanted to choose.

July 26, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Vincent Povirk

There's a TIFF_VERSION define that seems to have been renamed to TIFF_VERSION_CLASSIC in 4.0. It doesn't make sense to do the check at runtime, given we're only going to link to one of the versions.

July 26, 2013

Windows 7 64-bit?

by Ken Sharp

I have to ask: Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting…

July 26, 2013

Re: gdi32: Don't let the gdi32 driver allocate memory in the dplayx region.

by Alexei Svitkine

Sorry, I wasn't subscribed to wine-patches and the first two mails only went through to wine-devel, but didn't get through to wine-patches. On Fri, Jul 26, 2013 at 2:04 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 7/26/2013 08:48, Alexei Svitkine wrote: > > > > > On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine < > alexei.svitkine(a)gmail.com> wrote: > >> Don't let the gdi32 driver allocate memory in the dplayx region. >> >> Fixes bug: http://bugs.winehq.org/show_bug.cgi?id=34095 >> >> The issue is that the dplayx code in wine needs to allocate some >> memory at a static address (0x50000000) and loading the Mac native gdi >> driver ends up using that part of the address space. >> >> This patch fixes that by reserving that part of memory while the >> display driver is initialized and releasing it after. >> >> --- >> dlls/gdi32/driver.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> > Please stops resending this. Looks like dplay should be fixed to not > depend on that reserved address area. > >

July 26, 2013