by Michael S. Kaplan, published on 2007/03/16 14:11 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/16/1895610.aspx
Say what you want about MSLU (you might love it, you might hate it, you might have never even looked into it enough to have an opinion), one feature that it had quite overwhelmingly in its favor was that it did its best to make sure that you could write code that would work the same whether it as there or not.
There was an interesting problem that came up in the project early on -- the earliest builds were actually using the Visual C++ "Delay Load" functionality. Then Bryan Tuttle asked a question about this idea -- what if the developer was wanting to use delay load themselves for any of the myriad of functions that were not MSLU-wrapped but that were in the same DLLs? Since there was no mechanism for multiple, separate delay load handlers for the same binary, MSLU squatting on the handler would keep any other delay loading from happening.
Bryan was right here. In fact, right after that he had a conversation with Dan Spalding ("father of the linker") and between the two of them came up with the MSLU loader, which is a delay load solution I have mentioned previously which does not make developers choose between MSLU and their own delay loading desires. This model is definitely superior to one that forced a developer to pick and choose between incompatible features!
Now there are many cases when that does not happen. A good example is the way the resource editor plugs into VS via Visual Studio's rich extensibility model. Since it is handling events itself as a part of its integration, there is no documented way to extend its handling, which makes working around bugs like this one with RichEdit in Visual Studio much harder.
Perhaps it is unreasonable, this desire to have features that Microsoft creates not use extensibility hooks in ways that block further extensibility by developers.
But to be perfectly honest, in looking at what exists with the Visual Studio resource editor and what I would have shipped for MSLU were it not for the help of Dan and Bryan, it is hard for me to think of what happened with MSLU s anything but a powerful enabling feature and what happens with the resource editor to be a[n occasionally crippling] bug.
It is, to be frank, a superior model for providing solutions.
I'll mention additional examples of superior design plans in an upcoming post. :-)
This post brought to you by ဈ (U+1008, a.k.a. MYANMAR LETTER JHA)
referenced by