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(+)
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine <alexei.svitkine@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(+)
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine <alexei.svitkine@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(+)
On 7/26/2013 08:48, Alexei Svitkine wrote:
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine <alexei.svitkine@gmail.com mailto:alexei.svitkine@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.
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@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@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.
On Fri, Jul 26, 2013 at 2:04 AM, Nikolay Sivov bunglehead@gmail.com wrote:
Looks like dplay should be fixed to not depend on that reserved address area.
I agree, that's the ideal solution. However, I'm not sufficiently familiar with what dplay is doing to need that block of memory at that address or what would be involved in fixing it.
In the mean time, this patch fixes the Wine 1.6 regression on Mac OS X, while there's no fix for the harder problem.
-
Alexei Svitkine -
Nikolay Sivov