Good article, but the critique of the shell is misplaced. Shell provides a universal and extensible way to browse anything that makes sense to browse as a file system, without resorting to drivers. Yes, there's overhead that comes with that, but it allows to plug new things into Explorer, without waiting for Microsoft to do anything about it.
Also, FWIW, GetOpenFileName [1] turns the spaghetti from the article into just few lines of code.
GetOpenFileName is mentioned in the article as being the deprecated API that opens the old common dialog boxes. The first sentence in the documentation you linked to says to use the new COM API instead.
Yes, and upon clicking to the new COM API page, you are presented with the 11-deep nested if() "Basic Usage" monstrosity whose screenshot is also in the article.
I bet a lot of programmers just said "lol no. 'deprecated' my arse." and stayed with GetOpenFileName, as I did. MS isn't going to break countless apps by removing it.
Nah, the Chicago shell was a rubbish implementation of a common (for the time) concept. I tried to use it and extend it back in the 90s. What a disaster.
Firstly, it used binary paths with a complex and opaque structure. In fact there was no way to build a parser for such paths because each component was effectively a serialised object provided by each shell extension.
Now, I'm partial to binary structures myself. But as the article notes, this meant you couldn't do basic things like access it from a command line, or copy and paste a path into a text document (like, say, a SCRIPT!). And of course no existing software that used normal file APIs could understand such paths because they were all built on the expectation that paths are strings. So basically your shell extension was browseable by nothing except Explorer.
In theory you could write COM objects that would embed into Explorer and make your custom shell folders browseable. But there was virtually no documentation on how to do this, and it was extremely easy to completely screw up your entire Windows install this way because isolation in Windows 9x wasn't that great. I managed to hose my Explorer on more than one occasion trying to make this work.
Even if you got it working, what that let you do is replace the entire file viewer screen. But what if you wanted to express your plugin as a set of more files and folders? Oh, well then you needed to do even more work to re-use the standard shell views. You didn't get it by default. And of course, again, no useful examples or docs of any sort ... all in a pre-StackOverflow era.
Also, FWIW, GetOpenFileName [1] turns the spaghetti from the article into just few lines of code.
[1] https://docs.microsoft.com/en-us/windows/desktop/api/commdlg...