August 2007 - Wine-Devel - list.winehq.org

Re: wined3d: Use a safer, more compliant method to parse extension strings

by Vitaliy Margolen

Chris Robinson wrote: > > + > + /* End */ > + {NULL, 0} > }; [..] > - for (i = 0; i < (sizeof(EXTENSION_MAP) / sizeof(*EXTENSION_MAP)); ++i) { > + for (i = 0; EXTENSION_MAP[i].extension_string; ++i) { What was the reason for this change? It's a static const array why do you want to treat it as a dynamically sized one? Vitaliy.

Aug. 5, 2007

Re: user32 - set_active_window uses SendMessage instead ofPostMessage for WM_ACTIVATEAPP messages.

by Alexandre Julliard

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > This piece of code, if inserted into the test system, could (on original > Windows) show us which messages we are incorrectly posting or sending. I > can probably also be used for other test purposes. I works by checking > the call stack for the calls SendMessageA() and SendMessageW(). Works > like charm on Windows-XP. Will need some work to also work inside Wine, > but that is not important for now. This is silly. It can't possibly work right since there is no reason that messages are sent using the exported functions, it won't work on anything not compiled with frame pointer, and there's absolutely no need for anything like that at all. A posted message doesn't call the window proc directly, it goes through the message queue, so it's completely trivial to check for it between GetMessage and DispatchMessage. -- Alexandre Julliard julliard(a)winehq.org

Aug. 5, 2007

Re: [winetest] Show missing tests in single/group results

by Paul Vriens

Paul Vriens wrote: > Hi, > > (I've just remembered that there is a limit on the email size, so I'm > doing it a > bit differently now. The other email, including the screenshots, will > probably come through as well) > > Before sending this to wine-patches I would like people to have a look > first. > > This patch makes sure that missing tests are shown in the test results, > both > when there is only one system in a group (f.e. Win98) or multiple > systems in a > group. > > On 'http://www.xs4all.nl/~pvriens/200708031000.old.single/' you can see the > current state of the test results. When a test is missing a '.' is shown > (this is of course different from a missing test where we don't have > results at all but that's shown as a '.' as well). > > On 'http://www.xs4all.nl/~pvriens/200708031000.old.group/' you can see the > current state when a group of systems is involved. When tests are > missing for a > group, a '.' is shown with a link to the group overview. There is > however no > missing test output in the group overview (for example gdiplus and pdh) > > 'http://www.xs4all.nl/~pvriens/200708031000.new.single/' shows the new > results > page for single tests. Instead of a single '.' there is a failure shown > (red > box) and a skip border (as these tests have not run). There is still a > '.' which > could maybe better be a '?'. There is also a 'onMouseOver' hint when you > go over > the '.'. > > 'http://www.xs4all.nl/~pvriens/200708031000.new.group/' shows the new > results > when a group is involved. The main summary is still the same as in the > old one, > but the group results now also show the missing tests (see gdiplus and pdh > again). Again there is a 'onMouseOver' hint in the group results. > > Remember that this is still without winetest producing output about > missing dll's. > > Next patches will: > > - add a missing dll as one of the reasons for missing tests > - add some better clue's on the main summary for multiple systems in a > group > (not a single '.' but maybe the same 'failed and skipped'). > > As said, one of the thoughts I had was to replace the '.' with a '?' in > case of > missing tests for an unknown reason but I'm not sure about that yet. > > Comments/remarks etc.. are welcome. > > I'd also like to hear about other idea's for this page to make it useful > for > everybody. Apart from the fact that we probably should have more > exposure to the > fact that we have such a page/tool. > We saw an immediate rise (slowed down again) in test results as soon as > winetest > was mentioned on > 'http://tweakers.net/meuktracker/15817/Wine-0.9.42.html' (in > Dutch). There it was also mentioned that some machines crashed because > of the > tests etc.. (maybe a wine-winetest component on bugzilla could help with > that > which we could reference on the main test.winehq.org/data/*/index.html > pages). > > Cheers, > > Paul. > Forgot to mention that only the index.html file is on the mentioned pages. No result files (to cut down on size for me to push). I also forgot to attach the patch. So here it is. Cheers, Paul --- /wine/tools/winetest/gather 2007-08-03 17:20:09.000000000 +0200 +++ gather 2007-08-05 14:02:42.000000000 +0200 @@ -121,6 +121,22 @@ push @{$group->{tests}}, $testref; } +# Find missing tests. After this exercise all testresults are available +# for all systems. +foreach my $group (@groups) { + next unless exists $group->{tests}; + foreach my $test (@{$group->{tests}}) { + foreach my $testname (sort keys %alltests) { + if (!exists $test->{results}->{$testname}) { + # Make sure missing tests are shown in the group results + $group->{digests}->{$testname} = "differ"; + # Mark this test as missing for an unknown reason + $test->{results}->{$testname} = ["test missing", "-", "-", "-"]; + } + } + } +} + # Write out the tables my ($header); # same in thead and tfoot @@ -201,28 +217,30 @@ # Output a single cell of a test sub singletest { my ($test, $testname, $groupname) = @_; - - if (!exists $test->{results}->{$testname}) { - print OUT " <td class=\"note\">.</td>\n"; + my $file = "$test->{dir}/$testname.txt"; + my ($count, $todo, $error, $skipped) = @{$test->{results}->{$testname}}; + if ($count eq "failed") { + my $msg = $todo eq "-"?"crash": + $todo == 258?"timeout":"failed"; + my $fail = -r "$datadir/$build/$file"?"<a href=\"$file\">$msg</a>":$msg; + print OUT " <td class=\"note\">$fail</td>\n"; + } elsif ($count eq "test missing") { + print OUT <<"EOF"; + <td class="skip_fail"><a + title="Test did not run for an unknown reason" + onMouseOver="Test did not run for an unknown reason"; + >.</a></td> +EOF } else { - my $file = "$test->{dir}/$testname.txt"; - my ($count, $todo, $error, $skipped) = @{$test->{results}->{$testname}}; - if ($count eq "failed") { - my $msg = $todo eq "-"?"crash": - $todo == 258?"timeout":"failed"; - my $fail = -r "$datadir/$build/$file"?"<a href=\"$file\">$msg</a>":$msg; - print OUT " <td class=\"note\">$fail</td>\n"; - } else { - my $class = $error?"fail":"pass"; - my $skip = $skipped?"skip_":""; - print OUT <<"EOF"; + my $class = $error?"fail":"pass"; + my $skip = $skipped?"skip_":""; + print OUT <<"EOF"; <td class="$skip$class"><a href="$file" title="$count tests, $todo TODO, $error errors, $skipped skipped" onMouseOver="refresh('$testname','$groupname $test->{tag}',$count,$todo,$error,$skipped);" >$error</a></td> EOF - } } }

Aug. 5, 2007

[winetest] Show missing tests in single/group results

by Paul Vriens

Hi, (I've just remembered that there is a limit on the email size, so I'm doing it a bit differently now. The other email, including the screenshots, will probably come through as well) Before sending this to wine-patches I would like people to have a look first. This patch makes sure that missing tests are shown in the test results, both when there is only one system in a group (f.e. Win98) or multiple systems in a group. On 'http://www.xs4all.nl/~pvriens/200708031000.old.single/' you can see the current state of the test results. When a test is missing a '.' is shown (this is of course different from a missing test where we don't have results at all but that's shown as a '.' as well). On 'http://www.xs4all.nl/~pvriens/200708031000.old.group/' you can see the current state when a group of systems is involved. When tests are missing for a group, a '.' is shown with a link to the group overview. There is however no missing test output in the group overview (for example gdiplus and pdh) 'http://www.xs4all.nl/~pvriens/200708031000.new.single/' shows the new results page for single tests. Instead of a single '.' there is a failure shown (red box) and a skip border (as these tests have not run). There is still a '.' which could maybe better be a '?'. There is also a 'onMouseOver' hint when you go over the '.'. 'http://www.xs4all.nl/~pvriens/200708031000.new.group/' shows the new results when a group is involved. The main summary is still the same as in the old one, but the group results now also show the missing tests (see gdiplus and pdh again). Again there is a 'onMouseOver' hint in the group results. Remember that this is still without winetest producing output about missing dll's. Next patches will: - add a missing dll as one of the reasons for missing tests - add some better clue's on the main summary for multiple systems in a group (not a single '.' but maybe the same 'failed and skipped'). As said, one of the thoughts I had was to replace the '.' with a '?' in case of missing tests for an unknown reason but I'm not sure about that yet. Comments/remarks etc.. are welcome. I'd also like to hear about other idea's for this page to make it useful for everybody. Apart from the fact that we probably should have more exposure to the fact that we have such a page/tool. We saw an immediate rise (slowed down again) in test results as soon as winetest was mentioned on 'http://tweakers.net/meuktracker/15817/Wine-0.9.42.html' (in Dutch). There it was also mentioned that some machines crashed because of the tests etc.. (maybe a wine-winetest component on bugzilla could help with that which we could reference on the main test.winehq.org/data/*/index.html pages). Cheers, Paul.

Aug. 5, 2007

Re: user32 - set_active_window uses SendMessage instead ofPostMessage for WM_ACTIVATEAPP messages.

by Peter Dons Tychsen

On Sun, 2007-08-05 at 21:12 +0200, Peter Dons Tychsen wrote: > On Sat, 2007-08-04 at 12:04 +0900, Dmitry Timoshkov wrote: > > "Peter Dons Tychsen" <donpedro(a)tdcadsl.dk> wrote: > > > > > 1) Yes i did testing on Windows-XP. I did it by putting together various > > > examples and by checking with InSendMessage() for all cases. This > > > clearly showed that WM_ACTIVATEAPP was always posted and never sent. > > > > Looks like you misunderstood the InSendMessage behaviour and that led to > > some confusion. > > > > Wine test harness for message sequences works just fine, there is no need > > to blame it. > > > > I have found a new way of proving that ACTIVATEAPP must be sent using > the PostMessage call and not the SendMessage call. I have also found a > way to extend the unit test system to cover this. > > After realizing my bummer with InSendMessage() i set out to create a new > function that would do what i want: Check if a message was sent with > PostMessage() or SendMessage() on windows. I could not find any function > that would do this so i made my own hack (below): > > This piece of code, if inserted into the test system, could (on original > Windows) show us which messages we are incorrectly posting or sending. I > can probably also be used for other test purposes. I works by checking > the call stack for the calls SendMessageA() and SendMessageW(). Works > like charm on Windows-XP. Will need some work to also work inside Wine, > but that is not important for now. > > Usage: > > 1) Call call_stack_check_init(). > 2) Call called_from_send_message() inside the Proc handler. > > Cheers, > > /Pedro > > ------ CODE BEGIN -------- > > void call_stack_check_init(void) > { > HANDLE process = GetCurrentProcess(); > SymSetOptions(SYMOPT_UNDNAME | SYMOPT_DEFERRED_LOADS); > SymInitialize(process, NULL, TRUE); > } > > #define SYM_MAX_NAME_SIZE 1000 > BOOL call_stack_check_search(char *func) > { > STACKFRAME64 call_stack; > CONTEXT context; > HANDLE thread = GetCurrentThread(); > SYMBOL_INFO *sym = (SYMBOL_INFO *) malloc(sizeof(SYMBOL_INFO) + > SYM_MAX_NAME_SIZE); > CHAR name[SYM_MAX_NAME_SIZE]; > HANDLE process = GetCurrentProcess(); > > /* Setup symbol buffer */ > ZeroMemory(sym, sizeof(SYMBOL_INFO) + SYM_MAX_NAME_SIZE); > sym->SizeOfStruct = sizeof(SYMBOL_INFO); > sym->MaxNameLen = SYM_MAX_NAME_SIZE; > > /* Get thread context */ > ZeroMemory(&context, sizeof(context)); > context.ContextFlags = CONTEXT_FULL; > __asm call x; > __asm x: pop eax; > __asm mov context.Eip, eax; > __asm mov context.Ebp, ebp; > __asm mov context.Esp, esp; > > /* Setup stack walk offset */ > ZeroMemory(&call_stack, sizeof(call_stack)); > call_stack.AddrPC.Offset = context.Eip; > call_stack.AddrStack.Offset = context.Esp; > call_stack.AddrFrame.Offset = context.Ebp; > call_stack.AddrPC.Mode = AddrModeFlat; > call_stack.AddrStack.Mode = AddrModeFlat; > call_stack.AddrFrame.Mode = AddrModeFlat; > > while(1) > { > DWORD64 disp = 0; > > /* Walk that rusty old stack... */ > if(!StackWalk64( > IMAGE_FILE_MACHINE_I386, > process, > thread, > &call_stack, > NULL, > NULL, > SymFunctionTableAccess64, > SymGetModuleBase64, > NULL)) return FALSE; > > /* Get the next symbol on stack */ > if(SymFromAddr(GetCurrentProcess(), call_stack.AddrPC.Offset, &disp, > sym)) > { > /* Make it readable */ > UnDecorateSymbolName(sym->Name, name, SYM_MAX_NAME_SIZE, > UNDNAME_COMPLETE | > UNDNAME_NO_THISTYPE | > UNDNAME_NO_SPECIAL_SYMS | > UNDNAME_NO_MEMBER_TYPE | > UNDNAME_NO_MS_KEYWORDS | > UNDNAME_NO_ACCESS_SPECIFIERS); > > /* Check for match */ > if(!strcmp(func, name)) return TRUE; > } > } > > return FALSE; > } > BOOL called_from_send_message(void) > { > if (call_stack_check_search("SendMessageW")) return TRUE; > if (call_stack_check_search("SendMessageA")) return TRUE; > > return FALSE; > } > > ----- CODE END ----- By the way, this code does prove (if run on Windows-XP), that ACTIVATEAPP should be posted and not sent. /pedro

