LOAD ZX 40: "esxDOS - Portuguese Technology" - Miguel Guerreiro https://youtu.be/04XvWTR_Zu0

On a partially-related topic (as you suggested that someone could start tinkering with it), is the source code for esxDOS free / available?

esxDOS is closed source. Copyright is asserted on the boot screen, but the accompanying documentation contains the phrase "All rights perversed". There is no publicly available API, although the 0.8.5 API was leaked. I was hoping that I could use esxDOS as the OS for the ZX Spectrum SE, but all these issues and the long time between releases became very frustrating. That led me to reverse engineer the kernel of the divMMC version of esxDOS 0.8.5 and develop an open source OS based on it for my own use. Because I didn't want to step on Miguel's toes, no future esxDOS kernel features will ever be ported to it, and it will never support divIDE. Because it was reverse engineered, comments are limited and I doubt anyone other than Miguel would be able to add LFN support to it. If you want to have a look, the last source release is here: https://github.com/cheveron/unodos3

The disassembles you linked to were developed by Antonio Villena by working backwards from my reverse engineered kernel. Forwards engineering if you like. But they are incomplete. They still contain my code that is not part of esxDOS and I don't think they will build a working OS. Also these are for v0.8.5, and I believe things have moved on considerably in v0.8.7.

My understanding is that Miguel was planning to publish the API when it was no-longer subject to change.

Anyone interested in writing dot commands will find plenty of source code in the above repository.

Based on user feedback (there are no users) I am planning to develop my OS purely for the Chloe 280SE. Dr. Slump's NMI menu is tied very closely to esxDOS and so eventually my version of the OS is likely to diverge to the point that the Slump menu won't work. So I don't think I'm competing with esxDOS. However I have to retain a certain amount of Spectrum compatibility because my target platform is the ZX Uno, and those users want to be able to run Spectrum programs.

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.

Yes, I think thats the only meaningful thing: Use esxDOS as a startramp for an Browser-App which can display long file names and than pass the short name to esxDOS to open the wanted file. No need to do write-support. If someone really needs this, than he can do it with more powerful machines an there OS like ZX Next and his NextZXOS.

On a partially-related topic (as you suggested that someone could start tinkering with it), is the source code for esxDOS free / available?

I´m jumping in here into you discussion.

esxDOS is free, but as far as I know, there´s no official source or API available. However, disassembly and more infos like API-calls can be found here:

https://sourceforge.net/p/emuscriptoria … dosinc.asm
https://sourceforge.net/p/emuscriptoria … esxdos.asm

But please take attention to this notes from aowen: http://www.zxuno.com/forum/viewtopic.ph … =10#p13102

I hope, Miguel is not annoyed while i did posting the above links here. We have to accept he keeps his work as closed source. So he don´t have to discuss with other people about it. Maybe someday he feels it´s a good time to publish an official API. We should be pleased to have such talented programmers "on our Spectrum interest" who spending lots of their time for programming. There are only a few of them who get this far with hardware and software.

Also have a look at this: http://board.esxdos.org/viewtopic.php?pid=818#p818

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)

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.

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.

Or it will work as before?