Topic: LFN Support...
...is in progress
You are not logged in. Please login or register.
esxDOS BBS → News → LFN Support...
Awesome News!!!
Thanks!
Excellent! One of the most interesting features if you have many files.
Thanks
Great! Really great news!
Thank you!
Great News! Thank you !!!!!
Registred an login just to be able to say: THANKS! Been waiting with installing esxdos for years just because of this.. Now, I will finally do it (whenever it's released)=). Great news!
Neat!
Great news
So... will a new version of esxDOS be expected under our Christmas Tree this year?
So... will a new version of esxDOS be expected under our Christmas Tree this year?
I kind of doubt it. I'm parking all future development of SE Basic IV until the esxdos API is finalized. I am hoping it will support addressing system variables using only IY so I can give BASIC programmers an extra 7K of RAM to play with, but I put that request in months ago and haven't heard anything since.
Please, update status. Many people like got the the new picodivsd hoping ths shoul be fixed soon!!
Is there any roadmap ongoing or just tweaked screens to capure our attention?
If there is such beta, can be released to the community?
If development is stopped or delayed forever, have you corsidered to release ESXDOS source code so programmers can help to end this unfinished project?
Thanks in advance, hope to hear from you soon!!
I just heard that the updated NMI menu is available with LFN support, as some are already using it.
Anyone has a link to that (NMI.SYS)???
It would be a great update already, even if native LFN support still has to be completed.
Hi to everyone,
To put a stop to the rumours - there is no fully working version with LFN support - the code as it is has LFN-capable readdir (hence the screenshots above), but doesn't have LFN-capable open, so it's not useable yet. It will be ready when it's ready
Regards
Lodcoxis, any chance I can help with LFN? I have the implementation lying around for over a decade now, although I understand that there might be some specific ESXDOS-related issues that I'm not aware of. It's been a while since I last touched my Speccy but maybe I could contribute in some way.
Lodcoxis, any chance I can help with LFN? I have the implementation lying around for over a decade now, although I understand that there might be some specific ESXDOS-related issues that I'm not aware of. It's been a while since I last touched my Speccy but maybe I could contribute in some way.
Hi baze,
Sorry for the delay but I was abroad. Please send me an e-mail (I think you already have my address) - I'm not working on LFN code right now but it will come soon enough.
Regards,
lordcoxis
I hope that LFN support comes soon )
Great work, Miguel! You've achieved fantastic results so far, with esxDOS being chosen as the default firmware for ZX Spectrum Next's DivMMC!
Please make LFN support, the whole Next community relies on you
Great news LFN is in development. Is there any update on the progress please? This would be such a great feature to have.
This is kinda exciting news! :-)
Will API breaks after adding support of LFN?
Or it will work as before?
Hi to everyone,
To put a stop to the rumours - there is no fully working version with LFN support - the code as it is has LFN-capable readdir (hence the screenshots above), but doesn't have LFN-capable open, so it's not useable yet. It will be ready when it's ready
Regards
I think READONLY LFN (as readdir) would be enough to make most people satisfied. Does readdir not deliver the short name also to pass this to open? (this maybe a dump question from me).
Main reason for no LFN-support maybe the lack of memory I think?!
Even "no complete" LFN-support would be sufficient, e.g. support for 31 or 32 chars-long filenames is much better than 8.3 short names.
Even "no complete" LFN-support would be sufficient, e.g. support for 31 or 32 chars-long filenames is much better than 8.3 short names.
Or max file path limit to 255 bytes(including file name) - M$ Windows worked fine much time with this limits.
Isn't the LFN readonly not in any form linked/gotten from the same source the 8.3 file name is gotten from? You could even look back at the source and open from there, right? (it certainly is very hack-y and doesn't make for nice code, but if it works it works).
And the 255 bytes system also would work fine I imagine.
Or if you really can only open from a 8.3 file structure name, the 8.3 name only coming up with cursor over the name. And otherwise giving the read only name.
Really though, the lack of LFN really hinders me in using esxdos because nearly all files aren't in a 8.3 file system. And because the 8.3 files system on modern PC's have gone the way of the dinosaurs for a while now, it makes it all really hard to use with any volume of files as almost no files are natively in the 8.3 file format. (unless you really want to rename all files)
What folks need to remember is that even if esxDOS gets LFN support, the NMI menu isn't going to support it. There simply isn't enough RAM. Assuming no-one wants to use the OS functions of esxDOS with LFN (because no auto-complete), I'm guessing most of the demands for LFN are for people who want to turn their real hardware into an emulator and fast load their entire warez collection. There is already a solution for this. esxDOS offers low level access to the disk. So all that is required is for someone to write a browser application that reads the LFN names and then gets the SFN and passes it to the snapshot / tapeloader dot commands. That application could be loaded via the AUTOBOOT.BAS program. But of course someone with sufficient knowledge of FAT-32 would have to write the app.
Hi aowen, thanks for clarifying that for me, my expectation (since 2016 at least!) was that at some point the NMI browser would have supported Long File Names.
On a partially-related topic (as you suggested that someone could start tinkering with it), is the source code for esxDOS free / available?
esxDOS BBS → News → LFN Support...
Powered by PunBB, supported by Informer Technologies, Inc.