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.