[MiNT] Runtime AES application name change?
Standa Opichal
I assume this list to be the best place where to ask for this, so please
do not consider this as too heavy off-topic. ;)
Imagine we can have a scripting language that would be able to publish
e.g. a GEMScript commands. The GEMScript commands are sent via AES
messages (not very polish designe I know). But anyway... The application
is being found by appl_find( char appName[8] ) function. If I really have
such a scripting language that I would likely want to rename the scripting
AES application (lets say e.g. "FBASIC ") to something actually defined
by the script being interpreted (e.g. "NOTICE "). If this is possible
than we would be able to write scripts as GEMScript functionality serving
programs.
Is there any way how to do that? And if not could ve propose some AES
extension to let it be capable to do that? Would it be a nonharming
extension?
best regards
STan
Frank Naumann
> Is there any way how to do that? And if not could ve propose some AES
> extension to let it be capable to do that? Would it be a nonharming
> extension?
Do you mean changing the application entry in desktop menu?
Tschuess
...Frank
--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnau...@freemint.de
Standa Opichal
On Tue, 11 Feb 2003, Frank Naumann wrote:
> Hello!
>
> > Is there any way how to do that? And if not could ve propose some AES
> > extension to let it be capable to do that? Would it be a nonharming
> > extension?
>
> Do you mean changing the application entry in desktop menu?
No, I mean changing the application ID (char[8]) used to search for the
AES application ID by appl_find() call. The menu entry doesn't matter
here, but also would be a nice feature to let scripts change it too. ;)
E.g. When you are searching for the AES PID of the AV Server you do
something like (optimistic example - no error handling):
export AVSERVER="THING "
avID = appl_find( getenv( "AVSERVER" ) );
msg[0] = AV_INIT;
msg[1] = appId;
msg[2] = 0;
appl_write( avID, msg, 16 );
Konrad Kokoszkiewicz
> application is being found by appl_find( char appName[8] ) function.
> If I really have such a scripting language that I would likely want
> to rename the scripting AES application (lets say e.g. "FBASIC ") to
> something actually defined by the script being interpreted (e.g.
> "NOTICE "). If this is possible than we would be able to write
> scripts as GEMScript functionality serving programs.
>
> Is there any way how to do that? And if not could ve propose some AES
> extension to let it be capable to do that? Would it be a nonharming
> extension?
You can fork the script interpreter, register the child in GEM and give it
any name you want. Using fork() with GEM is difficult for principal reasons,
but it can be done with special libraries. You can also use tfork() (a
combination of Pexec(7) and Pexec(104)), but it wouldn't make it easier.
CVV
--
Konrad M.Kokoszkiewicz
http://draco.atari.org
** Ea natura multitudinis est,
** aut seruit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy.
Standa Opichal
On Wed, 12 Feb 2003, Konrad Kokoszkiewicz wrote:
> You can fork the script interpreter, register the child in GEM and give it
> any name you want. Using fork() with GEM is difficult for principal reasons,
> but it can be done with special libraries.
Do you mean the mt_aes? The new gemlib (the merge with mgemlib beeing
currently done) will have this ability.
But how to actually set the name of the child process? Could you point
me to some example code?
> You can also use tfork() (a combination of Pexec(7) and Pexec(104)),
> but it wouldn't make it easier.
tfork()?
From the sources and their documentation it seems like 'create a thread'.
Real threads under MiNT (no process?)? This would be a good 'news' for
me. Could you explain more about tfork() and possible real thread
implementation?
I would rather stick to the fork() and mt_aes instead for my purpose.
best regards
STan
Konrad Kokoszkiewicz
>> give it any name you want. Using fork() with GEM is difficult for
>> principal reasons, but it can be done with special libraries.
>
> Do you mean the mt_aes? The new gemlib (the merge with mgemlib beeing
> currently done) will have this ability.
I think this may be the mt_aes, yes. I actually used own libraries for
playing with that, but mt_aes will be fine I think.
> But how to actually set the name of the child process? Could you point
> me to some example code?
Do you mean the name for a GEMDOS process (displayable with 'ps') or rather
the name for an AES process?
When you use fork(), there is no way of changing the name I can think of.
Perhaps someone else could remind the method.
When you create the child with Pexec(7)/Pexec(104), the name of the newly
created process is passed as the second parameter of the Pexec(104), e.g.
Pexec(104, (char *)"foobar", basepage_ptr, 0L); starts new process with the
name "foobar" visible after you do "ps".
The names for the AES processes, either for the "Desk" menu or for the
appl_find()/appl_search() are set with menu_register(). The first argument
decides which of these names are changed. I don't have any manual handy ATM,
but I vaguely remember that the Atari's "TOS/MultiTOS release notes" should
contain the related information. And "The Atari compendium" should have it
as well (both under menu_register()).
>> You can also use tfork() (a combination of Pexec(7) and Pexec(104)),
>> but it wouldn't make it easier.
>
> tfork()?
>> From the sources and their documentation it seems like 'create a
>> thread'.
> Real threads under MiNT (no process?)?
No, the 'thread' the tfork() creates is a separate process.
Standa Opichal
On Thu, 13 Feb 2003, Konrad Kokoszkiewicz wrote:
> >> give it any name you want. Using fork() with GEM is difficult for
> >> principal reasons, but it can be done with special libraries.
> >
> > Do you mean the mt_aes? The new gemlib (the merge with mgemlib beeing
> > currently done) will have this ability.
>
> I think this may be the mt_aes, yes. I actually used own libraries for
> playing with that, but mt_aes will be fine I think.
Good.
> > But how to actually set the name of the child process? Could you point
> > me to some example code?
>
> Do you mean the name for a GEMDOS process (displayable with 'ps') or rather
> the name for an AES process?
I mean really the name of the AES process. Not the GEMDOS process name nor
the AES application name displayed in the 'Desk' menu.
e.g. in the Thing case:
'thing' = The GEMDOS process name (displayed by ps from EasyMiNT installation).
'Thing Desktop' = The AES application title (the 'Desk' menu entry).
'THING ' = The AES application name (the string you need to put to the
appl_find() to get the Thing's AES apID).
I need to change the 'THING ' one (the AES apName). I've just looked
into the XaAES. It creates this name from the u:/proc/ entry by appending
the spaces up to length of 8 (in the appl_init() call). So the only way
how to change this is to create the AES extension. I did not look into the
other strings above so far as I don't need them now.
> When you use fork(), there is no way of changing the name I can think of.
> Perhaps someone else could remind the method.
:(
> When you create the child with Pexec(7)/Pexec(104), the name of the newly
> created process is passed as the second parameter of the Pexec(104), e.g.
> Pexec(104, (char *)"foobar", basepage_ptr, 0L); starts new process with the
> name "foobar" visible after you do "ps".
This is not what I need, but might be useful otherwise.
> The names for the AES processes, either for the "Desk" menu or for the
> appl_find()/appl_search() are set with menu_register().
Not true.
best regards
STan
Petr Stehlik
> I need to change the 'THING ' one (the AES apName). I've just looked
> into the XaAES. It creates this name from the u:/proc/ entry
> So the only way how to change this is to create the AES extension.
> > Pexec(104, (char *)"foobar", basepage_ptr, 0L); starts new process with the
> > name "foobar" visible after you do "ps".
>
> This is not what I need, but might be useful otherwise.
IIUIC then this is exactly what you need since "foobar" in `ps` is the
/proc/ entry which in turn is used in appl_find.
Correct me if I am wrong.
Petr
Standa Opichal
The XaAES reads the /proc/ only in the appl_init() call....
Oh... OK so Pexec(104,"foobar",...) and that appl_init().
That would be it. Thanks for kiking me up Petr. ;)
regards
STan
PS: The other thing I wanted to discuss is the AES support of
long filenames (e.g. in the appl_find). Any proposals?
Petr Stehlik
> PS: The other thing I wanted to discuss is the AES support of
> long filenames (e.g. in the appl_find). Any proposals?
How is /proc/ itself dealing with long names? Can it handle say 200
chars long filename? Or is there some limitation?
--
Petr Stehlik <j...@sophics.cz>
Frank Naumann
> How is /proc/ itself dealing with long names? Can it handle say 200
> chars long filename? Or is there some limitation?
/proc strip down to 8+3.
Petr Stehlik
> Hello!
>
> > How is /proc/ itself dealing with long names? Can it handle say 200
> > chars long filename? Or is there some limitation?
>
> /proc strip down to 8+3.
Then extending AES for LFN in appl_find is impossible without changing
also the kernel. Good to know, it wouldn't be a wise idea, anyway.
Petr
Frank Naumann
> > > How is /proc/ itself dealing with long names? Can it handle say 200
> > > chars long filename? Or is there some limitation?
> >
> > /proc strip down to 8+3.
>
> Then extending AES for LFN in appl_find is impossible without changing
> also the kernel. Good to know, it wouldn't be a wise idea, anyway.
You can for sure use the much more powerful /kern filesystem (linux
compatible /proc). Extending /proc isn't really possible as the
compatibility will be lost.
Standa Opichal
I'm really sorry for wasting your time with this kind of ignorance. I
simply thought that I know AES API well enough.... and I don't. Yes, this
is exactly what I needed to do. Thank you very much for finding this for
me.
STan
On Fri, 14 Feb 2003, Konrad Kokoszkiewicz wrote:
> >>> The names for the AES processes, either for the "Desk" menu or for
> >>> the appl_find()/appl_search() are set with menu_register().
> >>
> >> Not true.
>
> I also wrote: "The first argument decides which of these names are changed."
>
> Today I found some time to download the TOS release notes, unpack it, read
> and make a test program. And, Standa, you simply didn't check the documents
> I was poiniting you to. TOS release notes say this about the first argument
> of the menu_register():
>
> me_rapid - The AES process identifier of the desk accessory or
> application. ... If this value equals -1, the
> me_rpstring will be used to replace the current
> accessory's process name.
>
> The accessory (or application) PROCESS NAME, it is said. And indeed:
>
> # include <stdio.h>
> # include "/usr/GEM/include/gem.h"
>
> int
> main()
> {
> short apid;
> short c2 = 0;
>
> apid = appl_init();
>
> menu_register(-1, "TOJA ");
>
> c2 = appl_find("TOJA ");
>
> printf("c2 %d\n", c2);
>
> return 0;
> }
>
> /* EOF */
>
> If you link this to an executable called 'foobar', and run, the appl_find()
> will return the apid, even if the search is done for the name 'TOJA '.
> Isn't this what you wanted?
>
> CVV
>
> --
> Konrad M.Kokoszkiewicz
> http://draco.atari.org
>
> ** Ea natura multitudinis est,
> ** aut seruit humiliter, aut superbe dominatur (Liv. XXIV,25)
> *************************************************************
> ** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
> ** albo bezczelnie sie panoszy.
>
> _______________________________________________
> Aranym mailing list
> Ara...@nightmare.sh.cvut.cz
> http://nightmare.sh.cvut.cz/cgi-bin/mailman/listinfo/aranym
>