CPCWiki forum

General Category => Applications => Topic started by: m_dr_m on 15:41, 06 June 21

Title: File tools: even jobs.
Post by: m_dr_m on 15:41, 06 June 21

So, the CPC scene failed at unified DOS support! Well UniDOS aims at that, but for some it looks like:


(https://imgs.xkcd.com/comics/standards.png)


May we have at least one common set of files utilities RSX, using common dos RSX?
A file-copy routine shouldn't have to be bound to any particular DOS (*), and would perfectly sit in a stand-alone ROM, even with just AMSDOS installed.


|cp,"*.o","toto:"  should go through all .o files in current drive+directory, and write them to "toto:" drive.


Not so fast! Several obstacles:
- No unified way of iterating through a directory (workaround: DISC_CATALOGUE + expecting the buffer is filled in Amsdos compatible format).
- No unified paths (root is "/" for most, ":" for unidos. Parent is ".." for most, "/" for unidos). By the way, @OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826)  why is that? I believe compatibility with existing software on CPC would have been more important than compatibility with Amiga...
- No unified to get/set current drive and current path.


So maybe we could agree on those "API" first, by discussing rather than introducing a 17th DOS. Each DOS could keep their own idiosyncrasies, but add common language.


(*) one exception would be for extra fast copies, interleaving read and write access when possible.
Title: Re: File tools: even jobs.
Post by: Targhan on 15:59, 06 June 21
Once you chosen the best DOS *for you*, it becomes your standard. Asking all the DOSes to submit to one standard will never happen (I'm not sure it is a bad thing). How many times a year are you switching from one to another?

Personally, I use UniDos, it is standard to me.
Title: Re: File tools: even jobs.
Post by: eto on 17:00, 06 June 21
Asking all the DOSes to submit to one standard

How many actively developed DOSes are out there?
Title: Re: File tools: even jobs.
Post by: GUNHED on 21:21, 07 June 21
Yeah great idea in principle...

But why !CP and all that? It's new, incompatible stuff.

If you wanna have one standart, then please keep up with software being released first.
So for example, it's !COPY,"ud:filename.ext","destination". Where u is user and d is drive/partition letter.

Have a look at X-DDOS 2.10, VDOS and other glorious DOS being the first and trailblazers for CPC.
Title: Re: File tools: even jobs.
Post by: Audronic on 02:39, 08 June 21
Yeah great idea in principle...

Have a look at X-DDOS 2.11, VDOS and other glorious DOS being the first and trailblazers for CPC.
I cannot find a copy of X-DDOS 2.11 The latest I can find is 2.10
Do you have a link or drop a copy here Thanks
Keep Safe
Ray
Title: Re: File tools: even jobs.
Post by: GUNHED on 04:54, 08 June 21
I cannot find a copy of X-DDOS 2.11 The latest I can find is 2.10
Do you have a link or drop a copy here Thanks
Keep Safe
Ray
Yes, 2.10 was the last release. Just a typo. I'll correct it.
Title: Re: File tools: even jobs.
Post by: Audronic on 04:59, 08 June 21
@GUNHED (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2029)


Ok Thanks


Keep Safe
Ray
Title: Re: File tools: even jobs.
Post by: OffseT on 13:29, 08 June 21
A file-copy routine shouldn't have to be bound to any particular DOS (*), and would perfectly sit in a stand-alone ROM, even with just AMSDOS installed.
That's actually the case of the |COPY from UniDOS. It relies on CAS APIs and works the same on AMSDOS and UniDOS. It could easily be extracted from the main ROM.

- No unified way of iterating through a directory (workaround: DISC_CATALOGUE + expecting the buffer is filled in Amsdos compatible format).
That's what I did. UniDOS creates an AMSDOS-compatible CAS_CATALOG buffer which allows big file size and directories. And since it was fully documented, ImpDOS is now also supporting this output format.

- No unified paths (root is "/" for most, ":" for unidos. Parent is ".." for most, "/" for unidos). By the way, @OffseT (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1826)  why is that? I believe compatibility with existing software on CPC would have been more important than compatibility with Amiga...


It has very little to do with Amiga compatibilty.


Root as "/" is consistent on UNIX systems because of its filesystem tree (all paths are "/drive/path").
On UniDOS where path are "drive:path", using "/" would not have been consistent. It fact the actual path is "[[user][drive]:][path]" where the user, the drive and the path are optional, and the fact that ":" used alone is the root of the current drive is the direct logical consequence. Everything is consistent.


Parent as ".." could have been used, but it introduced a new pattern and was two chars long. "/" had the advantage to be a char already used to form path. It is also used to identify directories (path ending with a / are explicit directories). So it was decided to use it so that "/" always refers to directories handling.


Also, UniDOS uses a single "." for the unamed streams, and using ".." which is similar for something totally different didn't sound like a good idea.


Finally, all of this was not decided for UniDOS itself, it was already used by the Tape2HD interface of ACE CPC Emulator about ten years ago. :)
Title: Re: File tools: even jobs.
Post by: m_dr_m on 18:26, 13 June 21
"/" had the advantage to be a char already used to form path.
That's a bug, not a feature! Same things should have the same name, different things should have different names.
The following could both be path to directory:
lib
lib/

