Image Map Image Map
Results 1 to 8 of 8

Thread: Retrieving executing filename in DOS 2.x

  1. #1

    Default Retrieving executing filename in DOS 2.x

    Accessing the executed file name in C is as simple as argv[0]. However this doesn't work in DOS 2.x. I know I'm not the only one with a Tandy 1000 (DOS 2.11) and/or PCjr on this forum, so I thought I'd ask on here to see how you go about determining this.

    For now I've worked around the issue by copying the __FILE__ macro contents and changing ".C" to ".EXE". Obviously this only works as long as the user doesn't rename the file!

    P.S. -- What interrupt is called to get the executable filename? I didn't see that information in the PSP.

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    24,727
    Blog Entries
    20

    Default

    IIRC (and it's been a long time), you scan the environemt strings (segment pointer at 002C in the PSP) to the double null (00 00). 2 bytes after that double null, and you'll find the name (and path) of your program. AFAIK, this works from 2.0 onward; the format may be a bit different after 3.0, but AFAIK, this worked way back when.

    e.g.:

    Code:
    02E4:0100  4C 45 44 3D 43 3A 5C 52-45 43 59 43 4C 45 44 00   LED=C:\RECYCLED.
    02E4:0110  00 01 00 43 3A 5C 42 49-4E 5C 44 45 42 55 47 2E   ...C:\BIN\DEBUG.
    02E4:0120  43 4F 4D 00 00 E8 3D 01-C4 3E 88 00 8B C7 8B D8   COM...=..>......

  3. Default

    According to the Interrupt List the command line only appears after the environment in MSDOS 3.0+.

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    24,727
    Blog Entries
    20

    Default

    Obviously, the answer is to try it and see what happens. If it's not there, it's probably internal to COMMAND.COM, which would be a shame. In any case, it's not the command line per se, but just the fully qualified name of the executable file. That is, command-line arguments are not present.

    Failing that, I'll have a look at my Lattice C 2.0 startup source and see what it says.

  5. #5
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,645

    Default

    We encountered this problem with 8088 MPH: the script for all effects is tacked onto the end of 8088MPH.EXE. The loader tried to be smart and get its own filename in order to open itself and read the script at the end of the file.
    This broke down in DOS 2.x because the functionality simply isn't implemented. There is no way to retrieve the current filename.
    I inspected the PSP with a debugger, it's simply not there.

    You'll find that Turbo Pascal, Watcom C and probably various other programming languages perform a DOS version check for DOS 3.0+ before they try to parse the commandline in their runtime libraries, because of this exact problem.

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    24,727
    Blog Entries
    20

    Default

    I wouldn't expect to find it in the PSP. Did you try to walk the memory allocation chain--that might yield something.

  7. #7

    Default

    Make a test program with a really unique name... something that wouldn't just randomly appear in memory like AGCTVXLJ.EXE

    DOS has no memory protection, so scan ALL of memory and see if you find a match anywhere... If you find it, rename the file and look for the new name and see if it's in the same spot.

    If you don't find it the first time, or it isn't in the same spot in memory in relation to absolute memory or your file's location in memory, you're probably Sierra Oscar Lima.
    From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.
    CUTCODEDOWN.COM

  8. #8

    Default

    FWIW, this is something I wrote in QuickBASIC years ago;
    Code:
    FUNCTION GetProgramPath$ ' This function requires DOS 3.0+
    	Reg.AX = &H5100 ' Get PSP segment. DOS 2+
    	INTERRUPTX &H21, Reg, Reg
    	DEF SEG = Reg.BX
    	DEF SEG = CVI(CHR$(PEEK(&H2C)) + CHR$(PEEK(&H2D))) ' Segment of environment. DOS 2+
    	DO ' Search for two consecutive nul bytes
    		Offset = Offset + 1
    	LOOP UNTIL (PEEK(Offset) OR PEEK(Offset - 1)) = 0
    	Offset = Offset + 3
    	ExePath$ = SPACE$(260)
    	FOR Index = 1 TO 260
    		ByteValue = PEEK(Offset)
    		IF ByteValue = 0 THEN EXIT FOR
    		IF ByteValue = 92 THEN LastBackSlash = Index
    		MID$(ExePath$, Index, 1) = CHR$(ByteValue)
    		Offset = Offset + 1
    	NEXT
    	'ExeName$ = MID$(ExePath$, LastBackSlash + 1, Index - 1)
    	GetProgramPath = LEFT$(ExePath$, LastBackSlash)
    END FUNCTION
    As has been pointed out already, there's no way to do this in DOS 2.x AFAIK
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •