This is WIP. For now I tried to list as many parts of shell32 as possible. Note that I'm comparing ros shell with windows 2003 one here.
Current Status and Roadmap
Legend: means only bugfixes needed. means unimplemented. means that it needs lots of work, either it is too buggy or implemented in a hacky/wrong way.
Core functions of the shell. ALL of these should be green in the end.
ShellExecuteExW: I think wine's implementation is completely backwards. This should execute items of the shell namespace. I think that every path passed should be resolved as a pidl first.
SHChangeNotifyRegister, SHChangeNotifyDeregister, SHChangeNotify: Many things need work here. Windows use a worker thread for some reason, we leak handles and support for items on the desktop is *terrible* (it needs some very clever hacks that we don't have)
SHFileOperationW: Many edge cases are broken. Right now most copy and paste problems are bugs in this function
Shell_NotifyIconW: This is a mere forwarder of the notifications to explorer. The forwarder is complete but a lot of stuff in explorer's end need work for this to seem to work properly
Control_RunDLLW: See the failed tests to see how broken it is
SHMapPIDLToSystemImageListIndex: The way it interacts with IIconExtraction is FUBAR. Overlays support is hacked.
CQueryAssociations: Only the documented part is implemented; In windows more internal classes expose IQueryAssociations. It is really questionable if any of the undocumented part merits to be implemented.
CDropTargetHelper (called CDragDropHelper in windows): Implements the visual effects that are used when dragging shell items. It is closely related to the DAD_* functions
|Def namespace objects
Core objects used by the namespace components to interact with the user. Fixing the noted problems in these items is really important
CDefaultContextMenu (called CDefFolderMenu in windows): tried to implement the context menu of the cpl items in the control panel with callbacks but run into problems with ids _again_
CDefView: I hope webview and crap like that won't be needed and we can keep this component simple. This misses some features like saving and loading icon positions but what is implemented has very few bugs
CExtractIcon: Its implementation and the way it interacts with the icon cache is a mess.
The components that constitute the shell namespace. Fixing the gray and red components that follow isn't really important for now. The rest are
CRegFolder. In windows users of this class aggregate it and let it handle IShellFolder2 first. Imo this is not needed. ParseDisplayName should support parsing user friendly names but it doesn't right now
CDrivesFolder: Windows use a CMountpoint class but we do the bare minimum. I guess it is fine thins way
CFSFolder: BindToObject must be improved not to create new CFSFolder objects for complex pidls. I stupidly thought we could use _ILGetFileStructW and access the name directly. Turns out it should also accept ansi-only pidls as well(CORE-14009)
CControlPanelFolder: The context menu of the cpl items should use CDefContextMenu and use callbacks to start launch the cpl (instead of having a separate implementation of the IContextMenu)
CRecycleBinFolder: Icons are unimplemented due to the stupidly complex internal architecture of the recycle bin implementation
CNetFolder: This is only a quick and dirty implementation so far
CMergedFolder: pidls must never contain pointers. they can contain other pidls however
CPrintersFolder: lots of stuff to implement here. in windows there is a strange interaction with printui but I don't think there is any reason to implement such an interaction; the printers folder can be completely self contained and use only documented exports of printui
CCDBurnFolder: do we even need this?
Components that implement the menu like toolbars of the shell
CMenuBand: Doesn't support accessibility, drag and drop and renaming shell folder items
CPersonalStartMenu: Used by the modern start menu. It implements the all programs popup menu.
CTrackShellMenu: Find out that this is for
|Built in shell extensions
Components that aren't part of the core and are mostly instantiated in the same way shell extensions are
CFileSearchBand: Why on earth is there an IDeskBand in shell32?
CStartMenuPin: I think this is the IContextMenu that lets you pin stuff in the modern start menu
Components exposing shell functionality with the IDispatch interface. As of now these are barely implemented
CDefViewDual (called CShellFolderView in windows)
CShellFolderViewOC: Find out what this is for
Components used by explorer that implement most of the desktop
CShellBrowser: It doesn't support refreshing environment variables. When a folder is draged on its edge it should show a docking bar with its contents. It should use RegisterDeviceNotifications and get notifications about storage devices and call SHChangeNotify accordingly.
CSDWindows, WinList_Init, WinList_Terminate: In windows this is implemented in shdocvw but our shell will not depend on it at all. WinList_Init should do CoRegisterClassObject with CLSID_ShellWindows and an instance of CSDWindows.
|Components intentionally ignored
Misc components with 0 chance to get implemented
Misc components that I don't know what they are for
|Auto complete support
Components used to implement autocomplete
Implementations of IBandSite and IDeskBand.
CBandSite: Several features are missing. Not sure if the existing code is correct
CISFBand: Several features are missing. Existing code is correct.
|Classic browser toolbar
The exported components that make up the toolbar in the browser.
CInternetToolbar: Windows share a lot of code of this class with others like CBaseBar and CBandSite
The classic file explorer.
CShellBrowser (called CShellBrowser2 in windows): In windows this shares a lot of code with internet explorer and even depends on shdocvw, in ReactOS this class is self contained.
CCommonBrowser: This is the shared component between the file explorer and internet explorer in windows. We follow a flat design of the CShellBrowser instead. This won't be implemented.
CExplorerBand: Originally in shdocvw but implemented in browseui to avoid any senseless dependency. Its implementation doesn't use the same helper classes which among others implement INSCTree. We opted for a completely flat design. Besides that it should be feature complete.
The components implement a com based support for work item objects.
Misc components. I'm not sure what most of them are for or if we need them
COrderList (called OrderListExport in the registry and CLSID_OrderListExport in the inf file)