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

Re: Wine disassembly and reverse engineering rules.

by Kai Blin

On Sunday 05 August 2007 17:27:23 you wrote: > Thanks for your comments Kai. My pleasure. > > 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. > > I thing killing is a bit off topic :-) Sure. I was exaggerating. :) > However i do get your point about making it clear. It would be difficult > to handle. OK, but changing the text i referred to would be a good start > though. > > The text could be changed to (or similar): > > "Disassembling native Windows DLLs is not allowed in the Wine project > due to legal implications. However, this does not change much, as > disassembling native Windows DLLs is virtually always useless, as as > technique disassemly is usually used to find out why the application is > crashing in an otherwise unexplainable way." That would probably help. Feel free to send a patch to the website. 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 Peter Dons Tychsen

On Sun, 2007-08-05 at 17:27 +0200, Peter Dons Tychsen wrote: > On Sun, 2007-08-05 at 09:58 +0200, 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. > > > > 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. > > > > > Another problem is that i want to introduce something which i am not > > > sure is covered or not by what is "not allowed". > > > > > > I want to introduce a function which can check if SendMessage() or > > > PostMessage() was the reason a message ended up in a Proc handler. > > > > [...] > > > > > I don't think there is a problem as i am just using documented APIs from > > > MSDN, but since it includes looking at the call stack, i was curious if > > > there might be a legal problem. > > > > If you are just using the documented API, this is just how Wine tests are > > done. > > > > > I don't want to put the idea to use or release it if it in any way is > > > illegal. > > > > 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." > > > > Hope that helps, > > Kai > > > > Thanks for your comments Kai. > > > 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. > I thing killing is a bit off topic :-) > > However i do get your point about making it clear. It would be difficult > to handle. OK, but changing the text i referred to would be a good start > though. > > The text could be changed to (or similar): > > "Disassembling native Windows DLLs is not allowed in the Wine project > due to legal implications. However, this does not change much, as > disassembling native Windows DLLs is virtually always useless, as as > technique disassemly is usually used to find out why the application is > crashing in an otherwise unexplainable way." OK. I will go ahead and post my proposals. Thank you for helping out. Always good to be on the safe side. /Pedro

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Peter Dons Tychsen

On Sun, 2007-08-05 at 09:58 +0200, 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. > > 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. > > > Another problem is that i want to introduce something which i am not > > sure is covered or not by what is "not allowed". > > > > I want to introduce a function which can check if SendMessage() or > > PostMessage() was the reason a message ended up in a Proc handler. > > [...] > > > I don't think there is a problem as i am just using documented APIs from > > MSDN, but since it includes looking at the call stack, i was curious if > > there might be a legal problem. > > If you are just using the documented API, this is just how Wine tests are > done. > > > I don't want to put the idea to use or release it if it in any way is > > illegal. > > 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." > > Hope that helps, > Kai > Thanks for your comments Kai. > 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. I thing killing is a bit off topic :-) However i do get your point about making it clear. It would be difficult to handle. OK, but changing the text i referred to would be a good start though. The text could be changed to (or similar): "Disassembling native Windows DLLs is not allowed in the Wine project due to legal implications. However, this does not change much, as disassembling native Windows DLLs is virtually always useless, as as technique disassemly is usually used to find out why the application is crashing in an otherwise unexplainable way."

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Jakob Eriksson

Peter Dons Tychsen wrote: > By browsing MSDN, i found out that i can accomplish this by using the > documented function StalkWalk64(), which can examine the call stack. I > would then introduce this into the test system for DLLs like "user32". > By running the test on original Windows we could know which messages we > are incorrectly "posting" or "sending" where it should have been the > opposite. This could fix some vital issues. > > I don't think there is a problem as i am just using documented APIs from > MSDN, but since it includes looking at the call stack, i was curious if > there might be a legal problem. > > I don't want to put the idea to use or release it if it in any way is > illegal. > > Please think long and hard before you reply. > DMCA Reverse engineering exemption: http://www.chillingeffects.org/reverse/faq.cgi#QID210 regards, Jakob

Aug. 5, 2007

[winetest] Show missing tests in single/group results

by Paul Vriens

Hi, Before sending this to wine-patches I would like people to have a look first. I've added as many screenshots as I thought where needed to show the changes (so sorry in advance for the flood of pictures). 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. 'single_test_before' shows that currently we have a single '.' where a test is missing (without a link obviously or explanation). 'main_summary_before' shows the same '.' but now we have 2 systems in the group. This means there is a link to the group overview. 'group_overview_before' shows nothing for these particular tests (gdiplus). Now with the new output: 'single_test_after' still show the '.' but now it's marked todo (and a skip border as these tests are skipped). 'failing_test_single_onmouseover' shows at least some explanation. 'main_summary_after' is still the same with this new version (there is a link to the group overview). 'group_overview_after' shows that now the group overview correctly shows the missing tests and 'failing_test_onmouseover' shows some explanation. 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'). 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 page). Cheers, Paul.

Aug. 5, 2007

Re: Wine disassembly and reverse engineering rules.

by Kai Blin

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. 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. > Another problem is that i want to introduce something which i am not > sure is covered or not by what is "not allowed". > > I want to introduce a function which can check if SendMessage() or > PostMessage() was the reason a message ended up in a Proc handler. [...] > I don't think there is a problem as i am just using documented APIs from > MSDN, but since it includes looking at the call stack, i was curious if > there might be a legal problem. If you are just using the documented API, this is just how Wine tests are done. > I don't want to put the idea to use or release it if it in any way is > illegal. 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." Hope that helps, 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

Wine disassembly and reverse engineering rules.

by Peter Dons Tychsen

