To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: INETD                                                             


On Tue, 5 Nov 96 02:52:12 GM test@swampdog.demon.co.uk wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-
>>
>>Why do you say "$602C" when it can in fact be any other address ?
>
>It's just easier.

Ok, but it's a bit cryptic that way, and might mislead people into believing
that it really is a guaranteed constant, like the system variable addresses.
You don't really think it has the same value in Magic for example, do you ?

In case you do, I'd better add that I just checked the OS header in my system,
and it told me this basepage pointer currently resides at $2E96...

I suggest we use some symbolic name rather than a number to speak of this
pointer, such as "OS current basepage pointer" and abbreviate this to
something like: "OS_currbp_p".  (Unless another, official name exists.)


>>The correct way to find it is from the pointer at offset $28 in the OS
>>header found at the address indicated by _sysbase (system var $4F2).
>
>Except for tos < 1.2 where as you say below, this pointer doesn't 
>exist.

Right, but anybody with that old a TOS would have to update it anyway,
before he could expect any modern software to behave properly.

Even so, all programs using the extended headers should of course check for
versions < $0102 anyway, and use the old constants for such TOS.


>>Very old TOS have shorter headers, so a constant (if known) must be used
>>for their basepage pointer address (which exists in all TOS versions).
>
>$602C for all versions except spain which is $873C.

The various MagiX/MagiC versions also differ, but do use the modern header
format so that this causes no problem.


>>It may have been something else of course, since with MultiTOS only one
>>thing is certain..., every session will end with bombs.
>>(eg: Boot MultiTOS without autoAPPs or anything, then wait... it bombs!)
>
>Even without messing with the $602C pointer?

Look, sometimes I've booted the system practically 'barefoot', no ACC's or
anything suspicious at all, and it still can bomb in some simple desktop
operation.  But all in a highly inconsistent fashion of course, so you can
sometimes (rarely) work several hours without problems.

I've said it before and I'll say it again, that product was never finished.
What we've got is a bugridden prototype not even compatible with itself.
(Yes, I do mean that _literally_.)

Fortunately both nAES and Geneva are finished products capable of fulfilling
the promise made but never kept by MultiTOS.  Together with MiNT they both
achieve full and fairly bugfree multitasking similar to MagiC, though not
quite so fast.  (But they both remove ACC limitations which MagiC doesn't.)


>True. Again, an auto folder patch would be trivial for each author to 
>write, subsequent versions would naturally have the call embedded in 
>the code proper. It has only to call the task switching code with the 
>exception that a switch to a specific application be performed, but 
>see below.

I do not see any need for a dedicated function call to be implemented in
any OS.  All we need is their agreement that this type of handling is not
in violation of any OS rules, but a legal way of controlling GEMDOS.
If they all prefer to implement such a function it might still take some
time for them to agree on a common standard for it, so we would have to
go ahead with a free-standing implementation anyway.


>>Yes I agree that it would be nice to have some 'legal' way of using
>>this pointer, but I do not think that actually switching task is even
>>possible to do in this fashion.
>
>Actually, I see no need to implement a forced task switch. It could 
>easily be abused.

Oh, then we agree!
I must have misunderstood you earlier then.


>>AFAIK the current basepage value is mainly used in assignments of RAM
>>ownership, to allow cleanup on termination.  So, again AFAIK, this is
>>purely a GEMDOS process we're talking about, _not_ an AES process.
>
>Our needs can be catered for simply by the provision of a function 
>which allows the owner of a particular memory block to be changed.

That would be a bit limited I think, since this pointer also can affect
the other forms of ownership on the GEMDOS level of the system.
We have already (in DIALER) had problems with file ownership for example.


>>Pexec would be a bit tricky anyway, since the original value should be
>>restored ASAP after achieving the needed ownership transfer, and for a
>>Pexec 'RUN' call that requires a GEMDOS link to fix it.
>>Pexec 'LOAD' should work fine however.
>
>It should, invoking Pexec(4) would be where the problems would arise. 
>Until this is done, the Pexec(3) code has no "childlike" attibutes 
>that I am aware of.

I'm not so sure of that..., although Pexec(4,...) naturally should carry
most of it, since that in itself actually starts the child process.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
