erik@mcrware.UUCP (Erik Johnson) (04/06/91)
Here is what I would like to do. I would like to append a picture file to the end of my executable file. In this case, the extra data is a picture file that is the menu for my program. Once a program is loaded into memory, is it closed and all file offset information lost, or is there a way I can start reading data from the file where the program data left off. If it matters, I am working in C with assembly when required. Thank you, Erik R Johnson
warwick@cs.uq.oz.au (Warwick Allison) (04/08/91)
In <5796@mcrware.UUCP> erik@mcrware.UUCP (Erik Johnson) writes: >Here is what I would like to do. I would like to append a picture file to the >end of my executable file. In this case, the extra data is a picture file that >is the menu for my program. Once a program is loaded into memory, is it closed >and all file offset information lost, or is there a way I can start reading >data from the file where the program data left off. Try: 1. Generate your .PRG (eg. with C or M2 linker, etc) 2. Have a separate program to: a) Fseek to the end of the .PRG file b) append any other data Your program should Fseek backwards from the end of the .PRG file, to the start of the additional data, then read it. This will work, provided the additional data does not confused the loader. If it does, then I'm stumped, I'd assume the loader ignores additional data. Warwick -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
jpexg@gaak.lcs.mit.edu (John Purbrick) (04/08/91)
>In <5796@mcrware.UUCP> erik@mcrware.UUCP (Erik Johnson) writes: > >Here is what I would like to do. I would like to append a picture file to the >end of my executable file. In this case, the extra data is a picture file that >is the menu for my program. Once a program is loaded into memory, is it closed >and all file offset information lost, or is there a way I can start reading >data from the file where the program data left off. I've done this successfully storing a SMALL amount of data holding default settings for a printer-driver program. It could probably be expanded though. The main point is that an executable file is like any other; it gets loaded into memory to run, but if you can find it on disk or wherever you can modify it at will, as long as you don't damage it. What I did was to start the program with a function which is never called. This contains any "password" you want, encoded into an ASM block. So: my_data(){ asm{ DC.B "The password" DC.B "Enough space to store what you need" } } The program opens its own file (the_prog.prg or whatever) and searches for the string "The password"; since function my_data is near the start, this doesn't take long. Then the subsequent data can be read or written. The data and password, which obviously aren't executable themselves, never screw anything up because the function is never called as a function. It's a kludge but it's fairly simple and it works. ONe problem for the stated application is that the program would have to know how to find itself and what its name is, in order to do the searching. Perhaps you could use the principle of a non-executed block to store your file as data, and give the program a pointer into it? John Purbrick jpexg@lcs.mit.edu
wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) (04/09/91)
erik@mcrware.UUCP (Erik Johnson) writes: >Here is what I would like to do. I would like to append a picture file to the >end of my executable file. In this case, the extra data is a picture file that >is the menu for my program. Once a program is loaded into memory, is it closed >and all file offset information lost, or is there a way I can start reading >data from the file where the program data left off. Although I havent tried, it should be possible to simply append the picure data to the end of the file without disturbing the program. The location of the picture can be located by looking at the program header, or by simply loading the last 32K or whatever. After program load, the entire program file should be in memory and should remain there during program execution (I dont know what will happen to relocation info, though, but I cant imagine it will be freed). Look at the program's basepage, and you will find some pointers to the text, data and bss segments of the program plus the lengths of these segments. The picture data should be just behind. for more info, consult the documentation of the basepage structure. Good luck Okami-san
wolfram@cip-s06.informatik.rwth-aachen.de (Wolfram Roesler) (04/11/91)
warwick@cs.uq.oz.au (Warwick Allison) writes: >Your program should Fseek backwards from the end of the .PRG file, to the >start of the additional data, then read it. The problem is again that it's a real hard job for a prg to find it's own executable. Dont rely on it being in the current directory. Dont rely on finding the name in argv[0]. The problem in this case is primarily to find the data in memory, since there is no reliable way to find it on the disk. There was a discussion in comp.lang.c about finding the executable file some time ago, and it convinced me that this is not generally (sometimes even not at all) possible. Regards Okami-san
bjoern@drdhh.hanse.de (Bjoern Kriews) (04/12/91)
From article <615@uqcspe.cs.uq.oz.au>, by warwick@cs.uq.oz.au (Warwick Allison): > Try: > 1. Generate your .PRG (eg. with C or M2 linker, etc) > 2. Have a separate program to: > a) Fseek to the end of the .PRG file > b) append any other data Works, but my confuse future loaders, etc. Cleaner method: Define a field in your programs data segment. Taking the offset (in the running program) from your textseg to the fields address you can figure out where your data is on disk. (offset + sizeof(PROGRAMHEADER)). Hope that helps, Bjoern --- bjoern@drdhh.hanse.de = Bjoern Kriews / Stormsweg 6 / 2000 Hamburg 76 / FRG "gaaga mahwe Bjoern urgl ufzae Turbo-C bnub" (J. Willamowius)
warwick@cs.uq.oz.au (Warwick Allison) (04/12/91)
wolfram@cip-s06.informatik.rwth-aachen.de (Wolfram Roesler) writes: >The problem is again that it's a real hard job for a prg to find it's >own executable. Why not: 1. Try ARGV/xARG 2. Try shell_read 3. Fail shell_read will work for Desktop run stuff. ARGV/xARG will work for stuff called from command line. If the user tries to use the program some other way (?) then that is there hard luck. Personally, I'd rather not put data into my executables anyway (what's wrong with separate files and environment variables? Much more flexible - we lose more flexibility in embedding data than we do by failing if the user calls our program by an obscure means.) Warwick. -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
apratt@atari.UUCP (Allan Pratt) (04/13/91)
>erik@mcrware.UUCP (Erik Johnson) writes: >Here is what I would like to do. I would like to append a picture file to the >end of my executable file. In this case, the extra data is a picture file that >is the menu for my program. Once a program is loaded into memory, is it closed >and all file offset information lost, or is there a way I can start reading >data from the file where the program data left off. wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes [some stuff based on wierd and wrong guesses about how things work]. You can't just tack the picture data onto the program file after the program's data segment, because that would mess up the BSS segment. I reiterate: you should not try to "append a picture file to the end of [your] executable file" but rather "arrange for a picture file to be included in your program file." This you can do, in the worst case, by turning the picture file into an assembly (or C!) source file, assembling (or compiling) it, and linking with the resulting .o file. Example using my DB (it doesn't matter what compiler you ultimately use): :read picture.neo :transcript mypic.c :dw(+ `rwstart 4)[@32] ; dw(+ `rwstart 80)[@32000] :transcript off Now, in mypic.c, there's a top line you should delete ("dw..."), two lines' worth of palette data, and 2000 lines' worth of picture data, followed by another line you should delete ("transcript off"). You have to edit the file to remove the address and ASCII fields from the dump, and prefix each number by "0x", and put commas between them, and now you can wrap them in to C as array initializers, so the result looks like this: short paldata[] = { 0x0777,0x0007,0x0070,0x0700, ..., ... }; short picdata[] = { 0x ... }; and now you can compile this file, link with it, and use the symbols paldata and picdata in your program. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
neil@cs.hw.ac.uk (Neil Forsyth) (04/17/91)
In article <2904@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >I reiterate: you should not try to "append a picture file to the end of >[your] executable file" but rather "arrange for a picture file to >be included in your program file." This you can do, in the worst case, >by turning the picture file into an assembly (or C!) source file, >assembling (or compiling) it, and linking with the resulting .o file. > >Example using my DB (it doesn't matter what compiler you ultimately use): > (DB example deleted) I use Allan's linker (ALN) instead: aln -p -i picture.neo _titlpic -o titlepic.o This produces an object file, titlepic.o, that contains the NEOchrome picture at label _titlepic which can then be accessed as a structure. I should add of course that the picture will not be on a 256 byte boundary and so you can't just point the hardware at it (unless you have an STE or a TT of course). >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! 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, UK "That was never 5 minutes!" ! +----------------------------------------------------------------------------+