Hi,
--- Alex Ionescu <ionucu(a)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?
1) 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