The wine team members would tell you themselves that quite a bit of headway was made with wine through reverse engineering. Heck, check out wikipedia on the subject:
http://en.wikipedia.org/wiki/Talk:Reverse_engineering
http://en.wikipedia.org/wiki/Talk:Wine_(software)
And check out these sites:
http://slashdot.org/article.pl?sid=06/01/31/005202
http://www.absoluteastronomy.com/ref...se_engineering
Quote:
The Samba software (Samba software: more facts about this subject) , which allows systems that are not running Microsoft Windows (Microsoft Windows: microsoft windows is a range of closed source proprietary commercial operating...
) systems to share files with systems that are, is a classic example of software reverse engineering, since the Samba project had to reverse-engineer unpublished information about how Windows file sharing worked, so that non-Windows computers could emulate this. The WINE (WINE: Fermented juice (of grapes especially)) project does the same thing for the Windows API (Windows API: windows api is a set of apis (application programming interfaces) available in the microsoft...
) , and OpenOffice.org (OpenOffice.org: openoffice.org is an open source office suite....
) is one party doing this for the Microsoft Office (Microsoft Office: microsoft office is a suite of productivity programs created by microsoft and developed...
) file formats.
|
http://ln.hixie.ch/?start=1086387609
Quote:
Making these specs more detailed is the work that Opera and Mozilla want to do. But to do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible. Notice how WINE has to reverse engineer Windows to determine how it should work. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability.
(. . . .)
Second: I was quite amused to see that, of all companies, Microsoft, Red Hat, and Sun Microsystems actually agreed on something. Namely that trying to standardise an API for sophisticated applications is simply a non-starter. The argument, which I agree with, is that such APIs are simply insanely complicated, and that making interoperable implementations is nigh on impossible. Just look at the trouble WINE has had trying to implement Win32 again — now imagine if you had to write a spec to actually describe the entire Win32 API in terms that could actually be implemented interoperably without reverse engineering the first implementation as the WINE people do.
|
Now, let's get back to the basic question: What is reverse engineering?
http://en.wikipedia.org/wiki/Reverse_Engineering
http://www.answers.com/main/ntquery?...neering&gwp=13
http://www.chillingeffects.org/reverse/faq.cgi
Conclusion:
Stop stating that:
- none of wine is based on reverse engineering Windows libraries or windows program libraries
- reverse engineering by analyzing externally how things are done (black box reverse engineering) is illegal
- decompiling to examine internally how things are done (white box reverse engineering) is illegal
Because each of those three points is blatently incorrect. If you state that wine is not based on reverse engineering the Windows API, you have NO clue what reverse engineering is. It is not always based on decompiling inecode; it can be based on looking at what an API calls, what its interface is, and reimplementing it. it's called systems analysis (or a subset of it) and is in fact reverse engineering. You're taking an existing design, analyzing how it works, and creating a new implementation of it, down to the ordinals which need to be binary compatible.
http://www.sane-project.org/old-arch...8-05/0252.html
OMFG, one of the developers refers to reverse engineering a Windows driver!
Now, stop posting nonsense, stop making crap up if you don't know what reverse engineering is, and if you know and continue posting FUD just to be a jerk, well, get a clue and STOP IT.
Sheesh.
