MAX_PATH is the gift that keeps on giving. Thanks to Microsoft's fanatical dedication to compatibility I don't see how it will ever get fixed. I think they cou

MAX_PATH is the gift that keeps on giving. Thanks to Microsoft's fanatical dedication to compatibility I don't see how it will ever get fixed. I think they could take a lesson from Apple here and have DLLS/EXEs contain SDK versions against which they are built, then mandate that Windows 10 apps must support a larger MAX_PATH. Of course if they were into learning lessons, they'd have done fat binaries so a single install could easily support 64-bit and 32-bit (or a single DLL could contain 64-bit and 32-bit versions). For those not in the know, MAX_PATH and PATH_MAX (ugh) are defined in the Windows headers as 255. Because it was public people copied that constant and spread it around. So many apps and libraries out there are hard-coded to expect 255 that even if you change it in the Windows headers a million things will still be broken. Even if you overcame that limitation, you'd have a situation where paths no longer worked reliably if they got passed around (or worse, long paths would trigger buffer overflows in poorly written apps and drivers). You could fix it by passing apps not declared as large-path aware a shortened virtual path but the testing/edge case burden would be enormous. So this is an example of a really quick decision one programmer probably made by themselves many years ago that we are forced to live with because the pain of changing it is too great compared to the benefit we'd receive.