Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!van-bc!ubc-cs!cheddar.cc.ubc.ca!panon From: panon@cheddar.cc.ubc.ca (Paul-Andre Panon) Newsgroups: comp.sys.amiga.tech Subject: Re: Problem with CreateProc & LoadSeg Message-ID: <7778@ubc-cs.UUCP> Date: 8 May 90 17:38:19 GMT References: <897@tau.sm.luth.se> <1856@dialog.sub.org> <5662@sugar.hackercorp.com> <1860@dialog.sub.org> Sender: news@cs.ubc.ca Reply-To: panon@cheddar.cc.ubc.ca (Paul-Andre Panon) Organization: UBC Computing Centre, Vancouver, B.C., Canada Lines: 50 In article <1860@dialog.sub.org> root@dialog.sub.org (Christian Motz) writes: >>Then you can add extra stuff you want to feed the program (like file handles) >>after the message. This is pretty much how RogueStart works (which is something >>else you should look into). > >As I said, this is something I cannot do, since the programs to be >started are usually standard CLI programs, often to the effect that >they can't or shouldn't be modified. Arrgh! I want fork()! ^^^^^^^ > >-- >Christian Motz root@dialog.sub.org I was going to say "couldn't you fake a fork()-Execute()?". What I had in mind (based on someone else's (device driver?) code from long ago) was: - Have a procedure in your program which is just specialized code that waits for a(n extended) WorkbenchStartup message, takes the required info from the message, and calls Execute() with it. - then, find your SegList and follow down it until you find the address of said procedure. - use that as the SegList for a call to CreateProcess(). - the child process will then Execute() the program with the parameters you gave it. - make sure your parent doesn't exit before the child does so that you can cleanup the child's resources and so that the pseudoforked section of the code doesn't get deallocated. You can separate the child code by detaching it from your SegList if you linked it so it would be last on the main SegList when loaded, and thus the parent program can exit without cleaning up for the child or the child getting the rug pulled out from under it, but you will lose the associated memory (nobody will be around to clean it up) so you should only do it if you want the code to stay around forever (for background demons and so forth - in which case you should probably have been able to use CreateProcess() directly instead of using Execute()). If you don't mind having to wait for the child to finish eventually but just want to do something else NOW, then this should do what you want. And it's likely to be more robust than your current method. Your ugly hack :-) :-) seems like the only way to spawn CLI processes and not have to worry about them later though and would probably be what you'd have to do if you were writing a shell for instance (actually I was wondering how to do that so thanks for the hint - I hope I never need it). -- Paul-Andre_Panon@staff.ucs.ubc.ca or USERPAP1@UBCMTSG or Paul-Andre_Panon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca Looking for a .signature? "We've already got one. It is ver-ry ni-sce!"