delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/03/23/08:02:09

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: <Pine DOT SUN DOT 3 DOT 91 DOT 1010322094711 DOT 7564F-100000 AT is> <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 <ams AT father DOT ludd DOT luth DOT se>
: > 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019