On Fri, Jul 26, 2013 at 2:04 AM, Nikolay Sivov 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
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 wrote:
> On 7/26/2013 08:48, Alexei Svitkine wrote:
>
>
>
>
> On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svit
On 7/26/2013 08:48, Alexei Svitkine wrote:
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine
mailto:alexei.svitk...@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
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine 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 (0x5000) an
On Mon, Jul 22, 2013 at 10:45 PM, Alexei Svitkine 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 (0x5000) an
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 (0x5000) and loading the Mac native gdi
driver ends up using that part of the ad
