Hi,
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://testbot.winehq.org/JobDetails.pl?Key=5580
Your paranoid android.
=== W98SE (32 bit tab) ===
tab.c:1354: Test failed: got 0xdedede, expected 0xdededede
=== W7PROX64 (64 bit tab) ===
tab.c:1354: Test failed: got 0xdededede, expected 0xdededede
Hi,
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://testbot.winehq.org/JobDetails.pl?Key=5575
Your paranoid android.
=== WVISTAADM (32 bit win) ===
win.c:835: Test failed: wrong dwStyle: 84cb0000 != 94cb0000 for 000201C0 in hook HCBT_MINMAX
win.c:3236: Test failed: Expected GetUpdateRect to return non-zero, got 0
win.c:3237: Test failed: Update rectangle is empty!
win.c:3581: Test failed: pixel should be black, color is ffffffff
win.c:3601: Test failed: pixel should be black, color is ffffffff
win.c:3643: Test failed: wrong update region
win.c:3656: Test failed: wrong update region
win.c:3674: Test failed: wrong update region
win.c:3684: Test failed: wrong update region in excessive scroll
win.c:3706: Test failed: wrong update region
win.c:3715: Test failed: wrong update region
win.c:3724: Test failed: wrong update region
win.c:3739: Test failed: wrong update region
win.c:3819: Test failed: pixel should be black, color is ffffffff
win.c:3823: Test failed: pixel should be black, color is ffffffff
win.c:3831: Test failed: rects do not match (0,0-0,0) / (0,0-100,100)
win.c:3838: Test failed: wrong update region
win.c:3848: Test failed: wrong update region
win.c:2322: Test failed: rgn right 0 not inside win rect -31700
win.c:2324: Test failed: rgn bottom 0 not inside win rect -31700
=== W7PROX64 (32 bit win) ===
win.c:2684: Test failed: GetActiveWindow() = 00000000
win.c:2684: Test failed: GetFocus() = 00000000
win.c:2710: Test failed: GetActiveWindow() = 00000000
win.c:2710: Test failed: GetFocus() = 00000000
win.c:2769: Test failed: GetActiveWindow() = 00000000
win.c:2769: Test failed: GetFocus() = 00000000
=== W7PROX64 (64 bit win) ===
win.c:2684: Test failed: GetActiveWindow() = 0000000000000000
win.c:2684: Test failed: GetFocus() = 0000000000000000
win.c:2710: Test failed: GetActiveWindow() = 0000000000000000
win.c:2710: Test failed: GetFocus() = 0000000000000000
win.c:2769: Test failed: GetActiveWindow() = 0000000000000000
win.c:2769: Test failed: GetFocus() = 0000000000000000
Andrew Nguyen <anguyen(a)codeweavers.com> writes:
> + ok( environ != NULL, "Expected the environ global variable to be initialized on startup\n" );
> + ok( _wenviron != NULL, "Expected the _wenviron global variable to be initialized on startup\n" );
This won't test what you want, importing variables is not supported on
Wine, you have to load the variables explicitly with GetProcAddress,
--
Alexandre Julliard
julliard(a)winehq.org
Jacek Caban <jacek(a)codeweavers.com> writes:
> @@ -369,7 +369,7 @@ static void write_type_v(FILE *h, type_t *t, int is_field, int declonly, const c
> if (type_get_type_detect_alias(pt) == TYPE_FUNCTION) {
> int i;
> const char *callconv = get_attrp(pt->attrs, ATTR_CALLCONV);
> - if (!callconv && is_object_interface) callconv = "STDMETHODCALLTYPE";
> + if (!callconv) callconv = is_object_interface ? "STDMETHODCALLTYPE" : "__cdecl";
It may be useful to be able to declare functions that use the native
calling convention, I don't think we want to prevent that.
--
Alexandre Julliard
julliard(a)winehq.org
2010/9/27 Rico Schüller <kgbricola(a)web.de>:
> !strcmp("unrecognized", debug_d3dcompiler_d3d_blob_part(part))
Oh, and please don't do that, I think it's very fragile.
2010/9/27 Rico Schüller <kgbricola(a)web.de>:
> ---
Wouldn't it be nicer if the "count" parameter to dxbc_init() was more
of a hint? I.e., allow the sections array to grow if needed. For
parse_dxbc() this works fine, because you know the number of sections
in advance, but as you must have noticed, for creating the destination
blob it's much more inconvenient.
Juan Lang <juan.lang(a)gmail.com> writes:
> This one may cause test failures on systems that don't have a route to
> the loopback address. As far as I can tell, Windows systems always
> have such a route, whereas on *ix it isn't guaranteed. I'm not sure
> how to handle that, as broken() isn't allowed for Wine, and such a
> networking configuration is at least strange.
If it's really always present on Windows and apps depend on it, you'll
have to fake a route. Otherwise just don't test it.
--
Alexandre Julliard
julliard(a)winehq.org
Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes:
> Test for bug #19397.
> Test only executed, if remote IrDA device is present.
> Otherwise test is skipped. (Proposal from Mike Kaplinskiy)
I'm not sure this is very useful. It's unlikely to be run on any of the
test boxes, and AFAICS this is a kernel bug anyway, it should be a Unix
test case not a Wine one.
--
Alexandre Julliard
julliard(a)winehq.org