cochrane@spot.Colorado.EDU (COCHRANE JIM T) (09/15/88)
How does one go about writing a GEM program that will accept arguments to main via argc and argv? I'm using Mark Williams C and when I try to use argc and argv with a GEM program the program bombs. Thanks for any help, Jim Cochrane
soohoo@cory.Berkeley.EDU (Ken Soohoo) (09/16/88)
In article <3441@boulder.Colorado.EDU> cochrane@spot.Colorado.EDU (COCHRANE JIM T) writes: > > > >How does one go about writing a GEM program that will accept arguments to >main via argc and argv? I'm using Mark Williams C and when I try to use >argc and argv with a GEM program the program bombs. > >Thanks for any help, >Jim Cochrane As far as I know, with MWC 3.0 (2.1.7 also), the method for using argc and argv from a GEM type program is to NOT use the -VGEM flag, instead, use the -laes -lvdi options as the last part of your cc command: cc -o myprog.prg main.o mod1.o mod2.o -laes -lvdi As far as _I_ can tell, argv[0] is undefined, and is NOT standard K&R from the desktop, but from the MSH shell it's OK (supposed to be the name of the program being executed). --Kenneth Soohoo (soohoo@cory.Berkeley.Edu) Atari 400/800/600xl/800xl/1200/130xe/65xe, 1040ST hacker Sometime Berkeley Student, othertimes... My opinions are my OWN, not necessarily Atari's
leo@philmds.UUCP (Leo de Wit) (09/16/88)
In article <3441@boulder.Colorado.EDU> cochrane@spot.Colorado.EDU (COCHRANE JIM T) writes: >How does one go about writing a GEM program that will accept arguments to >main via argc and argv? I'm using Mark Williams C and when I try to use >argc and argv with a GEM program the program bombs. Although I don't use MWC myself, I will make a few remarks: 1) There is no means that I know of to supply parameters to a Gem program if it is started from the Desktop. 2) If the program is started from a shell, the shell should be a Gem program, otherwise the program cannot use Gem functions. I'm not very sure about this one, though. 3) You don't need to do anything different for a Gem program than for a Tos-Takes-Parameters one. 4) The bus error is perhaps caused by incorrect treatment of the argc,argv list, e.g. accessing an element argv[i], with i >= argc, or argv[0], whose contents is undefined (GEMDOS does not pass the program's name). I even think there are compilers that put a null pointer (not an empty string pointer) in argv[0], which is in effect incorrect - argv[argc] should be the first null pointer of the list. Leo.
gert@uva.UUCP (Gert Poletiek) (09/16/88)
In article <3441@boulder.Colorado.EDU> cochrane@spot.Colorado.EDU (COCHRANE JIM T) writes: > > > >How does one go about writing a GEM program that will accept arguments to >main via argc and argv? I'm using Mark Williams C and when I try to use >argc and argv with a GEM program the program bombs. > >Thanks for any help, >Jim Cochrane Manually compare the tos and gem runtime startup modules. Sources are provided with Mark Williams C. You might also try linking directly with tos startup instead of gem startup. The the only thing you have to remember is that linking with -VGEM also includes the Gem library. Link with something like; ld -s -o output lib/gcrts0.o objectlist -lvdi -laes -lc That should do it. ------------------------------------------------------------------------------- Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet Opinions (if any) are my own. -------------------------------------------------------------------------------
dlm@druhi.ATT.COM (Dan Moore) (09/16/88)
in article <3441@boulder.Colorado.EDU>, cochrane@spot.Colorado.EDU (COCHRANE JIM T) says: > How does one go about writing a GEM program that will accept arguments to > main via argc and argv? I'm using Mark Williams C and when I try to use > argc and argv with a GEM program the program bombs. Just don't use the GEM switch on your link line. For some unknown reason Mark Williams uses a different startup routine when you say you have a GEM program. If you don't use the GEM switch you get the standard startup routine which lets the program accept command line arguments when you launch from a command shell. Dan Moore AT&T Bell Labs Denver dlm@druhi.ATT.COM
daanjj@neabbs.UUCP (DAAN JITTA) (09/17/88)
Jim, You probably compiled your program specifying the -VGEM or -VAPP option to the compiler driver cc. For an unknown reason, the GEM runti runtime startup sets ARGV to NULL. Just take a look at the source, or at the manual at page 141 (entry crtsg.o). Solution: call cc first with option "-c", and then call the linker yourself specifying both the correct runtime startup crts0.o and the VDI/AES libraries (-laes -lvdi). This will work!! Daan Josephus Jitta ( daanjj@neabbs )
apratt@atari.UUCP (Allan Pratt) (09/22/88)
In article <806@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > In article <3441@boulder.Colorado.EDU> cochrane@spot.Colorado.EDU > (COCHRANE JIM T) writes: > >How does one go about writing a GEM program that will accept arguments to > >main via argc and argv? I'm using Mark Williams C and when I try to use > >argc and argv with a GEM program the program bombs. > > Although I don't use MWC myself, I will make a few remarks: > 1) There is no means that I know of to supply parameters to a Gem > program if it is started from the Desktop. This is what "Install application" does. This is how to use it to install (for example) GFABASIC.PRG to run *.GFA: Select (click on) GFABASIC.PRG. Choose the menu item "Install Application" from the Options menu. Fill in the three blanks in the "Document Type" field with GFA. Now, whenever you double-click a file *.GFA, GFABASIC.PRG will be run and its command-line argument will be the name of the file you clicked. Of course, it's up to the program (in this case, GFABASIC.PRG) to deal with a command-line argument. GFABASIC happens to do nicely; other programs might not. Microsoft Write, for one, does not. There are other caveats. The "current directory" will be the directory the file is in, not the directory the program is in, so finding your resource file might be tricky. Put all your resource files on the root of the boot device (Drive C: if you have a hard disk) and AES will always find them. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
leo@philmds.UUCP (Leo de Wit) (09/24/88)
In article <1173@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >In article <806@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [ ]... >> 1) There is no means that I know of to supply parameters to a Gem >> program if it is started from the Desktop. > >This is what "Install application" does. This is how to use it to >install (for example) GFABASIC.PRG to run *.GFA: > > Select (click on) GFABASIC.PRG. > > Choose the menu item "Install Application" from the Options menu. > > Fill in the three blanks in the "Document Type" field with GFA. > >Now, whenever you double-click a file *.GFA, GFABASIC.PRG will be run >and its command-line argument will be the name of the file you clicked. [ ]... Of course, I forgot this one (see however STaccato, where I use it myself). However, this is only a very limited parameter passing mechanism: - it only allows for passing one string argument - this argument has to be a filename. - if you want to do different things to a file (e.g. edit/print) this allows for only one "Install Application". Summary: It is nice where you can use it, but rather restricted. B.T.W. Talking about command-line arguments, is there any chance we can have real large ones in the future? The current limit is rather low. Looking at Pexec this shouldn't be hard to implement, since a) for the environment this tactic is already followed, i.e. a separately space is allocated and a pointer to it put in the basepage. b) When starting a program, a basepage vector is already made to point to the command-line argument (basepage + 0x80). This vector now seems to be used as the DTA pointer. The new startup code can make a copy of this pointer. c) To keep existing programs happy, the new Pexec should still copy the first 128 bytes or so of the argument string to the old command line space (basepage + 0x80). Is there any chance this could get into a next ROM release, Allan? TOS 1.5 ? Leo.