Re: encapsulating directory operations

"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message
news:20250521121507.235@kylheku.com...

I think that if you're making some self-contained solution that must
havce a hierarchical file system, and has to be in C90, then just
code up a filesystem that exists entirely within one file that
you can open for updating in binary mode using fopen("....", "r+b")
and within which you create all the needed structure.
>
Then you need not have a shred of anything system-specific
in your file code.

I already have exactly that.

My new OS - PDOS-generic - runs under what I call a
pseudobios. Basically exactly the same as UEFI, except
instead of a UEFI "Open" or whatever they use, I have
instead used fopen().

Other people have converted UEFI into Posix. I converted
it into C90 (others may have done that too).

Regardless - with that pseudobios (or whatever you want
to call it) in place, I have an OS that runs under that. The
OS is passed a parameter of the "boot disk", which it
does a callback to the pseudobios's exported fopen to open.

The pseudobios can in fact be a fairly simple C90 program -
an ordinary program running under Windows, Unix etc.

In which case PDOS-generic will do all its operations on
that simple flat file - as r+b - as you noted.

But on some pseudobioses it is instead a privileged program
because it is the actual UEFI BOOTX64.EFI or whatever.

And in that instance, although you can give it a flat file to
open, and it will happily constrain itself to that flat file, you
can ADDITIONALLY give it a "!BOOT" parameter
(this is something else that may or may not belong in a
C90+ standard).

If you do !BOOT, it will still do the exact same FAT32
operations, but it will do them over the entire boot disk.
ie it takes control of the "host" disk.

That can't be done when running on the pseudobios that
PdAndro (in the Google Play Store) presents though. For
two reasons. First, I don't have privilege, because I don't
rely on jailbreaking, and secondly, the host system is not
FAT32 as far as I am aware.

So that's all existing and proven on various systems, including
Windows. I even have it working to some extent on the mainframe
- to the point where you can do a "dir" under an MVS batch job.
But there is still a bug that is preventing file creation, which
someone else is tracking down currently.

And now I have added a 3rd option. If you pass PDOS-generic
a parameter of "-allbios", there is no boot disk to open, and
it will instead send every fopen() attempt to the pseudobios,
in the hope that the pseudobios has the ability to open individual
files (UEFI does, but a pseudobios layered on top of the
IBM PC BIOS would only likely be able to handle !BOOT).

And it is this 3rd option I am trying to get to work. I have already
proven it under Windows, where I was able to create a \DOS
directory on my Windows 10 machine. Android is a bit more
complicated, and I have asked a question about that here:

https://www.bttr-software.de/forum/board_entry.php?id=22595

I can lift that \DOS restriction in due course, but currently, even
on Windows, I cannot yet do a "dir". I am sending fopen requests
up to the pseudobios, but I am not sending "opendir" requests
up to the pseudobios, because "opendir" doesn't yet exist.

And that's the crossroad I am now at. I don't know whether
to add an opendir(), plus a mkdir() that differs from POSIX,
or use the folder routines from Jean-Marc, or some other
option. That's my question. And while answering the question,
give some consideration to the fact that there are other changes
that I think - in hindsight - should have ideally been formalized
by a C90+ committee - such as EBCDIC ESC.

I believe then, as now, there were a lot of people frustrated that
EBCDIC is even a consideration. Can't the damned thing just
die already? But I'm the opposite of that. I want to nurture
EBCDIC. It provides an abstraction too.

I'm not asking anyone to agree with me. I'm just after technical
analysis.

BFN. Paul.