Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Unix V7 functionality under (or along with) AmigaDOS?  (*LONG*)
Message-ID: <6389@cbmvax.UUCP>
Date: 23 Mar 89 23:10:15 GMT
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 66

In article <6367@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
> >        Yup.  Also, the rom code maybe holding a lock on a semaphore,
> >or using Forbid() locking on a system structure, etc.
>
>Ok...  (I thought the RKM said that Exec doesn't use semaphores itself?)

	Exec doesn't (currently).  Other system modules do.

> >        NOT good.  Better to implement your own libraries (gets you tracking
> >as well) that call the system libraries.  You don't want to break system
> >stuff that calls the library entry points.
>
>Yeah, I was/am leary of the idea...  The only problem I see of using
>my own libraries is you need to rely on the programmer to use them,
>and the programmer has to be more careful, with #includes and order of
>library linking.

	No, the _only_ thing he has to do is open amiga.foo.library instead
of foo.library.  Since all the offsets are the same, nothing else need be done,
and amigix.foo.library will get all calls that would otherwise go to
foo.library.

>What system stuff would/could break by calling the library entry
>points, and how exactly?  (WHY would they break?)

	If make any changes to the semantics of regular system libraries, 
other libraries that called them might well break (as well as a big
performance drop).

>Methinks there's quite a bit of undocumented features in LC5.0...  I
>was looking at the examples/avail.c program and the neat things it
>does with declaring "void __asm avail(register __a0 char *cmd)" to get
>the CLI command line without using any assembly startup code...  and
>later in the program, "void __regargs prbuf(char c)" (where c is
>passed in D0) and calling functions __builtin_getreg() and
>__builtin_putreg()...  all sorts of neat tricks I don't recall ever
>seeing documented...

	They're documented.  There are some new pages to the lattice manuals,
which cover some of the things you mention in more detail than in the original
manuals, call lattice support and ask about it.

>Also, is it legal to FreeMem a different sized block than you
>AllocMem()'d?  If so, how can you keep it from depending on the
>granularity of the memory allocators?

	Check the exec memory chapter.

>So Forbid/FreeMem/RemTask(0) would be the recommended way to do that
>particular deallocation?

	Sure, though you don't need to RemTask(), just return from your
startup code, and you'll get removed by the system.

>One other thing...  will there ever be absolute references to the
>stack segment (other than tc_SP*) or would it be legal (and safe) for
>a program to extend its stack by reallocating it, copying it and
>changing the few fixed pointers to it?

	All automatic variables (including pointers to automatic variables)
are on the stack.  You lose, sorry.

	int Foo() { int x; scanf("%d",&x); return x; }

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup