From: Martin Str|mberg Newsgroups: comp.os.msdos.djgpp Subject: Re: Freedos, INT 0x21, AX=0x71a0 and emacs Date: Wed, 21 Mar 2001 21:47:19 +0000 (UTC) Organization: University of Lulea, Sweden Lines: 45 Message-ID: <99b7h7$eg9$1@news.luth.se> References: <99asp4$9a2$1 AT news DOT luth DOT se> <1438-Wed21Mar2001214222+0200-eliz AT is DOT elta DOT co DOT il> X-Trace: news.luth.se 985211239 14857 130.240.16.18 (21 Mar 2001 21:47:19 GMT) X-Complaints-To: abuse AT luth DOT se User-Agent: tin/pre-1.4-981225 ("Volcane") (UNIX) (SunOS/4.1.4 (sun4m)) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: :> From: Martin Str|mberg :> Newsgroups: comp.os.msdos.djgpp :> Date: Wed, 21 Mar 2001 18:43:48 +0000 (UTC) :> :> FreeDOS does not support LFN so I find that every program generates :> one INT 0x21, AX=0x71a0 at start-up. This is expected. :> :> However when I start emacs there are many (more than 25) calls to this :> function. That seems like a waste. Is emacs designed to behave like :> this or is there a bug lurking somewhere? : It's not a bug. The library startup code issues one call to 71A0h, to : find out whether LFN is supported, and then caches the result to be : used by all library functions. : But Emacs also needs this information in its application code, to know : whether a certain feature which requires long file names can or cannot : be used. There's a special function, msdos-long-file-names, which : returns nil or t depending on whether LFN is or isn't supported. What : you see is the 71A0h calls that function emits. : 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 ); } Right, MartinS