Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!tut.cis.ohio-state.edu!osu-cis!killer!texbell!tness1!sugar!peter
From: peter@sugar.uu.net (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Proposal for new DOS calls
Message-ID: <2973@sugar.uu.net>
Date: 9 Nov 88 12:35:24 GMT
References: <8811082053.AA26882@postgres.Berkeley.EDU>
Organization: Sugar Land Unix - Houston, TX
Lines: 51

In article <8811082053.AA26882@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
> 	I disagree ... I've tried that method.  It is not compatible and
> it doesn't work.

It seems to work in DTerm... (plug).

> Now, I suppose you CAN make it go to a different
> replyport, but a second problem exists:  You can't have more than one 
> pending packet for a given file handle for a given process.  Reason:
> Many device drivers can't handle it.  Specifically, the filesystem. 

This is a problem that needs to be addressed. It's not a fatal failure,
since I'd expect you'd want to use this to monitor multiple files. It'd
make it hard to do a write while you have a read outstanding, though. Can
you open the file (device) twice and get two handles on it?

> Finally, you have to keep track of ports and messages and pending messages
> and possibly other resources and free them yourself... they are far removed
> from the DOS domain because they do not go away automatically with Close().

This is the major part of the excersize... providing a library that gives you
the functionality of dos.library. Your "file handle" would be a pointer to
your DOS filehandle, message port, and pending message. You'd have to provide
some sort of locking. You'd have to provide a close routine that took care
of all this.

But you'd have to do much of this work to implement these extra DOS calls
anyway, wouldn't you?

> 	Doing things manually gives you less control and certainly
> is not simple in any sense of the word!

I do things manually in a couple of places in Browser, and it's not that hard.
It's harder to send a packet than call Rename, but it gives me more control...
I can specify a lock on the source *and* destination directories.

> Very much more difficult, I would say!

It's more difficult to write the library in the first place. I don't see how
it can be that hard for individual users to use it when it's written. Sure,
they'd have to call your Close and your Open and so on, but these routines
could be made transparent. Just link with your library ahead of the dos.library
stubs and even printf() would work. Build your sockets on top of this...

And if you do it cleverly enough you'd make it possible to do DOS stuff from
tasks!
-- 
		    Peter da Silva  `-_-'  peter@sugar.uu.net
		     Have you hugged  U  your wolf today?

	      Disclaimer: My typos are my own damn business.