Chris Ahrendt wrote:
> Ivan Gyurdiev wrote:
>> Ivan Gyurdiev wrote:
>>> James Hawkins wrote:
> context.c - same except in this case its just a return with noting
> else..
> why do a goto why not just do the return?
>
This is probably ok to change. I can only imagine that the o
Chris Ahrendt wrote:
>fail:
> if(wined3d_fake_gl_context_hdc)
> ReleaseDC(wined3d_fake_gl_context_hwnd,
> wined3d_fake_gl_context_hdc);
> wined3d_fake_gl_context_hdc = NULL;
> if(wined3d_fake_gl_context_hwnd)
> DestroyWindow(wined3d_fake_gl_context_hwnd);
>
Ivan Gyurdiev wrote:
> Ivan Gyurdiev wrote:
>> James Hawkins wrote:
context.c - same except in this case its just a return with noting
else..
why do a goto why not just do the return?
>>>
>>> This is probably ok to change. I can only imagine that the original
>>> author thought
Ivan Gyurdiev wrote:
> James Hawkins wrote:
>>> context.c - same except in this case its just a return with noting
>>> else..
>>> why do a goto why not just do the return?
>>>
>>
>> This is probably ok to change. I can only imagine that the original
>> author thought there might be cleanup needed
Ivan Gyurdiev wrote:
> James Hawkins wrote:
>>> context.c - same except in this case its just a return with noting
>>> else..
>>> why do a goto why not just do the return?
>>>
>>>
>>
>> This is probably ok to change. I can only imagine that the original
>> author thought there might be clean
James Hawkins wrote:
>> context.c - same except in this case its just a return with noting else..
>> why do a goto why not just do the return?
>>
>>
>
> This is probably ok to change. I can only imagine that the original
> author thought there might be cleanup needed at some later point.
>
Stefan Dösinger wrote:
> Can you give some examples of such code? Nobody here is a goto-maniac, but
> in all cases I know the goto is used for a good reason. Most of the time it
> is used for error path to avoid ugly if() nesting and/or code duplication
> when freeing partially allocated objects
>
On Mon, Jul 21, 2008 at 9:24 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
>
> Well here is my list so far :
>
> device.c - filled with goto's if you need the routines I can supply them...
> they can be moved to a routine and called...
>
wine$ find . -name "device.c"
./dlls/ddraw/device.c
./dlls/di
Can you give some examples of such code? Nobody here is a goto-maniac, but
in all cases I know the goto is used for a good reason. Most of the time it
is used for error path to avoid ugly if() nesting and/or code duplication
when freeing partially allocated objects
> -Original Message-
>
On Mon, Jul 21, 2008 at 8:41 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> As I have been going through trying to debug the everquest2 issues on my
> machine I have run into a few places where I think the code should be
> changed a little ( this alot of times is where there is a GOTO in the
> code
Stefan Dösinger wrote:
> Is the shader backend recreated properly after the reset?
>
>
>
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew Fenn
> *Sent:* Sunday, July 20, 2008 11:11 PM
> *To:* H. Verbeet
> *Cc:* wine-devel@winehq.org
> *Subject:* Re: one liner patch
yes I am looking at the shaders... and am noticing something as well in the
traces... some reason when it goes to ask how much memory to use...
on my machine it thinks it only has 16mb of texture memory.. when the laptop
has 256mb of video ram...? if you look in device.c the pixel shader fails
a
Hi Piotr,
I see a lot of new valgrind warnings today that seem to be
triggered by your new msxml3 code.
I don't know offhand if they're bugs in libxml2 or in your code,
could you have a look?
Thanks!
See
http://kegel.com/wine/valgrind/logs/2008-07-21-07.56/vg-msxml3_saxreader-diff.txt
Here are th
On Mon, 2008-07-21 at 22:08 +0100, Huw Davies wrote:
> Adam Petaccia wrote:
> >@@ -226,6 +277,11 @@ GpStatus WINGDIPAPI GdipSetEmpty(GpRegion*region)
> >
> > if(!(calls++))
> > FIXME("not implemented\n");
> >+TRACE("%p\n", region);
> >+
> >+GdipDeleteRegion(region);
> >+
Adam Petaccia wrote:
>@@ -226,6 +277,11 @@ GpStatus WINGDIPAPI GdipSetEmpty(GpRegion*region)
>
> if(!(calls++))
> FIXME("not implemented\n");
>+TRACE("%p\n", region);
>+
>+GdipDeleteRegion(region);
>+GdipCreateRegion(®ion);
>+region->node->type = RegionDataEmpty
Am Monday 21 July 2008 21:44 schrieb Reece Dunn:
> The error constants (e.g. ERROR_BUFFER_TOO_SMALL) are defined in
> raserror.h, which is needed for the tests to build using the Microsoft
> headers (checked against the Vista SDK headers).
>
> - Reece
my wine tree does not have the raserror.h head
On Mon, Jul 21, 2008 at 1:41 PM, Lei Zhang <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 12:54 PM, Lei Zhang <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> We should clear the out pointer on failure, so the caller won't access bad
>> data.
>>
>
> Anything wrong with this patch? Should I check the
On Wed, Jul 16, 2008 at 12:54 PM, Lei Zhang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We should clear the out pointer on failure, so the caller won't access bad
> data.
>
Anything wrong with this patch? Should I check the return value from
XDG_UserDirLookup() instead?
2008/7/21 Juan Lang <[EMAIL PROTECTED]>:
> Hi Reece,
>
> thanks for looking into failures on Vista.
No problem.
>> To me, without understanding this in any more detail, it looks as if
>> Vista is broken here (and thus the Vista return parts should be marked
>> as broken()). However, Vista may be
Hi Reece,
thanks for looking into failures on Vista.
> To me, without understanding this in any more detail, it looks as if
> Vista is broken here (and thus the Vista return parts should be marked
> as broken()). However, Vista may be doing the right thing, and thus
> the behaviour in these cases
> Right now it's simply broken of course. The extension being defined in
> the header is no guarantee the driver actually supports it.
That's the reason for the patch.
Of course my patch doesn't fix the fact that we just assume this extension
is supported. For perfection we'll need a codepath that
You could use oprofile to find out where the CPU time is spent - this
behavior can be caused by a lot of issues.
Does the Cuda client work now? If so, it would be cool if we could include
the wrapper in Wine, or get it into a shape to make it easilly
redistributable and installable next to Wine
For me make crosstest fails on comctl32, is anyone else seeing this? Or
have I missed a secret step?
make[2]: Entering directory
`/usr/local/src/cvs/wine/dlls/comctl32/tests'
i586-mingw32msvc-windres -i rsrc.res -o rsrc.res.cross.o
i586-mingw32msvc-windres: rsrc.res: Not a valid WIN32 resource fil
On Sat, Jul 19, 2008 at 11:06 AM, Mathias Kosch <[EMAIL PROTECTED]> wrote:
>> I provided a screenshot as attachment for you to see.
> I wasn't able to send it to this mailing list. I think this is by
> intention. So please ask me if you want to see.
You can attach the screenshots to the bug's entr
Right now it's simply broken of course. The extension being defined in
the header is no guarantee the driver actually supports it.
Francois Gouget <[EMAIL PROTECTED]> writes:
> I added code to filter out -L/usr/lib and -L/usr/lib64 because we're
> doing it for gphoto2 already, presumably to avoid trouble on 64bit Linux
> systems. I'm not sure if that was a gphoto2-specific issue or if it
> should be done more systematicall
(resending as I forgot to CC to wine-devel)
This test is here to test handling of incorrect flags. So a hex value is
necessary as even any combination of know values are correct according to
msdn. Sorry if I wasn't clear enough. I'm new to wine and English isn't my
first language.
I can add LINGU
> Ah, so it's essentially a recursive Reset call. My guess would be that
> we don't want to allow that, but it requires some tests on native
> win32 to verify. You could try returning WINED3DERR_INVALIDCALL when
> Reset gets called from inside another Reset call, to see how the
> application reacts
> I have been looking at writing a couple of tests for ntoskrl functions
> but I have had difficulty locating a suitable place. It sort of looks
> like ntdll/tests is the place but it is not clear. Is there a guide
> for locating this one?
>
> Jeff
Now I am working on ntoskrnl tests. I am
"Lei Zhang" <[EMAIL PROTECTED]> writes:
> diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
> index ebfa6fb..6b36364 100644
> --- a/dlls/ntdll/string.c
> +++ b/dlls/ntdll/string.c
> @@ -466,10 +466,31 @@ ULONG __cdecl NTDLL_strtoul( const char *nptr, char
> **endptr, int base )
>
> /*
> +interface IMLangLineBreakConsole : IUnknown
> +{
> +HRESULT BreakLineML(
> +[in] IUnknown* pSrcMLStr, /* FIXME: IMLangString */
> +[in] long lSrcPos,
> +[in] long lSrcLen,
> +[in] long cMinColumns,
> +[in] long cMaxColumns,
> +[out] long* plLi
"Lei Zhang" <[EMAIL PROTECTED]> writes:
> -datalen = abs(stride * height);
> +datalen = stride * height;
> size = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + datalen;
> +if (datalen <= 0 || size <= 0){
> +GdipFree(*bitmap);
> +*bitmap = NULL;
> +r
2008/7/21 Andrew Fenn <[EMAIL PROTECTED]>:
> Here's my uneducated idea about what's happening, it's calling the
> USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to
> SendMessageW.
>
> SendMessageW calls send_message which in turn calls call_window_proc. At
> this point so
Francois Gouget <[EMAIL PROTECTED]> writes:
> Blastwave's 'gphoto2-config --libs' does not say that we need to link
> with libintl.so when linking with libgphoto2.so. In a way it's normal as
> this dependency does not come from libgphoto2 itself, but from one of
> the libraries it links with. I
Here's my uneducated idea about what's happening, it's calling the
USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to
SendMessageW.
SendMessageW calls send_message which in turn calls call_window_proc. At
this point something resets because SendMessageW should log both a
2008/7/21 Andrew Fenn <[EMAIL PROTECTED]>:
> fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
> fixme:d3d_shader:shader_glsl_free FREE SHADER
> fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x
> fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x
> fixme:d3d9:IDirect3DDevice9Impl_Re
I changed:
hr = This->shader_backend->shader_alloc_private(iface);
To the following:
FIXME("BEFORE, hr: 0x%08x\n", hr);
hr = This->shader_backend->shader_alloc_private(iface);
FIXME("AFTER, hr: 0x%08x\n", hr);
...and then I ran everquest2.exe again, alt+enter to full screen...
fixme:d3d9:IDire
37 matches
Mail list logo
