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: 22 Mar 2001 09:11:56 GMT
Organization: Ericsson Erisoft AB, Sweden
Lines: 42
Message-ID: <99cfks$cbt$1@antares.lu.erisoft.se>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010322094711 DOT 7564F-100000 AT is>
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:

: On Wed, 21 Mar 2001, Martin Str|mberg wrote:

: > : In other words, Emacs is simply a program that checks whether LFN is
: > : supported in many places in its application code, while other programs
: > : you tested do not do that.
: > 
: > Ok. But it still seems wasteful. Can't the msdos-long-file-names function
: > be done like this C:
: > 
: > Bool msdos-long-file-names(void)
: > {
: > 	static int lfn = -1;
: > 
: > 	if( lfn < 0)
: > 	{
: > 		lfn = result_from_nice_call_to_DOZE();
: > 	}
: > 
: > 	return( lfn );
: > }

: 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.


Right,

						MartinS