Hi all,
I guess I'm responsible for a lot of redundant code between the implementations of filesystem shellfolders in shell32/shlfdr_fs.c and shfldr_unixfs.c. While I've always tried to re-use as much code as possible, unixfs by nature has to use posix apis to get hold of the unix filesystem.
In current cvs, unixfs can be used as a drop-in replacement for the old CLSID_ShellFSFolder implementation and if you apply the attached small patch, it will be. It would be nice if some people could try this in their local tree and report problems with it.
What do people think about getting rid of shfldr_fs.c in the long run, in order to remove the redundancy? Does ReactOS use wine's shell32.dll? I guess it would be a problem for them?
ChangeLog: shell32: Use shfldr_unixfs CLSID_ShellFSFolder implementation instead of the one from shfldr_fs
dlls/shell32/shellole.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Bye,
From: Michael Jung
What do people think about getting rid of shfldr_fs.c in the long run, in order to remove the redundancy? Does ReactOS use wine's shell32.dll? I guess it would be a problem for them?
Yes, we do and yes, it would be a problem... We don't import the shfldr_unixfs.c file because we have no use for it. I haven't really looked at the unixfs stuff, but I'm wondering if it's perhaps possible to use an inheritance mechanism? shfldr_fs and shfldr_unixfs could both inherit from a common implementation, we can tack on some internal routines to the existing vtable. Redundancy between the two can then be eliminated by extracting the common code to the "base class" which would call through the vtable to the internal routines. If this is only for the benefit of ReactOS then of course I would be willing to put in the work to make it happen.
Gé van Geldorp.
Hey Ge,
On Tuesday 17 January 2006 19:55, Ge van Geldorp wrote:
shfldr_fs and shfldr_unixfs could both inherit from a common implementation, we can tack on some internal routines to the existing vtable. Redundancy between the two can then be eliminated by extracting the common code to the "base class" which would call through the vtable to the internal routines.
As a first step, I'm planning to restrict the usage of posix apis as much as possible (largely to the code, which builds the pidls). As far as I understand by now, for stuff like moving or renaming files we should probably build on SHFileOperation. This way we don't have to replicate the UI stuff.
Currently, there's a unix path stored in UnixFolder's m_pszPath member. But we could store a DOS path there instead, as long as the current folder maps to a valid DOS path (m_dwAttributes & SFGAO_FILESYSTEM). This would of course always be the case for CLSID_ShellFSFolder.
If this is only for the benefit of ReactOS then of course I would be willing to put in the work to make it happen.
The thing that would only be for the benefit of ReactOS would be the code to build pidls based on win32 apis. Perhaps you could jump in, once we are at this point.
Thanks for your comments,
-
Ge van Geldorp -
Michael Jung