A typically way to form a complete path is to join strings with '/' as separator. That would give for instance:
lib/math.o
lib//math.o

The latter, despite ugly, works perfectly in nunix and prevent all the programs which handle paths to have to deal with the same corner case.
With unidos, it would lead to parent directory, a surprising fact potentially hard to debug.

Title: Re: File tools: even jobs.
Post by: OffseT on 19:59, 13 June 21
A bug? No, there is no bug at all.


lib can be either a path to a directory or a file.
lib/ is a path to a directory.


lib/math.o can be either a path to a sub-directory "math.o" in the directory "lib" or to a file "math.o" in the directory "lib".
lib//math.o is actually equivalent to math.o (which could be written lib/../math.o on UNIX, lib\..\math.o on Windows).


You like it or not, there is no bug; that's the expected behavior on UniDOS.


Your argument about manually forming path is just a consequence of a wrong pratice. Applications should avoid manual path handling and always rely on DOS layer for this purpose (which is not yet fully provided by UniDOS, but it will). Other than that, you inherit applications original OS semantics (for instance, /DRIVE/path is not a regular path on drive on Windows, C:path is not valid on UNIX, and so on...).



UNIX is not the universal computer path. :)
(to my mind, it might actually be the worst)


Anyway, all of this is out of the scope, we are on Amstrad. :P
Title: Re: File tools: even jobs.
Post by: GUNHED on 16:51, 16 June 21
Somehow the situation is like in the late 80ies. The names are different, but the principle is the same.

Back the day I used X-DDOS, RDOS and V-DOS (plus few other stuff). Now some are compatible, some not.

Back the day I decided to do my own OS to support all existing hardware. The target was achieved, but later on more hardware came out and I run out of time to support everything.
Today it feels like we have a new piece of hardware every three weeks anyway.  :laugh:

Sadly the support for SymbOS and FutureOS is minimal. Well, they both have their advantages and disadvantages. What's about doing the things in a proper way and get a bunch of well coders together: For making a new OS instead of a DOS only.
We could take the strength of existing DOS and OS.

Now I'm curious about your opinions, even if I may not expect too much of excitement.
Title: Re: File tools: even jobs.
Post by: m_dr_m on 05:15, 25 June 21
A bug? No, there is no bug at all.
Not saying that UnIdOs is bugged (well, i also said that, but I was young and rebellious).
In my book, that is not the best design choice.

Applications should avoid manual path handling and always rely on DOS layer for this purpose
Sure, it's nice to hide complexity and propose a well designed API.
Yet, as a mathematician, I love patterns and isomorphisms (even if I don't proclaim that in my dating profile). Being able to be form paths by simple concatenation is a nice property. That's a bit sad to lose it.
Also, complexity is not hidden after all, more often than not we manipulate path by hand (that is, non-programmatically). Then we are likely to face ambiguity and confusion before this non-standard choice.

Finally, all of this was not decided for UniDOS itself, it was already used by the Tape2HD interface of ACE CPC Emulator about ten years ago.
Yep, an amiga program interfacing an amiga filesystem.
Title: Re: File tools: even jobs.
Post by: m_dr_m on 05:24, 25 June 21
Now I'm curious about your opinions, even if I may not expect too much of excitement.
Great idea. We gathered some ideas for ANA OroboroS project (kickass name),  @zhulien (https://www.cpcwiki.eu/forum/index.php?action=profile;u=58) already has done some design investigation for shared RAM and unified driver interface.
This could and should be done incrementally, to solve some concrete problems. For instance, Orgams already use RAM persistance (sources still available across reset, with checksum verification). But Parados drive-tool would trash the memory (destructive RAM check, what a pity). Common routines to get the RAM amount and reserve a bank would be a good start.

Would be happy to give some feedback **before** it's too late.
Title: Re: File tools: even jobs.
Post by: GUNHED on 16:22, 26 June 21
True. A common memory management is needed. Of course new software (like Orgams) could search / occupy / use expansion RAM starting from the upper end (&FF, &FE, &FD... &C4). That may save some data.

F.e. FutureOS does use a simple RAM management. An application can ask for 16 KB blocks, so things are done in 16 KB blocks. That's fine since even the small 512 KB expansion has 32 of that 16 KB blocks.
In addition there is a way, to reserve different sized chunks of a 16 KB block.

Haven't read of ANA before though, will take a look. 
Title: Re: File tools: even jobs.
Post by: m_dr_m on 20:37, 28 June 21
starting from the upper end (&FF, &FE, &FD... &C4).
Orgams does that for 6 years (:   Doesn't solve the trashy memory detection issue, by construction!

Bank allocation, two requirements I actually need:
* Possibility to allocate contiguous banks
* Possibility to allocate given a certain mask (e.g C7 would return one of  C7, CF, D7, ... F7, FF). So we can use C1 / C3 connection modes.
* Housekeeping data shouldn't be in each bank itself, so we can use the full 16kb.