Re: one liner patch to stop crash, everquest2.exe

[H. Verbeet]

> certainly worth a try to see if it fixes the game. It'll involve
There should be a "You'll still need a test case though." somewhere in
that line.

Re: one liner patch to stop crash, everquest2.exe

[H. Verbeet]

2008/7/24 Andrew Fenn <[EMAIL PROTECTED]>:
> Any suggestion on where to go from here? Does this need more discussion
> elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?
>
> I'm having trouble understanding where I should be checking for this error
> and returning an the invalid call.
>
Simply returning WINED3DERR_INVALIDCALL on recursive Resets is
certainly worth a try to see if it fixes the game. It'll involve
switching a d3d window from windowed to fullscreen, and having a
window proc that calls Reset on position changes. There are two things
you want to know there: does your window proc get triggered by Reset
in the first place, and if it does, what does the second reset return.

Re: one liner patch to stop crash, everquest2.exe

[Andrew Fenn]

Any suggestion on where to go from here? Does this need more discussion
elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?

I'm having trouble understanding where I should be checking for this error
and returning an the invalid call.

On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger <[EMAIL PROTECTED]>
wrote:

> > 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 that.
> This also raises another question regarding the window handling in wined3d:
> Are we allowed / supposed to modify the window size and position of the
> destination window the app supplies like this? A lot of apps seem to need
> that, otherwise the rendering is placed incorrectly or not visible because
> the window is hidden. However, it could be that Windows somehow renders
> correctly without changing the Window's properties.
>
> So the SetWindowPos() call in Reset() might be the wrong thing here. It is
> not entirely unexpected that the app calls Reset when it receives a Window
> position / size change. If the Window size changes, the app is supposed to
> reset the D3D device, otherwise the rendering output is stretched in
> Present(which can look kinda ugly)
>
>
>

Re: EverQuest2.exe and context.c

[Chris Ahrendt]

Vitaliy Margolen wrote:
> Chris Ahrendt wrote:
>> Ok I ran make test and got the failure without running Everquest2.exe 
>> let me attach the output of maketest. I guess thats a start eh?
>>
> You getting off-topic too far here. Make test have nothing to do with 
> your game. Especially that you attached complete output of everything.
> 
> However this lines tell the whole story:
>> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
>> libGL error: reverting to (slow) indirect rendering
> 
> You have broken driver. And I'm afraid your configuration can not be 
> supported. You could try and read the faq about how to try and fix it. 
> But that still won't fix broken driver.
> 
> Vitaliy
> 
> PS:
> Please do not attach big files to mailing list. If you are asked for 
> them - send to that person directly or attach to the bug report.
> 
> PPS:
> Please take this discussion to the bug report. It's not a general case 
> but a game specific. It belongs there not in the developer's mailing 
> list. Since you are not a developer yourself and just add an extra noise 
> to the mailing list.
Actually Vialiy it is a discussion that belongs here... not in bug fix..
I have had that gl error and its not what we are working on... the 
problem we are working on was first found in EverQuest2.exe but I was 
able to reproduce it without everquest. so its not a game related issue.
Second point.. I was told to bring this sort of discussion over here to
discuss as the patch list is not for general discussion.

Chris

Re: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Victor]

On Wednesday 23 July 2008 21:48:59 Chris Robinson wrote:
> But extracting the mask offset and size from the actual mask takes a bit of
> time, 
Extracting mask is called once or twice per channel conversion. I.e. in case 
of converting a8r8g8b8->a1r5g5b5 mask should be calculated only 8 times, no 
matter how big surface is. check mask_copy() routine for details. Optimizing 
this is pointless - converter performs much more per pixel operations - 
shifts, bitwise operations, etc, so you won't notice any difference.

> and as it is, the table can't currently set a proper mask for 
> anything over 32 bits (including the 16-bit-per-component unsigned integer
> types).
Yes, this isn't supported. But with current scheme of conversion, adding 
support for 16-bit-per-component surfaces would require operating on 64bit 
numbers or increasing number of per-pixel operations. I think per-pixel 64bit 
shifts on 32bit CPUs will be slower. 

replacing masks with number of bits and shift will need additional work, since 
masks are probably used in other places. There will be also high chance of 
breaking entire table accidentally because of misprint. 

If you don't like current functionality, to my opinion the best approach would 
be to modify it once my patch made it in repository. 

