Nicolas Le Cam [EMAIL PROTECTED] wrote:
Vista introduced new flags for CompareString, as stated in [1].
The value defined for LINGUISTIC_IGNORECASE is 0x10. So the invalid flag
test don't fail as expected starting from this platform.
[1] http://msdn.microsoft.com/en-us/library/ms647476.aspx
2008/7/21 Stefan Dösinger [EMAIL PROTECTED]:
Is the shader backend recreated properly after the reset?
Just to clarify, in dlls/wined3d/device.c, IWineD3DDeviceImpl_Reset(),
line 7355 there's a call to shader_alloc_private(). This call is
supposed to recreate This-shader_priv.
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...
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_Reset
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
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
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 something
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;
+return
+interface IMLangLineBreakConsole : IUnknown
+{
+HRESULT BreakLineML(
+[in] IUnknown* pSrcMLStr, /* FIXME: IMLangString */
+[in] long lSrcPos,
+[in] long lSrcLen,
+[in] long cMinColumns,
+[in] long cMaxColumns,
+[out] long* plLineLen,
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 )
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 going
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 to
(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
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 systematically. If
Right now it's simply broken of course. The extension being defined in
the header is no guarantee the driver actually supports it.
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 entry in
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
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
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
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
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 doing 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?
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 return value
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 header.
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(region);
+region-node-type = RegionDataEmptyRect;
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);
+
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
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
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 to stop
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). My
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 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
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
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.
The bigger
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 at some
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 at some later
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 there might be cleanup
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);
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 original
author thought there
39 matches
Mail list logo