Aug. 5, 2007

Re: user32 - set_active_window uses SendMessage instead ofPostMessage for WM_ACTIVATEAPP messages.

by Peter Dons Tychsen

On Sat, 2007-08-04 at 12:04 +0900, Dmitry Timoshkov wrote: > "Peter Dons Tychsen" <donpedro(a)tdcadsl.dk> wrote: > > > 1) Yes i did testing on Windows-XP. I did it by putting together various > > examples and by checking with InSendMessage() for all cases. This > > clearly showed that WM_ACTIVATEAPP was always posted and never sent. > > Looks like you misunderstood the InSendMessage behaviour and that led to > some confusion. > > Wine test harness for message sequences works just fine, there is no need > to blame it. > I have found a new way of proving that ACTIVATEAPP must be sent using the PostMessage call and not the SendMessage call. I have also found a way to extend the unit test system to cover this. After realizing my bummer with InSendMessage() i set out to create a new function that would do what i want: Check if a message was sent with PostMessage() or SendMessage() on windows. I could not find any function that would do this so i made my own hack (below): This piece of code, if inserted into the test system, could (on original Windows) show us which messages we are incorrectly posting or sending. I can probably also be used for other test purposes. I works by checking the call stack for the calls SendMessageA() and SendMessageW(). Works like charm on Windows-XP. Will need some work to also work inside Wine, but that is not important for now. Usage: 1) Call call_stack_check_init(). 2) Call called_from_send_message() inside the Proc handler. Cheers, /Pedro ------ CODE BEGIN -------- void call_stack_check_init(void) { HANDLE process = GetCurrentProcess(); SymSetOptions(SYMOPT_UNDNAME | SYMOPT_DEFERRED_LOADS); SymInitialize(process, NULL, TRUE); } #define SYM_MAX_NAME_SIZE 1000 BOOL call_stack_check_search(char *func) { STACKFRAME64 call_stack; CONTEXT context; HANDLE thread = GetCurrentThread(); SYMBOL_INFO *sym = (SYMBOL_INFO *) malloc(sizeof(SYMBOL_INFO) + SYM_MAX_NAME_SIZE); CHAR name[SYM_MAX_NAME_SIZE]; HANDLE process = GetCurrentProcess(); /* Setup symbol buffer */ ZeroMemory(sym, sizeof(SYMBOL_INFO) + SYM_MAX_NAME_SIZE); sym->SizeOfStruct = sizeof(SYMBOL_INFO); sym->MaxNameLen = SYM_MAX_NAME_SIZE; /* Get thread context */ ZeroMemory(&context, sizeof(context)); context.ContextFlags = CONTEXT_FULL; __asm call x; __asm x: pop eax; __asm mov context.Eip, eax; __asm mov context.Ebp, ebp; __asm mov context.Esp, esp; /* Setup stack walk offset */ ZeroMemory(&call_stack, sizeof(call_stack)); call_stack.AddrPC.Offset = context.Eip; call_stack.AddrStack.Offset = context.Esp; call_stack.AddrFrame.Offset = context.Ebp; call_stack.AddrPC.Mode = AddrModeFlat; call_stack.AddrStack.Mode = AddrModeFlat; call_stack.AddrFrame.Mode = AddrModeFlat; while(1) { DWORD64 disp = 0; /* Walk that rusty old stack... */ if(!StackWalk64( IMAGE_FILE_MACHINE_I386, process, thread, &call_stack, NULL, NULL, SymFunctionTableAccess64, SymGetModuleBase64, NULL)) return FALSE; /* Get the next symbol on stack */ if(SymFromAddr(GetCurrentProcess(), call_stack.AddrPC.Offset, &disp, sym)) { /* Make it readable */ UnDecorateSymbolName(sym->Name, name, SYM_MAX_NAME_SIZE, UNDNAME_COMPLETE | UNDNAME_NO_THISTYPE | UNDNAME_NO_SPECIAL_SYMS | UNDNAME_NO_MEMBER_TYPE | UNDNAME_NO_MS_KEYWORDS | UNDNAME_NO_ACCESS_SPECIFIERS); /* Check for match */ if(!strcmp(func, name)) return TRUE; } } return FALSE; } BOOL called_from_send_message(void) { if (call_stack_check_search("SendMessageW")) return TRUE; if (call_stack_check_search("SendMessageA")) return TRUE; return FALSE; } ----- CODE END -----

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Jakob Eriksson

Kai Blin wrote: > > Why would you even bother to disassemble to write a unit test? All Wine cares > about is "What's the output of function X when I put in Y and Z as > parameters?". That's why you write a conformance test that will run on > Windows. Then you make Wine behave the same. No need to disassemble anything > there. > That is very true. There's no need. regards, Jakob

Aug. 5, 2007

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice

by Vitaliy Margolen

Peter Dons Tychsen wrote: >> OK, fair enough. Even though i did'nt like messing around with >> joystick_linuxinput.c i should have been smarter than trying to submit >> something i could not test... :-( >> >> But... tada!... now i have re-fixed it and re-tested both >> implementations. Its seems stable now. :-) >> >> Please give it another go on your machine Vitaliy. >> > As usual, i forgot the patch.... getting late inside my head :-) > > Here it is... > Looks good now. And it even works :) Send it it. Vitaliy.

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Kai Blin

On Sunday 05 August 2007 18:06:28 Jakob Eriksson wrote: > Kai Blin wrote: > > On Sunday 05 August 2007 04:23:15 Peter Dons Tychsen wrote: > >> It was regarding the fact that it is not allowed to disassemble and > >> reverse engineer Microsoft DLLs. I understand this part, as their > >> license prohibits it (EULA). > > > > Please note that "reverse engineering by disassembly" is not the same > > as "reverse engineering by black box testing". The former is not only > > disallowed by many license agreements, it's actually a violation of > > copyright in most (western) countries. > > Not all western countries by far. [...] > Dissambling is not illegal. Disassembling and then writing another > implementation > is against copyright. > [snip MSDN etc] Well, I'm talking about "in the context of using the results for Wine". I was also simplifying. However, given that the USA seem to consider the internet to be under their jurisdiction, the US legal system seems to be par for the interpretation of all of this. > I also can't see how it would be illegal to, for instance, person A > disassembling a DLL, then writing documentation for that DLL. > Then for person B to reimplement said DLL by means of the > specification specified by person A. > > This is how Compaq legally reverse engineered the IBM PC BIOS. I don't > see how there would be any difference writing the documentation as unit > tests or english. > > I.e. disassembling for the purpose of creating unit tests must be ok, > AFAIK. Why would you even bother to disassemble to write a unit test? All Wine cares about is "What's the output of function X when I put in Y and Z as parameters?". That's why you write a conformance test that will run on Windows. Then you make Wine behave the same. No need to disassemble anything there. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Jakob Eriksson

Kai Blin wrote: > On Sunday 05 August 2007 04:23:15 Peter Dons Tychsen wrote: > > >> It was regarding the fact that it is not allowed to disassemble and >> reverse engineer Microsoft DLLs. I understand this part, as their >> license prohibits it (EULA). >> > > Please note that "reverse engineering by disassembly" is not the same > as "reverse engineering by black box testing". The former is not only > disallowed by many license agreements, it's actually a violation of copyright > in most (western) countries. > Not all western countries by far. > Reverse engineering by black box testing is an established and legal method in > industry. Wine uses this method extensively by writing test cases. > > >> However, i would be more clear if someone would make these rules >> commonly available on the WineHQ website. >> > > [Omitting a quote about disassembly being useless] > > >> This should probably be fixed. It should make it crystal clear was is >> allowed and what is not. This would help avoid situation like the one >> mentioned above. >> > > It's also not allowed to break other laws while developing software. Where > would you draw the line? Disassembling software is (almost always) illegal. > Killing people is illegal. Should both be in the development guide? I would > assume common sense would tell people that they should only do things that > are legal. > Dissambling is not illegal. Disassembling and then writing another implementation is against copyright. [snip MSDN etc] > This is the common sense I was talking about before. Thank you for asking. > > >> Please think long and hard before you reply. >> > > The usual disclaimer about how I'm not a lawyer and can't give legal advice > applies, of course. But a rule of thumb is: "If you never looked at > disassembled code and you are using tests using the Windows APIs to determine > how the API you're interested in works, you're fine." > > I also can't see how it would be illegal to, for instance, person A disassembling a DLL, then writing documentation for that DLL. Then for person B to reimplement said DLL by means of the specification specified by person A. This is how Compaq legally reverse engineered the IBM PC BIOS. I don't see how there would be any difference writing the documentation as unit tests or english. I.e. disassembling for the purpose of creating unit tests must be ok, AFAIK. regards, Jakob

Aug. 5, 2007