[ros-dev] End-of-merge for some components shared with Wine

[Alex Ionescu]

Steven Edwards wrote:

>Hi,
>  
>
>
>
>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->???
>  
>
The best solution would be to follow that, yes, but I concede that it is 
not in WINE's best interests. Nevertheless, they will eventually suffer 
from not doing it that way. Look at how much stuff had to be done for 
apps like Safedisc, which required WINE to implement a completely 
emulated kernel-mode driver layer.

>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.
>  
>
Ok, so you're saying that crypt.dll should directly call some linux 
native openssl library... that makes sense. Now, what if 5 other 
exported, publically used dlls also need to call SystemFunction007? They 
will also have to call some linux native openssl library. Now, if that 
library is included statically, you've bloated 5 DLLs. If it's simply an 
external lib, then how much harder is it to stub SystemFunction007 to 
call the openssl library? That is 10 lines of adtionnal code, with the 
added benefit that if anyone ever calls that undocumented export, you 
can handle it. But in reality, even that would be flawed, because I do 
agree that ksecdd.sys should actually be called if  needed. Now you're 
going to call me crazy and say that's even beyond undocumented, plus 
it's kernel mode. Go ahead and laugh... I happen to have a copy of the 
WDK, and you'd be "pleased" to know that the KSECDD APIs are becoming 
documented. What if some of ksecdd are just regular IOCTLs that a 
user-mode app like safedisc would launch? You'd probably hack ksecdd to 
use openssl as well... but now you're having a duplicated design, where 
crypt is using openssl, advapi006 is not implemented, and ksecdd is also 
using openssl. Nice waste! If it would've been done properly since the 
start, you assure full compatibility. What happens when MS documents the 
SystemFunctionsXXX, like they've done with GdiEntryXXX? You scramble to 
implement the functions and tell yourself "Shit, I should've accepted 
that patch last year!"

>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. 
>
Well that's a big problem then, and we should have a serious discussion 
with those developers, as well as ensure that we don't allow commits to 
WINE libs if we don't see a patch first.

>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.
>  
>
I concede on that extremly weird and unused API, but you're using that 
case as a justification not to implement *ANY* unimplemented APIs, 
aren't you?
NtDeleteFile is undocumented too... should we forget about it? My 
apologies if you were only referring to setupapi.

>Thanks
>Steven
>
>
>
>		
>  
>
Best regards,
Alex Ionescu