March 2010 - Wine-devel - list.winehq.org

re: cmd: fixed use of uninitialised memory in WCMD_expand_envvar() (valgrind).
by Dan Kegel 09 Mar '10

09 Mar '10

Wouldn't it be easier to pass -1 for the length?

1 0

Re: [PATCH] kernel32: added some basic tests for CompareString().
by Henri Verbeet 08 Mar '10

08 Mar '10

On 8 March 2010 22:25, Yann Droneaud <yann(a)droneaud.fr> wrote: > While trying to debug cmd.exe, valgrind found some problem in > CompareString() calls. Those tests help me to understand how > CompareString() is excepted to be called: > when string length is given NUL characters are ignored in this string. > I think you should add those to the existing test_CompareStringA() in locale.c, for as far that doesn't already cover CompareString() behaviour.

1 0

Winetest.exe could mess up your secured wireless access on Windows
by Paul Vriens 08 Mar '10

08 Mar '10

Hi, If you never run winetest you can skip this email but shame on you ;) It turns out that one of the advapi32 tests messes up the registry, or to be more correct doesn't restore an original value. This bug has been present since the introduction of these specific tests in 2004. This means that once you've run winetest on a Windows 2000 or higher box one of the values in the registry prevents you from connecting to a secured wireless access point (problem reproduced on Vista and Windows 7). There could be more cryptographic related problems due to this bug but these haven't surfaced yet. A patch has been submitted to fix this for new test runs but it won't fix the current situation. If you experience this issue after running winetest you need to change a value in the registry. This can be done manually by changing the "Name" value at "HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Defaults\Provider Types\Type 001" from "Microsoft Base Cryptographic Provider v1.0" to "Microsoft Strong Cryptographic Provider". -- Cheers, Paul.

1 0

Re: rsaenh(2/6): Add support for SHA-256, SHA-384, and SHA-512
by Henri Verbeet 08 Mar '10

08 Mar '10

On 8 March 2010 22:36, Juan Lang <juan.lang(a)gmail.com> wrote: > Uses implementation from Aaron Gifford, > http://www.aarongifford.com/computers/sha.html (It's BSD licensed.) > Is the patch missing some files?

2 1

Significant performance "regression"
by Erich Hoover 08 Mar '10

08 Mar '10

I was looking into updating the AppDB with more recent results for PCB Artist* and discovered that on a fresh Wine install that the application opens and creates new files incredibly slowly (it now takes 23 minutes vs. old performance of ~5 seconds). I ran a regression test and discovered that an added feature in OLE32 is responsible for this "regression." I am, admittedly, not an expert on OLE32 - so I'm hoping that someone else has some thoughts on how to resolve this issue. ---- 226363f5dfb9caa8313e425c7f85ed9fe581f1fe is first bad commit commit 226363f5dfb9caa8313e425c7f85ed9fe581f1fe Author: Vincent Povirk <vincent(a)codeweavers.com> Date: Fri Dec 4 17:33:50 2009 -0600 ole32: Implement transacted storage. :040000 040000 79e7adf6177afe9cb8bfdea75270edb00026c5e5 abc173741982ee971ac490738917d735c6869a78 M dlls ---- Erich Hoover ehoover(a)mines.edu * Free proprietary application, direct download: http://www.4pcb.com/downloads/pcbartist/PcbArtist_1_3_2.exe

2 3

Re: shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile [try 6]
by Juan Lang 08 Mar '10

08 Mar '10

Hi Ilya, I like this one rather better, thanks. Especially the use of broken() makes it clearer what's happening. I think you could tidy it up just a little more: > + expected = 33; sprintf(fileA, testfile, tmpdir); > + rc=shell_execute(NULL, fileA, NULL, NULL); > + todo_wine { > + ok(rc==expected || (rc>32 && expected>32), > + "expected %s (%d), got %s (%d), lpFile: %s \n", > + expected==33 ? "success" : "failure", expected, rc > 32 ? "success" : "failure", rc, fileA > + ); > + } In this case, expected is 33, so the "expected == 33" is unneeded. Just replace "%s (%d)" with "success (32)". Same below with the remaining ok expressions: make them match the actual value of expected, rather than any possible value. Otherwise, looks good to me. Thanks, --Juan

3 3

Re: shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile [try 4]
by Juan Lang 08 Mar '10

08 Mar '10

Hi Ilya, I think you're still confused by the prohibition against using GetVersion. Your changes follow the letter of that edict, but not the spirit: + HMODULE hkernel32 = GetModuleHandle("kernel32"); + BOOL isreallyXP_2k3_plus = NULL != GetProcAddress(hkernel32, "AttachConsole"); + BOOL isreally98_2k_plus = NULL != GetProcAddress(hkernel32, "GetLongPathNameA"); That is, you're looking for other markers of particular versions of Windows. That's not the reason for avoiding the use of GetVersion. We avoid GetVersion because version checks in general are fragile. Sometimes a behavior will change due to the installation of a service pack, for example, and the tests will begin to fail if they expect a particular behavior on a particular version of Windows. What we prefer is for tests to check the behavior of the function being tested on every version of Windows where that's possible. In some cases, it's impossible, because the function doesn't exist on old versions of Windows, or because the function crashes when called in a particular way. In such cases, we try to avoid crashes, and use win_skip to indicate that certain tests couldn't be performed. In other cases, some older versions behave in ways that aren't really sensible. We mark these as broken(), indicating that it's acceptable for Windows to behave this way, but not for Wine to do so. I think this is what you want, e.g. here: + /* quoted lpFile not works on real win95 and nt4 */ + if (isreally98_2k_plus) { + /* if quoted, existing "drawback_file.noassoc" not prevents finding "drawback_file.noassoc foo.shlexec" on wine */ + testfile = "\"%s\\drawback_file.noassoc foo.shlexec\""; + expected = 33; sprintf(fileA, testfile, tmpdir); + rc=shell_execute(NULL, fileA, NULL, NULL); + TEST_LPFILE_PARSED_OK(); + } else { + win_skip("ShellExecute('\"command\"', ...) only works on 98/2k or newer\n"); + } What you want to do instead is to call shell_execute in any case (unless doing so would crash.) You'll want to check rc on succeeding versions of Windows/Wine with ok, and mark it as broken elsewhere. E.g., rc = shell_execute(NULL, fileA, NULL, NULL); ok((rc==expected || rc>32 && expected>32) || broken(rc == whatever busted versions of Windows return), "expected ..."); Also, those TEST_LPFILE_PARSED_OK macros are ugly, and hard to fix if one place has a certain behavior, while another has different behavior. Just use ok directly wherever you're using the macro. Thanks, --Juan

3 4

Re: [PATCH 1/4] WCMD_run_program overflow fix
by Paul Vriens 08 Mar '10

08 Mar '10

On 03/07/2010 09:46 PM, Eric Ho wrote: > --- a/programs/cmd/tests/test_builtins.cmd.exp > +++ b/programs/cmd/tests/test_builtins.cmd.exp > @@ -24,3 +24,9 @@ Testing case sensitivity with and without /i option > if seems to default to case sensitivity > if /i seems to work > if /I seems to work > +------------ Testing overflow -------------- > +Overflow by long filename with no explicit path was caught. > +Overflow by long filename with explicit path was caught. > +Overflow by long path was caught. > +Overflow by stemofsearch concatenation was caught. > +Overflow by allFiles concatenation was caught. Shouldn't this be part of patch 4/4? -- Cheers, Paul.

1 0

GSoC WPKG and test.winehq.org
by Seth Shelnutt 08 Mar '10

08 Mar '10

Alright, after reviewing everything, I think that tying appinstall into test.winehq.org along with adding more (if not most) of the wpkg scripts to appinstall would be most beneficial in terms of conformance and regression testing. Converting the wpkg scripts to appinstall doesn't seem like that difficult of a task, mostly just time consuming. That is why I thinking working on tying it into test.winehq.org is more worthy. I still think tying appinstall and patchwatcher together would be beneficial and allow people submitting patches to see where regressions pop up in software, and to see what new software works with each submitted patch. Perhaps a project of implementing all of this and adding wpkg scripts would be accepted? A little bit of background on myself, I am currently attending the University of Florida, seeking my undergraduate in mathematics. I've been an active linux user for several years. I've used wine for about as long. I have experience with writing the CUDA wrapper for wine, which is used mostly for folding at home. (Small fah plug, Folding at home is run by stanford to fold proteins and see how and why they fold or miss fold. For more info see http://folding.stanford.edu/ or http://www.overclockers.com/forums/forumdisplay.php?f=21) Thanks, Seth Shelnutt

1 0

Git down?
by James McKenzie 08 Mar '10

08 Mar '10

What a morning... git clone appears to not be working, receiving the old "Fatal: Other end hung up" message. James McKenzie

1 2