-- 
Victor Eremin ([EMAIL PROTECTED])


signature.asc
Description: This is a digitally signed message part.

Re: [5/5] WineD3D: Make the MAC ARBvp implementation happy about ARL

[Ivan Gyurdiev]

 > Unfortunately we can't make it a different function in the shader 
instruction table because the difference between MOV and ARL is decided 
with the dest register.

Sure you can, it seems that this MOV/MOVA specific stuff all belongs in 
vshader_hw_mov (both sides of the MOV if statement can be moved). 

There should also be a comment explaining what this ARL block is doing, and why 
(as part of "wined3d: Relative addressing offsets are limited to [-64; 63] in 
arb.").

Ivan

GL_INVALID_ENUM errors with FBO

[Vitaliy Margolen]

I've been trying to track some of the errors that I get with different 
games. To do that I've added some extra traces and this is what I see:


fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was 
0x8ce0 > GL_INVALID_ENUM (0x500) @ 
../../../wine.git/dlls/wined3d/surface.c / 918


0x405 is GL_BACK and 0x8ce0 is GL_COLOR_ATTACHMENT0_EXT. Also when this 
happens I have an inverted image of the entire screen in the left bottom 
corner. Is this an indication that we are reading from the wrong surface? Or 
writing into the wrong surface?


Attached is the patch that produces the above output. BTW if it looks fine 
to you guys (that extra TRACE()/FIXME() call overhead) then I can send it to 
 wine-patches as well.


Vitaliy.
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 53070f2..3e3789c 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -910,11 +910,12 @@ static void read_from_framebuffer_texture(IWineD3DSurfaceImpl *This)
  */
 TRACE("Locking offscreen render target\n");
 glReadBuffer(device->offscreenBuffer);
+checkGLcall("glReadBuffer(%#x) was %#x", device->offscreenBuffer, prevRead);
 } else {
 GLenum buffer = surface_get_gl_buffer((IWineD3DSurface *) This, (IWineD3DSwapChain *)swapchain);
 TRACE("Locking %#x buffer\n", buffer);
 glReadBuffer(buffer);
-checkGLcall("glReadBuffer");
+checkGLcall("glReadBuffer(%#x) was %#x", buffer, prevRead);
 
 IWineD3DSwapChain_Release((IWineD3DSwapChain *) swapchain);
 }
diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
index 874f972..f48268d 100644
--- a/dlls/wined3d/wined3d_private.h
+++ b/dlls/wined3d/wined3d_private.h
@@ -324,15 +324,16 @@ extern int num_lock;
 
 /* Checking of API calls */
 /* - */
-#define checkGLcall(A)  \
+#define checkGLcall(A...)   \
 {   \
 GLint err = glGetError();   \
 if (err == GL_NO_ERROR) {   \
-   TRACE("%s call ok %s / %d\n", A, __FILE__, __LINE__);\
-\
+TRACE(A);   \
+TRACE(" @ %s:%d call ok\n", __FILE__, __LINE__);\
 } else do { \
-FIXME("> %s (%#x) from %s @ %s / %d\n", \
-debug_glerror(err), err, A, __FILE__, __LINE__);\
+FIXME(A);   \
+FIXME(" > %s (%#x) @ %s / %d\n",\
+debug_glerror(err), err, __FILE__, __LINE__);   \
err = glGetError();  \
 } while (err != GL_NO_ERROR);   \
 } 

Re: EverQuest2.exe and context.c

[Vitaliy Margolen]

Chris Ahrendt wrote:
> Ok I ran make test and got the failure without running Everquest2.exe 
> let me attach the output of maketest. I guess thats a start eh?
> 
You getting off-topic too far here. Make test have nothing to do with your 
game. Especially that you attached complete output of everything.

However this lines tell the whole story:
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
> libGL error: reverting to (slow) indirect rendering

You have broken driver. And I'm afraid your configuration can not be 
supported. You could try and read the faq about how to try and fix it. But 
that still won't fix broken driver.

Vitaliy

PS:
Please do not attach big files to mailing list. If you are asked for them - 
send to that person directly or attach to the bug report.

PPS:
Please take this discussion to the bug report. It's not a general case but a 
game specific. It belongs there not in the developer's mailing list. Since 
you are not a developer yourself and just add an extra noise to the mailing 
list.

Re: crypt32/tests: check Vista error codes for the msg tests.

[Reece Dunn]

