February 2009 - Wine-Devel - list.winehq.org

Re: wintrust(3/3): Fix a couple tests on a variety of systems

by Ge van Geldorp

> From: Alexandre Julliard <julliard(a)winehq.org> > > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > > I sent out an email earlier to ask if we should include more > > information in the header of the report. We could use that > > information, if this change will be accepted by AJ, to > > limit the reporting only to boxes were we have admin rights. > > > > As soon as all boxes have zero failures (yeah, right) we > > can remove that limit. > > Yes, we will want to fix these tests eventually, since we > will some day support multi-user setups where normal users > won't have admin rights, and we will need tests to make sure > we fail the right way. But in the meantime we can certainly > block these reports and concentrate on the more meaningful failures. I'll take that as a hint to switch my test machines to full admin. Should result in quite a bit more green. Ge.

Feb. 13, 2009

Re: mshtml: allow REG_EXPAND_SZ values for GeckoCabDir

by Juan Lang

Hi Christoph, - /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ - res = RegOpenKeyW(HKEY_CURRENT_USER, mshtml_keyW, &hkey); - if(res != ERROR_SUCCESS) - return FALSE; - file_name = heap_alloc(size+sizeof(GECKO_FILE_NAME)); - res = RegQueryValueExA(hkey, "GeckoCabDir", NULL, &type, (PBYTE)file_name, &size); + /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ + res = RegGetValueA(HKEY_CURRENT_USER, mshtml_keyA, "GeckoCabDir", RRF_RT_ANY, &type, (PBYTE)file_name, &size); This change is unrelated to the subject. One change per patch, please. + if(res != ERROR_SUCCESS || (type != REG_SZ && type != REG_EXPAND_SZ)) { heap_free(file_name); return FALSE; } If you're allowing REG_EXPAND_SZ, oughtn't you call ExpandEnvironmentVariablesA as well? --Juan

Feb. 13, 2009

Re: [sane.ds try2 1/3] Get resolution from sane, instead of hard coding -1.

by Jeremy White

Hi Juan, >> The other comment is, is adding a new file (option.c) really >> necessary? If you're planning to expand it a lot, perhaps, but just >> for this one small function it looks like overkill to me. > > This remark still stands. Yes, I am planning on expanding options.c a fair amount, and I'm going to need that functionality in at least 2 of the existing files in sane.ds, so I thought it should go in another file. Cheers, Jeremy

Feb. 13, 2009

Re: [sane.ds try2 1/3] Get resolution from sane, instead of hard coding -1.

by Juan Lang

Hi again, Jeremy, > With this change, sane.ds will not compile unless SONAME_LIBSANE is > defined. This remark is incorrect, sorry. I only read the patch, I didn't read ds_image.c first. This change is correct. > The other comment is, is adding a new file (option.c) really > necessary? If you're planning to expand it a lot, perhaps, but just > for this one small function it looks like overkill to me. This remark still stands. --Juan

Feb. 13, 2009

Re: [sane.ds try2 1/3] Get resolution from sane, instead of hard coding -1.

by Juan Lang

Hi Jeremy, a couple comments: - pImageInfo->XResolution.Whole = -1; + if (sane_option_get_int(activeDS.deviceHandle, "resolution", &resolution) == SANE_STATUS_GOOD) + pImageInfo->XResolution.Whole = pImageInfo->YResolution.Whole = resolution; (snip) +/* Option functions */ +#ifdef SONAME_LIBSANE +SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val); +#endif With this change, sane.ds will not compile unless SONAME_LIBSANE is defined. Is this intended? More likely not, and you need to provide a version of sane_option_get_int when it isn't defined, or use an #ifdef at the call site (ick.) The other comment is, is adding a new file (option.c) really necessary? If you're planning to expand it a lot, perhaps, but just for this one small function it looks like overkill to me. --Juan

Feb. 13, 2009

Re: RFC: patch to advapi32's cred tests

by Juan Lang

> No, CRED_PERSIST_LOCAL_MACHINE should be fine but does this change > make any difference? I believe the ERROR_NO_SUCH_LOGON_SESSION is > returned when the tests are being run as a user that doesn't have a > profile, and therefore the credentials manager doesn't have anywhere > to store the credentials. Changing the persist type shouldn't affect > this, so I don't see why it would make these calls start working. I don't know whether it would make a difference, I don't see the failures myself. I just see a fairly consistent pattern of failure, and reading MSDN made me suppose that a different persist type might make a difference. Never mind, I'll send the patch as-is then. Thanks for the feedback. --Juan

Feb. 13, 2009

Re: Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows

by Reece Dunn

