jms@tardis.Tymnet.COM (Joe Smith) (09/25/89)
In article <2045@leah.Albany.Edu> wfh58@leah.Albany.Edu (William F. Hammond) writes: >P.S. "argv[0]" *ought* to be the filename rather than the command line entry. No, that is even worse. I was so glad when TOPS-10 came out with monitor calls that finally returned the name and complete path name of the currently executing program. It allows programs to find overlays, help files, and data files. It worked correctly regardless of the user's default directory, the search path for locating executables, any ASSIGNS, or arbitrary aliases. (It was actually implemented as a security tracking feature, but that's a different story.) AmigaDOS needs this, for the same reasons. Not as a kludge by mangling argv[0], but as a fully supported and official way. An example function name would be GetTaskFileName(). Of course, it should return NULL if the task was created on the fly and not loaded straight from disk. I'm surprised this wasn't part of AmigaDOS 1.0. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
jms@tardiq.Tymnet.COM (Joe Smith) (09/25/89)
In article <2045@leah.Albany.Edu> wfh58@leah.Albany.Edu (William F. Hammond) writes: >P.S. "argv[0]" *ought* to be the filename rather than the command line entry. No, that iq even worse. I was so glad when TOPS-10 came out with monitor calls that finally returned the name and complete path name of the currently executing program. It allows programs to find overlayq, help files, and data files. It worked correctly regardless of the user's default directory, the qearch path for locating executables, any ASSIGNS, or arbitrary aliases. (It was actually implemented as a security tracking feature, but that's a different qtory.) AmigaDOS needs this, for the same reasons. Not as a kludge by mangling argv[0], but as a fully supported and official way. An example function name would be GetTaskFileName(). Of course, it should return NULL if the task was created on the fly and not loaded qtraight from disk. I'm surprised thiq wasn't part of AmigaDOS 1.0. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglaq FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardiq!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
ccplumb@rose.waterloo.edu (Colin Plumb) (09/25/89)
In article <623@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >AmigaDOS needs this, for the same reasons. Not as a kludge by mangling >argv[0], but as a fully supported and official way. An example function >name would be GetTaskFileName(). Of course, it should return NULL if the >task was created on the fly and not loaded straight from disk. > >I'm surprised this wasn't part of AmigaDOS 1.0. Quick race-condition quiz: why is the filename useless to know? Answer: because someone might have moved the file in the meantime! Yes, unlikely, but it's possible. You need to use locks, not filenames, to get around this. 1.4 has a call which returns a lock on the directory the current program was loaded from (watch for NULL meaning from the resident list or otherwise not associated with a file), but I'd rather have a lock on the file proper. It seems simpler (the OS needs a lock to open and load the code) and the ParentDir() call exists. It also lets you tell which copy was run if there are (for some reason) multiple copies. -- -Colin
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/26/89)
In article <623@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >AmigaDOS needs this, for the same reasons. Not as a kludge by mangling >argv[0], but as a fully supported and official way. An example function >name would be GetTaskFileName(). Of course, it should return NULL if the >task was created on the fly and not loaded straight from disk. Suggested Implementation : Have LoadSeg() store a lock in the process structure for the executable it has loaded (this will also help later if you ever want to be able to page out of the executable) and provide a routine GetProcessFileLock(Proc) or some such name that would return you this lock. The user code would have to do an Examine(lock) to find the name of the file, or it could just do a DupLock(lock);Parent(lock) to find a lock on the directory where the original executable resides. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
jesup@cbmvax.UUCP (Randell Jesup) (09/26/89)
In article <623@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <2045@leah.Albany.Edu> wfh58@leah.Albany.Edu (William F. Hammond) writes: >>P.S. "argv[0]" *ought* to be the filename rather than the command line entry. ... >I'm surprised this wasn't part of AmigaDOS 1.0. Don't be. The CLI was almost an afterthought (remember the CLI switch in preferences?) Originally, you were supposed to run everything (more or less) from Workbench, which gives you a lock on the directory you were loaded from. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
esker@abaa.uucp (Lawrence Esker) (10/17/89)
In article <7991@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > Don't be. The CLI was almost an afterthought (remember the CLI switch >in preferences?) Originally, you were supposed to run everything (more or >less) from Workbench, which gives you a lock on the directory you were loaded >from. Thank God for small favors!! What convinced me to buy the Amiga the same day I saw it in a store was for a large part the CLI. I would not buy a Mac because it forced everything to be done via windows (and at that time, programmer tools were very clumsy to use through the windows or they were non-existant.) "You mean you can use this computer with the ease of a Macintosh and yet program it the same way I do at work on the VAX. All this, multitasking, powerful graphics, and sound. Its only $2,500 for what I need, not $5,000 that I saved up. I'll be back tonight to get one." -- Me, at computer store. -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any computer that is not IBM compatible. UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP