On 5 May 2010 01:39, wrote:
> #274 before wined3d_mutex_unlock(), 0x0020a3f0=HeapAlloc(),
> &wined3d_cs=0x7e22fda0
> #274 after wined3d_mutex_unlock(), 0x18fa7048=HeapAlloc(),
> &wined3d_cs=0x7e22fda0
> ^^^
> Any suggestion?
>
What exactl
Knowing that they are developing an opengl version of their engines
(for mac os), I'm guessing porting it to linux will be trivial.
J. Leclanche
On Thu, May 6, 2010 at 3:07 AM, Ben Klein wrote:
> On 6 May 2010 10:01, Evil Jay wrote:
>> On 05/05/2010 02:34 PM, André Hentschel wrote:
>>> Hi Fol
On 6 May 2010 10:01, Evil Jay wrote:
> On 05/05/2010 02:34 PM, André Hentschel wrote:
>> Hi Folks,
>> Steam seems to add a Linux client in the near future, so maybe Wine will not
>> be needed anymore for that. or did i get something wrong?
>> That might reduce our "market share" a bit as i guess
On 05/05/2010 02:34 PM, André Hentschel wrote:
> Hi Folks,
> Steam seems to add a Linux client in the near future, so maybe Wine will not
> be needed anymore for that. or did i get something wrong?
> That might reduce our "market share" a bit as i guess that many Wineusers
> play steam games.
> O
On 5/6/2010 02:11, Gerald Pfeifer wrote:
Also in other places don't we check the result of SendMessage, and that's
not really what we want to test here, either, from what I can tell.
-res = SendMessage(hwnd, MCM_GETMINREQRECT, 0, (LPARAM)&r1);
+SendMessage(hwnd, MCM_GETMINREQRECT,
On Wed, 5 May 2010, test...@testbot.winehq.org wrote:
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> Full results can be found at
> http://testbo
2010/5/5 André Hentschel :
> Hi Folks,
> Steam seems to add a Linux client in the near future, so maybe Wine will not
> be needed anymore for that. or did i get something wrong?
> That might reduce our "market share" a bit as i guess that many Wineusers
> play steam games.
The rumor is that Valv
Hi Folks,
Steam seems to add a Linux client in the near future, so maybe Wine will not be
needed anymore for that. or did i get something wrong?
That might reduce our "market share" a bit as i guess that many Wineusers play
steam games.
On the other hand Intel presented its Z600, which is basical
On 05/04/2010 03:59 AM, Love Nystrom wrote:
> Since this is not a straight 'diff' mail-body I'll post it here on
> wine-devel first, as I'm unsure how You handle wine-patches mail.
Send all patches in git format to wine-patches mailing list. Plain text
source file (not in diff format) is not a patc
---
Hi gus,
Thought I'd try again :) This is a cleaned up version. The license on
rtkit.c will still have to change, but since it's so heavily modified
to get it into a shape for wine, that only a few lines in
make_realtime are still original, so it would be easy to rewrite the
remainder of that
Gerald Pfeifer writes:
> I didn't see any response, directly or on wine-devel, so I assume
> this one just fell through the cracks; thus resending (now in git
> format-patch format and proper Subject).
It's very unlikely that we'd want to use red and green but not blue...
--
Alexandre Julliard
On 5 May 2010 00:24, Gerald Pfeifer wrote:
> I didn't see any response, directly or on wine-devel, so I assume
> this one just fell through the cracks; thus resending (now in git
> format-patch format and proper Subject).
>
It probably should be used. At first sight it looks like that's not
the on
On Tue, 04 May 2010 10:22:44 -0600, Charles Davis
wrote:
> On 5/4/10 10:17 AM, Johann "Myrkraverk" Oskarsson wrote:
>> Hi all,
>>
>> In the Solaris/BSD implementation of reserve_area() in libs/wine/mmap.c
>> there is
>>
>> for (i = 0; i < size; i += pagesize)
>> if (mincore(
So after next few hours of "debuging my way" (HeapAlloc + printf + HeapFree)
and bisecting where HeapAlloc is OK and where isn't i come to conclusion,
that there is someting bad with wined3d_mutex_unlock(), i.e. it looks
like pure luck, that the game runs with native openal32 and freezes
with buil
14 matches
Mail list logo