2009/2/13 Susan Cragin <susancragin(a)earthlink.net>: >>Hi, >> >>For those not monitoring slashdot [1], there is an article [2] that is >>comparing the Google V8 benchmark on Windows and Linux versions of >>Firefox 3. >> >>The result of this is that the Windows and Wine runs are pretty close >>(241 vs 227) when compared to the Linux run (181) and Opera (155). >> >>I wonder what the results are like on Firefox 3.1 with tracemonkey >>enabled on Windows, Wine and Linux. >> >>[1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 >>[2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-… >> >>- Reece > > One thing that interested me... one person wrote that Linux/Firefox compiled with msvc was faster than gcc, because msvc is better at optimization. > Has anyone tried compiling wine with msvc? Hi Susan, WARNING: This is fairly technical, so apologies if this goes over your head! The reason that Firefox javascript is faster when built with msvc (according to the slashdot comments -- of which I am only part of the way through) is because they use Profile Guided Optimization (PGO). [sidebar] This means that the code is compiled with special information that records what methods and variables are being accessed. This program is then run under normal usage patterns to gather profiling data. The data collected here shows what the most common methods and variables are. The data is then fed into the linker along with the original program. The linker can then use this information to organise the code so that it performs better. That is, it uses the profile data to hint at where to optimise the program (hence the name). [/sidebar] The commenters also point out that GCC (which is used to build Wine) also has PGO capabilities. In order to do this, you need to record the profile information for a given build. IIUC, you need to do this manually for each build to gather the data for that build. NOTE: I am not an expert on this, as I have only read bits and pieces on the subject and not actually tried it out. As for optimisation in general, I am not sure on how gcc compares with msvc in terms of overall performance. Both allow you to optimise for speed, size or balance the two. They both also allow you to do other independent optimisations (e.g. target newer CPUs or enable enhanced CPU instruction calls). Here, it is a matter of trying out different combinations of options to get better results. NOTE: The distribution versions of Firefox (and Wine) will be built to support older hardware and thus won't benefit from taking advantage of the newer hardware (Gentoo is your friend here :D). For building Wine with msvc, I have had limited success building the Wine components and (more specifically) tests with it, and have contributed patches to help build more of them with msvc. In addition to this, you will only be able to do this with a portion of the dlls and components -- the ones that do not make use of any Linux components. Adding PGO support in Wine (which would have to be using gcc, since the Wine program loader and other core components are likely to benefit -- possibly the GDI and DirectX/WineD3D stuff as well). It would be interesting to run a profiler on Wine with profile data for different programs and games to see where the slow areas are. The real benefit in terms of speed for Wine would be not to use msvc, but to hand-optimise specific algorithms to take advantage of faster assembly instructions. This would likely be for the cryptographic algorithms (SHA1, MD5, etc), DirectX mathematic functions, GDI/DIB code and pixel format transformations in DirectX/GDI. NOTE: These should be done (if done at all) using the data from the profile runs to see where the slow areas are. I apologise for rambling, but hopefully this makes things clearer. - Reece

Feb. 13, 2009

Re: RFC: patch to advapi32's cred tests

by Rob Shearman

2009/2/13 Juan Lang <juan.lang(a)gmail.com>: > Hi all, I've written a patch which should fix the failing advapi32 > cred tests that mirrors the skips in the existing tests: > > diff --git a/dlls/advapi32/tests/cred.c b/dlls/advapi32/tests/cred.c > index 58103c6..bb6935b 100644 > --- a/dlls/advapi32/tests/cred.c > +++ b/dlls/advapi32/tests/cred.c > @@ -238,7 +238,13 @@ static void test_generic(void) > new_cred.UserName = (char *)"winetest"; > > ret = pCredWriteA(&new_cred, 0); > - ok(ret, "CredWriteA failed with error %d\n", GetLastError()); > + ok(ret || broken(GetLastError() == ERROR_NO_SUCH_LOGON_SESSION), > + "CredWriteA failed with error %d\n", GetLastError()); > + if (!ret) > + { > + skip("couldn't write generic credentials, skipping tests\n"); > + return; > + } > > ret = pCredEnumerateA(NULL, 0, &count, &creds); > ok(ret, "CredEnumerateA failed with error %d\n", GetLastError()); > > I'm wondering whether a better patch would be to change the persist > type from CRED_PERSIST_ENTERPRISE to CRED_PERSIST_LOCAL_MACHINE. Rob, > this is particularly aimed at you since you wrote the original tests: > is there a good reason to use CRED_PERSIST_ENTERPRISE here? No, CRED_PERSIST_LOCAL_MACHINE should be fine but does this change make any difference? I believe the ERROR_NO_SUCH_LOGON_SESSION is returned when the tests are being run as a user that doesn't have a profile, and therefore the credentials manager doesn't have anywhere to store the credentials. Changing the persist type shouldn't affect this, so I don't see why it would make these calls start working. -- Rob Shearman

Feb. 13, 2009

RFC: patch to advapi32's cred tests

by Juan Lang

Hi all, I've written a patch which should fix the failing advapi32 cred tests that mirrors the skips in the existing tests: diff --git a/dlls/advapi32/tests/cred.c b/dlls/advapi32/tests/cred.c index 58103c6..bb6935b 100644 --- a/dlls/advapi32/tests/cred.c +++ b/dlls/advapi32/tests/cred.c @@ -238,7 +238,13 @@ static void test_generic(void) new_cred.UserName = (char *)"winetest"; ret = pCredWriteA(&new_cred, 0); - ok(ret, "CredWriteA failed with error %d\n", GetLastError()); + ok(ret || broken(GetLastError() == ERROR_NO_SUCH_LOGON_SESSION), + "CredWriteA failed with error %d\n", GetLastError()); + if (!ret) + { + skip("couldn't write generic credentials, skipping tests\n"); + return; + } ret = pCredEnumerateA(NULL, 0, &count, &creds); ok(ret, "CredEnumerateA failed with error %d\n", GetLastError()); I'm wondering whether a better patch would be to change the persist type from CRED_PERSIST_ENTERPRISE to CRED_PERSIST_LOCAL_MACHINE. Rob, this is particularly aimed at you since you wrote the original tests: is there a good reason to use CRED_PERSIST_ENTERPRISE here? --Juan

Feb. 13, 2009

Re: How to get more info on timed out/crashed tests?

by Juan Lang

> Something like the attached patch? Hoo, that'd be worlds better. Thanks, Rob! --Juan

Feb. 13, 2009