Hi,
--- Alex Ionescu ionucu@videotron.ca wrote:
Even if only an Windows DLL uses the function, it implies that the Windows DLL needs that functionality. It's also highly likely that DLL has exported functions used by applications, implying in turn that WINE has a FOSS version of that DLL. Now, it's not a far stretch that if this DLL needs to import an undocumented API from another DLL, it actually *needs* that functionality, and so will WINE. So let's say that crypt32.dll needs advapi32!SystemFunctionImSuperUndocumented007 to generate an RC5 hash, then WINE also probably needs a way to get an RC5 hash. What are the solutions?
- Implement a home-made RC5 hash and call it CryptpRc5Hash, and stick
it as an internal static function inside crypt32.dll 2) Above, but stuck into a winelib.dll 3) Above, but stuck into advapi32!SystemFunctionImSuperUndocumented007, with minor changes to make sure it corresponds to the same parameters.
What harm does #3 do? It gives the same result as #1/2, but has the added avantage that if, somehow, somewhere, an external app needs an RC5 hash and figured out that function, it will work. This goes back to what I said, undocumented functions are not exported just for the fun of it. Even if they are only used by other DLLs, those DLLs need that functionality and so will the WINE dlls.
If its a Windows System Dll then running it on Wine gains you nothing except people being lazy and not coding a proper replacement. Using this logic Wine should implement 8 layers of abstraction
Linux Kernel Crypto APIs->Ksecdd.sys->emulated syscall magic->advapi32.systemfunction->crypt.dll->rsabase.dll->???
If I am a Linux developer trying to make a API replacement as a migration tool I am going to make the crypt.dll and rsabase.dll be a wraper for a exported kernel API or use openssl, tinyssl or whatever else and save my time. Why? Because I want to have all Linux native applications. I could give 2 shits about following the precious Windows design for everything because ultimatly my end goal it to have native Linux applications not some bloated compatiblity layer.
It is a totally different mindset and if we want to share some code we have to work around that. Some things might not be shared. Big deal.
It's not like WINE developers were forced or had to spend time to write these functions, one of our developers did (and he submited patches to WINE). What possible -harm- can it do?
No thats the point. Our developers ARE NOT SENDING PATCHES TO WINE AS A GENERAL RULE. They are making massive changes and then doing a drop of code. That is not a patch. Then its impossible to merge in fixes from Winehq and keep our stuff up2date. Lets say I implement dllname.foo and wine has dllname.bar then I go and implement dllname.foobar1 dllname.foobar2 dllname.foobar3 dllname.foobar4 all of which depend on dllname.foo and later someone else in Wine then goes and fixes a bug in dllname.foo. Guess what we cannot sync the patch because it might break X number of other functions.
By the way, IE and WMP are OS Components. According to what you said, these also don't count: "made by Microsoft and NOT called a OS COMPONATE".
I certaintly hope they don't start using undocumented functions! (But trust me, their calls do end up in those SystemFunctionXXX advapi calls through other DLLs). Almost any crypto/security call does.
Right. Show me a real world application that calls all of the advapi32.systemfunction apis and I might agree with you. I know of one that does in totally violation of all of the rules and breaks on version of Windows to another. Ditto for the undocumented Setupapi functions which by the way Change from one version of Windows to another. Compare Windows 2000 setupapi.stringtable* to Windows XP/2K3 setupapi.pstringtable functions. They are exported under a totally different name and to date I have only found 1 application that uses them and yes it is a OS COMPONATE as defined by the EULA.
Thanks Steven
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs