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

[Eli Zaretskii]

> Date: Fri, 6 May 2011 03:38:46 +0200
> From: oslsachem <oslsachem@gmail.com>
> 
> > Which suggested solution is that?  There were 2 in that thread.
> 
> To be honest, I only tried the first one ("start Emacs from the
> command-line as: emacs -Q -xrm Emacs.fontBackend:gdi") because:
> 
> - I deemed them to be functionally equivalent.
> 
> - The second solution involves editing the windows registry (which is
> a frail but essential part of the system).
> 
> - Emacs doesn't seem to add any entry to the windows registry after
> running the "addpm.exe" as opposed to what is stated at
> http://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dWindows-Registry.html
> 
> - The "set Emacs.fontBackend in the registry" indication is too terse
> for me to understand.

No, I meant the suggestion to try resizing the Emacs window by
dragging its borders with the mouse.  But I guess that's a moot point,
now that it's clear that the problem is allocation of glyph matrices,
see below.

> > Anyway, Emacs developers need help to debug this, as none of us has
> > access to a Windows 9X machine anymore.  If you are willing to work
> > with us, I'm sure we will find the solution.
> 
> Of course, just tell me what I have to do :).

Thanks.

> Here is a log of the debugger after spending a while fiddling with the
> Emacs submenus until a fatal error happens:
> 
> http://www.speedyshare.com/files/28318621/gdb.txt

It crashes because current_matrix is a NULL pointer, i.e. the display
engine somehow did not create the glyph matrices it needs to display
Emacs windows.

> Note: I tried to build Emacs using the --no-opt option for configure
> but when trying to run Emacs using the debugger, gdb produced an error
> ("internal-error: virtual memory exhausted: can't allocate ..........
> bytes. A problem internal to GDB has been detected, further debugging
> may prove unreliable") so I have built Emacs without --no-opt ( I
> guess that is why the executables end up in oo-spd/i386 instead of
> oo/i386).

We actually need to be able to debug a binary produced with --no-opt,
since debugging an optimized binary is hopeless.  What versions of GCC
and GDB do you have?

Also, since you are able to build your own Emacs binary, it would be
best to use one of the versions that are currently being maintained:
either the emacs-23 branch or the trunk of the Emacs bzr repository.
Would that be possible for you?  Bazaar can be installed on Windows by
downloading this installer:

  http://launchpad.net/bzr/2.3/2.3.1/+download/bzr-2.3.1-1-setup.exe

If this is hard or bumps into problems, it's not a catastrophe; we can
continue debugging Emacs 23.3.

In any case, being able to debug a --no-opt binary is imperative.
Please try solving that problem, perhaps by up- or down-grading to
other versions of GCC or GDB.

Thanks.