D_DISK -- A POSIX-like DISK I/O library for non-Unix OSs

D_DISK.TXT, 30-Nov-1998

Copyright (C) 1998, Gregg Jennings

See D_DISK.HTM for the library specifications.
See NOTES.TXT for particulars about the source files.
See CHANGELOG.TXT for the latest changes.
See also my DISKLIB library documentation.

UPDATE 26-Feb-1999

    There is a major flaw in my implementation: the 'count' argument for
    'd_read' and 'd_write' indicate the _number of sectors_ rather than
    the Unix-like way of _number of bytes_. This means that I screwed up
    and Unix-like code will not be able to be ported via D_DISK to
    DOS/Windows. I will be fixing this.


I am in the process of converting D_DISK to use DISKLIB (see
http://www.diskwarez.com/disklib.htm for the source code). See
NOTES.TXT for more information.

DISKLIB is more up to date than the sub-directory files here, and
also has a more complete implementation for Windows. The test
applications here (see NOTES.TXT) have been proven for DOS and
Windows 98. The DJGPP version has also not been tested yet.

I will be updating D_DISK for Window 95/NT and DJGPP soon.


OVERVIEW

A filesystem is a terrible thing to waste.

To put it as simply as is possible: it would be nice to be able to
access disk drives in a similar manner on all operating systems within
a particular programming language. DUH! as a famous role-model once
put it.

System dependent proprieties makes this difficult at times, makes it
difficult to port programs from one OS to another.

The D_DISK library is a set of functions that match the POSIX file
I/O functions with which many operating systems can read and write
directly to the disk system of a non-POSIX OS; e.g. DOS and Windows.


WHY

To put it simply: because I develope for DOS and Windows; because I
have DOS and Windows.

There is no need to get into OS discussions here. Rather, let us just
say: why not have code portable to ALL operating systems? And if not
portable, how about at least similar?


THE CODE

Enough discussion, on to the code.

The library is like the POSIX functions (open, read, write, stat,
etc.), just with a 'd_' prefix to the function names and types.

One important deviation from operating systems that allow accessing
disks via open() and read(): the d_read() and d_write() functions in
this library uses the `count' argument as the number of sectors to
read or write, not the number of bytes. This may present problems to
people or programs from mother operating systems. It should not be
too difficult though, to convert d_read() and d_write() to handle
bytes (perhaps some buffering will increase efficiency as well).

Two things present incompatiblies with other implementations and
programs: integral type sizes and my lack of knowledge of other OSs.
This is why this package is being distributed as preliminary;
although quite complete and usable (albeit a bit limited), it will
change.

Here are the questionable:

In some places, the type 'size_t' might be a better choice than
'int'; however, the read and write functions, for example, use a
number of sectors as the count arguments, and an 'int' even on a
16-bit OS will hold a large enough value. So, stuff like that may
need some ironing out. (See also, LIMITATIONS below.)

What should make up 'struct d_stat' filled in by the d_dtat()
function? I chose 'long's for the member type only because that
was simplest, but the members of this function in similar
implemenations are all different as far as I can see (by looking
at Linux stuff for example). Not just the types but the member
names and how many there are. What I have put in 'struct d_stat'
are for FAT disks.

Also for the d_stat() function, all those funky typedefs and
file mode/type test macros are missing.

Errors

For error handling I opted to use 'd_errno', an 'int' (and not
a macro), and define my own 'D_' prefixed equates. It got just a
little bit too complicated to use the standard values and
definitions in <errno.h>.

Internals

The internal disk handle handling (sorry) is done using a singly
linked list which at times uses a linear search. It is small and
fast though (only if there will be thousands of opened disk
handles will the linear searching be detrimental). That code is
not heavily documented, it's just a simple linked list ala Knuth
but with a twist that I call a "gap first in, any out" approach
(I'll let you figure out what that means--I rather like the idea).


SOURCE CODE

You'll probably either like or hate the directory structure I
chose to hold the OS/Compiler specific files (see NOTES.TXT for
more information). Basically, the OS/Compiler functions are in
sub-directories. There is one important benefit to this strategy:
it limits the size and complexity of the sources immensely! The
lack of hundreds of #ifdef'd blocks is so nice! Did I say that
loud enough?

The disk I/O functions are no longer going to be updated! I am
converting D_DISK to use my DISKLIB library which is much more up
to date.


LIMITATIONS

The disk I/O functions are no longer going to be updated! I am
converting D_DISK to use my DISKLIB library which is much more up
to date. (Yes I repeat myself.)


THANK YOU FOR LISTENING

Gregg Jennings, 30-Nov-1998
http://www.diskwarez.com/d_disk.htm
http://www.diskwarez.com/disklib.htm