Hello James/Wine. 1) I noticed your comment the forums here: http://article.gmane.org/gmane.comp.emulators.wine.devel/52810 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). However, i would be more clear if someone would make these rules commonly available on the WineHQ website. I tried to search for it but all i could find was: http://www.winehq.org/site/developer-cheatsheet "Disassembling native Windows DLLs is virtually always useless, as a technique disassemly is usually used to find out why the application is crashing in an otherwise unexplainable way." This text does not make it sound prohibited (some might read is as an actual encouragement - (useless != probited)). 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. 2) Another problem is that i want to introduce something which i am not sure is covered or not by what is "not allowed". I want to introduce a function which can check if SendMessage() or PostMessage() was the reason a message ended up in a Proc handler. By browsing MSDN, i found out that i can accomplish this by using the documented function StalkWalk64(), which can examine the call stack. I would then introduce this into the test system for DLLs like "user32". By running the test on original Windows we could know which messages we are incorrectly "posting" or "sending" where it should have been the opposite. This could fix some vital issues. I don't think there is a problem as i am just using documented APIs from MSDN, but since it includes looking at the call stack, i was curious if there might be a legal problem. I don't want to put the idea to use or release it if it in any way is illegal. Please think long and hard before you reply. Thanks for your time, /Pedro

Aug. 4, 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. Hello Dmitry! Thanks for your comments, > Looks like you misunderstood the InSendMessage behaviour and that led to > some confusion. I sure did! I must have been tired or something :-). When i went back and tested it again i did verify that it worked differently than i expected. Even the InSendMessageEx() did not work as i expected. The MSDN documentation also seems vague on this. Anyway, you are right. > Wine test harness for message sequences works just fine, there is no need > to blame it. I'm not blaming it for anything. I am just pointing out that it does not work if you want to test for posted messages. It has a bit bit-mask which describes if the tested message is sent or posted. However the framework does not make sure that posted messages are actually received before it starts comparing. Look at the way the ok_sequence_() works. It compares with the messages which are picked up in the WinProc() function. 1) It does not make sure that all messages are received before comparing. I believe the best (maybe the only?) way of doing this would be to do: while(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessage(&msg); I don't see how you otherwise can make sure that all messages are received before comparing. Currently the existing test cases almost only checks for sent messages and not posted ones. This i probably why the current cases wok as well as they do. 2) It does not actually check if the message was posted or sent. This would make sense. I was too quick in assuming that this could be done with InMessageSend(). I was wrong. Maybe another mechanism can be used? I will go back and figure out a better way of checking these things if i can. I still think the test system needs a fix-up. Cheers, /Pedro

Aug. 4, 2007

Re: [PATCH] winecfg: Fix crash caused by calling set_reg_key with NULL value

by Evan Stade

On 8/3/07, Nigel Liang <ncliang(a)gmail.com> wrote: > On 8/3/07, Evan Stade <estade(a)gmail.com> wrote: > > On 8/3/07, Nigel Liang <ncliang(a)gmail.com> wrote: > > > diff --git a/programs/winecfg/winecfg.c b/programs/winecfg/winecfg.c > > > index 84dd4c8..05f322c 100644 > > > --- a/programs/winecfg/winecfg.c > > > +++ b/programs/winecfg/winecfg.c > > > @@ -468,11 +468,15 @@ void set_reg_key(HKEY root, const char * > > > > > > wpath = HeapAlloc(GetProcessHeap(), 0, (strlen(path)+1)*sizeof(WCHAR)); > > > wname = HeapAlloc(GetProcessHeap(), 0, (strlen(name)+1)*sizeof(WCHAR)); > > > - wvalue = HeapAlloc(GetProcessHeap(), 0, (strlen(value)+1)*sizeof(WCHAR)); > > > > > > MultiByteToWideChar(CP_ACP, 0, path, -1, wpath, strlen(path)+1); > > > MultiByteToWideChar(CP_ACP, 0, name, -1, wname, strlen(name)+1); > > > - MultiByteToWideChar(CP_ACP, 0, value, -1, wvalue, strlen(value)+1); > > > + > > > + if (value) > > > + { > > > + wvalue = HeapAlloc(GetProcessHeap(), 0, (strlen(value)+1)*sizeof(WCHAR)); > > > + MultiByteToWideChar(CP_ACP, 0, value, -1, wvalue, strlen(value)+1); > > > + } > > > > > > set_reg_key_ex(root, wpath, wname, wvalue, REG_SZ); > > > > > > -- > > > 1.4.1 > > > > > > > > > > > > > > > > You need to initialize wvalue to NULL > > > > -- > > Evan Stade > > > Why is that? The code is not dependent on wvalue being NULL, but it > checks "value" to catch NULL pointers passed in from the caller. I > think you may have missed that... ;-) > > -Nigel > The code depends on wvalue either being a valid pointer or NULL, and if value is NULL then you set wvalue to neither. It should also give a compiler warning when you compile because you are using an uninitialized variable. get_reg_key does make these initializations by the way. -- Evan Stade

Aug. 4, 2007

Re: Sent a patch twice

by Duane Clark

Rene Kok wrote: > I never submitted a patch before. It wasn't a patch I created just > resubmitting it. However I accidentally sent it to the wine-patches > mailing list twice. The first time I wasn't subscribed, which I prefer > not to because the huge amount of mail I'll get when I do :-) You can go to your preferences, by going here: http://www.winehq.org/mailman/listinfo/wine-devel Fill in your email address in the last box and click the edit options button. Scroll down and there is an option for "Mail delivery". Turn it off, and you can remain subscribed but not be sent the postings.

Aug. 4, 2007