Then last summer I read rumors that windows 10 would enable really long filenames by default in windows explorer, and sure enough after the windows 10 anniversary update (version 1607) everyone talks about the abolition of the 260 letter rule,
windows shell included apparently. All you need to do is set the system registry key value LongPathsEnabled to 1 (in HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) and Bob's your uncle. I am not sure how many non-microsoft programs (if we assume that their MS programs can live with it, TBC) can live with such a ground-breaking file naming change.
It gets worse for compatibility. Apparently windows 10 is turning 8.3 names (that used to exist in parallel with the "real" long names) off by default for any non-system partition you create (they still appear for C:\ for the time being). Quoting performance gains for dropping 8.3 names sounds reasonable, but the professed improvements only show in extremely large folders (who has one million files in any single folder?). And what about legacy programs? Combine huge file names without a short 8.3 alternative and you have guaranteed that 99% of the programs out there are stranded. There isn't even provision for an API to check if 8.3 names are disabled; you'd have to check registry keys like NtfsDisable8dot3NameCreation and for the usual setting you'd need admin privileges just to query the status on a volume using fsutil 8dot3name. Madness; they shouldn't have kicked poor Balmer out, the guy was a saint in retrospect <g>
I am certain that this drastic change will bite many MS shell departments as well. Old school drag drop with WM_DROPFILES and shell execution (cue %1 argument for open verbs), shell API like SHGetPathFromIDList, even shell data structures like SHCOLUMNDATA all come with MAX_PATH "disease". The constant is present in many MFC and ATL/WTL headers too — don't just look at your own source code. It will be a big knot to untangle.
Obviously now the die is cast, and I will have to sort out xplorer² with the new really long paths in a forthcoming version. But it is an unenviable task. A quick search for MAX_PATH in the source code finds it used in 326 places in various parts of the program. It is going to be a major and deep revision, frankly with little benefit for the average user. But that's developers' life, nasty, brutish and short
The old DOS command processor CMD.EXE doesn't want to know about huge paths either, but powershell is good for any depth!