ventsyv wrote:Well, the problem here is not that developers went and used the Shell Folders registry entry, it is that MS left in some half functioning piece of junk hack in their release code.
You didnt read the article. Microsoft had to leave those keys in for compatability with software that was already written. Those companies were told during the development of Windows that those keys would exist and when those plans changed the keys were left in so that four programs would continue to work until they could be updated.
And on top of that did not bother to document the fact that this was a hack that is not to be used.
If it's not documented then there is no guarantee that it will behave in a particular way. Thus, to make no guarantee that something should behave in a particular way, dont document it. Documenting the hack is guaranteeing that it will work in a particular way (namely, the hacked way).
If they put data in the registry they have to expect that people might be using it. If you don't want other people to touch those entries, don't publish them in the registry, use a private configuration file.
That is, very unfortunately, the practicle expectation that must exist but as I've explained that fact creates more work in maintainence which could have been used in innovation instead. Putting settings within configuration files wont fix the problem either since people will start grepping those instead.
The GUIDs that you provide are version specific. The new version of Office will have a different GUID and will cause you app to fail. Not to mention that MS recommends reading the GUIDs from the registry.http://support.microsoft.com/kb/832672
Yes, they are version specific. If there is a documented way of getting those GUIDs programmatically then that's awesome. If the GUIDs listed in your other KB articles are the same type of GUID listed in mine then yes, such a method exists and it is implicitly documented. However, it looks like they are GUIDs refering to different things: the one from my KB article refer to the MSI component while yours refer to the ProgID. I've verified on this machine that the MSI GUID for Excel is differnt from the ProgID GUID for Excel. You'll need to find a different method of finding the MSI component GUID for Excel and perhaps it is documented in some KB.
The app will be designated compatible with Office 11 and older, there should not be any reasonable expectation that it would work with newer versions of Excel.
There wont be for you, but there will be for users. Users expect everything to just work and they get angry at any or all parties involved when they do not.
I as the developer of the app, will check MS's documentation before their new version of Office ships to see if the compatability of my app has not been broken. If that's the case, I'll write a patch, or include support for that version of Office in the next version of my app.
If you arent diligent enough to do this you cause the problems listed above. Part of this diligence is making sure that all users have updated.