bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8562: Emacs 23.1 and later don't work in windows 98


From: Eli Zaretskii
Subject: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 28 Oct 2011 14:11:24 +0200

> Date: Fri, 28 Oct 2011 12:21:12 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > Date: Thu, 27 Oct 2011 21:38:55 +0200
> > From: oslsachem <address@hidden>
> > 
> > > Which process stays hidden -- the original runemacs.exe or emacs.exe
> > > that is run by runemacs.exe?
> > 
> > Judging by the GDB log
> > 
> > http://www.speedyshare.com/files/30954233/RunemacsGDB.txt
> > 
> >  and the process viewer window (WinTop)
> > 
> > http://www.speedyshare.com/files/30954234/RunemacsProcessViewer.png
> > 
> > , I would say that the original runemacs.exe process exits
> > successfully after launching the emacs.exe process, which is the one
> > that stays hidden in the background.
> 
> It is strange that I cannot reproduce this on my XP box.  (I simulated
> a Windows 9X system by inverting the is_9x test in
> w32_load_unicows_or_gdi32, and modified the name of the DLL to
> something that doesn't exist on my system.)  When I run "runemacs -Q"
> both from the command prompt and from a desktop shortcut, I get the
> abort dialog in both cases telling that UNICOWS.DLL was not found etc.

There was a bug in my changes: the function w32_load_unicows_or_gdi32
lacked a "return" statement.  Someone noticed this and fixed it in the
Emacs repository.  This bug could cause random failures, and perhaps
also the problem you describe.  Could you please apply the patch below
and see if the problem with invoking Emacs via runemacs is gone,
i.e. if unicows.dll is not present, Emacs now pops up the dialog
saying so?

--- a/src/w32font.c     2011-10-28 09:54:02 +0000
+++ b/src/w32font.c     2011-10-28 10:59:24 +0000
@@ -216,6 +216,7 @@
     }
   else
     ret = LoadLibrary ("Gdi32.dll");
+  return ret;
 }
 
 /* The following 3 functions call the problematic "wide" APIs via





reply via email to

[Prev in Thread] Current Thread [Next in Thread]