Extending the user shell was always for the benefit of Microsoft first, and for the rest of us second. Companies who tried to add serious advanced functionality through that found out that they were not really welcome, even though in theory everything was object-oriented, loosely coupled, language-agnostic, yada yada. It probably was mainly a solution to decrease the amount of territory wars over code inside Microsoft, and let teams work independently without demanding synchronous fixes.

We shouldn't forget that half of the documentation on how everything should work was only released after anti-trust investigation and pressure from courts.

https://www.geoffchappell.com/studies/windows/shell/index.ht...

By that time, Windows had already switched to shiny fresh undocumented technologies.

You should remember that a lot of software around the Millennium simply re-implemented latest fashion trends (Office controls, XP styles, etc.) on their own in not quite exact ways, not just because programmers back then wore skins, and ate raw meat, and feared nothing, and because such third party toolkits were available commercially, but also because official interfaces to do the same were not offered until later releases (or sometimes ever). I vaguely recall discussions of teams within Microsoft sometimes doing the same, resulting in Office controls sharing no code with common controls used by the rest of the system which look exactly the same.

The irony is that web browsers, being the most popular kind of application, and interfaces built on top of their technology simply ignore the native interface toolkits, and do everything independently, which is even more extreme than some old school custom paint handlers. A lot of work has been spent on re-implementing native look and behaviour there, multiple times.

One of the examples of actively supported applications interfacing with shell object hierarchy without using system dialogs I can name is Tixati, which needs to have file picker(s) at hand inside its own dialogs. It's not open source, but it has been using GTK, custom controls, and probably some sauce on top. Given the user complains about its performance or missing items, and regular appearance in change log over the years, I'd say it's a wrestling game for the author. At the moment the tree is lazily populated at the first appearance, which is fine, but not unnoticeable.

It is a bit hilarious that showing a list of file names in some directory is a trivial example on using system-provided iterators for the novice programmers, but adding icons matching those that Explorer shows (handling links and other special files, special directories, non-filesystem-based locations which still have files user might want to choose in them, etc) to that list suddenly becomes a nightmare.