5 ms·

They broke it on day one. Basically we are stuck with a bad decision. It's a Win32 subsystem specific problem. Both NT and NTFS do not have this issue intern

They broke it on day one. Basically we are stuck with a bad decision. It's a Win32 subsystem specific problem. Both NT and NTFS do not have this issue internally. It's not backwards compatibility - it's just a turd.

archangel_one 15y ago
It is backwards compatibility, because there are a fantastic number of programs out there that simply allocate a MAX_PATH sized buffer and assume that a single file path has to fit into it. If MS simply changed things so that paths of 500 characters could be returned all those programs would fail.
- rbanffy 15y ago
  > all those programs would fail. And, hopefully, be rewritten. Or, you could have a new set of API calls without this limitation. This new API could also receive a version argument, so that calls to its present version would return present-style data, even if the then-current implementation were much smarter. It's so obvious, in fact, I wouldn't be surprised if they already did it.
  - ephemient 15y ago
    As said above, it's only Win32 that's broken. NT filenames (e.g. \\?\...) aren't limited by MAX_PATH.
    - rbanffy 15y ago
      How well documented is the NT kernel APIs? I remember reading the documentation is a little sparse (no first-hand experience)
      - btn 15y ago
        These aren't kernel APIs. In most cases, you can simply call the Unicode version of the same functions and prepend "\\?\".