Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pacbell!att!chinet!mcdchg!clyde!watmath!julian!uwovax!7103_300
From: 7103_300@uwovax.uwo.ca (Eric Smith)
Newsgroups: comp.sys.atari.st
Subject: Re: Many questions
Message-ID: <645@uwovax.uwo.ca>
Date: 2 Sep 88 01:15:25 GMT
References: <30@orbit.UUCP>
Lines: 56
Organisation: University of Western Ontario, Canada

In article <30@orbit.UUCP>, johno@pnet51.cts.com (John Ogawa) writes:
> ... But then I had major problems looking for a key
> combination from the desktop (anyone know why the Desktop ignores MU_KEYBD
> events?).  So, I decided to try and put a keyboard intercept in.  No go.  I
> have never messed with interrupt routines before, so I don't know what the
> problem is.  Right now, I can't even install a dummy routine.  I am replacing
> the routine that I find from Kbdvbase in the kb_kbdsys pointer.  I use Mark
> Williams' C, and the setrte routine (which saves registers) first, and then
> pass control to the original routine after finishing.  This always bombs out. 
Your best bet is to pass control to the original keyboard handler first, after
which you can check the keyboard input buffer for the desired keys.
> ... I am also wondering whether it is safe
> to use system calls (like Bconout) in an interrupt routine.
No, not unless you expand the size of the BIOS stack (the pointer to which is
located at 0x4a2). If you replace this with a pointer to a suitably large
area of your own (say, 1 or 2K) then you can use BIOS and XBIOS calls. GEMDOS
is another story, and making GEMDOS calls from inside of an interrupt is
basically impossible (unless you want to rewrite the GEMDOS trap dispatcher).
> ...  The second problem is with the desktop.inf reading.  Right now,
> short of reading it myself, the only way I can do this is to rename a file to
> desktop.inf, and then reboot.  Obviously this is a poor answer.  Is it the
> only answer though?

> John Ogawa

No, it isn't the only answer. The best way to change the desktop.inf settings
is to tell the desktop to do it for you. That's what the control panel does.
There are 2 AES calls to do this; shel_put and shel_get. The syntaxes are
as follows:

shel_get(buf, n)
char *buf; int n;
Get n bytes of data from the desktop's current desktop.inf values, and put
them in memory starting at 'buf'. A value of n=128 gets the whole thing, I
think.

shel_put(buf, n)
char *buf; inf n;
Put n bytes of data, pointed to by 'buf', into the desktop's copy of
desktop.inf. A value of n=128 puts a whole new copy of desktop.inf in there.
When the user next selects 'Save Desktop' from appropriate menu, then this
information will be used to create (or re-create) the file desktop.inf on disk.

One last note; the control panel apparently only does one 'shel_get' (when it
is first loaded) and hence won't recognize changes made by other accessories
unless you save the desktop and reboot. I guess Atari or DRI didn't 
expect anyone else to use these calls. They're also very poorly documented,
at least in the stuff available to poor 'unregistered developer' slobs like
myself! So I can make no guarantees about the above information, but it
seems to work (a friend and I wrote a replacement VT52 emulator acc. and used
these calls to communicate with the desktop).
--
Eric R. Smith                      email:
Dept. of Mathematics               7103_300@uwovax.uwo.ca
University of Western Ontario      7103_300@uwovax.bitnet
London, Ont. Canada N6A 5B7    (a shared mailbox: put my name on
ph: (519) 661-3638              the Subj: line, please!)