From: eplmst AT lu DOT erisoft DOT se (Martin Stromberg) Newsgroups: comp.os.msdos.djgpp Subject: Re: Freedos, INT 0x21, AX=0x71a0 and emacs Date: 23 Mar 2001 12:31:47 GMT Organization: Ericsson Erisoft AB, Sweden Lines: 84 Message-ID: <99ffnj$lq1$1@antares.lu.erisoft.se> References: <99cfks$cbt$1 AT antares DOT lu DOT erisoft DOT se> <99dikd$ftj$1 AT news DOT luth DOT se> <2110-Fri23Mar2001131056+0200-eliz AT is DOT elta DOT co DOT il> NNTP-Posting-Host: lws256.lu.erisoft.se X-Newsreader: TIN [version 1.2 PL2] To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote: : > From: Martin Str|mberg : > Newsgroups: comp.os.msdos.djgpp : > Date: Thu, 22 Mar 2001 19:09:01 +0000 (UTC) : > : > : : This is already done by the library. Except that, in FreeDOS's case, : > : : I understand that 71A0h doesn't return ENOSYS, so the library thinks : > : : something else went wrong, and doesn't cache the return value. See : > : : the source of _use_lfn; I think we discussed this a while ago, and you : > : : said the problem is going to be solved in the next release of FreeDOS. : > : > : Now I'm really confused. Unsupported INT 0x21 calls should set AL to : > : zero according to you and other persons. How is FreeDOS going to be : > : able to set AX to an error value in that case? : > : > : Hmm... (Digging in the use_lfn() source...) Ok. You mean : > : _get_volume_info() instead 71A0h above returning ENOSYS. I think with : > : the FreeDOS kernel I tried _get_volume_info() really returns ENOSYS : > : (or at least should), but I have to check it. : > : > Ok, now I've checked and my FreeDOS kernel do make _get_volume_info() : > set errno to ENOSYS and return 0. : > : > So if I understood you correctly there ought to be bug somewhere (in : > DJGGP or emacs) because there should only one calls to it in that case : > but I see several. : I'm not sure there's a bug; Emacs doesn't do anything that any other : DJGPP program would do. Please step with a debugger into _use_lfn and : see what happens there. : What you describe can and should happen if 71A0h doesn't return 71h : in the AH register. In that case, the library function : `_get_volume_info' does this: : if (r.h.ah == 0x71) : { This is executed. : errno = ENOSYS; : retval = 0; /* meaning none of the features supported */ : } : else : { : /* If the call failed, but not because the OS doesn't support : the function (e.g., invalid drive), don't disable LFN. */ : errno = __doserr_to_errno(r.x.ax); : retval = _FILESYS_UNKNOWN; : } : If FreeDOS doesn't return 71h in the AH register, this will return : _FILESYS_UNKNOWN. The function `_use_lfn' then does this: Sure but it's not relevant as the branch indicated above is taken. : if (!same_drive_as_last_time || filesystem_flags == _FILESYS_UNKNOWN) : filesystem_flags = _get_volume_info (path, 0, 0, 0); : /* If _get_volume_info failed (e.g., an invalid drive letter), : leave the previous LFN setting alone. */ : if (filesystem_flags == _FILESYS_UNKNOWN) : { : _lfnenv = old_lfn_flag; : last_drive = 0; : return _lfnenv != 'n'; : } : In other words, if `_get_volume_info' returns _FILESYS_UNKNOWN, the : result is not cached for future calls to `_use_lfn', because : `_use_lfn' suspects that the call failed because some problem that is : irrelevant to whether LFN is or isn't supported, e.g. if the drive : letter was invalid. Instead of caching the result in : filesystem_flags, `_use_lfn' leaves _FILESYS_UNKNOWN there. This in : turn will cause the next call to `_use_lfn' call `_get_volume_info' : again and again... As I said _get_volume_info() returns 0. Right, MartinS