Subdirectories emulation in CP/M

[FloppySoftware]

Hello CP/M people!

I recently introduce myself in this forum, as a CP/M fan.

I like to start my posts here, asking a question that it's in my
head for the last weeks.

¿It's posible to emulate a directory tree in CP/M?

I'm working in that subject in order to build a "layer" between programs
and BDOS, and it not seems very dificult to do it with a simplified directory tree.

We have 16 user areas, and we can have 16 directories with a name.

We can connect (link) that user areas building an emulated directory tree, for
example:

C:/ (root - user 0)
|
+--- CC (user 1)--+--- LIB (user 2)
| |
| +--- EXAMPLES (user 4)
+--- WORDSTAR (user 5)
|
+--- SUPERCALC (user 6)

User areas 7 to 15 are available.

A more simple idea can be a root with 15 subdirectories:

C:/ (root - user 0)
|
+---- WORDSTAR (user 1)
|
+---- SUPERCALC (user 2)
|
+---- BACKUP (user 3)

Users 4 to 15 are available.

Or, a more simple idea is build 16 directories with no root.

If we have a root directory, we can have files and subdirectories (user areas) in it,
but it's more dificult to do (but I like it).

We can have a "path search" to execute commands (similar to setdef facility with drives), etc.

We can have some utilities as chdir, tree, rendir, etc.

The names for subdirectories can be in a configuration file, and standard CP/M
BDOS and programs will not know nothing about that subject (no compatibility
problems).

It can be done as a RSX, for example, with new BDOS functions that convert
new path files to older doing:

- Save current user.
- Set new user (directory in path)
- Do standard BDOS file function.
- Set old user.

A:/>TYPE C:/MYDOCS/APRIL.TXT

Look nice, it's'nt?

Yours,
Mike

 

[Chuck(G)]

Sure, and other CP/M "add-ons" have done similar things (and actually, more than 15 user areas are available--one only needs a very small patch to CP/M).

But in my mind, the big problem is that you're still limited to a fixed number of directory entries and that's a fundamental part of CP/M as directory entries also carry the allocation information. So as files grow in number and size (multiple extents) and as CP/M Plus time and date stamps are used, you run out of directory space even though your disk may not be anywhere near full.

You can redefine the disk parameters and increase the number of directory entries, but that takes a BIOS modification, which has its own problems. CP/M never thought to place the DPB values in any standard place (or anywhere at all) on the volume, so one can't simply read a label to figure out how the disk is laid out. So you sacrifice backward compatibility.

Second, as the number of allocated entries goes up, directory searches get longer and longer.

I suppose you could use a FAT-type filesystem to separate allocation information from file name information as an add-on. Oh, wait--that's been done--it's called "MS-DOS"...

 

[FloppySoftware]

Hello, Chuck.

Thanks for your answer.

I'm not talking about modifying CP/M in any sense. I'll try to explain it better.

I want to simulate directories. That's is: simulate.

How? Well, doing special tools like CHDIR, TREE, RENDIR and PWD.

The subdirectories names (and other data) will be in a configuration file (a regular CP/M file), nothing about write directory entries in disk.

For example, I need only 128 bytes (1 file record) to hold the names (16 user areas * 8 characters).

And for new programs, I'll need supporting routines in assembler, or maybe functions in C (or both), in order to support directories in file names.

For example, if I enter CHDIR SOURCES at CCP prompt, the code will search the name SOURCES in the configuration file, calculate the user number (if it's the 2nd entry, the user number is 1), and call BDOS in order to set it.

For PWD the behaviour is more simple: print the directory name in configuration file for current user number (shift on record = user number * 8).

TREE only prints all directory names for all user numbers in specified drive.

And so on.

I have another possibility: Because I have a SHELL program (a sort of CCP replacement) written in C by me (well, in my MESCC really), I can write the utilities as internal commands.

I know about named user areas in Z-SYSTEM, but it's not what I want.

And about MS-DOS... it's only for x86 systems. Nothing to do with 8080 / Z80. But my crazy idea can run in every 8 / 16 bit CP/M system with appropiate shared source code (maybe C?).

PD: I think CP/M 3 directory entries is a mess because compatibility with
previous versions, and because passwords and date fields. IMHO it was not a good idea add support for passwords in BDOS becasuse it's a very poor and slowly security system.

 

[Chuck(G)]

Sure, you can create any set of utilities to handle this however you want. But the issue for me (and with ZCPR) is that no program understands the scheme. So if you're going to copy a file using PIP, you still have to use the old syntax. If you want to edit a file that's not currently in the same user area that you're logged on to, you're stymied if you've already started the editor.

CP/M 3's extensions were actually an outgrowth of the first version of MP/M (which was buggy and a marketing flop). The need to time-stamp a file was getting to be pretty acute with more business applications being deployed. Since all the fields in a directory entry had already been claimed, the only solutions were to create a parallel directory with time and date stamps or use extra directory entries to encode them (sort of the way long file names are stored in a FAT filesystem).

A FAT filesystem on a CP/M base isn't as ridiculous as it sounds. Several CP/M emulators that run under DOS do a great job of masquerading the fact that there's a FAT filesystem underneath it all. Rewrite the CCP and to more resemble COMMAND.COM and you've got a much more up-to-date operating system.