madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) (08/02/87)
In article <1013@vi.ri.cmu.edu> jfb@vi.ri.cmu.edu (John Brennen) writes: >In article <1690@bellcore.bellcore.com>, tr@wind.bellcore.com (tom reingold) writes: >> >> I just discovered an undocumented feature of the more recent >> versions of DOS: it is at last possible to obtain argv[0]. >> > >The method described is documented, quite clearly, in the PC-DOS 3.0 (3.1?) >manual. Maybe your documentation is missing it... I can't even guess. > >Supposedly, this was considered a problem in DOS 2.0. Personally, I've never >had a real desire to know what argv[0] is. MS-DOS doesn't support links >(hard or symbolic), so each file has a unique name. But I can see where >you might want to be really friendly or something, and parse argv[0]. This is true, it is documented in the section discussing the Program Segment Prefix in the PC-DOS Technical Reference Guide, at least for versions 3.10 and up. Anyone want to discuss other "documented" things? I have a new favorite "documented" thing that I found recently. I am creating a program called "psh" (a csh workalike, generally) that, by its very nature, must use the DOS Exec function. In the documentation for the Exec function, it clearly tells you how to give the Exec function its parameter block, which includes a pointer to an argument line. Now, it never tells you about the parameter line, except that it should be a string with a byte telling the length of the string in the first position. It does, however, tell you about it in the section on the Program Segment Prefix. The most interesting thing about this is that the command line MUST BE IN A PARTICULAR FORMAT. This is not documented even once in the text, but instead in an oblique reference in the map of the PSP. The format REQUIRED by almost every MS-DOS utility is to have a space preceeding every parameter in the line. Even the first one. The map of the PSP tells you this as follows: "parameter string with spaces preceeding each parameter" or something very similar to this. If you forget that space, *nothing* works. EDLIN won't. CHKDSK will, but improperly (it won't pick up the drive specifier). Regular programs run fine, though, since I presume whoever wrote them didn't make their code dependent on that space (since it really isn't well documented). I found it by tracing the passing of everything to programs by both my program and COMMAND.COM until I found a difference. In addition, there is at least one mistake that is clearly documented in the section dealing with invoking a command processor from a program. My manuals say that when invoking the command processor, you should pass it the argument string FOLLOWED BY A CARRIAGE RETURN. This will work, but is not DOS-standard. There is no mention of the leading space in this section, either, or even in the example assembler code that they give you. Note that COMMAND.COM does not require the leading space, but it is about the only supplied program I found that does not. Another interesting note: FORMAT will not work even with the space problem fixed. Does anyone know what they did when they made FORMAT? I'd be very, very interested in knowing. I pass each program a perfect match for the command line and also a good FCB if possible. My FCB building routines fail in some circumstances, but so do DOS's (although in a different manner) so I don't worry about it. It gets a perfect environment, too. Yet it gives me an "invalid parameter" error whenever I try to run FORMAT. Tracing the COMMAND.COM parameters showed absolutely *no* differences between my parameters and those passed by COMMAND.COM, yet FORMAT works with COMMAND.COM and not with my program. I suspect more Microsoft assumptions on who is calling the program. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd H H | ARPA: madd@bucsb.bu.edu H-C-C-OH <- heehee +---------+---------------------------------- H H | "We are strangers in a world we never made"
ayac071@ut-ngp.UUCP (William T. Douglass) (08/04/87)
>FORMAT will not work even with the space problem fixed. Does anyone know >what they did when they made FORMAT? I'd be very, very interested in >knowing. I pass each program a perfect match for the command line and >also a good FCB if possible. My FCB building routines fail in some >circumstances, but so do DOS's (although in a different manner) so I >don't worry about it. It gets a perfect environment, too. Yet it >gives me an "invalid parameter" error whenever I try to run FORMAT. I would suspect the FCB's. My working with EXEC and format indicated that the FORMAT command does indeed pull its parameters from the FCB that DOS sets up before executing the program. If there is a bug in your FCB routine, that could kill the program right there. I set up my call to EXEC to parse the FCB with the relevent DOS call (don't have the function # right now), but will be glad to e-mail the whole program to you if interested. Bill Douglass ayac071@ngp.UUCP