Re: [cc65] Apple2 Libraries - Current status of file io ?

On Thu, Jul 29, 2004 at 06:45:49AM -0400, jim wrote:
> errno.inc - additions:
> ENOTDIR        =    20    ; A component is not a directory

Can be mapped to ENOENT or EINVAL.

> EROFS        =    21    ; Read only file system & write requested

Can be mapped to EACCES.

> EBADF        =    22    ; fd not a valid file descp or not open for writing

Can be mapped to EINVAL.

The reason why I'm trying to keep the number of different error codes low is
because

  1. the strerrno function gets larger with each error code added, and

  2. for debugging, the system dependent error code can be checked which
     is available anyway, and describes the error better.

> I've checked the 2.10 version and seen that the SEEK codes are already
> there so that change doesn't need to be done.

2.10 is old already. When developing new stuff, you should have a look at the
current development snapshot, since this is the codebase on which new stuff
will finally running.

> Uz,  do you have any documentation on the new loadable modules and how
> it's supposed to work ?  Without such functionality I was thinking of
> having two Apple DOS libraries, however, with loadable modules it is
> possible to load just what is wanted from a developer point of view.

As I said before: You cannot load disk drivers as loadable modules. The most
prominent reason is that the modules are loaded from disk, and if you cannot
access the disk, because the module is missing, you cannot load said module
from the disk ...

There are several more reasons that make loadable modules not very attractive
for disk access:

  * Writing loadable modules in C has a high overhead, because the runtime is
    not shared between a program and the module.

  * Loadable modules cannot call application code or access application data
    easily. This means that you cannot set __oserror, __errno or whatever, and
    you cannot call any functions that are statically linked to the
    application.

  * Loadable modules cannot load or call other loadable modules, so you cannot
    "stack" them.

  * While the linker includes just includes the needed stuff when statically
    linking, with a loadable module, one does always get the whole module,
    even if part of it is not used. This means that loadable modules have a
    bigger memory footprint compared to statically linked code.

My suggestion would therefore be to forget loadable modules for your purpose.
They are nice, but the wrong tool in the given case.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.