On Mi, 2009-11-11 at 15:16 +0100, Henri Verbeet wrote:
> I.e., does the attached patch work for you?
yes, with 0 failures :-)
d3d9 has the same code (but i cant test d3d9 on my machine).
Thanks.
Do you want to send the patches yourself?
--
By by ... Detlef
2009/11/11 :
> Hi,
>
> AJ wrote in
> http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html
>>If there is proper synchronization you don't need
>>volatile, and if there isn't volatile won't magically fix it.
>
> However, mcimidi has in its code since pre 1999:
> :/* it seems that in
2009/11/11 Dan Kegel :
> As of today, six tests:
>
> http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt
> http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt
> http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt
> http://kegel
On Mon, Nov 9, 2009 at 2:12 PM, Rob Shearman wrote:
> 2009/11/9 Dan Kegel :
>> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728
>> at RtlAllocateHeap (heap.c:1423)
>> by RtlAllocateAndInitializeSid (sec.c:156)
>> by NtQueryInformationToken (nt.c:379)
>> by GetTokenInforma
On Wed, Nov 11, 2009 at 11:08 AM, Nikolay Sivov wrote:
> Hi, guys.
> I'd like to read something about decisions if any you've made at this
> conf, some principle ideas or something. Wiki page
> doesn't talk too much - but thanks for Michael's slides about
> wine-oopses. All I'm able to find is Mar
As of today, six tests:
http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt
http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt
http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt
http://kegel.com/wine/valgrind/logs/2009-11-11
Alexandre Julliard wrote:
> chris ahrendt writes:
>
>> Alexandre Julliard wrote:
>>> chris ahrendt writes:
>>>
Well its been a few since I ran CPP Check and so I ran it today and got
the following:
New CPP Check Errors for the Wine Code:
[/home/cahrendt/wine-git/d
2009/11/11 Dan Kegel :
> http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html
> shows (using Chromium as an example) how windows
> developers can find memory errors in their
> windows code by running their test suites under valgrind+wine.
> It's still an early draft; I expect to improve
http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html
shows (using Chromium as an example) how windows
developers can find memory errors in their
windows code by running their test suites under valgrind+wine.
It's still an early draft; I expect to improve it as I gain experience
tracking
Dan Kegel wrote:
>I had a new hang on yesterday's git under valgrind:
>err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason:
>Resource temporarily unavailable
>... 1600 dup lines removed ...
>ALSA lib ../../../src/pcm/pcm.c:7228:(snd_pcm_recover) underrun occured
Good that I'm not al
Hello Alexandre and Maarten,
as you guys where discussing right now on irc about it I'm rushing this
email out.
On 11/07/2009 02:45 PM, Maarten Lankhorst wrote:
> ---
> From 88fde5ad95a33dc2da29757605891ccc5047c12f Mon Sep 17 00:00:00 2001
> From: mlankhorst
> Date: Sat, 7 Nov 2009 13:34:54 +000
Hi, guys.
Unfortunately, but as I expected, I wasn't able to participate in
Wineconf2009 (I'm business tripping for 3 weeks in central Asia now).
I'd like to read something about decisions if any you've made at this
conf, some principle ideas or something. Wiki page
doesn't talk too much - but th
Lucid has fixed the bug I mentioned earlier, and now Wine can be compiled in
pre-alpha Lucid Lynx, providing all updates are as-of today, ll/11.
In case anyone is interested, the working gcc is:
gcc (Ubuntu 4.4.2-1ubuntu4) 4.4.2
http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/diff-winhttp_notification.txt
http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/vg-winhttp_notification.txt
has a bunch of new errors, all of which seem to look like this:
Invalid read of size 4
at check_notification (notification.c:65)
Hi Joerg,
I had a new hang on yesterday's git under valgrind:
../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p
winmm_test.exe.so mci.c && touch mci.ok
preloader: Warning: failed to reserve range 0011-6800
mci.c:186: Test failed: mci close all notify (without buffer) returned
e
Hello!
Damjan Jovanovic wrote:
> Can someone please write a bit about Wineconf 2009, for those of us
> that didn't go?
>
> Also is there videos/presentations to see?
I have added mine to the bottom of http://wiki.winehq.org/WineConf2009
bye
michael
2009/11/6 Henri Verbeet :
> If changing the usage makes it work, that's ok. Maybe try just passing
> 0 for usage. The texture doesn't have to be lockable, all we care
> about is having a unique texture pointer for the
> SetTexture()/GetTexture() calls.
>
I.e., does the attached patch work for you?
Hi
Can someone please write a bit about Wineconf 2009, for those of us
that didn't go?
Also is there videos/presentations to see?
Thank you
Damjan Jovanovic
2009/11/11 Michael Stefaniuc :
> Ben Klein wrote:
>> 2009/11/11 Michael Stefaniuc :
>>> For fedora it will not be possible to do a special 32bit compile on the
>>> x86_64
>>> arch.
>>
>> Wait ... no gcc -m32 on Fedora x86_64?
> The compiler is not the problem but the missing i586 libraries+headers
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
the MCI relies on notification to implement auto-open correctly. When
the command is done, it must send out a notification via PostMessageW.
The receiver then ought to call mciClose.
One possible implementation would be to have auto-open start a th
On Wed, Nov 11, 2009 at 11:13:06AM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Hi,
>
> AJ wrote in
> http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html
> >If there is proper synchronization you don't need
> >volatile, and if there isn't volatile won't magically fix it.
>
Owen Rudge writes:
> For some reason, we have implemented the GetFileNameFromBrowse
> function in shell32 with ANSI functions. According to MSDN, the
> function should use Unicode, and IE7 (which uses the function for its
> File -> Open routine) expects this. This patch fixes that.
It should pro
2009/11/10 Owen Rudge :
> +static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage,
> +HBITMAP hbmMask, int *pi)
> +{
> +FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi);
> +return E_NOINTERFACE;
> +}
This is minor at this point, but E_NOTIMPL is usually a
writes:
> So what's the use of volatile? When is it appropriate in Wine?
In general it's never appropriate. There are some very specific cases
where it can be used, but you have to be sure to know what you are
doing. Using proper synchronization instead is strongly recommended.
--
Alexandre Ju
Owen Rudge writes:
> These patches finish the implementation of the IImageList v6 interface
> in comctl32.
This doesn't seem to match Windows, even independently from the
structure layout issue. There's no DllGetClassObject or clsid
registration on Windows, it's not handled as a standard COM dll
Hi,
AJ wrote in http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html
>If there is proper synchronization you don't need
>volatile, and if there isn't volatile won't magically fix it.
However, mcimidi has in its code since pre 1999:
:/* it seems that in case of multi-threading, gcc
Hi,
So far my my patches have dealt only with "internal thread
consistency", i.e. to avoid bogus conditions that result by using
threads *internal* to the MCI.
I wonder whether the individual MCI devices must protect themselves
from application-level threads, i.e. an application issuing commands
Hi,
the MCI relies on notification to implement auto-open correctly. When
the command is done, it must send out a notification via PostMessageW.
The receiver then ought to call mciClose.
One possible implementation would be to have auto-open start a thread
that does nothing else but wait for this
Ben Klein wrote:
> 2009/11/11 Michael Stefaniuc :
>> For fedora it will not be possible to do a special 32bit compile on the
>> x86_64
>> arch.
>
> Wait ... no gcc -m32 on Fedora x86_64?
The compiler is not the problem but the missing i586 libraries+headers
in the x86_64 build tree.
>> Hence the
chris ahrendt writes:
> Alexandre Julliard wrote:
>> chris ahrendt writes:
>>
>>> Well its been a few since I ran CPP Check and so I ran it today and got
>>> the following:
>>>
>>> New CPP Check Errors for the Wine Code:
>>>
>>> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error
30 matches
Mail list logo
