On Sunday 24 December 2006 17:53, Vitaliy Margolen wrote:
Patrik Stridvall wrote:
On Sunday 24 December 2006 05:37, Vitaliy Margolen wrote:
Is there are any reason why do you need this functions at all? According to ddk they are part of "Installable File System Drivers". This is a kernel level thing only and no user app should use these routines.
Should, perhaps. Does, well that is a different matter entirely. :-)
Secondly we could perhaps find use for them ourselves. Splay and AVL trees are nice.
Especially stabbing them won't do you any good if something actually using them. But that something has no place to run in Wine yet.
ReactOS has some sort of implementation of them so I guess we can borrow
Please don't mention ros' code here. It's barred from Wine.
Huh? OK, I have been away from Wine development for a few years but it not ReactOS under GPL and/or LGPL? Or have I missed something.
In any case implementing Splay and AVL trees is hardly rocket science and just looking at other implementation and being inspired is allowed regardless of license.
In any case having them stubbed in better than nothing. I don't think
Not really. As I said before, if a program uses these functions, then it's: a) Probably a kernel driver (which acre currently not supported) b) Won't run at all with stubbed implementation (in case we implement "kernel"
From what I've seen Wine prefers to crash instead of returning bogus data or unimplemented functionality.
Any implementation of anything must start somewhere. But OK we can let the stubs remain in the spec file if crashing applications is preferred and unstub them for each complete implementation.
Still applying the patch minus the .spec change won't hurt and is a good start...