2008/7/23 Markus Hitter <[EMAIL PROTECTED]>:
>
> Am 23.07.2008 um 02:25 schrieb Reece Dunn:
>>
>> +/* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */
>> +/* ret is FALSE on XP and earlier but TRUE on Vista, therefore
>> it cannot be tested for */
>> +ok((GetLastError() == E_INVALIDARG || GetLastError() ==
>> 0xdeadbeef),
>> +   "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError
>> ());
>
> A more general question: Is it Wine's policy to just ignore
> differences in behaviour between different Windows versions? From my
> own (naive) standpoint I'd say something like this would be better
> (pseudo-code):

The tests should not rely on detecting the running platform version.

> if (WinVer <= XP) {
> ok((!ret && [...]),
>"Expected [...]);
> } else {
> ok((ret && [...]),
>"Expected [...]);
> }

This gets messy when testing something like urlmon, shlwapi and others
that get updated with IE. You then have to check IE version as well,
or more specifically the DLL version.

This would then make it difficult for the tests to pass on Wine that
is essentially a hybrid of all the current Windows versions.

> Likely a often asked question, but I couldn't find hints about the
> answer yet.

>From http://www.winehq.org/site/docs/winedev-guide/testing-platforms:

"If an API is only present on some Windows platforms, then use
LoadLibrary and GetProcAddress to check if it is implemented and
invoke it. Remember, tests must run on all Windows platforms.
Similarly, conformance tests should nor try to correlate the Windows
version returned by GetVersion with whether given APIs are implemented
or not. Again, the goal of Wine is to run Windows applications (which
do not do such checks), and not be a clone of a specific Windows
version. "

- Reece

Re: crypt32/tests: check Vista error codes for the protectdata tests.

[Juan Lang]

Hi Reece,

> (Vista does not set the last error on success for the functions used
> in protectdata).

In that case, it seems to me we should just remove those tests, as
it's unlikely an app can depend on the last error being set on
success.
--Juan

Re: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Chris Robinson]

On Wednesday 23 July 2008 10:29:37 am Victor wrote:
> 0) initial patch used "mask size" + "mask offset", but was rewritten to use
> mask value when Stefan Dösinger requested that. I don't want to rewrite it
> back to use mask size + mask offset.
> 1) mask size and offset can be extracted from mask value.
> 2) using mask instead of "mask size" + "mask offset" requires less function
> arguments and smaller format table, although, yes there is a higher chance
> of producing errors.

But extracting the mask offset and size from the actual mask takes a bit of 
time, and as it is, the table can't currently set a proper mask for anything 
over 32 bits (including the 16-bit-per-component unsigned integer types).

Re: crypt32/tests: check Vista error codes for the msg tests.

[Juan Lang]

Hi Markus,

> A more general question: Is it Wine's policy to just ignore
> differences in behaviour between different Windows versions?

No, we wish to accept most Windows versions.  Not quite all, because
in some cases old versions of Windows are clearly broken.  That's what
we have the handy broken() for in the tests.

> From my own (naive) standpoint I'd say something like this would be better
> (pseudo-code):
>
> if (WinVer <= XP) {
> ok((!ret && [...]),
>"Expected [...]);
> } else {
> ok((ret && [...]),
>"Expected [...]);
> }

This isn't better, because the Windows version isn't a reliable way to
check the expected behavior.  New service packs, new versions of IE,
new drivers, and many other things not reflected by the Windows
version affect the expected result.  So the current way of accepting
any Windows result we think is not terribly broken is better than your
suggestion.

> Likely a often asked question, but I couldn't find hints about the
> answer yet.

Indeed, that is often asked.  /me thinks we need a developer FAQ..
--Juan

Re: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Victor]

On Wednesday 23 July 2008 21:18:57 Chris Robinson wrote:
> Maybe it would be better if the table was changed to have a bit offset and
> a mask size, instead of the actual mask.
0) initial patch used "mask size" + "mask offset", but was rewritten to use 
mask value when Stefan Dösinger requested that. I don't want to rewrite it 
back to use mask size + mask offset. 
1) mask size and offset can be extracted from mask value.
2) using mask instead of "mask size" + "mask offset" requires less function 
arguments and smaller format table, although, yes there is a higher chance of 
producing errors.

-- 
Victor Eremin ([EMAIL PROTECTED])


signature.asc
Description: This is a digitally signed message part.

