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: oslsachem
Subject: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 30 Oct 2011 00:24:31 +0200

>> 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





reply via email to

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