Re: [PATCH 2/2] kernel32/tests: Add test for 'all processors' flag on Vista and newer (try 3).
On Fri, Feb 19, 2010 at 5:08 PM, Henri Verbeet wrote: > On 20 February 2010 00:19, Erich Hoover wrote: >> + /* NOTE: Pre-Vista does not recognize the "all processors" flag (-1) */ >> + thread_affinity = -1; > ~0UL probably makes more sense than -1 for an unsigned variable. > >> - const ULONG_PTR *paff = data; >> + ULONG_PTR req_aff = *(ULONG_PTR *)data; > You shouldn't cast const away. > > Is "-1" special, or does the call just always mask the requested mask > with the available processors on Vista and above? "-1" is special, I was honestly very surprised by this as it seems like a dirty trick*. You can see that this is the case from the test for "other masks," which still errors out on Vista and Window 7 (ie. the test succeeds): --- ok(SetThreadAffinityMask(curthread,processMask+1)==0, "SetThreadAffinityMask passed for an illegal processor\n"); --- Erich Hoover ehoo...@mines.edu * That there's no good reason to do this except to artificially make apps run better on Vista and Windows 7.
Re: Compiler Defaults
On Fri, Feb 19, 2010 at 6:32 PM, Kenneth Robinette wrote: > Is the Wine compile option to treat warnings as errors a Wine default or is > it some type of system configuration option? > > Since the last couple of releases have quite a few of these, I am suspecting > something is broken on my system. That would be '-Werror', and is not a wine default. See: http://source.winehq.org/git/wine.git/?a=blob;f=configure.ac;hb=HEAD#l1497 -- -Austin
Compiler Defaults
Is the Wine compile option to treat warnings as errors a Wine default or is it some type of system configuration option? Since the last couple of releases have quite a few of these, I am suspecting something is broken on my system.
Re: [PATCH 2/2] kernel32/tests: Add test for 'all processors' flag on Vista and newer (try 3).
On 20 February 2010 00:19, Erich Hoover wrote: > +/* NOTE: Pre-Vista does not recognize the "all processors" flag (-1) */ > +thread_affinity = -1; ~0UL probably makes more sense than -1 for an unsigned variable. > -const ULONG_PTR *paff = data; > +ULONG_PTR req_aff = *(ULONG_PTR *)data; You shouldn't cast const away. Is "-1" special, or does the call just always mask the requested mask with the available processors on Vista and above?
Re: SDL for DirectDraw
Our DirectDraw implementation is good. Sure there are performance issues in some cases but those can be fixed. SDL is not suited for DirectDraw emulation because it doesn't offer all the functionality we need. Second, SDL on Linux uses X11 and other APIs directly. Games running on Wine use win32 APIs for window creation and other tasks which doesn't work with Linux SDL. Roderick On Sat, Feb 20, 2010 at 12:12 AM, MD.IMAM HOSSAIN wrote: > Dear Developers, > > I just toying with SDL for a month and so. > I am just wondering is there any possibilities to use SDL as a WINE > DirectDraw wrapper. > > From my experience, SDL is not such a bad 2D graphics library and very easy > to use and implement and has many flexible functions. > > Best Regards, > MD. IMAM HOSSAIN > > > >
SDL for DirectDraw
*Dear Developers,* I just toying with *SDL* for a month and so. I am just wondering is there any possibilities to use *SDL* as a *WINE DirectDraw* wrapper. >From my experience, *SDL* is not such a bad 2D graphics library and very easy to use and implement and has many flexible functions. Best Regards, MD. IMAM HOSSAIN
Re: Hans Leidekker : msi: Add summary information stream to the streams table.
On 2/19/2010 21:28, Hans Leidekker wrote: A bug would be nice, yes. Do you have a URL? I can't reproduce it with the latest JRE downloaded from sun.com. Ok, I'll file a report now. Yes, it could be downloaded in archives section - http://java.sun.com/products/archive/j2se/6u16/index.html -Hans
Re: Hans Leidekker : msi: Add summary information stream to the streams table.
On Friday 19 February 2010 18:56:37 Nikolay Sivov wrote: > Bad news about this one I'm afraid. It breaks a Sun JRE install > (jre-6u16-windows-i586-s to be exact). > It fails with following output: > --- > err:msidb:TABLE_fetch_stream fetching stream L"Binary.RegUtilsMSI", > error = 1627 > err:msi:store_binary_to_temp Failed to get stream > err:msi:ITERATE_Actions Execution halted, action L"IsMozillaInstalled" > returned 13 > err:msidb:TABLE_fetch_stream fetching stream L"Binary.NewBinary7", error > = 1627 > err:msi:msi_dialog_bitmap_control Failed to load bitmap L"NewBinary7" > err:msidb:TABLE_fetch_stream fetching stream L"Binary.NewBinary11", > error = 1627 > err:msi:msi_dialog_bitmap_control Failed to load bitmap L"NewBinary11" > --- > and installer reports error that wizard was interrupted (no crash). > > Do you want a bug report for this or you got what a regression is about? A bug would be nice, yes. Do you have a URL? I can't reproduce it with the latest JRE downloaded from sun.com. -Hans
Re: Hans Leidekker : msi: Add summary information stream to the streams table.
On 2/19/2010 18:21, Alexandre Julliard wrote: Module: wine Branch: master Commit: 1ff992314887d03abeb4098789701ff3bfd5d2d8 URL: http://source.winehq.org/git/wine.git/?a=commit;h=1ff992314887d03abeb4098789701ff3bfd5d2d8 Author: Hans Leidekker Date: Fri Feb 19 12:27:36 2010 +0100 msi: Add summary information stream to the streams table. Hi, Hans. Bad news about this one I'm afraid. It breaks a Sun JRE install (jre-6u16-windows-i586-s to be exact). It fails with following output: --- err:msidb:TABLE_fetch_stream fetching stream L"Binary.RegUtilsMSI", error = 1627 err:msi:store_binary_to_temp Failed to get stream err:msi:ITERATE_Actions Execution halted, action L"IsMozillaInstalled" returned 13 err:msidb:TABLE_fetch_stream fetching stream L"Binary.NewBinary7", error = 1627 err:msi:msi_dialog_bitmap_control Failed to load bitmap L"NewBinary7" err:msidb:TABLE_fetch_stream fetching stream L"Binary.NewBinary11", error = 1627 err:msi:msi_dialog_bitmap_control Failed to load bitmap L"NewBinary11" --- and installer reports error that wizard was interrupted (no crash). Do you want a bug report for this or you got what a regression is about?
[PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
Hi, Erich Hoover wrote: >so if we're not testing >the version we wouldn't know that it got removed. This is a very valid point. For instance, I'm currently writing a test that will read ok(1234123123==mhdr.dwOffset || broken(0==mhdr.dwOffset/*w9x,nt*/) ...) i.e. w2k+xp+Vista+7 differ from w95+98+me+nt. The Wine testsuite will not warn should MS-Windows ever revert back to w9x+nt behaviour. I've been fixing multimedia bugs in Wine, some of which were present for almost 10 years now. My point is: right *now* I'm closely looking at the exact behaviour under existing versions of MS-Windows (and having Wine mimick "modern" w2k/xp behaviour), yet the broken() mechanism prevents the tests from noticing when that behaviour will change next time. Patches these days make Wine implement the now "modern" behaviour, but remember modern is relative and tests with broken() will fail to report any future change... Until, perhaps again in ten years, somebody will look closely at the results, perhaps triggered by a bug report. Why wait for a bug report? Somehow, I feel that not noticing changes in behaviour is a waste of the test automation resources. broken() shadows broken (not valid any more) assumptions. Every now and then I wish there were a switch to disable broken() entirely and see what test.winehq reports for the various OS. E.g. $WINETEST_STRICT=1 => have broken() always yield 0/false. The goal to reach becomes WINETEST_STRICT=1 => no test failures on the system Wine purports to mimick (currently XP(?)). (Seems like a good idea, expect a patch soon ;) Regards, Jörg Höhle Well, at least the above example of broken() is much stricter than ok(!rc||broken(rc/*w9x*/)) == anything goes What does such a test tell except impose Wine's rc?
Re: msxml3: Accept IObjectSafety for query from IXMLDOMDocument, fix its implementation.
On 2/19/2010 19:28, Paul Vriens wrote: On 02/19/2010 11:48 AM, Nikolay Sivov wrote: Accept IObjectSafety for query from IXMLDOMDocument, fix its implementation Hi Nikolay, This one introduces some test failures: http://test.winehq.org/data/tests/msxml3:domdoc.html Could you have a look? Hi. Fix is simple, another option needed here - equals 8. I removed it cause this test doesn't fail on my WinXP box, I don't know why.
Re: msxml3: Accept IObjectSafety for query from IXMLDOMDocument, fix its implementation.
On 02/19/2010 11:48 AM, Nikolay Sivov wrote: Accept IObjectSafety for query from IXMLDOMDocument, fix its implementation Hi Nikolay, This one introduces some test failures: http://test.winehq.org/data/tests/msxml3:domdoc.html Could you have a look? -- Cheers, Paul.
Re: [PATCH] shell32: Allow copy operation to overwrite an existing write protected file + tests
Nikolay Sivov a écrit : On 2/19/2010 17:34, Christian Costa wrote: --- dlls/shell32/shlfileop.c | 10 +- dlls/shell32/tests/shlfileop.c | 20 2 files changed, 29 insertions(+), 1 deletions(-) Correct me if I'm wrong, but isn't SetFileAttributes dependent on user security permissions? I mean will it work as expected if this call fails for that reason? I would say yes wrt SetFileAttributes. And no, it will not work if the call fails. I've just see that the move operation already implement does a similar things. Everything should work fine as long as there is a sigle user which is what most people does I guess.
Re: [PATCH 3/3] kernel32/tests: Test for 'all processors' now valid (try 2).
On 19 February 2010 15:30, Erich Hoover wrote: > What is the appropriate log notation for this? Is it > "ntdll,kernel32/tests" ? Thanks. > You'd just use the subject from patch 2, "ntdll: ...". However, I think a more logical way to do this would be to first send a patch for ntdll + tests, and send a test for kernel32 afterwards to prove it's consistent with ntdll. Sending the test before the series is (IMO) something you do when it's not entirely obvious that the test would fail without the change introduced by the patch.
Re: [PATCH] shell32: Allow copy operation to overwrite an existing write protected file + tests
On 2/19/2010 17:34, Christian Costa wrote: --- dlls/shell32/shlfileop.c | 10 +- dlls/shell32/tests/shlfileop.c | 20 2 files changed, 29 insertions(+), 1 deletions(-) Correct me if I'm wrong, but isn't SetFileAttributes dependent on user security permissions? I mean will it work as expected if this call fails for that reason?
Re: [PATCH 3/3] kernel32/tests: Test for 'all processors' now valid (try 2).
On Thu, Feb 18, 2010 at 10:08 PM, Charles Davis wrote: > Erich Hoover wrote: >> Real Name: >> Erich Hoover >> Description: >> Patch 2 added support for the "all processors" flag, so this is >> no-longer a todo. This version is against the revised patch 1, please >> note that patch 2 is unchanged. >> ChangeLog: >> kernel32/tests: Test for 'all processors' now valid. > Patches 2 and 3 should be merged. If patch 2 is applied without patch 3, > then we'll get "test succeeded inside todo block" failures. > > Chip What is the appropriate log notation for this? Is it "ntdll,kernel32/tests" ? Thanks. Erich Hoover ehoo...@mines.edu
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer (try 2).
On 19 February 2010 05:22, Erich Hoover wrote: > Real Name: > Erich Hoover > Description: > The attached patch adds a test for > SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and > newer. This version uses broken() rather than specifically testing > versions. Note that this "all processors" flag is not documented, but > was discovered tracking down another issue. Please see the wine-devel > thread for more information: > http://www.winehq.org/pipermail/wine-devel/2010-February/081879.html > ChangeLog: > kernel32/tests: Add test for 'all processors' flag on Vista and newer. > Shouldn't this need tests for NtSetInformationThread() and NtQueryInformationThread() as well?
