Pase@DOCKMASTER.ARPA (Bill Pase) (01/21/87)
Could someone send me info on the form used for calling pexec. I need the actual call, ie address, plus the expected arguments and return. Thanx in Advance. /bill
apratt@atari.UUCP (Allan Pratt) (01/22/87)
> Could someone send me info on the form used for calling pexec. I need > the actual call, ie address, plus the expected arguments and return. > Thanx in Advance. /bill I don't get it. "address"? OS calls on the ST don't have addresses. Where's your documentation? If you don't have any, why not? Forgive my presumption, but it seems possible that you have an illegal copy of Atari's or somebody else's compiler without the documentation. There is a mistake in Atari's (and therefore some other people's) documentation of the Pexec call (using function code 4), but I'm not about to tell you what it is. Please get legitimate. It's not even that expensive for some of the compilers out there. There is another possibility: you are writing assembly code with a PD assembler, and you haven't bought any of the books describing the ST's operating system. In that case, BTFM! (BTFM = please go purchase a book.) /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
pett@socrates.ucsf.edu (Eric Pettersen%CGL) (01/23/87)
In article <536@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> Could someone send me info on the form used for calling pexec. I need >> the actual call, ie address, plus the expected arguments and return. >> Thanx in Advance. /bill > >... > >There is another possibility: you are writing assembly code with a PD >assembler, and you haven't bought any of the books describing the ST's >operating system. In that case, BTFM! (BTFM = please go purchase a book.) > >/----------------------------------------------\ >| Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. >| reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt >\----------------------------------------------/ Gee, I bought $300 worth of documentation from Atari itself and it doesn't seem to have the correct method of invoking Pexec() in it. I still haven't figured it out. Presumeably, mode 4 (create basepage) would return a basepage address. Does the Atari documentation mention this? No. Once one has a basepage address how does one subsequently invoke Pexec() with this address and what other arguments are then used with the call? The Atari documentation doesn't say. Rumor has it that Mshrink() must be invoked to give the called process memory to execute in. Does the Atari documentation mention this? No. How does one calculate how much memory to keep in the invoking program and starting from what address? The Atari docs don't say. It seems a little ridiculous that after paying $300 for docs that I would have to pay X more dollars to either buy more docs or to get onto Compuserve to see the corrected docs. Is there some gratis method of getting the correct documentaion for Pexec(), Allan? Eric Pettersen UCSF Computer Graphics Lab ucbvax!ucsfcgl!pett
apratt@atari.UUCP (01/27/87)
> Is there some gratis method of getting the correct documentaion for Pexec(), > Allan? Yes. Use the Developer Support phone number provided in your documentation. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
fischer-michael@YALE.ARPA.UUCP (01/28/87)
> From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt) > > > Could someone send me info on the form used for calling pexec. I need > > the actual call, ie address, plus the expected arguments and return. > > Thanx in Advance. /bill > > I don't get it. "address"? OS calls on the ST don't have addresses. > Where's your documentation? If you don't have any, why not? > > Forgive my presumption, but it seems possible that you have an illegal > copy of Atari's or somebody else's compiler without the documentation. > There is a mistake in Atari's (and therefore some other people's) > documentation of the Pexec call (using function code 4), but I'm not > about to tell you what it is. Please get legitimate. It's not even > that expensive for some of the compilers out there. I can't believe this attitude! Someone asks for some information about how to use a system call on the ST. Instead of either ignoring the request or answering it, Allan Pratt says tough luck -- there's a bug in our documentation but I'm not going to tell you (or presumably anyone else out on the net) what it is because I don't believe you've bought our compiler. First of all, Allan's presumption is questionable. The guy might be trying to call GEMDOS from ST Basic or OSS Pascal, both of which provide hooks into the OS but don't describe the calls in their documentation. Second, what good is it going to do the guy to "get legitimate" if Atari's and other people's documentation is wrong anyway? I was not aware of the bug, nor have I had occasion to use Pexec yet. But I expect to soon, and I don't relish the thought of wasting hours of my time finding a bug in the documentation that Atari already knows about but won't tell me about. I have both the developer's kit and Mark Williams C. The MWC documentation is pretty good about correcting the bugs and filling in the omissions from Atari's documentation. I hope when I come to using Pexec that I will find the error corrected there since it looks like I can't expect any help from Atari on this one. By the way, we'd all like to know where our documentation is. We were promised an official Atari ST internals book by Christmas time last year, but like so many Atari promises, it never materialized, nor did we hear any explanation for the delay, nor when it would appear, nor even if it will still appear. What's the story? --Mike Fischer <fischer@yale.arpa> -------
KJBSF@slacvm.BITNET.UUCP (01/30/87)
Date: 29 January 87 22:58-PST From: KJBSF@SLACVM To: INFO-ATARI16@SCORE Subject: Re: Re: Pexec Date: 29 January 1987, 22:56:52 PST From: Kevin J. Burnett x3330 <KJBSF@SLACVM> To: <INFO-ATARI16@SCORE.STANFORD> Subject: Re: Re: Pexec Forwarded-from: KJBSF Alan Pratt writes: >I don't get it. "address"? OS calls on the ST don't have addresses. >Where's your documentation? If you don't have any, why not? > >Forgive my presumption, but it seems possible that you have an illegal >copy of Atari's or somebody else's compiler without the documentation. >There is a mistake in Atari's (and therefore some other people's) >documentation of the Pexec call (using function code 4), but I'm not >about to tell you what it is. Please get legitimate. It's not even >that expensive for some of the compilers out there. I think this is ridiculous. It's insulting. Who are you to presume that just because someone asks a rather basic question, he is instantly a 'software pirate'? I always cringe when I see comments like the ones above, as they go a long way to destroying the generall feeling of good will I have seen on this mailing list. Kevin J. Burnett KJBSF%SLACVM.BITNET@Forsythe.Stanford.EDU Santa Clara University '88
john@viper.UUCP (02/09/87)
Organization:
I am also more than a bit irritated with the current state of technical docs
available (or not-available) for the ST. The people responsible for marketing
must be living in another universe. How do they expect people to develop
code for a machine where the only documentation available either costs far
too much or is grossly(!!) inadequate???! The correct, factual information
for -ALL- the system calls, all known bugs, and all data structures used
should have been made available more than a year ago at a reasonable ( < $35 )
cost in a cleanly written reference manual with a decent index(!!). Come on
Atari... This isn't someone asking for a freebe. I'm just asking Atari to
sell a concise updated(!) reference so I'll have an even chance at
writing the kind of programs that will sell more ST's!
Please don't get me wrong, I really like the machine and it's capabilities,
but I'm sick and tired of beating my head against the wall trying to get
information about even simple things that don't work as-advertised.... There
is -NO- reason a developer should have to waste literaly days looking thru
hundreds of pages of contradictory information, trying this and that, to
get something to work...! (Mind you, -most- of the system functions do
exactly what they're suppost to and you don't have to dig to find out what
you need to know about them. It's that last 5-10% that's causing needless
frustration that's driving programmers crazy...)
----------------------------
The following is the correct (to the best of my knowledge anyway) EXEC call:
In assembly language:
move.l #env,-(sp) * environment string
move.l #tag,-(sp) * command tag
move.l #file,-(sp) * full program name.ext
move.w #0,-(sp) * load and go subfunction
move.w #4b,-(sp) * EXEC (Pexec) function
trap #1 * Trap-call GEMDOS to do the work
add.l #14,sp * clean-up stack afterwards
In C:
Pexec(0,file,tag,env);
or gemdos(0x4b,0,file,tag,env);
char file[] = "EMACS.PRG";
char tag[] = "\008FILE.TXT";
char env[] = "\0"; /* yes, the \0 -is- intentional... */
This assumes you have either assembly language access, or access to a C
compiler. In the instance Bill gave, he's using a language where I'm not
familiar with the constructs used to access GEMDOS calls, but it looks like
the order of parameters as well as the sizes of some of the parameters may
be incorrect.
The problem most peole have is with the tag parameter. This is the rest
of the command line after you've subtracted the leading program file name.
The thing not mentioned in 90% of the documentation is that the tag string
is a -PASCAL- style string, not C...! In the example I've given, you can
see I've added a single byte giving the number of characters to the start
of the string.
Unless you really need to, ignore the environment (env) string. There
are currently two distinctly incompatable formats being used for that
string. As long as you don't need them and you have a double-null
terminated string, it will work with programs written to either standard.
The file name itself must be the full filename plus extension. If you
want to run a program from another directory/folder or drive, you have
to include the drive and/or path designation because GEM doesn't support
search PATHs.
Hope this helps, please let me know if you have additional questions...neil@atari.UUCP (02/24/87)
In article <507@viper.UUCP>, john@viper.UUCP (John Stanley) writes: > I am also more than a bit irritated with the current state of technical docs > available (or not-available) for the ST. The people responsible for > marketing must be living in another universe. We are living in the same universe you are. So is the documentation department. However, the docs in question are in the hands of the software endineering department and an outside writing group, and they are just taking a long time to get finished. This is meant to in no way cast aspersions on anyone, just giving credit where it is due :-) -- --->Neil @ Atari ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil BIX: neilharris CIS: 70007,1135 Delphi: NEILHARRIS GENIE: nharris WELL: neil Atari Corp. BBS 408-745-5308
john@viper.UUCP (02/25/87)
In article <565@atari.UUCP> neil@atari.UUCP (Neil Harris) writes: > >We are living in the same universe you are. So is the documentation >department. However, the docs in question are in the hands of the software >endineering department and an outside writing group, and they are just >taking a long time to get finished. > Neil, Thank you for your response. I'm glad, no, make that "overjoyed", to hear that something is being done to correct this unfortunate situation. Can you give us a (teeny tiny) hint as to what the current schedule says about a release date and price of this/these(?) documents? I'm sorry I've been doing more than my share of flaming at Atari lately. I suspect(hope) that most of the things I was bitching about are things Atari has plans to correct in the not too distant future. I'm just very emotionaly drained from all the problems and all the support I -personaly- have had to provide people in my area just because Atari hasn't been keeping up with the information needs of people. When a week goes by without my receiving frantic phone calls asking questions, that's when I'll feel that Atari has provided what is needed to make the ST the really great machine I know it can be. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
rowley@ORVILLE.ARPA.UUCP (02/26/87)
In Info-Atari16 Digest, Volume 87 : Issue 92, imagen!turner@ucbvax.Berkeley.EDU (James Turner) writes: > > no necessarily so, i just got an excellant book on the ST, It has > everything in the dev ket doc's including the shell lib in a clear > concise format. It is called > > The Concise Atari ST 68000 Programmer's Reference Guide > by Katherine Peel > I looked this book over. Each function is described in one or two short sentences, and a list of parameters is given. I don't think that the descriptions are adequate in many cases, unless you have lots of time to write and play with sample programs. >> >> P.S. Neil@atari, Jack@atari, others -- where is the documentation that can >> be purchased without paying $300? > >between this book and Abacus (typos and all) books i think this is a >dead issue. For about $20 you can get all the info in the dev kit. > No, this issue is alive and kicking. We are still waiting for some complete and detailed GEM documentation that doesn't come as a box full of paper. Karl Rowley rowley@orville.arpa "It's OK to live in a one-horse town as long as you are the horse."
HAHN_K@DMRHRZ11.BITNET (07/16/87)
Is there anybody in NETland who could provide me with a somewhat complete description of 'long Pexec(a,b,c,d)' ??? I understand that the first parameter can be 0 (i.e. load'n'go) or 3 (i.e. just load and return the basepage's address), but some rumours i heard claimed that there's a possibility to set it to 4 (i.e. take the basepage's address and execute the 'child') and even to five (perhaps that means 'disconnect the drive and rewrite the ROMs' or something else...)! I need to load a child-process (maybe two of them) and execute it/them some time later, but all the time they have to remain in memory, because they are incorporating interrupt-routines. So; what could Pexec() do for me? I'm sure you know. Thanks to all who reply. Klaus. -- Klaus Hahn -- Department of Psychology Gutenbergstr. 18 University of MARBURG D-3550 Marburg, West-Germany <HAHN_K@DMRHRZ11.bitnet>
rowley@ORVILLE.ARPA (Karl Rowley) (08/25/87)
I wrote a desk accessory that brings up a file selector box, and then Pexec's the selected file. I set the screen to a new area in memory before doing the Pexec, and return to the old screen when done. This seems to work fine for programs that don't use GEM. When a GEM application is run from the desk acessory things get really strange. The menu bar for the GEM application gets installed, but the GEM desktop responds to the menu items that are selected. Rebooting is sometimes the only way to straighten things out when a GEM application is run from the desk accessory. Anyway, desk accessories seem to be able to call Pexec just fine, but GEM gets messed up badly if a desk accessory Pexec's a GEM application. I have also tried out the shel_write function. It appears to be not much more than a bells-and-whistles function that calls Pexec. The MWC documentation for shel_write is not very complete. Can anyone shed any light on what this function does besides clearing the screen, and setting the mouse and text cursor? Karl Rowley rowley@orville.nas.nasa.gov
koreth@ssyx.ucsc.edu (Steven Grimm) (09/10/87)
Can anyone give me information about the innards of Pexec()? I have the
following program...
#include <osbind.h>
main()
{
long basepage;
basepage = Pexec(3, "test.tos", "", 0L);
printf("basepage = %08lx\n", basepage);
Pexec(4, 0L, 0L, basepage);
printf("done\n");
}
(test.tos is a single printf statement.) The Pexec(4,...) bombs. I've tried
putting the "basepage" parameter in each of Pexec()'s parameter positions,
with the same results all the time. Jumping directly to the text segment
bombs, too. What do I need to set up before executing a program? I'd hate
to have to waste time writing my own memory management and process management
system, but if necessary I'll do it.
-------------------------------------
Steven Grimm, koreth@ucscb.ucsc.edu
koreth@ssyx.ucsc.edu
-------------------------------------apratt@atari.UUCP (Allan Pratt) (09/12/87)
in article <767@saturn.ucsc.edu>, koreth@ssyx.ucsc.edu (Steven Grimm) says: > #include <osbind.h> > > main() > { > long basepage; > > basepage = Pexec(3, "test.tos", "", 0L); > printf("basepage = %08lx\n", basepage); > Pexec(4, 0L, 0L, basepage); > printf("done\n"); > } The correct call for Pexec type 4 is "Pexec(4,0L,basepage,0L);" The combination of load/nogo plus just-go does not work reliably. There are bugs in Pexec relating to memory ownership which cause trouble. You should be able to determine something about where the bombs are, though: is the PC in ROM, or less than "basepage" (i.e. in the parent), or greater than basepage (i.e. in the child)? I have a trick which *does* work for fooling with a child before it has started executing, but it is ugly. I use it in my debugger. What are you trying to do? Maybe the same trick would work for you. Mail me more explanation. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
neil@cs.hw.ac.uk (Neil Forsyth) (02/23/88)
First of all thanks to all those people who responded to my Pexec plea.
Here is a uuencoded archived summary of Allan Pratts answers from way back
covering:-
What the system does when it gets a Pexec
What Pexec(4, is about and why it disna work
Executing processes at the end of the TPA
Since the Pexec cookbook posted here is only a preliminary version I would
welcome a more complete version from Allan.
-------------------------------------------------------------------------------
"I think all right thinking people in this country are sick and tired of being
told that ordinary decent people are fed up in this country with being sick and
tired. I'm certainly not and I'm sick and tired of being told that I am!"
- Monty Python
Neil Forsyth JANET: neil@uk.ac.hw.cs
Dept. of Computer Science ARPA: neil@cs.hw.ac.uk
Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil
Edinburgh
Scotland
-------------------------------------------------------------------------------
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 PEXEC.ARC
M&@A015A%0RY$3T, _W\71A< %<0DDM2!/ J ,0=BP">,&!!0Y8>C0 8$Ba
M")TP<M*D /&F(!TT94#,J2-&39DQ"]^8,5@&ST<=+10HH((FS1P0+F$6E%-Fa
M#IR*<S+2>0,B# B:<>K47&A&SILV((:@B3B'3AJ"():$*2/'C9@P8]" N-,Ra
M*X@D(,Z\H:.@Z%$0((0DH>*D"!4=7T&,(7AB(4TX;/* ().&)LB\(':F7=N6a
M"@L08NHL3'("Z4::%"]2!0&GS!N\913<22,0A)DT;L@$;OD2-!VJ0T&?.;SSa
M#=PT=$Z\] F')ILT;4!#U&N'ZIPT%2F.E*R 3<4S+<+<"0.[C&@H)3_*??-Fa
MC1CJ:T*H3%)0C-$PHD_+:3.'-<;1JE_F>5,'!)HPO0/S7./FS9V>UQ63-#FFa
M)^2+"<%$5E,0T?%2'7#T1)E18]14'@ALE&&@@"!$-X9B99A7QDP2UE'52X))a
M)E<8 E&E&486O;=0;6\T. >(5.7F1D(UN8 62QF),%>)<H@ 0@LMC)81BRZ^a
MQ%4:7M61TW,6*@":D)[UU11E S7X8Y#OO33'41G19!-.:8C!&6QIU/3:0EG*a
M!T(;8:R141MEM/&&''DH !]S XD1H9HB/C&%9W/V)%"+"0%G$4\B9L49&8<1a
M)!IL[H4!(D^)+:H @E!"=$8=<+JQ4%,1N7$&H') J2@;9+B@4D!L@'!$$4T0a
MX>>";YR!$'G^942@'*>)MME%4 XDQQE#(6;<&&L(!\*L<,I))PAV#CI7KWQBa
MU(:-(!2!1X-P+/1D;\\B!-D8?5U(WD-NN&A>3'JVN(:3()Y7D:YTT$2'HJ)Za
M9A12(FXHFDB9CE'DG&7.%MI/-:5!QH9D*3:F4S55FY$899P!FANJ*3O'Ma
MN&:<<^9A(XZ4O6$:3/$&N)Z'"K!H:QA(I<GB57KJ1;'')!Y+HVA!,,&$LD65a
M\2;(=&++'45R+%SJ3@JPZ>;'SNIU)V=AZ)F1&8'Z=*IH1#IXV,J1QB?8%$A(a
MD8032PBI0+O(@@"V?6X<9J^'&.<KXDX)PE&@LI *]FJL?F)+LE-PRJ< &8B2a
MAO)6*+K-GD8/\0H"@JHJD,1(8"N944!CK%?0$ R9Q>]Y"_=F7&5RR ;"&K"Ea
M\/7C]-DWFLKL1;M<'B_=YD:ROVKETV=[[ABA:']/04404E!A-.;LG1#?S07Ia
MG4?&=BK$L*&OMS<'&NRA&G9&8EF?8D8JN%'&'2JX"JOQR%.A[UE#' 6'YG+Ta
MI@ *@8JN$9?7D:%7&6S(">-X$CX!I0 N8+F#44XSNX44[WC),YH;%/# ]KE@a
M"AJ"3$Q\8IR0C(0O&U/2;X)3-?8LI%DA6],;%A; 1AU,,A/TB1T@\A2K.4Y[a
M$@H, '4W*N[=IPUU\ H*GP6VY7A*36XJ0X("9;'G8>5=(3I/X-#2A#9E9&6Ea
MRHK)K(0"KGCL28CC"!T.HSD0L&\(2^A!#%S7DQ?%R6H47!\$E8?!$75&1%ZJa
M QL<N+XB8*$(0W#!$Q@2J"W!Z2*J8:.C( 2:9!''9;<R4E>T AW^; 4V6@$0a
M43C3I81@9&GO&1\(ZC,>$JFO">R+H$J<(+M/ED%U/@'AA5YD*&5Q)4 53%ZDa
M)K47GO0.83;YR$*8ED0X9"Q0<ZM*QH:8!QVH) OL*14D8;8XT-BA.LZY)+!$a
M!!XR>.DE (,-.._0'4DI,0S$:J,"N#DL3C%,3;^K0[J<$AP4:!)EC5H(#5!@a
MDQ2X@ W^1,O1$/F2J^1$;\2"%Y1 %40Z>.B*CYM+03YSL"=AL9?F8EBA*B*Xa
M\Y@&-4U135G*A*K90 8):X%"$!C"33)XTT% D])"Q) '!CKA">ZS:#1!0 65a
MNDX!0IC"%(00A"D4@:7G^8P<IM3-;RKKHF)XT406&=0I,*$(3D!J1B(D*F")a
M1 $7K:H_G[E3 K7M)A\MU:XF%""4]C0(+< !0R@VES+*-28BXNH9O#H<C*S-a
MG C-B*;<><1%BH@,G&J#7I)9$"B +C@B,NL: LK3\]@$*U?;%U"%2E2CKJ"Ja
M5\VJ8"XZ!2@L3D0BD.P*,!(&./CHL@W"%A/")"Z]L$E:*$B! H1W( $25"-Za
M:]!AY&2'C-'&9)Z:C/"RB5KOE*%-/D+!DX@SPXA4;4]?^()SVW280(D(=-6Ma
M(7:WFZPT,*\]9>2<YY(R$4Q)2D"7RLE+F(DM:'H(<D\L65I5V)N7((Z<[QN=a
M3B[31@II;@Y-(UH>7/BHONHJ08O4+DW:5"%P?4Q"V3L!9$RH+/H*=()FP,H8a
M8>+@_UEX#%R2BW$$V$5,/LDG.NJ*FR8JXCGY"& EU$\-8B"#M=4T8H&*P1+8a
M>-MCY?:2G0DQ9Q#SD3"4$5*(JXD;ZK(5@BSDHI(UW!O I<#FA(4ZHB%#0L)@a
M(Y5<H7&T81!,U_H@2!%K0BK(6?H QDQ!Z8Q:@H$-7/1'''\IBR!2$YB#" ;Da
M4GE)8>]TV&T@=J $13$C"PNQ'C_%,:%-T,-?.6^5CRB8,E;R(]G[GIJ:J*L4a
MU_DJ;6-:GZ90W\<A#CU&PB24FK"]4"5+>$9C:SL[I6N=^+6I, 68B$Y]+$?Ra
MI-:-9 A4 8M.P;KTFU-]H5_-=Y_?Z&' &EE*LOOVAE9KCWMZ% W%-/)0-44(a
M/AG9$'O.H!6CG*6$]@NK4$FEH EO:48VS#(* G3N*<E@R%124D_<8-N<M>C(a
MO 7KXTI2&9"HR6EED*V$5#>',.AE91K.2)>=DB\10-Q'BRRBE0UW[OCD>"$Sa
M^#>]BWSPB: :Z6ZZ,(J$YH-=0YR<FCH0^= V8!LB04*^$VZWF3%Q?G%0[_Ia
M3:BWUSW1E'RK8P'G2&![->]:]B%M2PF;\C!N@HSEDR"(@0V6T-&,4%L^2QQ)a
MG>]YT6DBQ7S.*<T<G*D $$"" -3&&PAZ<,-21;6@YNS)LV&Z@KXCYD4:2<.Ua
M05!XL:<MRX5/>=I8"P>53 $T5L(RUI.%UN26:H/#/(_> 7;1(51!"E+ JOO>a
MRN ;9AP_)ESGL;6]NP9F6-P2$@]_(7I?R=+=[@0@;L39D("\7X8%-EFE[$3.a
M:9Z@N WS8^!%S_[6Q"]^D<(# :UIOX;?WUWX_RS^^?#& C+ H.YWWX@8PF_0a
M<Q*K_#!(P Y&.?[+M*#]@5W<PGY#$]%4W]J9 7S@1WSFQP(MP$]PD +RIQ$Ya
MA"G;9VLH@'_-!G^Z)8!;-GP)(('O=X#]A'[!=X$N< <), (D0 -AD +: 8%a
M@6(+0V\/V$@>6"^M-8(QX('=%'XC$ ,P@'QP@(+S-P;G5A#N-2P(I@"L=!]La
MUSSQ46ORE"P7Q7I0,BL296>$PD"_=79K]P8*=U];DVLC4A DLB63XUN*4V<Pa
MIWT&-P:Y=1A'XA4QH3EDH M,A<C-","83-Z\3<@8 5$ !9GJ"<S50=F8 :^a
M<1@2,@;8PDI6J"(W1!%ND!<*\!YBPQ.O]EL5(5R,XS%@LU:3 P=P$09FH'N:a
M%&I3^&KO!419H0"?-@8G8%SJ\3A&1 >5<V::"(LC)Q@6HB!;$VJ5XCWB-!W0a
M%R$,!#PUT7 R(1CS$G3UHAJM]XN#Q6NEX2D\X762(0=EYQ^;PFLXES$;Q$@*a
M$2'*B!"B4@9P(2)*-259 1$B-AG"=A[/^$Z@PHWQLE4;LE=:T8Z9X24>M%#+a
M*"K:H0!(@!J+XQ._$8RZ@CNG@13" Q=Z@WA]<QXS4CCX&"5[@HO\@2%V(FV"a
MM6OPV(^CTFDY43D)8!SY,@<(&2<H, 9MP"B:PG,*D #I6"HJH)*, @)Q1H0[a
M\))[\)+ %Y.((8A;P&,XT 4YR9-W9UX, 2I<M6]$.!$^$'8R8 ,3L9,H6!NFa
M808H( +O>$3Q:#?4 2''P05N( (ID),HR%@_$@-F"7Q]8)0$ "IC =Y$(&"a
MN (QP (M698) D#\ +I@V)RB8V\E!B#2!5V:9,OX):$N04PT 5[AW-+F9<[a
M@()^R8"!6)ARP)B.*1A<A9ANB9:KB ([2),L0)@L -,4)8OV98KD50R!0+7a
M9A0R 26K:$>M@E?G49MF($\@44LL2(Y@"1X#%X=B<8TTB8V$Y2WSZ!EZU"K$a
M&$QCP(:R)B)Z<Q&'08RC!#,9DI&B@9UTD >5<8V(E#3(J8VXF1'/QR:AT0*Za
MLY'9V)&ALAK<"258XR' LI7*"24;4EQ&X0;:V'GB@2TKY0;-62%NP)\5P6LMa
M@URZ!R<$\1(B((RFTA*^Z :?!"DK-01/ 59L"Q&L";_<Z!]D: ,XP(BH!(La
M$1/9MQF=81S"29U&\3)M<!@-N9SX:3"BL9\CZI_OQ#2PT7H6@B$"@BVT*$INa
MIT/CH1NG\2")DC,(XU ?HC8E 2F_&6!0XG;+0YNYJ&0!Q!#UL1#J5@?L!C4Aa
M<YV<I !?"BCR5).'Z )317]G4"CQ4:4QP5C.T7J;"&[>LS"FU#M.LA!8@6))a
MHQIYD8ACX6L!0A5&86@=$J7Z4YL0(5AL<#LO83YQZA3VPP1/X 1'4$='LB=Ha
M^9LOP6?GL35(UBJ2F!&Q^0;1""4(@CIA9P.((4Z5XT=KD11/0 1%, 5T]S>Ra
M4D>W\32HU *_RF0PEQ$_2H5W\!)NQTMHZ1-B=W^0,J5D4:6/UA>4$:F>(DD>a
M(QEZ(1XR0B,=%1,Q@3CFHTV9Y%=0 *XHH*B_.1&X=B/G,4-L(!2SZ:XKA*S,a
M*BE+(C'92A.>8B?+B9;T:J\369LFV11Q8IO7"#JWX1V[P9SS9"@*0*WM*@=Ra
M\*YC6 <YHQ<'!FL,JQ)5X 8PYU S<AIYH2&481F8,4!;L4"^1B\%@BG8>88Ba
MHE[!,02[)3^<5"I\0093MA!E1%#&R;,1DD4Y\Q(6.Q&_!!6*&BB_"72+M+2Va
M^1)?L+2'D1@+<;5X "DD0JEC&#'K&B,PL(:,@R3MUJAN@&"K6F#]TK4+\9M&a
M$R4F$1Z*0U,(LW$9DTMTI++$N(6,5'N_=(X+X45"*'2C@K-N4*N]D2+KIA5Ga
MUZQ/2C=0$A'L!J9P.QT+H[+/9TQ'^Z<YP093YQ2=$65S$+1$ND.' 1:IFJWWa
M@A%V.S&Z$1% -A).^DC\6KNF8K23(8;>"@*RXH4N$;21DC2MET"<T2HWT11.a
MLK;UTE"&,AN "B$TXK,T0F^(PXVR*% ?F@5/4 7 .TA4@%)U! 57551%H "Ra
MX@0GX#Y"@%-(4 12L"RGEQ158#Q/T 3R:T95 50\ 2Z! 5%L*%7]14?>JNRa
MLJOLZSY7 ,!D=R/QFP7JNZGM&Q4W=04@$ 1.D 7C>S9'D,'O6P7NLQ:5P[J7a
M@:BA%Q.+1@?!@QW741UK8D4O49L1@GB*I; 1P1YS,+>I&K0["R[9M!%>@3=(a
M,AO+R3%DLB,M\+2E8E@QHJ09T1L@,2</4@:-.QJ/NTX8(34:Y"FX02. @6)Na
M8#X@D4V_)"*(YA, 8R&MF"]; [ "JD(TL;,&R4 H5ATOG"Q,%VY,1BH7\7RJa
M4<(.!AF1.G#_@[%4C#1A812(=Q0N48>MRDW7(38E,6*884[%D4.%$SOW(00=a
MV@1!D 0_(X9@,86"ZA>AM[ HYDJ>4JAHP02.$AS#6Q>1*)""D14?D2R*Q8#Ja
MZ11C\""D',-ZT;JYX4:B84@2TA*B@BU; ,NA41$*%1PS-"VU]"1&((Y6(D^Da
M6R$0 1A3H$0)23'6V 4JH0*00 0J$4A1,155@6IHH#I!D1K!L1R2-,P;)&@Oa
M4J9GZQ4&A20=NQ<*8R?[(1WZ\SN<Q( 1,L5R<!@_2[Q?:W%&,B=K<(T/>@>3a
M@9L)\:=;(='<>KAF[&)@2"LRNL]:D29VFJ/U(:9:D85:G!&S8K.E2J&I@A9Ga
M9EMI<+D4<AUM( 8_@!9"T&1/9KLB?2N[I GK2 JL,(1DCY9&(5_@C^/*#7Ya
ML1#_ID@_.2I/4IM!YT.-UD"(,6%KL)QUII[-9HUH$03XO"6T:U+T(H[I1#&2a
M8B 9F0>W<QAB"--OPJHKLC?/)R9U\Y%W<&PR.(Y,%M<OT1!I36@(MDBK.!'La
M(IS4ML,J\0(M DNP 4*P ?+8DP8@Q,5@@>UX2#9!&^0QA-I2L8.0D. 0*:a
M?249+!!0<1 ),6(.04-),2=PH"J:31-FD-"AQZH9 3"U'1&W+0>YK<B -B\5a
M$D 1Q]IV5P NP)=LP)?L*3 A,&81<=VU,=L*P 65[0(OD - 052$ 14X#[!a
M\2H84P:ZU;S^X<M[P@,W8 ,W 05!Z6+&T0;XP+.40<^<!AK,"?);-\FB0<Na
MH-^(V-\,,06G<<5'$!%MT 8347&XXTQ/.0*85Z\MR .LZM>I@@8^H !/*>(Qa
M#!JY1>([^90C>1R(P6S$DI,CKN(:F!%\%YHS<!@BL*2RN!-S( (X[N,@@)JJa
MJ>)6Z2E8*0(S_I@E ,XP 9X()9 /N-##@()$)HT<!BHB>5,D+4NSMXP3N5%a
M3@=';JYE .53SIHD<\K"9)OT5IO?61D@0 .+(P)6?II;/N-V7I8GVIKH>11^a
MO5$% 3 N2@8O4!]B$7 OH09*0@<M<.BF.TICL=%RD"RV(5XBP^>$#!F)<0:Ma
M6INV42A>2:;/ C>^T1()TH9:45>^910<$2&58U_9UG1]?%W8MC#@"AJE=DC*a
M/"HGEXG_<1XZ'56Y G07\;BOL9R.-9M2D+_=52HUG#(%@>1='EUIP-\V,EWGa
MH3< 2P<_Q403)HJAU.('U6P,4>W-C>WH*=,I\ /;(6H^L8QM@^HV:;KI$]B3a
M3F]8\P8\A*ZZ*-/&*N 4DB7*6"#9%*0<MQH_Z2WY*::N'!=/YBT%L<L+L^G$a
M8M8@<&8!$JF 6R_3$^J(T]-HR'4QJQ':&1@1$>^R;N_)<H8K@RU5M&2%XRR9a
MP7 #<;*&4CF4;=F8K=E/P-G1^]FA;<RP%Q^O=MH?D=H1L=JM#22O7?,&@1 *a
M<1C#G0;%G=N9C3"]O>;%+D#"'3E4'S_&;2-90W#*#4 AZ=R0 -W23=UL8-W8a
MG0;:#?5DX=V6G9CN72!($M\QD'(R 1BEK QX )54 5# 7_#3E67 9FX/>2a
M@CN!/_B%O^ -OCDV8@1E !H*"QH3#M$6#KQO$#')?:Z<3.)(68WZ:LBW(Q]Va
M;7'!*1II5BM$;1J),V!I!R5O1>)3>Y$,!"F88OK8,@6)$R"&2R'4RJ2NM-'$a
MVW4$YQ[Z7A/LCNFGK]RI+QB5J#B_M(I9JQ^0 A1UT!<1P\D9XT-K$D1HD&!1a
M<Z4Q2M0LVBIP)QHHT$%2YQYEX"$NX<LOX4IC51PLCC>A29HMR0+[B7R*Q]Z[a
M]1XR29HV^?\VN9\Y*4^_<0;FXW0L#H Y297R]!MG8#Y.Q^)L$]:*5P9FZ9-Qa
M]FQF29*C8B]%F8'%!H"/646XU0(QD)J369D4]2_Z 8#*(BS$,B5LDRPJD)@)a
M@)016&P@P /6Q]X@0)4)@)98-07ZVP23F0"5*2S$,B5LDRQI*B:C$J;L%@*>a
MF0!MF0!-]9A5A%ML$]:*Y^4)4)EI>+WWQ#;)H@*)F0 ON#O[]FRE66P V ( a
MJ)>5B6RU!REX"X \-07SV_XOH0*)F0#V\IBA.9HKB9=$R +[J9>5F8LB0@53a
M,+\JD)@)T 1!4P;[]FQZR9>5&30CKS<NE3$JD)@)@);V,IE\69EH^;94FJ^>a
MB>:*TS6(]1\RK""II7AE '(<>43R?IX](2?:W&$*UM)#34U/$L\A-<_)2W_9a
M=(:_>!IX,&)B]A!9^R)</N[O5[$BVI^\UGJ2]0*4-ZYR!^G3V[F*0>NCQ"GBa
M#!<K$XGHIB:?L2D:%!+Z$2?&=/(=BRVG@0=TL )B]A K\'<KL)]V"0-I4TBSa
MUW2:(='9?V6PF+R" K9/IR!S4&3,OR<!<C<$1F<*!G1TY60"1 53( 6P-*D0a
MK7W(5GL<!!LL++NRJ!(] E U_.@\?,,]TVC/<FE#>D+@=HOHMIYD !,SRJQa
M+?=2[_55KRJ\[=M8S/4C,?55+_9-3/;G:O81EP!H$=T#H)US<-U>'_?<W0.0a
$ '0: /55a
a
endpete@tcom.stc.co.uk (Peter Kendell) (02/23/88)
Does anyone know how to startup a ".PRG" Gem program from a ".TTP" program. I can get the program to load and run but the mouse is not active. The pointer is displayed and moves with the mouse but the buttons do not respond. The ".PRG" program executes correctly when run from the desktop and the ".TTP" program will run other ".TTP" and ".TOS" programs with out problems. Please email - I'll summarise. -- ---------------------------------------------------------------------------- | Peter Kendell <pete@tcom.stc.co.uk> | | ...{uunet!}mcvax!ukc!stc!pete | ----------------------------------------------------------------------------
jjung@castor.usc.edu (John Jung) (06/09/89)
Okay, a technical question for all the die-hard C ST GEM programmers out there. I'm having problems getting shel_write() and Pexec() to work together. Specifically, I have the following situation: Program A terminates and launches Program B with shel_write() Program C activates Program A from within itself. Now, when I start up Program C, it runs Program A. No problem. Program A does a shel_write() call to Program B, and exits. THE ST RETURNS TO PROGRAM C. When Program C terminates, *then* Program B will run. How can I solve this problem? Specifically, how can I have Program B execute after Program A, and *then* return control to Program C? Is there a solution at all (I think NeoDesk had the same problem, but I don't know if it's been "fiexd")? Or is there a way to throw out Pexec() and do what I want without it? Please reply by e-mail or net postings. Thanks in advance. John P.S. To whoever was asking about GDOS fonts in the public domain: They're there, you just have to look around a bit.
kbad@atari.UUCP (Ken Badertscher) (06/13/89)
The current incarnation of shel_write is only useful to chain to another program when you are run from the desktop. If you need to run programs which chain via shel_write from a shell program, the shell program must intercept trap #2 and look for shel_write calls, and handle them itself. This is precisely the same problem NeoDesk was having. In my opinion, the solution of having a "shel_write patch" program in your computer all the time is suboptimal. All that is necessary is for the "shell" type program to perform the shel_write calls itself via Pexec. That's all the AES does when a program uses shel_write to chain to another program. Rather than restarting the desktop, the AES shell Pexecs the program whose name was shel_written. This and other sticky shel_stuff will be covered by the forthcoming (yeah, it's been forthcoming for about 6 months now, so sue me...) shel_games document. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>