Re: Long File Path support
"Yet other systems have had it a lot longer, without said issues..."
These other systems have issues of their own. For one thing, they almost certainly don't run <insert-important-and-private-internal-app-here>. If that's not important to you, go ahead and run other systems, but you can hardly blame Microsoft for supporting their existing customers.
Actually the registry hack isn't safe. For 25 years, MS have promised developers that a 260-character buffer will be able to accomodate an arbitrary path. If you quietly raise that limit, all that happens is that end-users suddenly find that the filename they type is not the one that actually gets used by the program. At best, that's a bug. At worst, it is a security hole.
As an alternative to the registry hack, where developers have taken the trouble to support longer paths safely they can advertise that in the program's manifest. Users will then get the benefit where it is safe and be protected with legacy behaviour where it would not be safe. (Please note, however, that if your program uses a standard file open or file save dialog, you are potentially hosting arbitrary Explorer extensions, so you can't honestly write that manifest entry.)
And on a completely different tangent, 260 characters is over three lines of text. If your paths are longer than this paragraph, I'd say you were using the filename to write a short abstract of the document contents, which is an abuse of the metadata.
Biting the hand that feeds IT
