GNU bug report logs -
#8562
Emacs 23.1 and later don't work in windows 98
Previous Next
Reported by: oslsachem <oslsachem <at> gmail.com>
Date: Tue, 26 Apr 2011 21:59:01 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #161 received at 8562 <at> debbugs.gnu.org (full text, mbox):
>> 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.
>
I have checked that myself too, out of disbelief, after observing the
windows 98 GUI behaviour stated later on.
> 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?
I have patched Emacs and that omission doesn't seem to affect this problem.
However:
- I have commented out the message box code (w32font.c:197) and
replaced it with just 'exit(1)':
After this change, runemacs.exe launches emacs.exe and now this
process ends instead of staying in the background.
- I have changed the value of start.wShowWindow to SW_SHOW (runemacs.c:148):
After this change, the unicows.dll error dialog window is shown (with
a console window behind it, which actually defeats the purpose of
runemacs.exe to begin with)
From this I guess that:
- the messagebox is actually hidden even though it is waiting for
input from the user.
- the visibility of the messagebox is linked to the visibility of the
console window created for the process from which it is called ( Even
though this behaviour can't be reproduced in windows XP)
Besides:
- I have changed the value of priority_class to NORMAL_PRIORITY_CLASS
| DETACHED_PROCESS (runemacs.c:56):
After this change, the emacs.exe process doesn't have a console window
created for it, and the error dialog window is shown without a console
window behind it.
I have used runemacs.exe with unicows.dll after this change too, and
Emacs seems to run without problems and without showing a console
window.
I was wondering if Emacs requires a console window to operate
correctly (even if it can be hidden), or if it can run without having
a console window created for it (and so it would not need to be
hidden).
Greetings,
Osl
This bug report was last modified 13 years and 201 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.