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

[Steven Edwards]

Hi,

--- Alex Ionescu <ionucu at videotron.ca> wrote:
> 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.

They would have had to be done anyway and it would have taken just as long and in the interm
hardly applications would work on Wine just like ReactOS can really not run much of anything. Wine
is a userspace server. They could properly implement a kernel compatiblity layer for loading
Windows drivers but even still there are all sorts of issues you are not taking in to account.
Linux's lack of a stable driver interface, the SCSI subsystem changing from one Linux kernel
Revision to another making emulation of Windows ICTOLs a pain and constanly changing.

> 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!"

And in the mean time X number of Application would have been working attracting more users to the
project as well as more money and more developers. As opposed to saying "We are going to do a 100%
perfect replication with no working around the design limiations along the way". Using the no
creative solutions method is boring, It gets nothing working short term, It gives Microsoft more
time to lock the world in to the next version of the legal crack known as windows. By the time we
are even 90% compatible with NT4, Windows Server 2010 is going to be out following these design
decisions.

> 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.

> 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?

No I am using that as a example of clean room reverse enginering. Find me a application that uses
it so I can replicate the interface in a clean room without Windows, or a prototype documented in
a published header and I will have a legal leg to stand on. Even when the Wine guys have used
tools like IDA, etc they have not been reversing Windows. They have been looking at the
applications that use Windows and seeing what that application expects. I don't run Windows nor I
am going to potentially break the law in working on ReactOS and taint the project by dissasmbling
a running Windows system. 100% driver and application compatiblity can be reached without it.

> NtDeleteFile is undocumented too... should we forget about it? My 
> apologies if you were only referring to setupapi.

NtDeleteFile might not be a good example but lets take a user32->Win32k.sys functions. We have two
options. 1 Implementing everything properly and it taking years/decade/never or 2. Taking
shortcuts using more Wine code and maybe violating some design rules short term. I will give you a
example that might work. Right now our code for GetSystemMetrics is mostly a hard coded stub in
User32->Win32k I could spend a month rewriting it in Win32k.sys and get a 20% working
implementation or I could take Wines 2000 line source file and stick it in user32.dll. Now there
are other functions in Win32k.sys that depend on NtUserGetSystemMetrics(CX_*) so I would still
leave the old code in Win32k.sys there and slowly start improving it so that I could being to
forward options from User32.GetSystemMetrics to win32k.NtUserGetSystemMetrics one at a time.

Using your logic you are saying "You are not going to implement NtUserGetSystemMetrics!!!" No I am
saying I am going to use what code we can to get applications working today while designing it
where it can be properly implemented long term. 

Thanks
Steven



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs