Date:	Mon, 15 Jul 1996 23:21:40 +0100
Message-Id:	<199607152221.XAA00067@sirius.demon.co.uk>
From:	D C Haslam <dch AT sirius DOT demon DOT co DOT uk>
To:	eliz AT is DOT elta DOT co DOT il
CC:	djgpp AT delorie DOT com
In-reply-to:	<Pine.SUN.3.91.960711120121.7062A-100000@is> (message from Eli
	Zaretskii on Thu, 11 Jul 1996 12:09:12 +0200 (IST))
Subject:	Re: Emacs 19.31 - LFN doesn't work

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 
> On Wed, 10 Jul 1996, D C Haslam wrote:
> 
> > The reason emacs.exe has _crt0_startup_flags preset with 0xC00 is
> > because it is generated by temacs dumping itself.
> > At the time of the build LFN=n, and so temacs will have the 
> > _CRT0_FLAG_NO_LFN flag set. This gets copied into the emacs executable.
> > 
> > I have now unpacked and built again using LFN=y and LFN is now 
> > working fine.
> 
> Thanks for debugging this.  However, I think that telling people to build 
> with LFN=y is not the best way to solve the problem, because it will 
> prevent an executable that was built on MSDOS to run correctly on Win95.  
> So please try to build Emacs with the patches below and see if LFN works 
> even if you build Emacs with LFN=n.  I cannot test this on Win95, but if 
> you tell me it works, I will make sure that this patch gets into the next 
> release of GNU Emacs.

OK, the patch itself works. The dumped emacs doesn't have the
_CRT0_FLAG_NO_LFN flag set. But now there's another problem. Because I
set LFN=n when untarring, the names of some of the lisp files are
crunched. Now when I run emacs with LFN=y it tries to open the files
with the long names and can't find them. I had to rename font-loc.elc
and case-tab.elc back to their long names before emacs would run.

I'm wondering if expecting an MSDOS build of emacs to run in an LFN
environment is just asking too much. Emacs is more than just the
executable.

- Raw text -