Re: Wonderful ProDOS patch!

[zcaa1122@rpool3.rus.uni-stuttgart.de (Wulf Hofbauer)]

In article <KAPFFER.94Jan11151719@uaimzi.zdv.uni-mainz.de>,
Matthias & <kapffer@Informatik.Mathematik.Uni-Mainz.DE> wrote:
>In article <2grk7i$1nvg@info2.rus.uni-stuttgart.de> zcaa1122@rpool2.rus.uni-stuttgart.de (Wulf Hofbauer) writes:
>
>[...]
>   CP/M is even more primitive than Apple DOS, but has a better machine
>   language interface. [...]
>
>No. Apple DOS 3.x consists of three modules, each with its own calling
>interface and each built on top of the layer beneath it: The RWTS
>(Read or Write a Track & Sector) containes the hardware drivers for
>the (Disk II) disk drives, as its name implied. The File Manager
>implements all the operations on files, managing the file system on
>the drives and offers this functionality through a rich machine
>language interface, which is superior to the one in CP/M (IMHO). The
>third layer is the BASIC filing interface, also known as the Control-D
>Interpreter, since it handles all the DOS commands on input or PRINTed
>after an initial Ctrl-D and maps them onto appropriate File Manager
>calls.

Alas, the File Manager isn't documented at all in the DOS manual, so I
guess it's not legal to call it. Also, the FM is not cleanly seperated
from the command parser (ctrl-D interface) - it evaluates at least one
variable in the parser on an error.

To read the directory, you have to make low-level RWTS calls or use the
FM catalog routine, redirecting its output to your own routine. The first
is cumbersome if done correctly, and the latter is a clumsy approach.

It is possible to use the ctrl-D interface from machine language programs,
but in this case you'll have to fake several zero page variables and patch
the error handler vectors of DOS (which are - to my knowledge - not documented
by Apple). Not quite clean, either.

I know, most of what I call "undocumented" is documented. I'm reluctant to
use routines not officially documented by Apple, however. I've seen to much
Apple ][ and ][+ programs not running on other machines because they use
routines internal to the monitor, for example.

Also, DOS is what it says - a disk operating system, but not a real operating
system. For example, character oriented I/O is not part of DOS, so application
programs have to call monitor routines directly or even implement their own
drivers which cause many compatibility problems on different machines. SOS
offered character device support, but ProDOS doesn't either (this is the point
I like least about ProDOS).

Admittedly, CP/M file operations are primitive, but they are officially
documented and usable. Look at the application programs running under CP/M.
Most serious applications I've seen for DOS blindly patch DOS in memory, often
requiring to reboot the machine on termination.

Having written this, I must say that I don't like CP/M at all ;-). But DOS
was conceived as a BASIC extension to access the disk drives and was always
tied to Applesoft or Integer Basic which made it very difficult to write
non-Basic programs. ProDOS is much better (though there are still some
irregularities that don't make sense to me, like not returning the EOF on a
get_file_info call). ProDOS is still the best 8-bit DOS I've had the
opportunity to work with: it is structured cleanly, and offers quite orthogonal
fundamental operations. I never had to think about calling the device drivers,
for example - you don't need to bypass the file system.

- Wulf

-- 
 ______________________________________________________
|                                                      |
| Wulf Hofbauer | zcaa1122@rpool1.rus.uni-stuttgart.de |
|                                                      |