Sender: nate AT cartsys DOT com
Message-ID: <364DEB3F.55571108@cartsys.com>
Date: Sat, 14 Nov 1998 12:42:39 -0800
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i486)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: djgpp file i/o
References: <72fdsa$ngi$1 AT news DOT metronet DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Felix wrote:
> 
> hi,
> i'm looking for a good way to do file i/o with djgpp...
> if you wanted to write it yourself, would you have to call the dos services
> almost like in real mode ? anyways, i think djgpp offers two versions - one
> with file descriptors and one is the C style one. which one is better ?
> i tried using the c functions, but they don't seem to work when i copy more
> than 30000 bytes (or sth like that, only works for very small files!!). it
> may be my fault, but maybe you have some hints on file IO with djgpp..

It is a bit complicated.  DJGPP provides several levels of file I/O,
each of which is (at least conceptually) built on the next.

* The ANSI C stream model.  This uses the `FILE *' cookie to keep track
of file state.  It's buffered, will do binary/text conversion (depending
on whether you give the "b" flag to `fopen'), and includes all the
formatted I/O routines (`printf', etc).  It's good for portability and
text files.  Uses functions like `fopen', `getc', `puts', etc.

* The Unix-style file descriptor model.  Uses small integers to
represent open files.  `open', `read', `write', and so on.  It also will
do text/binary conversion, unless O_BINARY is given to `open'.  It's
limited to block I/O.  Respects FSEXT (if you don't know, don't worry;
it probably doesn't matter).  Portable to Unix and other DOS compilers.

* `_open', `_read', etc.  Like the above, except without any
conversions.  Some functions need DOS-ish flag arguments instead of the
Unix-ish ones.  No FSEXT.  Portable to other DOS compilers.

* `_dos_open', `_dos_read', and so forth.  Do absolutely no conversion;
you must know about several DOS flags.  Not portable.

All, however, can deal with buffers of over 64K.

It's probably wise to use C streams for most things, including files
which you pick apart.  If you have a need for great efficiency and raw
data is fine, Unixy `read'/`write' may suit.  The lower levels aren't
very useful, and are very unportable.

But none have limits of any kind that are anywhere close to what you
describe.  The fault is probably in your program.  Please post a small
but complete example, along with what you expect it to do and what it
does.  (One common pitfall is the text/binary issue; read FAQ section
9.3.)
-- 

Nate Eldredge
nate AT cartsys DOT com