U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (10/26/88)
The following is from the recently posted source of the PATH: handler,
Submitted by: Rico Mariani <rmariani@watmum.waterloo.edu>
#define FH struct FileHandle
#define PArg1 dospacket->dp_Arg1 /* oslt */
#define BTOC(x) BADDR(x) /* or something like that */
FH *p;
if (p = Open(buf1,PType)) {
bmov(BTOC(p),BTOC(PArg1),sizeof(FH));
FreeMem(BTOC(p),sizeof(FH)); /* <-- Note This */
}
else
error = IoErr();
Are you sure that you free all the memory here, i.e. that the
FileHandle was not DosAllocMem()ed (using Arp lingo)? And if so,
how did you know without disassembling the DOS and/or using
other questionable practices ? :-)
The proper way to do it is, of course, send your own hand-made
DOS packet to the proper handler, asking it to fill in the
FileHandle (PArg1) for you. In that case, you save yourself a
rendez-vous with one icky BPTR.
Now we are talking about PATH: anyway... did everybody see that the
code to be added to Matt's original RAM disk is fairly minimal??
I would like to suggest that code like this could be added to the
*normal* file system in a next release, using one of those protection
bits.
In fact, if you have the code for a search-path-file, you almost have
symbolic links. These are even slightly simpler.
Isn't there a lot of room left in the file header block? That space
could also be used in the future for some useful information.
Now a pseudo-announcement...
I have written a RDF: handler. That is a Raw DFx: interface: it turns
your floppy (or your hard disk) into a sequential stream of bytes
(just like Unix :-). You can (with some minor limitations) Zoo to it,
for example, and have a *real* 880K Zoo archive on a single floppy.
You can disassemble the boot block directly from the disk, or
just look at it using TYPE <RDF: OPT H, and so on, and so on.
It is currently being tested. Hopefully out soon.
(BTW: Guess what happens if you stick a 'raw Zoo archive' in the drive
while Workbench is running.....)
Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)->
Olaf.Seibert;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++ Let me tell you that I disclaim anything you care to name +++
--- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet ---
7167 BYTES FREE
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
(Yes: You get a disk icon with DF0:ZOO below it)dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/27/88)
U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) Writes:
:Now we are talking about PATH: anyway... did everybody see that the
:code to be added to Matt's original RAM disk is fairly minimal??
:I would like to suggest that code like this could be added to the
:*normal* file system in a next release, using one of those protection
:bits.
:In fact, if you have the code for a search-path-file, you almost have
:symbolic links. These are even slightly simpler.
:Isn't there a lot of room left in the file header block? That space
:could also be used in the future for some useful information.
I agree, softlinks are a must! I also like the directory
concentrator PATH: gives us ... all that needs to be added is a way
to be able to DIR it (and get *all* the directories).
For softlinks, it seems pretty obvious that the way to implement
them is to simply add a protection bit.
For sof links, the comment field would contain the path of the
link. This is relatively painless to implement and works along the same
lines as PATH: (but even easier!). I suppose one could use the file
contents as the link but this is very, very wastefull of time and space.
As an example, to make my Makefile's more independant I can always
write object files to the local directory 't' instead of T: or RAM: or VD0:..
this would be (A) A real directory if I want the objects to stick around on
my HD (survive resets), or (B) A softlink to RAM: or VD0: or whatever...
-Mattpeter@sugar.uu.net (Peter da Silva) (10/27/88)
Great! PATH:, RDF:, and soon an MS-DOS handler. The Amiga device system is beginning to bear really cool fruit. Now how about a CON: with a scrollbar so you can scroll back in your output? How about a CON: that takes ANSI-like escape sequences to program function keys, menus, and the title bar... How about a CON: that turns mouse clicks into escape sequences? Or cuts and pastes into the clipboard? Or... (raves off into the night) -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
pds@quintus.uucp (Peter Schachte) (10/28/88)
In article <8810261744.AA28807@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I agree, softlinks are a must! Absolutely. > For softlinks, it seems pretty obvious that the way to implement >them is to simply add a protection bit. I'm not so sure. Symbolic links could be implemented very simply as a generalization of a device. If an individual file could somehow specify that a particular device driver be used to read it, instead of the one we'd expect, then symbolic links would be easy. But so would lots of other, much more interesting things. We could write a zoo.device, which zoo files would declare as their device, and then we could do dir or list of them from the shell just as if they were directories. We could copy files into and out of them. All this controlled by the device driver. Another really neat use for this would be for keeping compressed files. An individual file could specify its driver as compress.device, and when the file is read, it would be uncompressed. So it would be possible to just say cc foo.c, where foo.c is such a compressed file, and as cc reads foo.c's bytes, it gets them uncompressed. Another use for this would be for files to keep track of their edit history, sort of like sccs, only better. You could just type the file and see the latest version. And writing to the file would automatically take the differences from the previous version and remember them. But a special program would know how to get back old versions. I think this generality would be REALLY useful. It may sound esoteric, but I expect you'd quickly find versions of compress.device showing up, and wouldn't it be nice to transparently keep 1.5 Meg on a single floppy that you don't update too often? Or to transparently keep histories of source code development with sccs.device? This would blow away what unix can do. -Peter Schachte "Clean water? I'm for clean water." pds@quintus.uucp -George Bush ..!sun!quintus!pds
shf@well.UUCP (Stuart H. Ferguson) (10/29/88)
It seems to me that the correct way to implement directory searches on a "PATH:" would be to merge all the directories in the path into one big directory space with instances of files occuring early in the path overriding instances later in the path. For example, if your path as defined by PATH:x consisted of the directories A and B and there were files both of name "file" in both directories, then the directory search applied to PATH:x would return the instance of "file" that an application would see if it searched for PATH:x/file, and ignore the other one. Food for thought. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@wso.Stanford.EDU)
billsey@agora.UUCP (Bill Seymour) (10/31/88)
From article <8810261438.AA14294@jade.berkeley.edu:, by U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert):
: Now a pseudo-announcement...
:
: I have written a RDF: handler. That is a Raw DFx: interface: it turns
: your floppy (or your hard disk) into a sequential stream of bytes
: (just like Unix :-). You can (with some minor limitations) Zoo to it,
: for example, and have a *real* 880K Zoo archive on a single floppy.
: You can disassemble the boot block directly from the disk, or
: just look at it using TYPE <RDF: OPT H, and so on, and so on.
: It is currently being tested. Hopefully out soon.
How well would this work on a tape drive, I wonder? No one out there
that I know of has a real tape device out, and this would certainly allow
me some use of my tape drive. The problem I see is that you would have no
support for multiple files on the media. (Or am I wrong there...)
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: +++ Let me tell you that I disclaim anything you care to name +++
: --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet ---
: 7167 BYTES FREE
: *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
--
-Bill Seymour ...tektronix!reed!percival!agora!billsey
...tektronix!sequent!blowpig!billsey
Creative Microsystems Northwest Amiga Group At Home Sometimes
(503) 684-9300 (503) 656-7393 BBS (503) 640-0842