Date: Mon, 15 Jul 1996 23:21:40 +0100 Message-Id: <199607152221.XAA00067@sirius.demon.co.uk> From: D C Haslam To: eliz AT is DOT elta DOT co DOT il CC: djgpp AT delorie DOT com In-reply-to: (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 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.