Well, I think you let applications developers off the hook too easily.
But then again, being a kernel level developer, perhaps I’m just grumpy
because *I* have to handle every single one of these cases, which
includes writing test code to validate them, so I must admit, I have a
tough time swallowing the assertion that they “have no choice”.
I will certainly agree that “someone” (the owner of the library, no
doubt) has to step up to the plate and make this work right. Perhaps
the problem is that I’m used to being told “suck it up and deal with it”
when I find some obscure feature of NTFS/FAT/CDFS/UDFS/RDR2/NWRDR/NFS
that doesn’t work in a rational fashion.
As to the last point, I’m honestly not quite sure what it means. WHICH
OS defined constant? It seems to me that the problem is the OS defines
at least three different constants that could apply here. The
application writer chose one of those three (the most restrictive) and
has never revisited that decision. Of course, there’s a separate
question of why not just increase the value of the manifest constant -
it will likely break some applications, but only when we recompile them
and not in any way they aren’t already broken (e.g., applications that
can’t look at a deep path, or a file name with embedded null characters)
anyway.
The problem with never accepting that things have to change is that it
means we can never really fix the user experience, can we? And then I
would ask “if we break the user experience in order to preserve
application compatibility, are we really applying the correct metric to
this decision?”
Alas, I fear there’s no “one size fits all” answer for this problem.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com