Re: ntdll: Added stubs for the Rtl*GenericTable* functions
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. 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. Vitaliy.
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 that I think the code in under the correct license. It seems to depend on some sort of external library though. Not 100% sure. In any case having them stubbed in better than nothing. I don't think implementing them is that difficult either. There are very likely to be code there beside the ReactOS code that we can borrow or link to. Splay and AVL trees are not really rocket science.
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.
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.
Vitaliy.
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...
Patrik Stridvall wrote:
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...
No. Having stubs that won't ever be called in a totally separate file makes no sense at all. Until you have a real life program that depends on this functionality, there is no reason to do anything about them. Vitaliy.
On Monday 25 December 2006 00:23, Vitaliy Margolen wrote:
Patrik Stridvall wrote:
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...
No. Having stubs that won't ever be called in a totally separate file makes no sense at all. Until you have a real life program that depends on this functionality, there is no reason to do anything about them.
Nothing really important. I was just playing around with the Windows XP EXEs and DLLs. The VSSAPI.DLL which is used for backup uses them. But yes it is filesystem related as you said. It was just something that I noticed was missing and seemed reasonably easy to add. But sure they not really very useful unless 100% correctly implemented. However waiting for an 100% correct patch is not a good strategy either. It is also something that we possible could use in other parts of Wine like OpenGL and/or DirectX. Just because Windows possible just uses them for file system stuff doesn't mean that we need to be equally limited. There reason I wrote the patch was more like cool, Windows have APIs for Splay and AVL trees. Oh they are not implemented yet. Oh well, if I send in a stubbed implementation somebody might start using it and writing the rest. As I said it seem to exists open sourced code that can be borrowed or linked to.
participants (2)
-
Patrik Stridvall -
Vitaliy Margolen