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


On Thu, 7 Nov 96 08:05:36 GM Guy Harrison <test@swampd wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-

----- snip ----->> re: basepage pointer of OS


>Okay, let's call it p_run as that's what the compendium calls it.

Sure, I didn't know it had a proper symbol.


>>The various MagiX/MagiC versions also differ, but do use the modern header
>>format so that this causes no problem.
>
>Manipulating MagiC 2's p_run causes the system to lock. I expected 
>something bad to happen but there was no harm in trying!

Hmmm, that must be a bug specific to that version.  I can't remember if I
did try it that far back, but it certainly works on later versions though.
Not that this matters much since Andreas won't guarantee future versions.
Hopefully he will come through with the alternative, MagiC-specific method
he promised Peter.

Then we make a function using the appropriate method for current OS, so that
this is transparent to all programs that use this function.


>I've never had the opportunity (or desire) to try multitos.

I do not have any desire for that at all either, and I don't do it any more,
but while it was still supported (if that's the word) I naturally had to test
it and attempt to adapt programs to its requirements.
Many of those requirements are still valid, both for MagiC and for most of
the other AES replacements, so the time wasn't completely wasted.


>I thought it highly unlikely that I'd get away with changing p_run in 
>MagiC - even if it does start running the new process the registers 
>would all be wrong.

Oh, now I see !
You attempted to force a task switch by simply changing p_run and leave it
changed didn't you...?

That has never been legal on any system, and is something I never would do
or recommend.  If you try using it like I do instead, you'll probably find
that it does work in MagiC 2 as well as in the latter ones that I've tested.

The following example assumes that initialization code has found the address
of 'p_run', and stored this in a local pointer named 'p_run_p'.
The example allocates a RAM block to a TSR whose basepage address has been
found through a cookie and stored in the example programs local pointer 'tsr_p'.

----- example start -----
        move.l  p_run_p(pc),a0           ;a0 --> p_run
        move.l  (a0),-(sp)               ;push current p_run value
        move.l  tsr_p(pc),(a0)           ;force p_run --> TSR program
        gemdos  Malloc,#$4000            ;allocate 16K, then owned by TSR
        move.l  p_run_p(pc),a0           ;a0 --> p_run
        move.l	(sp)+,(a0)               ;restore original p_run value
        tst.l   d0                       ;test Malloc result
----- example end -----

This should work, so try this sort of thing instead.


>The only chance of it working would be if such a 
>change was the method MagiC used internally. ie on the next interrupt, 
>switch to process p_run. As it hung, it obviously doesn't which means 
>that the only solution is for each author to provide our function for 
>us, leaving us to write the standard Gem one.

Not really, since your way of using it seems incorrect, while I use my way
of doing it under both MagiC and single-TOS every day.

But we may have to implement three methods anyway, since Andreas said "No".


>Hopefully, Eric and Andreas will say that the Ovlexec theory is 
>possible. It only takes one of them to say it isn't or decline to 
>write the patches and the whole idea is shot for good. It is still 
>worth asking though.

Andreas did say no, but considered providing another method to achieve
ownership transfer, so we may still plan a function combining the methods
within a single interface.


>As for stating that changing the memory block owner is all that is 
>required, I dont know what I was thinking when I wrote it! It 
>obviously is not good enough. You could probably write directly into 
>the memory block header and change the owner anyway. I've not tried it 
>under MagiC but I bet it would work.

Very very dangerous stuff.

He abandoned the original RAM allocation scheme without looking back, when
he designed the current one for MagiC, and may do the same for the current
header structure if/when he thinks of a better one.

Direct patching of RAM blocks has always been (as it should) highly illegal.


>I've just seen Peter's post where he states Pexec(3) does posess child 
>attributes such as standard handles. Something more complex may be 
>needed. I hope not, the more complex the idea gets the less chance it 
>has of ever seeing the light of day.

Our basic needs do not involve those complexities.  If we stick to the type
of call outlined in my example above, but applied to either of the functions
Malloc, Mfree, and Pexec  we should have no problems, since the overlays
shouldn't use GEMDOS channels anyway, so we don't care who they inherit from.

Naturally the implementation will have to take into account the other methods
demanded by Andreas, and possibly also by Eric.


I've had a look at your OVLEXEC.ZIP and have the following comments:

NB: I know you didn't intend anything final, so take them as comments
    to clarify my views, rather than as criticism of your work.

1: I completely disagree with producing three separate patches, and making
   people have to switch to the appropriate one depending on system changes.
   The extra code for differences should not be much, and the correct code
   can be chosen at init such that no later runtime speed loss exists.
   And by dropping a single program into \AUTO\ installation is complete.
   IMHO this should be a pure ASM program for reasons of efficiency.


2: You appear to consider it OK to do a lot more than some simple ownership
   related operations in these calls, and I disagree with this too.
   It might be okay to do a few such operations in one go, but not to do any
   other system interaction.  Most especially not any AES or VDI stuff.
   Even GEMDOS I/O is likely to cause problems, and should be avoided in the
   'patched' state, which should always be exited ASAP.


3: The implementation of Ovlswitch as a separate function causes a large
   speed loss, as does the repeated use of Supexec, when ordinary bsr/jsr
   will do the same job if we stay in super mode instead.  These are only
   quick patches, so doing so should not have any bad effects on the system.
   Ovlswitch calls should be replaced by insertion of optimized inline code.


Note also that the routines Andreas mentioned as MagiC alternatives would
only allow pure changes of ownership, not any continued running with a
patched 'p_run' which I am certain that he would forbid.

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