steelie@pro-charlotte.cts.com (Jim Howard) (12/15/88)
Is there any quick and easy way to find a 68000 address from a BCPL filehandle, such as the one returned by the _LVOOpen dos.library call? I need to do some relative offsets and data copying directly into the file, and I can't really do it without this... The main reason I need to use it is for something like, Open file1 Open file2 read 50 bytes from file1 into file2 using the _LVOWrite function, by giving the routine the address of file1 instead of a "buffer" ... any help appreciated! /s UUCP: ....!crash!pro-charlotte!steelie | Pro-Charlotte - (704) 567-0029 ARPA: crash!pro-charlotte!steelie@nosc.mil| 300/1200/2400 baud 24 hrs/day INET: steelie@pro-charlotte.cts.com | Log in as "register"
usenet@ucbvax.BERKELEY.EDU (USENET News Administration) (12/16/88)
>a BCPL filehandle,
From: amorando@euler.uucp (Alexander R. Morando)
Path: euler!amorando
The obvious answer is multiply by 4, but I'm not sure that's what you want.
The file handles are actually private, and you and I are not supposed to
know about any of the fields used in them. Look at how lousy the stuff is
documented. Nothing beyond the structure itself.
It sounds like you want to copy from filehandle1 to filehandle2 without
using a temporary buffer, i.e. without doing a
Read(fh1,buffer,size);
Write(fh2,buffer,size);
I don't know if it is possible, and my gut reaction is don't try to get around
using the buffer. I can't even think of a reason why you would rather not
use a temporary buffer. Not enough memory? Use a smaller buffer, and wait
longer for the copy.
There is no reason to think that within the file handle is a buffer contain
-ing just the data you want. Most likely, what happens is when you do the
Read command, it goes to the disk and gets the data and uses your buffer as
the storage area. It isn't like it has its own buffer and it is just doing a
copy.
David Ashley
amorando@euler.berkeley.edu
P.S. Sketchy questions cause sketchy answers. Be more specific.
dillon@CLOUD9.BERKELEY.EDU (Matt Dillon) (12/17/88)
steelie@pro-charlotte.cts.com (Jim Howard) Writes:
:Is there any quick and easy way to find a 68000 address from
:a BCPL filehandle, such as the one returned by the
:_LVOOpen dos.library call? I need to do some relative
:offsets and data copying directly into the file, and I
:can't really do it without this... The main reason I need
:to use it is for something like,
:
:Open file1
:Open file2
:
:read 50 bytes from file1 into file2 using the _LVOWrite
:function, by giving the routine the address of file1
:instead of a "buffer" ...
:
:any help appreciated!
:/s
It can't be done. You have a file handle returned from some
Open() call. This is a BCPL pointer to a file handle. You shift
it left 2 to get a real pointer to a file handle structure.
Which contains various fields of which only two are really
used. One points to the handler process, and the other, fh_Arg1, is a
'private data pointer' that is that handler's notion of a handle on the
file. I.E. a RAM: disk might use this field to point to a memory structure.
A filesystem handler might use this field to point to a sector on the disk.
What this 'private data pointer' points to is not documented and
can't be documented because it is in the domain of the implementation of
that particular handler. The fh_Buf and other associated fields in the
file handle structure ARE NOT USED BY THE FILESYSTEM. These are BCPL
cludges for the DOS superstructure (argument passing to BCPL programs,
etc...). The only time the actual device driver has access to the file
handle structure is in the packets associated with an Open() call.
After that, the handler knows only about fh_Arg1.
----
Now, beyond that there is the fact that the filesystem probably
won't read the data into any internal buffers at all until you issue
the Read() call so even if you were to hack your way in to find where
its internal buffers are (a no-no in itself), the data would not be there.
-Matt