andrew@.cs.utk.edu (Andrew Krzywdzinski) (11/11/90)
I want to be able to write setup information directly to a program file. (This has been done in several applications -- ARCSHELL 2.1 is one example). I figure that I will have to mess with the Getmpb procedure, as well as the structure of the executable files, to find out where a variable "lives" on the disk file. Alas, the documentation for that stuff is *very* unrevealing, and I don't want to resort to trial & error. I would really appreciate any suggestions, example code (C please!), or at least a pointer to a book (he he) which carries such information. Please e-mail to andrew@cs.utk.edu. Thank you so much. -andrew krzywdzinski 1732 Laurel Ave. Knoxville, TN 37916
apratt@atari.UUCP (Allan Pratt) (11/13/90)
andrew@.cs.utk.edu (Andrew Krzywdzinski) writes: >I want to be able to write setup information directly to a program file. >[...] I figure that I will have to mess with the Getmpb procedure, Oh, boy! Getmpb has NOTHING to do with locations of things on disk. No wonder you got confused! Getmpb is a BIOS call which is used by GEMDOS to find out the lay of the land at the beginning of the world: it is the BIOS's way of telling GEMDOS what memory it found and where. It should not be used by user programs. (Gulam used this for the "mem" command and that's one reason the "mem" command doesn't work in Rainbow TOS.) In the Hitchhiker's Guide to the BIOS there is a discussion of the format of an executable file on disk. It starts with a header, then the image of the text segment, then the data segment, then the symbol table, then the "fixups" which tell GEMDOS how to relocate your program. (Programs are linked as if they start at zero, and the actual starting address of the program is added to all absolute references by Pexec(). The fixup information tells Pexec what places need fixing up.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
andrew@cs.utk.edu (Andrew Krzywdzinski) (11/13/90)
I was thinking (erroneously) that Getmpb would tell me where the program being executed starts in memory, so that I can match the location of the variable in the "self modifying" program and on the disk. Now that I've learned more about the format of the executable files, I know better. The suggestion I received was to look at the initialized data segment, and look for my magic number. This sounds like it might work, but seems like a bit of a hack. I suppose there is no better way of doing it, so I'll try it the hack-way. Thanks to all who responded to my query, I appreciate it very much. -andrew krzywdzinski (andrew@cs.utk.edu)
klute@heike.informatik.uni-dortmund.de (Rainer Klute) (11/15/90)
In article <1990Nov11.013428.4566@cs.utk.edu>, andrew@.cs.utk.edu (Andrew Krzywdzinski) writes: |> I want to be able to write setup information directly to a program |> file. I once posted a fundamental (as I think) article against self-modifying code to this newsgroup. Here it is again - slightly generalized and of course open to consideration and discussion: ------------------------------ cut here ------------------------------ No, no, no! Never write self-modifying code! Self-modifying code is very bad style. It is difficult to write and even more difficult to understand. Programs that modify itself tend to be unmaintainable. A lot of machines do not allow you to modify a program file for security aspects. Consider everyone on a multiuser system would be allowed to modify any file. Sure, this is not true for the Atari ST, but one should learn to do it the right way. Spend some time to figure out how to do it on e. g. a Unix system and you can to it equivalently on the ST. (Slight simplification here, but you got the idea, right?) On a related topic: Several systems do not even allow you to modify your executing program while it is located in memory. You will only be allowed to write to the data portion of the program. This is due to the fact that on a multitasking system several tasks can execute one single program simultaneously. Now, if the program code can not be modified by the executing task it is sufficient to load the program into core only once, thus gaining a lot of efficiency. (Of course each program get it's individual data section.) If you are afraid of virusses don't modify your program file. You (the average user) can never tell whether the program has been modified by a virus or not. There are programs on the market (including the PD market) that estimate a certain checksum for each program and alarm you if this number changes. How could such a program tell if the change is due to a virus or not? If you are afraid of virusses write protect your media as far as possible. A program that writes to its program file needs to be run from a not write protected disk. This a unnessary and an avoidable security hole. In most cases it is fully sufficient to maintain a configuration file. Keep an entry for every variable that needs to be modified permanently. Upon startup of the program the whole stuff is read in again and the program's variables are set accordingly. Simple, isn't it? -- Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (11/15/90)
andrew@cs.utk.edu (Andrew Krzywdzinski) writes: >I was thinking (erroneou sly) that Getmpb would tell me where the program >being executed starts in memory, so that I can match the location of >the variable in the "self modifying" program and on the disk. Now that Follow the pointers in the process descriptor to find out the start of your text, data and BS segment. Best way to do things like that. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
kawakami@volcano.Berkeley.EDU (John Kawakami) (11/16/90)
In article <1990Nov13.144721.21402@cs.utk.edu> andrew@cs.utk.edu (Andrew Krzywdzinski) writes: >I was thinking (erroneously) that Getmpb would tell me where the program >being executed starts in memory, so that I can match the location of >the variable in the "self modifying" program and on the disk. Now that >I've learned more about the format of the executable files, I know better. >The suggestion I received was to look at the initialized data segment, >and look for my magic number. This sounds like it might work, but seems >like a bit of a hack. >I suppose there is no better way of doing it, so I'll try it the hack-way. Ok everyone, repeat after me: All hail the Mac resource forks All hail the Mac resource forks All hail the Mac resource forks Maybe this is the next thing Atari can standardize :-) Now that the PC+Windows has it (like outline fonts, graphics independence, etc.) I guess that's the bummer part of having an Atari (or Amiga): even cool system-safe addons have to be done in-house. John Kawakami kawakami@ocf.berkeley.edu ucbvax!ocf.berkeley.edu!kawakami Amateur crank! My Atari Macks!