ignac@electro.UUCP (Ignac Kolenko) (04/23/89)
In article <1927@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: >--- >allen pratt (or anyone that might know...) - > >i have a question on Pexec, specifically on load/nogo then go more than once. >here is a short example which does not work, probably because the child is >gone after the first Pexec (4,...). > >what i want to know is just how to do this. actually, i want to have a GEM >program (uses AES) Malloc screen buffer, load in some special code(s) which >will be executed any number of times (may be several programs acting like >special drivers),then Malloc more memory. the children will never Malloc/malloc >any memory but must be able to read/write to memory loc passed to it by parent: > hmm, interesting. this is pretty well the exact same problem that i've come across in the GEMDOS pexec: namely, you cannot tell GEMDOS to load in a program at a specific address. this makes overlays a real bugger, since i can't allocate, say 32K of memory as an overlay buffer, and tell gemdos to load a program into this buffer for execution. the ability to do this would allow people to write really HUGE accessories, but instead of eating up 200K for the huge accessory all at once, the modules it need to run can be pexeced when needed into an internal buffer. no muss, no fuss. but, i have a feeling this would interfere with any attempts by atari to make TOS multitask/swap processes/etc. or is that being too optomistic?? :-) >all these types of questions SHOULD have been answered in the Pexec Cookbook >or else you should just release the src to developers so we don't have to >bug you. i really need an answer before the weekend so i can get this >stuff working. i am on a tight schedule for my customer. > again, interesting. if simple questions like this aren't answered in the "all powerful atari developer documentation", then what is covered??? hearing of problems like this from developers (i assume from bill's posting that he is indeed a developer) makes me VERY hesitant on spending $100+ on documentationthat is no better than the abacus books. -- Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac "Catholic or Protestant, you got not choice. I tried to scream, but I lost my voice!" from 'Irish Eyes Don't Smile Tonight' by SUBURBAN DISTORTION
apratt@atari.UUCP (Allan Pratt) (04/25/89)
In article <477@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > In article <1927@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: > >i have a question on Pexec, specifically on load/nogo then go more than once. > [I have the same problem...] > ... the ability to do this would allow > people to write really HUGE accessories, but instead of eating up 200K for > the huge accessory all at once, the modules it need to run can be pexeced > when needed into an internal buffer. I will tell the net the same thing I told Bill Rosenkranz: don't try to use Pexec to load overlays. If you want to load overlays, do it some other way. For example, demand that the overlays be position-independent and load them anyplace you want. Alternatively, load them and fix them up yourself -- there is enough information in the documentation to do this. The normal startup will not work, of course, because an overlay is a fragment, not a program. Certainly, an overlay should never call Pterm(), and should not expect to have a basepage. Some programs which have multiple printer drivers, like Degas and (I believe) MicroSoft Write, use this trick. The driver is a module, not a program: the beginning of the module contains relative pointers to the externally-visible entry points. Your best bet is to load the driver code into memory and relocate it yourself (unless it's position independent), JSR to it, and have it RTS to you, and stop trying to think of it as a process. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt