Scary Windows development stories
I’m currently reading a book about the evolution of Windows. One of the most interesting things I keep finding is how stupid some 3rd party application developers must have been…. for example, it seems to have been common practice that if you wanted your app to grab a particular Windows setting (let’s say the Fonts directory), instead of a quick MSDN search, which turns up both the SHGetFolderPath and SHGetKnownFolderPath functions (either of which is exactly what you want), these programmers fired up RegEdit and searched for the path of their own Fonts folder… the first key they found, they used as the parameter for a call to RegOpenKeyEx and they read the value that way.
To me, that is not only a frighteningly ignorant and dangerous way to develop software (you’re not going to discover caveats & usage notes by browsing RegEdit!) but of course this is not the supported way to do it (how could any sane developer think otherwise?), and of course that app would have broken immediately on any new of Windows had MS not added a compatibility shim to watch for that program checking that buggy key, and substituting in a quick call to obtain the real value…
This isn’t backyard programmers writing in VBA in Excel to accomplish some one-off business task, either.. it’s commercial software that did this, written by professional developers and sold to unsuspecting customers for big cash. Scary stuff.
The only question worth pondering here is: was this ‘grab something promising out of the Registry’ technique better or worse than just hard-coding “C:\Windows\Fonts\” into the application? (I’m not 100% sure but it seems very likely there’s a shim out there for programs that did that, too.)