For translation from long to short filename I think it should be possible to integrate seamlessly in most DOS2 calls. Even _PARSE (to my surprise) does not stop at spaces, so that too could just support it without breaking backwards compatibility.
For translation from wildcard / short filename to long filename I think a LFN-version of _FFIRST and _FNEXT (and _FNEW?) would be needed, adding a parameter pointing to a 255-byte buffer where they can fill in the long filename. Because of the way LFNs are stored, doing it via these calls seems the most efficient / logical to me (as it needs to scan the directory entries preceding the short filename to determine the long one).
Finally the deletion and renaming of long filenames should be handled, I think currently the directory gets polluted because only the 8.3 entry is removed and the preceding LFN-entries are not.
An example of how LFN in Nextor would be useful in VGMPlay is for M3U VGM playlist support. These are distributed with packs you download from VGMRips. However currently users can’t really use these playlists as-is on MSX because they contain long filenames.
To support this in VGMPlay I will _FOPEN the filename on each line of the playlist. People will need to create M3U files especially for MSX with only short filenames in them. However when Nextor supports LFNs, the M3U files distributed with the packs can be used as-is.
For translation from long to short filename I think it should be possible to integrate seamlessly in most DOS2 calls. Even _PARSE (to my surprise) does not stop at spaces, so that too could just support it without breaking backwards compatibility.
For translation from wildcard / short filename to long filename I think a LFN-version of _FFIRST and _FNEXT (and _FNEW?) would be needed, adding a parameter pointing to a 255-byte buffer where they can fill in the long filename. Because of the way LFNs are stored, doing it via these calls seems the most efficient / logical to me (as it needs to scan the directory entries preceding the short filename to determine the long one).
Finally the deletion and renaming of long filenames should be handled, I think currently the directory gets polluted because only the 8.3 entry is removed and the preceding LFN-entries are not.
An example of how LFN in Nextor would be useful in VGMPlay is for M3U VGM playlist support. These are distributed with packs you download from VGMRips. However currently users can’t really use these playlists as-is on MSX because they contain long filenames.
To support this in VGMPlay I will _FOPEN the filename on each line of the playlist. People will need to create M3U files especially for MSX with only short filenames in them. However when Nextor supports LFNs, the M3U files distributed with the packs can be used as-is.