Re: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Chris Robinson]

On Wednesday 23 July 2008 09:10:02 am Stefan Dösinger wrote:
> The patch looks reasonably, just one small thing: There is a count_bits
> function implemented in utils.c, which as far as I can see does the same as
> getMaskSize. Can you check if you can reuse it?

Maybe it would be better if the table was changed to have a bit offset and a 
mask size, instead of the actual mask. All the bits for any given component 
are always continuous, and things would be easier to handle with the offset 
and size (eg. the float formats could get a proper mask; not that they could 
be converted in this way, though). So for a generic converter, you can 
basically get:

outcolor = (((incolor>>infmt->r_offset)&((1r_size / infmt->r_size) << outfmt->r_offset;
outcolor |= (((incolor>>infmt->g_offset)&((1g_size / infmt->g_size) << outfmt->g_offset;
outcolor |= (((incolor>>infmt->b_offset)&((1b_size / infmt->b_size) << outfmt->b_offset;
outcolor |= (((incolor>>infmt->a_offset)&((1a_size / infmt->a_size) << outfmt->a_offset;

For any non-mixed unsigned integer type.

Re: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Victor]

On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> Actually, one more idea:
>
> It will be extra-slow, but we could implement a general all-to-all format
> by converting the source format to A32R32G32B32F(float values), and then
> write code to convert this format to all possible destination formats. The
> from->to table lookup could be replaced by code that can combine multiple
> conversions to find a conversion strategy(e.g. R5G6B5->ARGB32F->R8G8B8). I
> am not sure if it is a good idea, but it is worth a consideration
I thought about that, but decided that it'll be too slow (conversion to float 
and back), and there are more than 4 possible channels (luminance, palette, 
depth, stencil, channels for formats like D3DFMT_V8U8), there are compressed 
formats like DXT, and two palette formats that would need additional data for 
conversion. I think it makes sense (later) to implement several different 
generic converters, several special conversion functions (like A8R8G8B8->P8) 
and then use this strategy to combine all these converters into one chain. It 
makes sense to consider which conversions are really used. Stuff like 
R5G6B5->X8R8G8B8 is common, but I don't think anyone would ever need 
D24S8->ARGB32F. Even ARGB32F->P8 is unlikely (although X8R8G8B8->P8 is 
required by some games).

On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> The patch looks reasonably, just one small thing: There is a count_bits
> function implemented in utils.c, which as far as I can see does the same as
> getMaskSize. Can you check if you can reuse it?
Done and resubmitted (count_bits was more elegant, by the way). But I hope 
that there is a warranty that unsigned int isn't less than 32 bit on all 
systems where WINE is used (maybe I'm just paranoid).

-- 
Victor Eremin ([EMAIL PROTECTED])


signature.asc
Description: This is a digitally signed message part.

RE: Convert 565 to 0888

[Stefan Dösinger]

This patch collides with Victor Eremin's general convertor I think. We may 
still want both, because the special function is faster than code that attempts 
to handle all potential formats.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-patches-
> [EMAIL PROTECTED] On Behalf Of Austin English
> Sent: Wednesday, July 23, 2008 9:34 AM
> To: [EMAIL PROTECTED]
> Subject: Fwd: Convert 565 to 0888
> 
> -- Forwarded message --
> From: Einars <[EMAIL PROTECTED]>
> Date: Jul 22, 2008 11:22 PM
> Subject: Convert 565 to 0888
> To: wine-devel@winehq.org
> 
> 
> I had graphical problems with an online game called Angels Online, when
> just a black screen was visible, and complaints about missing converter
> from  WINED3DFMT_R5G6B5 to WINED3DFMT_X8R8G8B8, so I added a converter
> for this format, and the game runs flawlessly now on wine, the 1.1.1
> release as well as git version (at least for me). I hope this was the
> right way to fix it.
> 
> Kind regards,
> 
> Einars Lielmanis

RE: EverQuest2.exe and context.c

[Stefan Dösinger]

> Ok I did a clean install.. rebuilt wine from the base 1.1.1  code put
> the above patch into the context.c and reran EverQuest2.exe I put
> export WINEDEBUG=+d3d,+sed before running and am attaching the trace.
> (If you need more just send me a message and I will retry it.
> I still get the card does not have pixel shader error (and yes the card
> has pixel shaders (its an ATI FIREGL5200)). I am attaching the log and
> the screenshot.
Don't let yourself be fooled by the pixelshader error message. It most
likely has nothing to do with pixel shaders at all. Most likely the game
does something like this:

try {
do_init_1();
do_init_2();
do_init_3();
} catch(all_stuff_that_can_go_wrong) {
/* Initialization fails. This usually means that the card doesn't have
the features
 * we need
 */
MessageBox("NO PIXEL SHADERS! GO BUY A BETTER CARD!!11!1!!\n");
}

Of course the app isn't prepared for other things to go wrong, e.g. a Wine
bug or a driver bug, and fails to write as much details about the problem as
it can. Writing proper error paths is a pain in the ass, and so on.

wine: Unhandled page fault on read access to 0x016c6580 at address 0xa3502f
(thread 0021), starting debugger..

This line is much more suspicious. The app seems to crash somewhere, and as
far as I can see in the log long after initializing the opengl context. It
does a reset call, but the Reset call succeeds. If changing the pixel format
loading changes the behavior, it's most likely because it avoids triggering
some crash in the graphics driver(doesn't mean it is a driver bug though).

RE: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Stefan Dösinger]

The patch looks reasonably, just one small thing: There is a count_bits 
function implemented in utils.c, which as far as I can see does the same as 
getMaskSize. Can you check if you can reuse it?


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-patches-
> [EMAIL PROTECTED] On Behalf Of Victor Eremin
> Sent: Wednesday, July 23, 2008 10:25 AM
> To: [EMAIL PROTECTED]
> Subject: wined3d: universal surface convertor function for unsigned
> integer color formats(3rd attempt)
> 
> 
> Supports conversion between most of "unsigned color" argb/xrgb surface
> formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and "luminosity" color
> formats (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8,
> D3DFMT_P8 and D3DFMT_A1.
> luminosity to argb/xrgb (and vice versa) conversions are not supported
> 
> Removes "Cannot find coverter" FIXMEs from "Ancient Evil" and "Stranded
> 2" games.
> 
> Fixes water glitches in "Stranded 2" game.
> ---
>  dlls/wined3d/surface_base.c|  202
> ++-
>  dlls/wined3d/utils.c   |  126 +-
>  dlls/wined3d/wined3d_private.h |2 +-
>  3 files changed, 260 insertions(+), 70 deletions(-)

RE: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)

[Stefan Dösinger]

Actually, one more idea:

It will be extra-slow, but we could implement a general all-to-all format by 
converting the source format to A32R32G32B32F(float values), and then write 
code to convert this format to all possible destination formats. The from->to 
table lookup could be replaced by code that can combine multiple conversions to 
find a conversion strategy(e.g. R5G6B5->ARGB32F->R8G8B8). I am not sure if it 
is a good idea, but it is worth a consideration

valgrind warning in wineconsole

[Dan Kegel]

Here's a warning that seems to pop up if you type
or mouse or something during the kernel32/console test.
I first saw it last year, but it popped up again once last month
and again today:

http://kegel.com/wine/valgrind/logs/2008-07-23-07.18/vg-kernel32_console.txt

 Syscall param writev(vector[...]) points to uninitialised byte(s)
at  (within /lib/ld-2.7.so)
by  send_request (server.c:246)
by  wine_server_call (server.c:327)
by  wine_server_call_err (server.h:61)
by  WriteConsoleInputW (console.c:429)
by  WCUSER_GenerateKeyInputRecord (user.c:1059)
by  WCUSER_Proc (user.c:1118)
by  ??? (library.h:163)
by  call_window_proc (winproc.c:457)
by  WINPROC_call_window (winproc.c:2198)
by  DispatchMessageW (message.c:3125)
by  WCUSER_MainLoop (user.c:1381)
by  WinMain (wineconsole.c:869)
by  main (exe_main.c:48)
  Address 0x7f22f8a6 is on thread 1's stack
  Uninitialised value was created by a stack allocation
at  WCUSER_GenerateKeyInputRecord (user.c:1019)

That user.c is in programs/wineconsole.

This might just be a matter of INPUT_RECORD being holey,
I haven't checked.

Re: Valgrind warnings in new msxml3 saxreader code?

[Piotr Caban]

Hi Dan,
I have send patches fixing some of the valgrind warnings. I'll look over rest 
of them when the patches are accepted and valgrind logs updated.

Regards,
Piotr

Re: [3/4] ntdll: Implement the timer queue thread.

[Alexandre Julliard]

"Rob Shearman" <[EMAIL PROTECTED]> writes:

> 2008/7/23 Dan Hipschman <[EMAIL PROTECTED]>:
>> This isn't the most efficient implementation, but it works, and it should
>> not be difficult to tweak.  Hence, I'd rather get this version in and add
>> the optimizations one at a time, in little patches.  "Get it working 
>> first..."
>
> Yes, I think you're right. I don't think it will be too hard to change
> the architecture of this to that of my suggestions.

Actually I think the code will be much simpler with a sorted timer list,
so I'd suggest to start with that.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: [3/4] ntdll: Implement the timer queue thread.

[Rob Shearman]

Hi Dan,

2008/7/23 Dan Hipschman <[EMAIL PROTECTED]>:
> This isn't the most efficient implementation, but it works, and it should
> not be difficult to tweak.  Hence, I'd rather get this version in and add
> the optimizations one at a time, in little patches.  "Get it working first..."

Yes, I think you're right. I don't think it will be too hard to change
the architecture of this to that of my suggestions.

However, I have one minor nit.

> +static void WINAPI timer_queue_thread_proc(LPVOID p)
> +{
> +struct timer_queue *q = p;
> +ULONG timeout_ms;
> +BOOL done;
> +
> +timeout_ms = INFINITE;
> +while (!q->quit)
> +{
> +LARGE_INTEGER timeout;
> +DWORD ret = NtWaitForSingleObject(q->event, FALSE,
> +  get_nt_timeout(&timeout, 
> timeout_ms));

This should be NTSTATUS.

> +
> +if (ret == STATUS_TIMEOUT)
> +queue_timer_expire_next(q);
> +
> +RtlEnterCriticalSection(&q->cs);
> +timeout_ms = timer_queue_update(q);
> +RtlLeaveCriticalSection(&q->cs);
> +}

-- 
Rob Shearman

Re: d3dx8: implement D3DXSphereBoundProbe

[H. Verbeet]

2008/7/22 David Adam <[EMAIL PROTECTED]>:
> +b = pow(D3DXVec3Dot(&difference, praydirection), 2);
Maybe I'm just bad at math, but shouldn't that just be
b = D3DXVec3Dot(&difference, praydirection);
(The test case doesn't really help there)

> +ok(result == TRUE, "expected FALSE, received TRUE\n");
That's misleading.

Re: crypt32/tests: check Vista error codes for the msg tests.

[Markus Hitter]

Am 23.07.2008 um 02:25 schrieb Reece Dunn:
>
> +/* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */
> +/* ret is FALSE on XP and earlier but TRUE on Vista, therefore  
> it cannot be tested for */
> +ok((GetLastError() == E_INVALIDARG || GetLastError() ==  
> 0xdeadbeef),
> +   "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError 
> ());

A more general question: Is it Wine's policy to just ignore  
differences in behaviour between different Windows versions? From my  
own (naive) standpoint I'd say something like this would be better  
(pseudo-code):

if (WinVer <= XP) {
 ok((!ret && [...]),
"Expected [...]);
} else {
 ok((ret && [...]),
"Expected [...]);
}

Likely a often asked question, but I couldn't find hints about the  
answer yet.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

Re: [RFC] crypt32: fixed the base64 tests on Vista.

[Reece Dunn]

2008/7/21 Juan Lang <[EMAIL PROTECTED]>:
> 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 has changed between XP and Vista. The
>> latter seems more likely, but I do not have any experience in this
>> area, nor understand these tests well enough to say one way or the
>> other.
>
> I think you're probably right that Vista's changed.  By definition,
> that makes it "right."  I suspect what it's doing is guessing that
> something is base64-encoded even if it doesn't begin with the
> "-BEGIN CERTIFICATE-" or whatever header.  It'd be interesting
> to see what format Vista guesses the encoded data was in when the
> encoded data have no header.  I don't have access to a Vista machine
> myself, so it'd be hard for me to fix it.
>
> Would you mind having a go?  Thanks,

Ok, so I extended these tests to give more information on failure to
help see what is going on (see the crypt32/tests: be more verbose on
the failing base64 tests on Vista to help locate the failures. patch).

What I get is:

base64.c:282: Test failed: Expected !ret and last error
ERROR_INVALID_DATA, got ret=1, error=13
base64.c:293: Test failed: Expected 9 characters of "garbage
AQID
" skipped when trying format 0001, got 0 (used format is 0001)
base64.c:282: Test failed: Expected !ret and last error
ERROR_INVALID_DATA, got ret=1, error=13
base64.c:293: Test failed: Expected 9 characters of "garbage
AQID
" skipped when trying format 0006, got 0 (used format is 0001)
base64.c:282: Test failed: Expected !ret and last error
ERROR_INVALID_DATA, got ret=1, error=13
base64.c:293: Test failed: Expected 9 characters of "garbage
AQID
" skipped when trying format 0001, got 0 (used format is 0001)
base64.c:282: Test failed: Expected !ret and last error
ERROR_INVALID_DATA, got ret=1, error=13
base64.c:293: Test failed: Expected 9 characters of "garbage
AQID
" skipped when trying format 0006, got 0 (used format is 0001)
base64: 710 tests executed (0 marked as todo, 8 failures), 0 skipped.


So it is only failing on the CRYPT_STRING_BASE64 (1) and
CRYPT_STRING_BASE64_ANY (6), which both correctly select
CRYPT_STRING_BASE64 as the format to use (the tests at line 264
comparing use/used formats do not fail) as expected.

Some things of interest are:

1.  The tests @282 report that it is failing (last error ==
ERROR_INVALID_DATA) while ret is indicating it succeeded.

This is actually misleading, because this RFC patch shows (by setting
last error to some garbage value before the call), that the last error
is not being set by Vista in this case.

2.  The documentation for CRYPT_STRING_BASE64 (thanks for the link
Kai!) notes that this format does not include a header.

3.  The garbage+data test is passing on Vista for all but the "AQID"
test, where it is not skipping the "garbage\r\n" string.

The thing that is interesting about "AQID" is that it is the only case
that does not have '=' at the end of the buffer. It is this test that
is succeeding without a header and is not skipping any data.

Therefore, it would make sense from (3) that data is skipped until a
header is found, only if a header is present. This is only for Vista
and later. Indeed, if I apply:
-ok(skipped == strlen(garbage),
+ok((skipped == strlen(garbage)) || (skipped == 0 && !header),
the skipped characters tests pass on Vista.

So this leaves the
if (header)
ok(ret, "CryptStringToBinaryA failed: %d\n", GetLastError());
else
ok(!ret && GetLastError() == ERROR_INVALID_DATA,
test @282.

I am not sure what to do here, but the complete check looks like:
ok((!ret && GetLastError() == ERROR_INVALID_DATA) ||
 (useFormat == CRYPT_STRING_BASE64 && ret &&
GetLastError() == 0xdeadbeef) /* Vista */ ||
 (useFormat == CRYPT_STRING_BASE64_ANY && ret &&
GetLastError() == ERROR_INVALID_DATA) /* Vista */,
 "Expected !ret and last error ERROR_INVALID_DATA when
converting \"%s\" with format %d, got ret=%d, error=%d\n",
 str, useFormat, ret, GetLastError());
This makes the remaining tests pass on Vista, but looks darn ugly!

The question here is what to do in this case. Removing the test is
loosing information in the other tests and is not very helpful - I
only want to remove this test as a last resort.

I have attached a diff that provides the above changes, fixing these
tests on Vista.

Comments?

- Reece
diff --git a/dlls/crypt32/tests/base64.c b/dlls/crypt32/tests/base64.c
index 965b3f8..9f648ac 100644
--- a/dlls/crypt32/tests/base64.c
+++ b/dlls/crypt32/tests/base64.c
@@ -273,14 +273,18 @@ static void decodeAndCompareBase64_A(LPCSTR toDecode, 
LPCSTR header,
 strcat(str, toDecode);

Re: libs/wpp/ppy.y signedness fixes

[Alexandre Julliard]

Gerald Pfeifer <[EMAIL PROTECTED]> writes:

> In ISO C, operations involving both signed and unsigned types are 
> using signed.  If the case of ui = ui OP si is really ment to make
> use of this (despite the result being stored in an unsigned type),
> we'd need to handle this via two casts, but I doubt this is really
> the intent here.

It's supposed to follow the C rules, so yes the result most likely needs
to be signed in this case. That doesn't mean using two casts, it means
using the correct output type.

-- 
Alexandre Julliard
[EMAIL PROTECTED]