GNU bug report logs - #8562
Emacs 23.1 and later don't work in windows 98

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8562 in the body.
You can then email your comments to 8562 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 23.1 and later don't work in windows 98
Date: Tue, 26 Apr 2011 23:55:46 +0200

[Message part 1 (text/plain, inline)]

Hi, emacs no longer works under windows 98 since emacs version 23.1.

It worked with version 22.3.

This problem has been already reported at
http://lists.gnu.org/archive/html/help-emacs-windows/2009-09/msg00042.html

The suggested solution doesn't seem to work.


Note:
If maintaining compatibility with outdated versions of windows is no longer
relevant then the information provided at
http://www.gnu.org/software/emacs/windows/Introduction.html#Introduction
should be revised.

Anecdotal note:
I took my chances by posing this problem at #emacs freenode irc channel.
I was told that perhaps it was time to upgrade to windows Me.
I ascertained that this guy didn't work for microsoft.
It serves me right for trying to take a shortcut to posting to the mailing
list.

Greetings,
                Osl

[Message part 2 (text/html, inline)]

Message #8 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 27 Apr 2011 06:09:03 +0300

> Date: Tue, 26 Apr 2011 23:55:46 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> 
> Hi, emacs no longer works under windows 98 since emacs version 23.1.
> 
> It worked with version 22.3.
> 
> This problem has been already reported at
> http://lists.gnu.org/archive/html/help-emacs-windows/2009-09/msg00042.html
> 
> The suggested solution doesn't seem to work.

Which suggested solution is that?  There were 2 in that thread.

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.

And no, we don't want to discontinue support for running Emacs on
Windows 9X, not yet anyway.

TIA

Message #11 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 6 May 2011 03:38:46 +0200

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


> 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 :).

Here you have "updated" screenshots of what Emacs-23.3 looks like in
windows 98 when started in GUI mode:

Initial size:

http://www.speedyshare.com/files/28318597/EmacsInitialSize.png

Maximized size:

http://www.speedyshare.com/files/28318598/EmacsMaximized.png

File submenu:

http://www.speedyshare.com/files/28318599/EmacsFileSubmenu.png

Edit submenu:

http://www.speedyshare.com/files/28318600/EmacsEditSubmenu.png

The Options and Buffers submenus look hidden but are there:

http://www.speedyshare.com/files/28318601/EmacsOptionsSubmenu.png

http://www.speedyshare.com/files/28318602/EmacsBuffersSubmenu.png

Emacs abort dialog when it eventually has a fatal error:

http://www.speedyshare.com/files/28318603/EmacsAbortDialog.png

Spanish version of Windows 98 error message:  "This program has
performed an illegal operation and will be shut down.  If the problem
persists, contact the program vendor. [Close] [Details]":
Inside the text box, spanish version of Windows 98 error message:
"EMACS caused an invalid page fault in module EMACS.EXE".

     First part:

    http://www.speedyshare.com/files/28318604/EmacsPageFault1stPart.png

    Second part:

    http://www.speedyshare.com/files/28318605/EmacsPageFault2ndPart.png

In the meantime, I've been skimming through the instructions about
compiling and debugging Emacs and I have managed to build Emacs
succesfully and run it using the debugger.

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

Notice that I run Emacs more than once and that, the last time,
running Emacs using the suggested solution doesn't produce any
noticeable difference (i.e the fatal error is the same).

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


Unrelated note:
Sorry for the poor text format of my previous message.  I failed to
notice that I was using rich text format instead of plain text.
Hopefully this message will look better.

Message #14 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 06 May 2011 14:52:04 +0300

> Date: Fri, 6 May 2011 03:38:46 +0200
> From: oslsachem <oslsachem <at> 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.

Message #17 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <at> gmail.com
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 06 May 2011 18:28:32 +0300

> Date: Fri, 06 May 2011 14:52:04 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 8562 <at> debbugs.gnu.org
> 
> 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.

Alternatively, compile only a few files without optimizations; maybe
that will stop GDB from crashing.  For starters, we need w32.c,
w32fns.c, w32term.c, dispnew.c and xdisp.c compiled like that.  Please
be sure to use the "-gdwarf-2 -g3" switches when you do that.

Message #20 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 22 May 2011 23:32:22 +0200

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

http://www.speedyshare.com/files/28593335/ProgramsVersions.txt

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

I have tried to build the trunk of the Emacs bzr repository under
Windows 98 but the building process gets stuck at a line which
presumably can't be handled by command.com or win95cmd.exe (more about
it below) because it makes use of standard handles redirection (2>&1)
and logical operators (||) and because win98's version of fc doesn't
seem to output a value for || to use (in the case of win95cmd.exe,
MinGW's version of cmp can be used for this).

After this, the bootstrapping process fails to compile some lisp files
showing fatal error dialogs and, after accepting them, skips those
files and continues with the building process. I didn't get to the end
of it because eventually there were too many lisp files that prompted
an error dialog window and required input from me to continue.

I've tried to copy a lisp directory with precompiled lisp files and
build from there without bootstrapping.

http://www.speedyshare.com/files/28593336/EmacsTrunkConfigureW98.txt

http://www.speedyshare.com/files/28593337/EmacsTrunkMakeW98.txt

http://www.speedyshare.com/files/28593338/EmacsTrunkMakeInstallW98.txt

And this is a GDB session:

http://www.speedyshare.com/files/28593339/EmacsTrunkGDBW98.txt

And I have tried running these same binaries under windows XP:

http://www.speedyshare.com/files/28593340/EmacsTrunkGDBW98WXP.txt

I have been able to build the trunk of the Emacs bzr repository under
Windows XP (using exacly the same version of MinGW), although the
bootstrapping process prompts me with a new command line shell
instance inside the original one and stops, and I have to type "exit"
to continue with the building process.

I provide the logs:

http://www.speedyshare.com/files/28593341/EmacsTrunkConfigureWXP.txt

http://www.speedyshare.com/files/28593342/EmacsTrunkMakeWXP.txt

http://www.speedyshare.com/files/28593343/EmacsTrunkMakeInstallWXP.txt

I have copied those binaries with their corresponding source files
from Windows XP to the windows 98 system, and the same graphical
glitch still appears, though this isn't reflected in the debugging
session which doesn't show any error. Superficially, the program is
functional: I can write to the *scratch* buffer (though it isn't
visible) and save it to a file. Not only the application window is
clipped to a small size but the tooltip rectangles as well. They
appear as small squares of a few pixels of side.

http://www.speedyshare.com/files/28593344/EmacsTrunkGDBWXPW98.txt

Is it necessary that the binaries are built on the same OS that they
are going to be debugged in?
Obviously, the official binary release of the Windows version of Emacs
is going to be "cross-compiled" but berhaps an error spotted on the
"natively built" binaries could give a hint about the cause of the
graphical glitch? Or could it become an added problem to solve?

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

I have been able to build non-optimized binaries of Emacs 23.3 (that
is, with a symbol table that GDB can read) by using an alternative
command line shell from microsoft named Win95Cmd.exe ( from
http://ftp.uni-erlangen.de/mirrors/cygwin32.old/porters/Wilson_Charles_S/consize/index.html
).
Down-grading to other versions of GCC or GDB (I was using the latest
versions available from MinGW) didn't change the results.

http://www.speedyshare.com/files/28593345/Emacs-23.3ConfigureW98.txt

http://www.speedyshare.com/files/28593346/Emacs-23.3MakeW98.txt

http://www.speedyshare.com/files/28593347/Emacs-23.3MakeInstallW98.txt

Unlike when I used the officially released binaries, I couldn't even
get to the initial Emacs window by executing these binaries (either
from Emacs-23.3 or from bazaar's trunk). The process was interrupted
with a fatal error (though the -nw version (text console) worked
without problems).

I provide the log of a GDB session:

http://www.speedyshare.com/files/28593348/Emacs-23.3GDBW98.txt

I have tried running that binary under windows XP with identical result:

http://www.speedyshare.com/files/28593349/Emacs-23.3GDBW98WXP.txt

I have tried building Emacs-23.3 under windows XP and debugging it
under windows 98 (by copying the whole directory). It hangs showing a
fatal error too, but at least the initial Emacs window appears (though
still at that small size)

http://www.speedyshare.com/files/28593350/Emacs-23.3GDBWXPW98.txt

Lastly, I have noticed that, when I run Emacs-22.3 (which I can both
build and execute under Windows 98 without errors or graphical
glitches) inside GDB, a "-geometry" option flag with a default initial
window size appears automatically appended to the binary name in the
debugger output. This doesn't happen in the other versions of Emacs
(23.3 or Trunk). I provide the log for this:

http://www.speedyshare.com/files/28593351/Emacs-22.3GDBW98.txt

cheers,
             Osl

Message #23 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Mon, 23 May 2011 21:43:40 +0800

oslsachem <oslsachem <at> gmail.com> writes:

> Is it necessary that the binaries are built on the same OS that they
> are going to be debugged in?

No, the main thing is that you have the source that you know matches the
binary you are running.

From http://www11.speedyshare.com/files/28593350/download/Emacs-23.3GDBWXPW98.txt

--8<---------------cut here---------------start------------->8---
Program received signal SIGSEGV, Segmentation fault.
0x01051020 in display_mode_line (w=0x3495c00, face_id=MODE_LINE_FACE_ID, 
    format=46642574) at xdisp.c:17289
17289	      last->right_box_line_p = 1;
(gdb) warning: clipped frame 03495000 (EMACS <at> OEMCOMPUTER) got WM_PAINT - ignored

list
17284	  extend_face_to_end_of_line (&it);
17285	  if (face->box != FACE_NO_BOX)
17286	    {
17287	      struct glyph *last = (it.glyph_row->glyphs[TEXT_AREA]
17288				    + it.glyph_row->used[TEXT_AREA] - 1);
17289	      last->right_box_line_p = 1;
17290	    }
17291	
17292	  return it.glyph_row->height;
17293	}
(gdb) where
#0  0x01051020 in display_mode_line (w=0x3495c00, face_id=MODE_LINE_FACE_ID, 
    format=46642574) at xdisp.c:17289
--8<---------------cut here---------------end--------------->8---

It appears that the pointer last is invalid here. What are the values of
it.glyph_row->glyphs[TEXT_AREA] and it.glyph_row->used[TEXT_AREA]?

Message #26 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Mon, 23 May 2011 20:39:16 +0300

> Date: Sun, 22 May 2011 23:32:22 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> I have tried building Emacs-23.3 under windows XP and debugging it
> under windows 98 (by copying the whole directory). It hangs showing a
> fatal error too, but at least the initial Emacs window appears (though
> still at that small size)
> 
> http://www.speedyshare.com/files/28593350/Emacs-23.3GDBWXPW98.txt

Thank you for all your efforts.  I think we are getting somewhere.

> Program received signal SIGSEGV, Segmentation fault.
> 0x01051020 in display_mode_line (w=0x3495c00, face_id=MODE_LINE_FACE_ID, 
>     format=46642574) at xdisp.c:17289
> 17289	      last->right_box_line_p = 1;
> (gdb) warning: clipped frame 03495000 (EMACS <at> OEMCOMPUTER) got WM_PAINT - ignored
> 
> list
> 17284	  extend_face_to_end_of_line (&it);
> 17285	  if (face->box != FACE_NO_BOX)
> 17286	    {
> 17287	      struct glyph *last = (it.glyph_row->glyphs[TEXT_AREA]
> 17288				    + it.glyph_row->used[TEXT_AREA] - 1);
> 17289	      last->right_box_line_p = 1;
> 17290	    }
> 17291	
> 17292	  return it.glyph_row->height;
> 17293	}

As Jason requested, please show the values of
it.glyph_row->glyphs[TEXT_AREA] and it.glyph_row->used[TEXT_AREA].

I suspect that the former is a valid address, but the latter is zero.

I think at this stage we need more help from Emacs.  I'm sorry to ask
you to do another build, but could you perhaps compile Emacs again (on
Windows XP will probably be the best in terms of not wasting too much
of your time), and this time manually edit src/makefile to add the
following compiler flags to CFLAGS:

   -DENABLE_CHECKING -DXASSERTS

Then delete src/oo/i386/*.o and type "make" again.

This will enable additional checking in various places in Emacs.  If
we are lucky, you will see Emacs aborting somewhere earlier during its
startup, and that will hopefully show us the problem which leads to
this crash.

Thanks again.

Message #29 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 24 May 2011 21:31:24 +0200

> > Is it necessary that the binaries are built on the same OS that they
> > are going to be debugged in?
>
> No, the main thing is that you have the source that you know matches the
> binary you are running.

Ok, thanks.

> It appears that the pointer last is invalid here. What are the values of
> it.glyph_row->glyphs[TEXT_AREA] and it.glyph_row->used[TEXT_AREA]?
>

A new GDB session with the additional information:

http://www.speedyshare.com/files/28627434/Emacs-23.3GDBValues.txt

Greetings,
                Osl

Message #32 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 24 May 2011 21:32:05 +0200

> I think at this stage we need more help from Emacs.  I'm sorry to ask
> you to do another build, but could you perhaps compile Emacs again ...

No problem, really. :)
Just tell me what you need me to do.

> ... , and this time manually edit src/makefile to add the
> following compiler flags to CFLAGS:
>
>   -DENABLE_CHECKING -DXASSERTS

http://www.speedyshare.com/files/28627435/makefile

> Then delete src/oo/i386/*.o ...

http://www.speedyshare.com/files/28627555/deletions.txt

> ...and type "make" again.

http://www.speedyshare.com/files/28627436/Emacs-23.3Make.txt

http://www.speedyshare.com/files/28627437/Emacs-23.3MakeInstall.txt

> This will enable additional checking in various places in Emacs.  If
> we are lucky, you will see Emacs aborting somewhere earlier during its
> startup, and that will hopefully show us the problem which leads to
> this crash.

http://www.speedyshare.com/files/28627438/Emacs-23.3GDBCFlags.txt

Greetings,
                Osl

Message #35 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 24 May 2011 23:37:55 +0300

> Date: Tue, 24 May 2011 21:32:05 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > This will enable additional checking in various places in Emacs.  If
> > we are lucky, you will see Emacs aborting somewhere earlier during its
> > startup, and that will hopefully show us the problem which leads to
> > this crash.
> 
> http://www.speedyshare.com/files/28627438/Emacs-23.3GDBCFlags.txt
> 
> (gdb) where
> #0  w32_abort () at w32fns.c:7365
> #1  0x01050284 in window_box_height (w=0x37f3c00) at xdisp.c:1104
> #2  0x01207f8b in required_matrix_height (w=0x37f3c00) at dispnew.c:1999

Thanks.  It aborts here:

    INLINE int
    window_box_height (w)
	 struct window *w;
    {
      struct frame *f = XFRAME (w->frame);
      int height = WINDOW_TOTAL_HEIGHT (w);

      xassert (height >= 0);  <<<<<<<<<<<<<<<<<<<<<

Which means the value of height is non-positive.  So please go to
frame #1 and show the values of height, w->total_lines and
w->total_cols.  I suspect that they are all zero.  If that is true,
please see how did that happen, because the function make_frame was
supposed to set this window (the root window of the newly created
frame) to 10x10 dimensions, around line 385:

  /* 10 is arbitrary,
     just so that there is "something there."
     Correct size will be set up later with change_frame_size.  */

  SET_FRAME_COLS (f, 10);
  FRAME_LINES (f) = 10;

  XSETFASTINT (XWINDOW (root_window)->total_cols, 10);
  XSETFASTINT (XWINDOW (root_window)->total_lines, (mini_p ? 9 : 10));

If total_lines and total_cols get the right values here, then please
set a watchpoint on these fields, or step through the code between the
above and where it aborts, and see where they are reset to zero.

Thanks.

Message #38 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 25 May 2011 04:01:22 +0200

> Which means the value of height is non-positive.  So please go to
> frame #1 and show the values of height, w->total_lines and
> w->total_cols ...

> ... the function make_frame was
> supposed to set this window (the root window of the newly created
> frame) to 10x10 dimensions, around line 385:
>
>  /* 10 is arbitrary,
>     just so that there is "something there."
>     Correct size will be set up later with change_frame_size.  */
>
>  SET_FRAME_COLS (f, 10);
>  FRAME_LINES (f) = 10;
>
>  XSETFASTINT (XWINDOW (root_window)->total_cols, 10);
>  XSETFASTINT (XWINDOW (root_window)->total_lines, (mini_p ? 9 : 10));
>
> If total_lines and total_cols get the right values here, then please
> set a watchpoint on these fields, or step through the code between the
> above and where it aborts, and see where they are reset to zero.

http://www.speedyshare.com/files/28632428/Emacs-23.3GDBframe1.txt

greetings,
                 Osl

Message #41 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 25 May 2011 00:28:34 -0400

> Date: Wed, 25 May 2011 04:01:22 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > If total_lines and total_cols get the right values here, then please
> > set a watchpoint on these fields, or step through the code between the
> > above and where it aborts, and see where they are reset to zero.
> 
> http://www.speedyshare.com/files/28632428/Emacs-23.3GDBframe1.txt

This shows that my guess was wrong:

  (gdb) frame 1
  #1  0x01050284 in window_box_height (w=0x37f3c00) at xdisp.c:1104
  1104	         xassert (height >= 0);
  (gdb) p height
  $1 = -482614272
  (gdb) p w->total_lines
  $2 = 32
  (gdb) p w->total_cols
  $3 = 40

The problem is not the window dimensions, which look fine, but
something else.  `height' is computed like this:

  int height = WINDOW_TOTAL_HEIGHT (w);

WINDOW_TOTAL_HEIGHT is defined like this:

  #define WINDOW_TOTAL_HEIGHT(W) \
    (WINDOW_TOTAL_LINES (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  #define WINDOW_TOTAL_LINES(W) \
    (XFASTINT ((W)->total_lines))
  #define WINDOW_FRAME_LINE_HEIGHT(W) \
    (FRAME_LINE_HEIGHT (WINDOW_XFRAME ((W))))
  #define FRAME_LINE_HEIGHT(F) ((F)->line_height)

So the problem must be that FRAME_LINE_HEIGHT (WINDOW_XFRAME ((W)))
returns a negative value.  Can you verify that?  In frame #1, please
type "print f->line_height" and see if the value is negative or maybe a
large positive (which causes the multiplication in WINDOW_TOTAL_HEIGHT
to overflow).

If the value of f->line_height is indeed bogus, please put a
breakpoint in x_new_font, run Emacs again, and when the breakpoint
breaks, step through that function and see why it doesn't put a valid
value into this field.  This should happen on line 5280 of w32term.c:

  FRAME_LINE_HEIGHT (f) = font->height;

If this indeed assigns a bogus value, please show the contents of the
`font' structure ("print *font" at GDB prompt).

Thanks.

Message #44 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 25 May 2011 12:53:29 +0200

> So the problem must be that FRAME_LINE_HEIGHT (WINDOW_XFRAME ((W)))
> returns a negative value.  Can you verify that?  In frame #1, please
> type "print f->line_height" and see if the value is negative or maybe a
> large positive (which causes the multiplication in WINDOW_TOTAL_HEIGHT
> to overflow).
>
> If the value of f->line_height is indeed bogus, please put a
> breakpoint in x_new_font, run Emacs again, and when the breakpoint
> breaks, step through that function and see why it doesn't put a valid
> value into this field.  This should happen on line 5280 of w32term.c:
>
>  FRAME_LINE_HEIGHT (f) = font->height;
>
> If this indeed assigns a bogus value, please show the contents of the
> `font' structure ("print *font" at GDB prompt).

http://www.speedyshare.com/files/28635231/Emacs-23.3GDBfont.txt


Greetings,
                Osl

Message #47 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 25 May 2011 19:44:31 +0300

> Date: Wed, 25 May 2011 12:53:29 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > If the value of f->line_height is indeed bogus, please put a
> > breakpoint in x_new_font, run Emacs again, and when the breakpoint
> > breaks, step through that function and see why it doesn't put a valid
> > value into this field.  This should happen on line 5280 of w32term.c:
> >
> >  FRAME_LINE_HEIGHT (f) = font->height;
> >
> > If this indeed assigns a bogus value, please show the contents of the
> > `font' structure ("print *font" at GDB prompt).
> 
> http://www.speedyshare.com/files/28635231/Emacs-23.3GDBfont.txt

> (gdb) p font->height
> $2 = 2087156864
> (gdb) p *font
> $3 = {
>   size = 1075838994, 
>   next = 0x37fc800, 
>   props = {50024618, 50024882, 52291426, 50024834, 50018570, 102720, 102528, 
>     102656, 52, 49805314, 440, 49805314, 50073638, 49805314, 52216865, 
>     52216881, 49805314, 50018522}, 
>   max_width = 2113995264, 
>   pixel_size = 13, 
>   height = 2087156864, 
>   space_width = 101581574, 
>   average_width = 101581574, 
>   min_width = 101581574, 
>   ascent = 2053600883, 
>   descent = 33555981, 
>   underline_thickness = 0, 
>   underline_position = -1, 
>   vertical_centering = 0, 
>   encoding_type = 0 '\000', 
>   baseline_offset = 0, 
>   relative_compose = 0, 
>   default_ascent = 2053600883, 
>   font_encoder = 0x0, 
>   driver = 0x151c220, 
>   encoding_charset = -1, 
>   repertory_charset = -1
> }

Looks like the font structure is garbled, at least most of its fields
are.

On Windows XP I see this instead:

  (gdb) p *font
  $1 = {
    size = 1075838994,
    next = 0x101ed800,
    props = {48349354, 48349618, 50593634, 48349570, 48343306, 102720, 102528,
      102656, 52, 48130050, 440, 48130050, 48395622, 48130050, 50523489,
      50523505, 48130050, 48343258},
    max_width = 9,
    pixel_size = 13,
    height = 16,
    space_width = 8,
    average_width = 8,
    min_width = 8,
    ascent = 12,
    descent = 4,
    underline_thickness = 1,
    underline_position = 3,
    vertical_centering = 0,
    encoding_type = 0 '\000',
    baseline_offset = 0,
    relative_compose = 0,
    default_ascent = 12,
    font_encoder = 0x0,
    driver = 0x153c300,
    encoding_charset = -1,
    repertory_charset = -1
  }

We are entering an area of Emacs where I don't know enough, so I hope
Jason will chime in RSN...

Anyway.  Could you please step through x_default_font_parameter, and
see which font it picks up here:

  font = !NILP (font_param) ? font_param
    : x_get_arg (dpyinfo, parms, Qfont, "font", "Font", RES_TYPE_STRING);

  if (!STRINGP (font))
    {
      int i;
      static char *names[]
        = { "Courier New-10",
            "-*-Courier-normal-r-*-*-13-*-*-*-c-*-iso8859-1",
            "-*-Fixedsys-normal-r-*-*-12-*-*-*-c-*-iso8859-1",
            "Fixedsys",
            NULL };

      for (i = 0; names[i]; i++)
        {
          font = font_open_by_name (f, names[i]);
          if (! NILP (font))
            break;
        }
      if (NILP (font))
        error ("No suitable font was found");

A word about displaying values of variables declared Lisp_Object.  You
need to start GDB from a directory where you have the .gdbinit file
that comes with the source tarball (you will find it in the src/
directory).  Then use the "pp" command instead of "p" or "print" to
display values of Lisp_Object variables.

After you determine which font is being picked up in the above loop,
please put a breakpoint in uniscribe_open and see if it and especially
w32font_open_internal that it calls succeed to open the font; if they
fail, please try to see why.

Finally, if you start Emacs with "emacs -Q -xrm Emacs.fontBackend:gdi",
does it also aborts in the same way, i.e. inside window_box_height?

Thanks.

Message #50 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Thu, 26 May 2011 03:50:24 +0200

> We are entering an area of Emacs where I don't know enough, so I hope
> Jason will chime in RSN...

Your efforts are much appreciated, really.

> Anyway.  Could you please step through x_default_font_parameter, and
> see which font it picks up here:
>
>  font = !NILP (font_param) ? font_param
>    : x_get_arg (dpyinfo, parms, Qfont, "font", "Font", RES_TYPE_STRING);
>
>  if (!STRINGP (font))
>    {
>      int i;
>      static char *names[]
>        = { "Courier New-10",
>            "-*-Courier-normal-r-*-*-13-*-*-*-c-*-iso8859-1",
>            "-*-Fixedsys-normal-r-*-*-12-*-*-*-c-*-iso8859-1",
>            "Fixedsys",
>            NULL };
>
>      for (i = 0; names[i]; i++)
>        {
>          font = font_open_by_name (f, names[i]);
>          if (! NILP (font))
>            break;
>        }
>      if (NILP (font))
>        error ("No suitable font was found");

http://www.speedyshare.com/files/28648980/EmacsGDBCourierNew.txt

> You
> need to start GDB from a directory where you have the .gdbinit file
> that comes with the source tarball (you will find it in the src/
> directory).

I always start GDB with 'gdb oo/i386/emacs' to be sure I am in the
right place, as suggested at
http://www.gnu.org/software/emacs/windows/Getting-Emacs.html#Getting-Emacs

> After you determine which font is being picked up in the above loop,
> please put a breakpoint in uniscribe_open and see if it and especially
> w32font_open_internal that it calls succeed to open the font

http://www.speedyshare.com/files/28648981/Emacs-23.3GDBuniscribe.txt

> Finally, if you start Emacs with "emacs -Q -xrm Emacs.fontBackend:gdi",
> does it also aborts in the same way, i.e. inside window_box_height?

http://www.speedyshare.com/files/28648982/Emacs-23.3GDBfontBackend.txt

Greetings,
                 Osl

Message #53 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 17:04:23 +0300

> Date: Thu, 26 May 2011 03:50:24 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > After you determine which font is being picked up in the above loop,
> > please put a breakpoint in uniscribe_open and see if it and especially
> > w32font_open_internal that it calls succeed to open the font
> 
> http://www.speedyshare.com/files/28648981/Emacs-23.3GDBuniscribe.txt

Here's what I see in this transcript:

> Breakpoint 3, uniscribe_open (f=0x37f3000, font_entity=58707461, 
>     pixel_size=13) at w32uniscribe.c:124
> 124	  Lisp_Object font_object
> (gdb) n
> 128	    = (struct uniscribe_font_info *) XFONT_OBJECT (font_object);
> (gdb) 
> 127	  struct uniscribe_font_info *uniscribe_font
> (gdb) finish
> Run till exit from #0  uniscribe_open (f=0x37f3000, font_entity=58707461, 
>     pixel_size=13) at w32uniscribe.c:127
> 0x01289daa in font_open_entity (f=0x37f3000, entity=58707461, pixel_size=13)
>     at font.c:3074
> 3074	  font_object = driver_list->driver->open (f, entity, scaled_pixel_size);
> Value returned is $1 = 52252165

> Breakpoint 4, w32font_open_internal (f=0x37f3000, font_entity=58707461, 
>     pixel_size=13, font_object=52252165) at w32font.c:816
> 816	  OUTLINETEXTMETRICW* metrics = NULL;
> (gdb) n
> 818	  w32_font = (struct w32font_info *) XFONT_OBJECT (font_object);
> (gdb) finish
> Run till exit from #0  w32font_open_internal (f=0x37f3000, 
>     font_entity=58707461, pixel_size=13, font_object=52252165)
>     at w32font.c:818
> 0x0131e6b1 in uniscribe_open (f=0x37f3000, font_entity=58707461, 
>     pixel_size=13) at w32uniscribe.c:132
> 132	  if (!w32font_open_internal (f, font_entity, pixel_size, font_object))
> Value returned is $2 = 1

So both functions think they are succeeding.  But I think something
abnormal must be happening inside w32font_open_internal, because
that's where the font object's contents is being filled, and we
already saw that the font winds up garbled in most of its fields in
x_new_font.

So please step through w32font_open_internal and print some of the
important values there, as I did in the session reproduced below.
(Note: the output of the "pp" command does not get written to the GDB
log, so if you use "pp", please either manually add its output into
the log or copy it to your mail response, where I could see it.)

> > Finally, if you start Emacs with "emacs -Q -xrm Emacs.fontBackend:gdi",
> > does it also aborts in the same way, i.e. inside window_box_height?
> 
> http://www.speedyshare.com/files/28648982/Emacs-23.3GDBfontBackend.txt

Same thing.  So the problem is not in the Uniscribe font backend, but
rather in some code that is common to both Uniscribe and GDI font
backends.

Here's the GDB session on Windows XP that shows how the font object is
initialized and what are its values just before w32font_open_internal
is about to return:

GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\usr\test\emacs-23.3\src/./oo/i386/emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from termina
l]
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 1 at 0x131219c: file w32fns.c, line 7365.
Temporary breakpoint 2 at 0x113de7a: file sysdep.c, line 1132.
(gdb) break w32font_open_internal
Breakpoint 3 at 0x133c56a: file w32font.c, line 816.
(gdb) r -Q
Starting program: D:\usr\test\emacs-23.3\src/./oo/i386/emacs.exe -Q
[New Thread 5360.0x2d4]
Warning: arch-dependent data dir (d:/usr/test/emacs-23.3/bin/) does not exist.
[New Thread 5360.0x6f0]

Breakpoint 3, w32font_open_internal (f=0x101f3000, font_entity=270458373,
    pixel_size=13, font_object=52391429) at w32font.c:816
816       OUTLINETEXTMETRICW* metrics = NULL;
(gdb) n
818       w32_font = (struct w32font_info *) XFONT_OBJECT (font_object);
(gdb) pp font_entity
#<font-entity uniscribe outline Courier\ New mono iso8859-1 normal normal normal 0 nil 110 nil ((:format . opentype) (:script nko arabic hebrew cyrillic greek latin))>
(gdb) pp font_object
#<font-object nil>
(gdb) n
819       font = (struct font *) w32_font;
(gdb) n
821       if (!font)
(gdb) n
824       bzero (&logfont, sizeof (logfont));
(gdb) p w32_font
$1 = (struct w32font_info *) 0x31f6e00
(gdb) p *w32_font
$2 = {
  font = {
    size = 1075838994,
    next = 0x101ed800,
    props = {48349354, 48349618, 50593634, 48349570, 48343306, 102720,
      102528, 102656, 52, 48130050, 440, 48130050, 48395694, 48130050,
      48130050, 48130050, 48130050, 48130050},
    max_width = 33562893,
    pixel_size = 75378178,
    height = 8,
    space_width = -16777216,
    average_width = 856579,
    min_width = 2052,
    ascent = 0,
    descent = -267582465,
    underline_thickness = 2113995519,
    underline_position = 218890759,
    vertical_centering = 269352976,
    encoding_type = 0 '\000',
    baseline_offset = 242901620,
    relative_compose = 16908291,
    default_ascent = 220204082,
    font_encoder = 0x2e0102f2,
    driver = 0x200080e,
    encoding_charset = 2053600259,
    repertory_charset = 234883341
  },
  metrics = {
    tmHeight = 67239945,
    tmAscent = 2053600883,
    tmDescent = 33555981,
    tmInternalLeading = 1718186756,
    tmExternalLeading = 3018362,
    tmAveCharWidth = 101581574,
    tmMaxCharWidth = 2113995264,
    tmWeight = 33562893,
    tmOverhang = 75378178,
    tmDigitizedAspectX = 8,
    tmDigitizedAspectY = -16777216,
    tmFirstChar = 4611 L'<error reading variable>,
    tmLastChar = 13 L'<error reading variable>,
    tmDefaultChar = 2052 L'<error reading variable>,
    tmBreakChar = 0 L'<error reading variable>,
    tmItalic = 0 '\000',
    tmUnderlined = 0 '\000',
    tmStruckOut = 0 '\000',
    tmPitchAndFamily = 0 '\000',
    tmCharSet = 255 '\377'
  },
  glyph_idx = 2113995519,
  cached_metrics = 0xc0307,
  n_cache_blocks = 1685217636,
  hfont = 0x6e6f662d
}
(gdb) p Qnil
$3 = 48130050
(gdb) n
825       fill_in_logfont (f, &logfont, font_entity);
(gdb) n
829       val = AREF (font_entity, FONT_FOUNDRY_INDEX);
(gdb) n
830       if (!EQ (val, Qraster))
(gdb) pp val
outline
(gdb) n
831         logfont.lfOutPrecision = OUT_TT_PRECIS;
(gdb) n
833       size = XINT (AREF (font_entity, FONT_SIZE_INDEX));
(gdb) n
834       if (!size)
(gdb) p size
$4 = 0
(gdb) n
835         size = pixel_size;
(gdb) n
837       logfont.lfHeight = -size;
(gdb) p size
$6 = 13
(gdb) n
838       hfont = CreateFontIndirect (&logfont);
(gdb) n
840       if (hfont == NULL)
(gdb) n
844       dc = get_frame_dc (f);
(gdb) n
845       old_font = SelectObject (dc, hfont);
(gdb) n
848       len = GetOutlineTextMetricsW (dc, 0, NULL);
(gdb) p old_font
$7 = (HFONT) 0x18a0021
(gdb) n
849       if (len)
(gdb) p len
$8 = 372
(gdb) n
851           metrics = (OUTLINETEXTMETRICW *) alloca (len);
(gdb) n
852           if (GetOutlineTextMetricsW (dc, len, metrics))
(gdb) n
853             bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
(gdb) n
859       if (!metrics)
(gdb) n
862       w32_font->cached_metrics = NULL;
(gdb) p *metrics
$9 = {
  otmSize = 372,
  otmTextMetrics = {
    tmHeight = 16,
    tmAscent = 12,
    tmDescent = 4,
    tmInternalLeading = 3,
    tmExternalLeading = 0,
    tmAveCharWidth = 8,
    tmMaxCharWidth = 9,
    tmWeight = 400,
    tmOverhang = 0,
    tmDigitizedAspectX = 96,
    tmDigitizedAspectY = 96,
    tmFirstChar = 32 L'<error reading variable>,
    tmLastChar = 65532 L'<error reading variable>,
    tmDefaultChar = 31 L'<error reading variable>,
    tmBreakChar = 32 L'<error reading variable>,
    tmItalic = 0 '\000',
    tmUnderlined = 0 '\000',
    tmStruckOut = 0 '\000',
    tmPitchAndFamily = 54 '6',
    tmCharSet = 0 '\000'
  },
  otmFiller = 82 'R',
  otmPanoseNumber = {
    bFamilyType = 2 '\002',
    bSerifStyle = 7 '\a',
    bWeight = 3 '\003',
    bProportion = 9 '   ',
    bContrast = 2 '\002',
    bStrokeVariation = 2 '\002',
    bArmStyle = 5 '\005',
    bLetterform = 2 '\002',
    bMidline = 4 '\004',
    bXHeight = 4 '\004'
  },
  otmfsSelection = 64,
  otmfsType = 0,
  otmsCharSlopeRise = 1,
  otmsCharSlopeRun = 0,
  otmItalicAngle = 0,
  otmEMSquare = 2048,
  otmAscent = 8,
  otmDescent = -2,
  otmLineGap = 0,
  otmsCapEmHeight = 7,
  otmsXHeight = 3,
  otmrcFontBox = {
    left = 0,
    top = 13,
    right = 8,
    bottom = -9
  },
  otmMacAscent = 11,
  otmMacDescent = -4,
  otmMacLineGap = 0,
  otmusMinimumPPEM = 9,
  otmptSubscriptSize = {
    x = 9,
    y = 8
  },
  otmptSubscriptOffset = {
    x = 0,
    y = 2
  },
  otmptSuperscriptSize = {
    x = 9,
    y = 8
  },
  otmptSuperscriptOffset = {
    x = 0,
    y = 5
  },
  otmsStrikeoutSize = 1,
  otmsStrikeoutPosition = 3,
  otmsUnderscoreSize = 1,
  otmsUnderscorePosition = -3,
  otmpFamilyName = 0xd8 <Address 0xd8 out of bounds>,
  otmpFaceName = 0xf0 <Address 0xf0 out of bounds>,
  otmpStyleName = 0x108 <Address 0x108 out of bounds>,
  otmpFullName = 0x118 <Address 0x118 out of bounds>
}
(gdb) n
863       w32_font->n_cache_blocks = 0;
(gdb) n
865       SelectObject (dc, old_font);
(gdb) n
866       release_frame_dc (f, dc);
(gdb) n
868       w32_font->hfont = hfont;
(gdb) n
875         len = 96;
(gdb) n
876         name = alloca (len);
(gdb) n
877         while (name && w32font_full_name (&logfont, font_entity, pixel_size,
(gdb) n
883         if (name)
(gdb) n
884           font->props[FONT_FULLNAME_INDEX]
(gdb) n
891       font->max_width = w32_font->metrics.tmMaxCharWidth;
(gdb) n
898       font->space_width = font->average_width = w32_font->metrics.tmAveCharWidth;
(gdb) n
900       font->vertical_centering = 0;
(gdb) n
901       font->encoding_type = 0;
(gdb) n
902       font->baseline_offset = 0;
(gdb) n
903       font->relative_compose = 0;
(gdb) n
904       font->default_ascent = w32_font->metrics.tmAscent;
(gdb) n
905       font->font_encoder = NULL;
(gdb) n
906       font->pixel_size = size;
(gdb) n
907       font->driver = &w32font_driver;
(gdb) n
910       extra = AREF (font_entity, FONT_EXTRA_INDEX);
(gdb) n
911       if (CONSP (extra))
(gdb) n
913           val = assq_no_quit (QCformat, extra);
(gdb) n
914           if (CONSP (val))
(gdb) n
915             font->props[FONT_FORMAT_INDEX] = XCDR (val);
(gdb) n
922       font->props[FONT_FILE_INDEX] = Qnil;
(gdb) n
923       font->encoding_charset = -1;
(gdb) n
924       font->repertory_charset = -1;
(gdb) n
926       font->min_width = font->space_width;
(gdb) n
927       font->ascent = w32_font->metrics.tmAscent;
(gdb) n
928       font->descent = w32_font->metrics.tmDescent;
(gdb) n
929       font->height = font->ascent + font->descent;
(gdb) n
931       if (metrics)
(gdb) n
933           font->underline_thickness = metrics->otmsUnderscoreSize;
(gdb) n
934           font->underline_position = -metrics->otmsUnderscorePosition;
(gdb) n
946       font->props[FONT_NAME_INDEX] = Ffont_xlfd_name (font_object, Qnil);
(gdb) n
948       return 1;
(gdb) p *font
$10 = {
  size = 1075838994,
  next = 0x101ed800,
  props = {48349354, 48349618, 50593634, 48349570, 48343306, 102720, 102528,
    102656, 52, 48130050, 440, 48130050, 48395694, 48130050, 50523505,
    50523521, 48130050, 48343258},
  max_width = 9,
  pixel_size = 13,
  height = 16,
  space_width = 8,
  average_width = 8,
  min_width = 8,
  ascent = 12,
  descent = 4,
  underline_thickness = 1,
  underline_position = 3,
  vertical_centering = 0,
  encoding_type = 0 '\000',
  baseline_offset = 0,
  relative_compose = 0,
  default_ascent = 12,
  font_encoder = 0x0,
  driver = 0x153c260,
  encoding_charset = -1,
  repertory_charset = -1
}
(gdb) n
949     }
(gdb)
uniscribe_open (f=0x101f3000, font_entity=270458373, pixel_size=13)
    at w32uniscribe.c:138
138       uniscribe_font->cache = NULL;
(gdb) p font_object
$18 = 52391429
(gdb) xtype
Lisp_Vectorlike
PVEC_FONT
(gdb) xfont
$19 = (struct font *) 0x31f6e00
(gdb) p $->props[14]
$20 = 50523505
(gdb) xstring
$21 = (struct Lisp_String *) 0x302ed70
"-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1"
(gdb) p font_object
$23 = 52391429
(gdb) xfont
$24 = (struct font *) 0x31f6e00
(gdb) p $->props[15]
$25 = 50523521
(gdb) xstring
$26 = (struct Lisp_String *) 0x302ed80
"Courier New-10.0"
(gdb)

Message #56 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 18:13:29 +0200

>> Finally, if you start Emacs with "emacs -Q -xrm Emacs.fontBackend:gdi",
>> does it also aborts in the same way, i.e. inside window_box_height?

This has made me wonder what happens in the trunk version of Emacs
with assertions enabled.

http://www.speedyshare.com/files/28671939/EmacsTrunkGDBAssert.txt

http://www.speedyshare.com/files/28671940/EmacsTrunkGDBw32font.txt

http://www.speedyshare.com/files/28671941/EmacsTrunkGDBfont.txt

Greetings,
                Osl

Message #59 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 20:15:37 +0300

> Date: Fri, 27 May 2011 18:13:29 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> >> Finally, if you start Emacs with "emacs -Q -xrm Emacs.fontBackend:gdi",
> >> does it also aborts in the same way, i.e. inside window_box_height?
> 
> This has made me wonder what happens in the trunk version of Emacs
> with assertions enabled.

It crashes in the same way, so it's the same problem.

> http://www.speedyshare.com/files/28671940/EmacsTrunkGDBw32font.txt

> 819	  len = GetOutlineTextMetricsW (dc, 0, NULL);
> (gdb) 
> 820	  if (len)
> (gdb) 
> 830	  if (!metrics)
> (gdb) 
> 831	    GetTextMetricsW (dc, &w32_font->metrics);

This means GetOutlineTextMetricsW failed, and we then call
GetTextMetricsW.  But we don't test its return value, and it looks
like it also fails, because the values we put into font are based on
what it returns, and they are garbage:

> (gdb) p *font
> $3 = {
>   header = {
>     size = 1075838994, 
>     next = {
>       buffer = 0x3594800, 
>       vector = 0x3594800
>     }
>   }, 
>   props = {53574682, 53574946, 55205178, 53574898, 53568634, 102720, 102528, 
>     102656, 52, 53352474, 440, 53352474, 53642494, 53352474, 55030721, 
>     55030737, 53352474, 55205298}, 
>   max_width = -1, 
>   pixel_size = 13, 
>   height = -2, 
>   space_width = -1, 
>   average_width = -1, 
>   min_width = -1, 
>   ascent = -1, 
>   descent = -1, 
>   underline_thickness = 0, 
>   underline_position = -1, 
>   vertical_centering = 0, 
>   encoding_type = 0 '\000', 
>   baseline_offset = 0, 
>   relative_compose = 0, 
>   default_ascent = -1, 
>   font_encoder = 0x0, 
>   driver = 0x14cd800, 
>   encoding_charset = -1, 
>   repertory_charset = -1
> }

So I think we found the culprit, the question is how to make this
work.  But first let's make sure the call to GetTextMetricsW indeed
fails.  Please change this code in w32font_open_internal:

  len = GetOutlineTextMetricsW (dc, 0, NULL);
  if (len)
    {
      metrics = (OUTLINETEXTMETRICW *) alloca (len);
      if (GetOutlineTextMetricsW (dc, len, metrics))
        bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
               sizeof (TEXTMETRICW));
      else
        metrics = NULL;
    }

  if (!metrics)
    GetTextMetricsW (dc, &w32_font->metrics);

to say this instead:

  unsigned e;
  ...
  len = GetOutlineTextMetricsW (dc, 0, NULL);
  if (len)
    {
      metrics = (OUTLINETEXTMETRICW *) alloca (len);
      if (GetOutlineTextMetricsW (dc, len, metrics))
        bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
               sizeof (TEXTMETRICW));
      else
        metrics = NULL;
    }
  else
    e = GetLastError ();

  if (!metrics)
    {
      if (!GetTextMetricsW (dc, &w32_font->metrics))
	e = GetLastError ();
    }

Then compile, step through the code again, and tell what value gets
assigned to e.

Thanks.

Message #62 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 19:22:14 +0200

> So please step through w32font_open_internal and print some of the
> important values there, as I did in the session reproduced below.

http://www.speedyshare.com/files/28672873/Emacs-23.3GDBpp.txt

> (Note: the output of the "pp" command does not get written to the GDB
> log, so if you use "pp", please either manually add its output into
> the log or copy it to your mail response, where I could see it.)

You are right. Thanks for the hint.

Greetings,
                Osl

Message #65 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 21:17:57 +0300

> Date: Fri, 27 May 2011 19:22:14 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > So please step through w32font_open_internal and print some of the
> > important values there, as I did in the session reproduced below.
> 
> http://www.speedyshare.com/files/28672873/Emacs-23.3GDBpp.txt

Okay, the picture is the same as what you saw with the trunk.  So
please modify the code as I asked there (it doesn't matter if you do
it in the Emacs 23.3 version or in the bzr trunk version), and see
whether the GetTextMetricsW call indeed fails and with what error
code.

Thanks.

Message #68 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 20:33:33 +0200

> So I think we found the culprit, the question is how to make this
> work.  But first let's make sure the call to GetTextMetricsW indeed
> fails.  Please change this code in w32font_open_internal:
>
>  len = GetOutlineTextMetricsW (dc, 0, NULL);
>  if (len)
>    {
>      metrics = (OUTLINETEXTMETRICW *) alloca (len);
>      if (GetOutlineTextMetricsW (dc, len, metrics))
>        bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
>               sizeof (TEXTMETRICW));
>      else
>        metrics = NULL;
>    }
>
>  if (!metrics)
>    GetTextMetricsW (dc, &w32_font->metrics);
>
> to say this instead:
>
>  unsigned e;
>  ...
>  len = GetOutlineTextMetricsW (dc, 0, NULL);
>  if (len)
>    {
>      metrics = (OUTLINETEXTMETRICW *) alloca (len);
>      if (GetOutlineTextMetricsW (dc, len, metrics))
>        bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
>               sizeof (TEXTMETRICW));
>      else
>        metrics = NULL;
>    }
>  else
>    e = GetLastError ();
>
>  if (!metrics)
>    {
>      if (!GetTextMetricsW (dc, &w32_font->metrics))
>        e = GetLastError ();
>    }
>
> Then compile, step through the code again, and tell what value gets
> assigned to e.

http://www.speedyshare.com/files/28673968/Emacs-23.3GDBprintE.txt

Greetings,
                Osl

Message #71 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 27 May 2011 23:51:41 +0300

> Date: Fri, 27 May 2011 20:33:33 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> >  unsigned e;
> >  ...
> >  len = GetOutlineTextMetricsW (dc, 0, NULL);
> >  if (len)
> >    {
> >      metrics = (OUTLINETEXTMETRICW *) alloca (len);
> >      if (GetOutlineTextMetricsW (dc, len, metrics))
> >        bcopy (&metrics->otmTextMetrics, &w32_font->metrics,
> >               sizeof (TEXTMETRICW));
> >      else
> >        metrics = NULL;
> >    }
> >  else
> >    e = GetLastError ();
> >
> >  if (!metrics)
> >    {
> >      if (!GetTextMetricsW (dc, &w32_font->metrics))
> >        e = GetLastError ();
> >    }
> >
> > Then compile, step through the code again, and tell what value gets
> > assigned to e.
> 
> http://www.speedyshare.com/files/28673968/Emacs-23.3GDBprintE.txt

> 849	 len = GetOutlineTextMetricsW (dc, 0, NULL);
> (gdb) 
> 850	 if (len)
> (gdb) 
> 860	   e = GetLastError ();
> (gdb) 
> 862	 if (!metrics)
> (gdb) p e
> $1 = 120
> (gdb) n
> 864	     if (!GetTextMetricsW (dc, &w32_font->metrics))
> (gdb) n
> 865	       e = GetLastError ();
> (gdb) n
> 868	  w32_font->cached_metrics = NULL;
> (gdb) p e
> $2 = 120
> (gdb) 
> 

120 means "This function is not supported on this system".  Do you
have the Microsoft Layer for Unicode (MSLU) installed on that system?
If you do, you should have UNICOWS.DLL somewhere on Path.

If you have that package installed, can you try compiling a simple
program that just calls these two functions, and run it on the Windows
98 machine to see if they fail in the same way?

Message #74 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Mon, 30 May 2011 17:12:26 +0200

> 120 means "This function is not supported on this system".  Do you
> have the Microsoft Layer for Unicode (MSLU) installed on that system?

I remember having downloaded the MSLU from
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=73ba7bd7-ed06-4f0d-80a4-2a7eeaee17e2
some time ago.

"The download contains UnicoWS.dll (the MSLU binary), and UnicoWS.pdb
which can be used when debugging."

These files are extracted in the directory that the user chooses.

I had no idea where to put them, so I chose the windows subdirectory
which seemed to contain the most dll files and which happened to be
"system".

> If you do, you should have UNICOWS.DLL somewhere on Path.

The "system" directory isn't in the path by default, so unicows.dll
wasn't in the path.

Unfortunately, after adding the "system" directory to the path ( or
another one which contains the unicows.dll  ) the same error ( 120 )
still appears in Emacs.

> If you have that package installed, can you try compiling a simple
> program that just calls these two functions, and run it on the Windows
> 98 machine to see if they fail in the same way?

They seem to work in the sample program:

http://www.speedyshare.com/files/28718617/sample.c

http://www.speedyshare.com/files/28718618/sampleGDB.txt

Greetings,
                Osl

Message #77 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Mon, 30 May 2011 21:43:21 +0300

> Date: Mon, 30 May 2011 17:12:26 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> I remember having downloaded the MSLU from
> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=73ba7bd7-ed06-4f0d-80a4-2a7eeaee17e2
> some time ago.
> 
> "The download contains UnicoWS.dll (the MSLU binary), and UnicoWS.pdb
> which can be used when debugging."
> 
> These files are extracted in the directory that the user chooses.
> 
> I had no idea where to put them, so I chose the windows subdirectory
> which seemed to contain the most dll files and which happened to be
> "system".

The safest place is the same directory where you have emacs.exe.  But
doing what you did is also OK.

> Unfortunately, after adding the "system" directory to the path ( or
> another one which contains the unicows.dll  ) the same error ( 120 )
> still appears in Emacs.
> 
> > If you have that package installed, can you try compiling a simple
> > program that just calls these two functions, and run it on the Windows
> > 98 machine to see if they fail in the same way?
> 
> They seem to work in the sample program:
> 
> http://www.speedyshare.com/files/28718617/sample.c
> 
> http://www.speedyshare.com/files/28718618/sampleGDB.txt

The difference here is that your sample program dynamically loads
unicows.dll:

> Breakpoint 1, WinMain (hInstance=0x400000, hPrevInstance=0x0, 
>     lpCmdLine=0x81631ea2 "", nCmdShow=10) at sample.c:139
> 139	  hm_unicows = LoadLibrary("unicows.dll");

whereas Emacs doesn't, AFAICT.  Could you try loading that DLL in
Emacs, by adding just the single line as the one above to some
function that is run early during the startup, e.g. in globals_of_w32?
(There's no need to go to extra lengths such as calling
GetOutlineTextMetricsW and GetTextMetricsW through function pointers.)
Then recompile Emacs and see if that solves the problem.

Thanks.

Message #80 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 31 May 2011 20:16:00 +0200

> The safest place is the same directory where you have emacs.exe.  But
> doing what you did is also OK.

I tried putting the unicows.dll there too and adding that directory to
the path but I still got the same error (120)

> The difference here is that your sample program dynamically loads
> unicows.dll:
>
>> Breakpoint 1, WinMain (hInstance=0x400000, hPrevInstance=0x0,
>>     lpCmdLine=0x81631ea2 "", nCmdShow=10) at sample.c:139
>> 139     hm_unicows = LoadLibrary("unicows.dll");
>
> whereas Emacs doesn't, AFAICT.

I haven't found any reference to the word unicows in the source files.
I suspect Emacs is not aware of the availability of the MSLU library
for windows 98, by reading this comment (which I found while searching
for the word unicode) from w32font.c:510

---------------------------------------------------------------------------------------------------------------------------------
  if (GetTextExtentPoint32W (dc, wcode, nglyphs, &size))
    {
      total_width = size.cx;
    }

  /* On 95/98/ME, only some unicode functions are available, so fallback
     on doing a dummy draw to find the total width.  */
  if (!total_width)
    {
      RECT rect;
      rect.top = 0; rect.bottom = font->height; rect.left = 0; rect.right = 1;
      DrawTextW (dc, wcode, nglyphs, &rect,
                 DT_CALCRECT | DT_NOPREFIX | DT_SINGLELINE);
      total_width = rect.right;
    }
----------------------------------------------------------------------------------------------------------------------------------

DrawTextW is a unicode function which is available (from User32.dll)

http://www.speedyshare.com/files/28740563/BrowsingUser32.png

But GetTextExtentPoint32W is a unicode function which is available too
(from unicows.dll)

http://www.speedyshare.com/files/28740564/BrowsingUnicows.png

>  Could you try loading that DLL in
> Emacs, by adding just the single line as the one above to some
> function that is run early during the startup, e.g. in globals_of_w32?
> (There's no need to go to extra lengths such as calling
> GetOutlineTextMetricsW and GetTextMetricsW through function pointers.)
> Then recompile Emacs and see if that solves the problem.

I see the same error (120)

http://www.speedyshare.com/files/28740565/Emacs-23.3GDBglobals.txt

Greetings,
                  Osl

Message #83 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 01 Jun 2011 00:02:21 +0300

> Date: Tue, 31 May 2011 20:16:00 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> >  Could you try loading that DLL in
> > Emacs, by adding just the single line as the one above to some
> > function that is run early during the startup, e.g. in globals_of_w32?
> > (There's no need to go to extra lengths such as calling
> > GetOutlineTextMetricsW and GetTextMetricsW through function pointers.)
> > Then recompile Emacs and see if that solves the problem.
> 
> I see the same error (120)
> 
> http://www.speedyshare.com/files/28740565/Emacs-23.3GDBglobals.txt

OK, so let's call GetOutlineTextMetricsW and GetTextMetricsW in Emacs
through function pointers, like the sample program did.  Let's see if
that works.  You will need to declare hm_unicows `extern' in w32font.c
and give it global scope in w32.c.  Then copy the code from the sample
program that calls these function through function pointers, viz.

  len = s_pfn_Get_Outline_Text_Metrics_W (dc, 0, NULL);

(and similarly for the other calls) into w32font_open_internal, and
see if it starts working.

Thanks.

Message #86 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 01 Jun 2011 00:04:10 +0300

> Date: Tue, 31 May 2011 20:16:00 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> >  Could you try loading that DLL in
> > Emacs, by adding just the single line as the one above to some
> > function that is run early during the startup, e.g. in globals_of_w32?
> > (There's no need to go to extra lengths such as calling
> > GetOutlineTextMetricsW and GetTextMetricsW through function pointers.)
> > Then recompile Emacs and see if that solves the problem.
> 
> I see the same error (120)
> 
> http://www.speedyshare.com/files/28740565/Emacs-23.3GDBglobals.txt

OK, so let's call GetOutlineTextMetricsW and GetTextMetricsW in Emacs
through function pointers, like the sample program did.  Let's see if
that works.  You will need to declare hm_unicows `extern' in w32font.c
and give it global scope in w32.c.  Then copy the code from the sample
program that initializes the necessary function pointers and calls
these functions through function pointers, viz.

  s_pfn_Get_Outline_Text_Metrics_W =
    (GetOutlineTextMetricsW_Proc) GetProcAddress (
	hm_unicows, "GetOutlineTextMetricsW");

  len = s_pfn_Get_Outline_Text_Metrics_W (dc, 0, NULL);

(and similarly for the other calls) into w32font_open_internal, and
see if it starts working.

Thanks.

Message #89 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 3 Jun 2011 01:41:59 +0200

> OK, so let's call GetOutlineTextMetricsW and GetTextMetricsW in Emacs
> through function pointers, like the sample program did.  Let's see if
> that works.  You will need to declare hm_unicows `extern' in w32font.c [...]

It works! :)

There isn't any error in the debugger and the program quits cleanly:

http://www.speedyshare.com/files/28780096/Emacs-23.3GDBSizeOK.txt

But a new problem ( which maybe has been there all this time but there
was no way for us to know about until now ) is apparent:

The *About GNU Emacs* buffer:

http://www.speedyshare.com/files/28780097/AboutEmacs.png

A GNU Emacs tooltip:

http://www.speedyshare.com/files/28780098/Emacs23ToolTips.png

A test of the *scratch* buffer:

http://www.speedyshare.com/files/28780099/Emacs23BufferTests.png

The previous image represents approximately the following sequence of
characters:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

                                   (a line of spaces)
OOOOOOOOOOOOOOOOOOOO
TTTTTTTTTTTTTTTTTTTT
SSSSSSSSSSSSSSSS
XXXXXXXXXXXXXXXXXXXXX
.....................................
:::::::::::::::::::::::::::::::::::::
JJJJJJJJJJJJJJJJJJJJJJJJJJ
33333333333333333333333
77777777777777777777
????????????????????
>>>>>>>>>>>>>>>>>
XXXXXX XXXXXX XXXXXX

That is, the cursor doesn't advance enough and so consecutive
characters overlap.
Also, the Space and the End Of Line are represented as an empty square
that advances the cursor correctly.
The Tab key doesn't have any visible effect on the buffer.

Greetings,
                 Osl

Message #92 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 03 Jun 2011 10:10:38 +0300

> Date: Fri, 3 Jun 2011 01:41:59 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > OK, so let's call GetOutlineTextMetricsW and GetTextMetricsW in Emacs
> > through function pointers, like the sample program did.  Let's see if
> > that works.  You will need to declare hm_unicows `extern' in w32font.c [...]
> 
> It works! :)
> 
> There isn't any error in the debugger and the program quits cleanly:
> 
> http://www.speedyshare.com/files/28780096/Emacs-23.3GDBSizeOK.txt

Good.  I will prepare a patch for you to try along these lines, but
I'd really be glad if someone beats me to it.

> http://www.speedyshare.com/files/28780099/Emacs23BufferTests.png
> 
> The previous image represents approximately the following sequence of
> characters:
> 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
>                                    (a line of spaces)
> OOOOOOOOOOOOOOOOOOOO
> TTTTTTTTTTTTTTTTTTTT
> SSSSSSSSSSSSSSSS
> XXXXXXXXXXXXXXXXXXXXX
> .....................................
> :::::::::::::::::::::::::::::::::::::
> JJJJJJJJJJJJJJJJJJJJJJJJJJ
> 33333333333333333333333
> 77777777777777777777
> ????????????????????
> >>>>>>>>>>>>>>>>>
> XXXXXX XXXXXX XXXXXX
> 
> That is, the cursor doesn't advance enough and so consecutive
> characters overlap.
> Also, the Space and the End Of Line are represented as an empty square
> that advances the cursor correctly.

It's more than overlap, it sounds like the font is not really working
(empty squares mean the character has no glyphs in the font).  I will
look into this when I have time, but in the meantime, please try the
same in an Emacs invoked with "-xrm Emacs.fontBackend:gdi", and see if
these problems persist with the GDI font driver.

Message #95 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 03 Jun 2011 11:29:33 +0300

> Date: Fri, 3 Jun 2011 01:41:59 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> But a new problem ( which maybe has been there all this time but there
> was no way for us to know about until now ) is apparent:
> 
> The *About GNU Emacs* buffer:
> 
> http://www.speedyshare.com/files/28780097/AboutEmacs.png
> 
> A GNU Emacs tooltip:
> 
> http://www.speedyshare.com/files/28780098/Emacs23ToolTips.png
> 
> A test of the *scratch* buffer:
> 
> http://www.speedyshare.com/files/28780099/Emacs23BufferTests.png

It could be that more Unicode functions have similar problems, because
they reside inside unicows.dll on Windows 9X.  Could you please look
up all the functions in w32font.c and w32uniscribe.c whose names end
with a `W', and see which ones of them are in unicows.dll?

Thanks.

Message #98 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 3 Jun 2011 22:10:05 +0200

> It could be that more Unicode functions have similar problems, because
> they reside inside unicows.dll on Windows 9X.  Could you please look
> up all the functions in w32font.c and w32uniscribe.c whose names end
> with a `W', and see which ones of them are in unicows.dll?

C:\emacs-23.3\src>grep -E -o -h "\<\w+[a-z0-9]+W\>" w32font.c w32uniscribe.c | s
ort | uniq

DrawTextW
ExtTextOutW
GetGlyphOutlineW
GetOutlineTextMetricsW
GetTextExtentPoint32W
GetTextMetricsW


And in a wider search:

C:\emacs-23.3\src>grep -E -o -h "\<\w+[a-z0-9]+W\>" *.c | grep -v
"Elf\|MingW" | sort | uniq

AppendMenuW
DrawTextW
ExtTextOutW
GetFileSecurityW
GetGlyphOutlineW
GetOutlineTextMetricsW
GetTextExtentPoint32W
GetTextMetricsW
ImmGetCompositionStringW
LookupAccountSidW
lstrlenW

Note: The words that begin with Elf are macros, not functions.

I was going to report that the rest of these functions are already
implemented in core system libraries:

==================================================
Function Name     : AppendMenuW
Address           : 0xbfc010eb
Relative Address  : 0x000010eb
Ordinal           : 8 (0x8)
Filename          : USER32.DLL
Full Path         : C:\WINDOWS\SYSTEM\USER32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : DrawTextW
Address           : 0xbfc010f4
Relative Address  : 0x000010f4
Ordinal           : 176 (0xb0)
Filename          : USER32.DLL
Full Path         : C:\WINDOWS\SYSTEM\USER32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : ExtTextOutW
Address           : 0xbff21cb2
Relative Address  : 0x00001cb2
Ordinal           : 207 (0xcf)
Filename          : GDI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\GDI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : GetFileSecurityW
Address           : 0xbfe8216d
Relative Address  : 0x0000216d
Ordinal           : 116 (0x74)
Filename          : ADVAPI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\ADVAPI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : GetGlyphOutlineW
Address           : 0xbff2797f
Relative Address  : 0x0000797f
Ordinal           : 264 (0x108)
Filename          : GDI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\GDI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : GetTextExtentPoint32W
Address           : 0xbff21ed0
Relative Address  : 0x00001ed0
Ordinal           : 309 (0x135)
Filename          : GDI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\GDI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : ImmGetCompositionStringW
Address           : 0xbfe210a7
Relative Address  : 0x000010a7
Ordinal           : 25 (0x19)
Filename          : IMM32.DLL
Full Path         : C:\WINDOWS\SYSTEM\IMM32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : LookupAccountSidW
Address           : 0xbfe8217f
Relative Address  : 0x0000217f
Ordinal           : 173 (0xad)
Filename          : ADVAPI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\ADVAPI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : lstrlenW
Address           : 0xbff77454
Relative Address  : 0x00007454
Ordinal           : 865 (0x361)
Filename          : KERNEL32.DLL
Full Path         : C:\WINDOWS\SYSTEM\KERNEL32.DLL
Type              : Exported Function
==================================================


But I have stumbled across this comment:

w32menu.c:1505
	  /* On W9x/ME, unicode menus are not supported, though AppendMenuW
	     apparently does exist at least in some cases and appears to be
	     stubbed out to do nothing.[...] */

And then I have checked that both GetTextMetricsW and
GetOutlineTextMetricsW, which caused the system error #120 ("This
function is not supported on this system."), are actually
"implemented" in a core system library along with other of the
previous functions:

==================================================
Function Name     : GetOutlineTextMetricsW
Address           : 0xbff2795b
Relative Address  : 0x0000795b
Ordinal           : 286 (0x11e)
Filename          : GDI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\GDI32.DLL
Type              : Exported Function
==================================================

==================================================
Function Name     : GetTextMetricsW
Address           : 0xbff27952
Relative Address  : 0x00007952
Ordinal           : 315 (0x13b)
Filename          : GDI32.DLL
Full Path         : C:\WINDOWS\SYSTEM\GDI32.DLL
Type              : Exported Function
==================================================


So, your idea of trying the unicode functions which have been
reimplemented in unicows.dll and seeing if they make a difference
looks very promising.

Greetings,
           Osl

Message #101 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 3 Jun 2011 22:51:06 +0200

>> with a `W', and see which ones of them are in unicows.dll?

I had forgotten to reply to the last part of your question:

==================================================
Function Name     : AppendMenuW
Address           : 0x7f2e7a8a
Relative Address  : 0x00017a8a
Ordinal           : 12 (0xc)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : DrawTextW
Address           : 0x7f2e90c0
Relative Address  : 0x000190c0
Ordinal           : 104 (0x68)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : ExtTextOutW
Address           : 0x7f2eedec
Relative Address  : 0x0001edec
Ordinal           : 135 (0x87)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : GetGlyphOutlineW
Address           : 0x7f2ef4ee
Relative Address  : 0x0001f4ee
Ordinal           : 191 (0xbf)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : GetOutlineTextMetricsW
Address           : 0x7f2ef8fe
Relative Address  : 0x0001f8fe
Ordinal           : 213 (0xd5)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : GetTextExtentPoint32W
Address           : 0x7f2efe67
Relative Address  : 0x0001fe67
Ordinal           : 244 (0xf4)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : GetTextMetricsW
Address           : 0x7f2f0125
Relative Address  : 0x00020125
Ordinal           : 247 (0xf7)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

==================================================
Function Name     : lstrlenW
Address           : 0x7f2e5117
Relative Address  : 0x00015117
Ordinal           : 484 (0x1e4)
Filename          : unicows.dll
Full Path         : C:\gnu\unicows.dll
Type              : Exported Function
==================================================

Greetings,
                Osl

Message #104 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sat, 4 Jun 2011 00:52:15 +0200

I have realized that I had mistook system error #120 ("This function
is not supported on this system." ie. the function is a stub) for
system error #1 ("Incorrect function." ie. the function does not
exist).

This renders my previous reasoning unnecessary.

So I'm going to put calls to the function GetLastError after each call
to each of these unicode functions to see what happens.

Greetings,
                Osl

Message #107 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sat, 04 Jun 2011 10:11:33 +0300

> Date: Sat, 4 Jun 2011 00:52:15 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> I have realized that I had mistook system error #120 ("This function
> is not supported on this system." ie. the function is a stub) for
> system error #1 ("Incorrect function." ie. the function does not
> exist).
> 
> This renders my previous reasoning unnecessary.
> 
> So I'm going to put calls to the function GetLastError after each call
> to each of these unicode functions to see what happens.

Thanks, that would be useful.

An alternative would be to download and install libunicows from here:

  http://libunicows.sourceforge.net/

and then manually add "-lunicows" before all the other -lFOO libraries
on the link command line in src/makefile, and rebuild Emacs.  If that
binary works, then we at least will know that the linking against
unicows.dll is the root cause of all these problems.

Whether to switch to linking Emacs with libunicows or manually load it
on Windows 9X and call the Unicode functions through function
pointers, is a different issue.  Given the small number of affected
functions, I'm not sure what's best.

Message #110 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 5 Jun 2011 03:58:25 +0200

>> So I'm going to put calls to the function GetLastError after each call
>> to each of these unicode functions to see what happens.

I have only observed that:
- Emacs chooses the ansi versions of the functions LookupAccountSid
and GetFileSecurity.
- The next problematic unicode function is GetGlyphOutlineW which,
like GetOutlineTextMetricsW and GetTextMetricsW, is just a stub.

The breakpoints I have set for the calls to the other unicode
functions are never reached before the Emacs window is opened and is
"operative" and then, after a while, I simply quit.

http://www.speedyshare.com/files/28808320/Emacs-23.3GDBGetErrors.txt

> An alternative would be to download and install libunicows from here:
>
>  http://libunicows.sourceforge.net/
>
> and then manually add "-lunicows" before all the other -lFOO libraries
> on the link command line in src/makefile, and rebuild Emacs.  If that
> binary works, then we at least will know that the linking against
> unicows.dll is the root cause of all these problems.

I have compiled the unmodified officially released source code of
Emacs-23.3 with assertions enabled and libunicows. And the binary
works.

http://www.speedyshare.com/files/28808321/Emacs-23.3Working.png

http://www.speedyshare.com/files/28808322/Emacs-23.3ToolTip.png

However, Emacs still chooses the ansi versions of the functions
LookupAccountSid and GetFileSecurity, presumably because it bases the
decision on checking the version of Windows and not on whether the
functions are actually available.

http://www.speedyshare.com/files/28808323/Emacs-23.3GDBlibunicows.txt

> Whether to switch to linking Emacs with libunicows or manually load it
> on Windows 9X and call the Unicode functions through function
> pointers, is a different issue.  Given the small number of affected
> functions, I'm not sure what's best.

IMHO, using function pointers would mean increasing the number of
lines of explicit code, whereas using the unicows loader would open up
the possibility of decreasing the number of lines of explicit code by
unifying w9x/Me and NT/XP branches of code which handle cases of
unicode support.
On the other hand, I can imagine that the introduction of the
libunicows dependency may be an annoyance to users/developers who
don't actually need to make use of it on their systems. Perhaps this
could be addressed with a new configure option?

Greetings,
                 Osl

Message #113 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 05 Jun 2011 06:07:52 +0300

> Date: Sun, 5 Jun 2011 03:58:25 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> I have only observed that:
> - Emacs chooses the ansi versions of the functions LookupAccountSid
> and GetFileSecurity.

That's OK, and has no relation to the problem at hand.  First, file
security is not available on filesystems supported by Windows 9X.  And
second, even if they were, Emacs currently uses only the ANSI versions
of those functions anyway.

> - The next problematic unicode function is GetGlyphOutlineW which,
> like GetOutlineTextMetricsW and GetTextMetricsW, is just a stub.
> 
> The breakpoints I have set for the calls to the other unicode
> functions are never reached before the Emacs window is opened and is
> "operative" and then, after a while, I simply quit.
> 
> http://www.speedyshare.com/files/28808320/Emacs-23.3GDBGetErrors.txt

Thanks, this is great news.

So if you call GetGlyphOutlineW through a function pointer, like you
did with the other 2 functions, and do NOT link against libunicows, do
you then get a working binary?  It would be good to run such a binary
for a while, and see if something else is broken, if you can afford
that.

> IMHO, using function pointers would mean increasing the number of
> lines of explicit code, whereas using the unicows loader would open up
> the possibility of decreasing the number of lines of explicit code by
> unifying w9x/Me and NT/XP branches of code which handle cases of
> unicode support.
> On the other hand, I can imagine that the introduction of the
> libunicows dependency may be an annoyance to users/developers who
> don't actually need to make use of it on their systems.

Right, that's exactly the tradeoff.  If the issue is with only 3
functions, I tend to the function pointer method.

> Perhaps this could be addressed with a new configure option?

If we go the libunicows way, I'd tend simply to silently link without
it if it is not installed.  That would take care of this for most of
the users who build their own Emacs.

But the annoyance is for those who build binaries we upload to the GNU
servers.  They will have to make sure libunicows is installed and
workable.

Anyway, thanks for your great help.  I think we will have a solution
very soon.

Message #116 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <at> gmail.com
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 05 Jun 2011 01:48:27 -0400

> Date: Sun, 05 Jun 2011 06:07:52 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > Date: Sun, 5 Jun 2011 03:58:25 +0200
> > From: oslsachem <oslsachem <at> gmail.com>
> > Cc: 8562 <at> debbugs.gnu.org
> > 
> > I have only observed that:
> > - Emacs chooses the ansi versions of the functions LookupAccountSid
> > and GetFileSecurity.
> 
> That's OK, and has no relation to the problem at hand.  First, file
> security is not available on filesystems supported by Windows 9X.  And
> second, even if they were, Emacs currently uses only the ANSI versions
> of those functions anyway.

It's actually more than that: Emacs currently uses the ANSI versions
of _all_ functions, except those that are explicitly called with the
`W' suffix in the Emacs sources.  So only those calls to Unicode
functions you see in the sources are relevant to the issue at hand.

Message #119 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Mon, 6 Jun 2011 00:32:16 +0200

>> I have only observed that:
>> - Emacs chooses the ansi versions of the functions LookupAccountSid
>> and GetFileSecurity.
>
> That's OK, and has no relation to the problem at hand.  First, file
> security is not available on filesystems supported by Windows 9X.  And
> second, even if they were, Emacs currently uses only the ANSI versions
> of those functions anyway.

I'm sorry for bringing up this issue. I should have realized of that
myself: these functions are not in the list of unicode functions
called by Emacs which are implemented in unicows.dll, which I
previously posted in this thread.

> So if you call GetGlyphOutlineW through a function pointer, like you
> did with the other 2 functions, and do NOT link against libunicows, do
> you then get a working binary?  It would be good to run such a binary
> for a while, and see if something else is broken, if you can afford
> that.

Of course, I will check it.

> Anyway, thanks for your great help.  I think we will have a solution
> very soon.

Thanks to you for your instructions.

Greetings,
                  Osl

Message #122 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 7 Jun 2011 21:25:55 +0200

>> So if you call GetGlyphOutlineW through a function pointer, like you
>> did with the other 2 functions, and do NOT link against libunicows, do
>> you then get a working binary?  It would be good to run such a binary
>> for a while, and see if something else is broken, if you can afford
>> that.
>
> Of course, I will check it.

The binary works without any noticeable problem.

http://www.speedyshare.com/files/28854882/EmacsWithLogo.png

Well, it has a glitch: when the window is maximized, clicking on the
help menu item "about Emacs" brings out an alternative version of this
buffer which doesn't have the Emacs logotype, has a slightly different
phrasing and its links are no longer coloured.

http://www.speedyshare.com/files/28854883/EmacsWithoutLogo.png

But I have checked that this glitch also happens in the version of
Emacs built with libunicows, and it still appears in the trunk
version.  And it already appeared in Emacs-22.3 but I hadn't noticed
until now.  In any case, only under windows 98.


http://www.speedyshare.com/files/28854884/Emacs-23.3GDBGetGlyph.txt

Observations:
- AppendMenuW is called through a function pointer and is a stub
(error 120), but this is handled by subsequent code.
- ExtTextOutW doesn't produce an error so, apparently, this function
is not a stub in windows 98.
- Again, the breakpoints I have set for the calls to the other unicode
functions are never reached before the Emacs window is opened and is
operative and then, after a while, I simply quit.

In a second build, I have tried using the unicows implementation of
AppendMenuW and I have noticed that the menu items tooltips no longer
show.

I have built an updated trunk version of Emacs with the same changes
applied and it works equally well.

Greetings,
                 Osl

Message #125 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Tue, 07 Jun 2011 23:32:14 +0300

> Date: Tue, 7 Jun 2011 21:25:55 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> >> So if you call GetGlyphOutlineW through a function pointer, like you
> >> did with the other 2 functions, and do NOT link against libunicows, do
> >> you then get a working binary?  It would be good to run such a binary
> >> for a while, and see if something else is broken, if you can afford
> >> that.
> >
> > Of course, I will check it.
> 
> The binary works without any noticeable problem.

Thank you.  I will prepare an official patch for that, which should
work both on Windows 9X and on the NT family of Windows, and will ask
you to test it.  In the meantime, if you could give this binary more
testing when you have time, it would be even better.

> Well, it has a glitch: when the window is maximized, clicking on the
> help menu item "about Emacs" brings out an alternative version of this
> buffer which doesn't have the Emacs logotype, has a slightly different
> phrasing and its links are no longer coloured.
> 
> http://www.speedyshare.com/files/28854883/EmacsWithoutLogo.png

This is not a bug: the usual "fancy" splash screen is only shown if
Emacs can display XPM or PBM images.  Otherwise, Emacs shows the
"normal" splash screen, which is what you see.  I'm guessing that you
don't have XPM or PBM libraries installed on the Windows 9X machine,
or you didn't have the necessary headers when you built Emacs (the
configure.bat script should announce what image libraries it builds
with).  See the function use-fancy-splash-screens-p in startup.el.
The file nt/INSTALL explains where to get the image libraries if you
want to build Emacs with full image support.

> In a second build, I have tried using the unicows implementation of
> AppendMenuW and I have noticed that the menu items tooltips no longer
> show.

So it looks like we are better off without libunicows, with using
function pointers to call the crucial several functions needed for
normal display.

Btw, could you please enumerate those functions you replaced?  I'm not
sure my notes about that are accurate.

> I have built an updated trunk version of Emacs with the same changes
> applied and it works equally well.

Thanks again.

Message #128 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 8 Jun 2011 20:11:37 +0200

>> Well, it has a glitch: when the window is maximized, clicking on the
>> help menu item "about Emacs" brings out an alternative version of this
>> buffer which doesn't have the Emacs logotype, has a slightly different
>> phrasing and its links are no longer coloured.
>>
>> http://www.speedyshare.com/files/28854883/EmacsWithoutLogo.png
>
> This is not a bug: the usual "fancy" splash screen is only shown if
> Emacs can display XPM or PBM images.  Otherwise, Emacs shows the
> "normal" splash screen, which is what you see.  I'm guessing that you
> don't have XPM or PBM libraries installed on the Windows 9X machine,
> or you didn't have the necessary headers when you built Emacs (the
> configure.bat script should announce what image libraries it builds
> with).  See the function use-fancy-splash-screens-p in startup.el.
> The file nt/INSTALL explains where to get the image libraries if you
> want to build Emacs with full image support.

For simplicity (for me) I have been building Emacs without image
libraries (i.e --without-xpm --without-png --without-jpeg
--without-gif --without-tiff ).

After more fiddling, I can now describe the issue more accurately, and
it seems to be a design decision:

In any version of windows, if the window apparently does not have at
least a certain height and I type c-h c-a, I get the *about GNU Emacs*
buffer version of text terminal Emacs (i.e. emacs -nw) which does not
show a logotype:

http://www.speedyshare.com/files/28873451/EmacsNotHighEnough.png

On the contrary, if the window has at least a certain height and I
type c-h c-a, I get the expected *about GNU Emacs* buffer version of
graphical Emacs which, in this case, shows the black and white,
coarser logotype:

http://www.speedyshare.com/files/28873452/EmacsHighEnough.png

However, I still have one more question left:
In any version of Emacs for windows, if you start Emacs without the -Q
option and then type c-h c-a you end up with two differently named and
sized buffers (*GNU Emacs*, *About GNU Emacs*) which have the same
contents and so, presumably, the same functionality. Is there a reason
for this?

http://www.speedyshare.com/files/28873453/TwoGNUEmacsBuffers.png

> Btw, could you please enumerate those functions you replaced?  I'm not
> sure my notes about that are accurate.

In the end, only 3 functions seem to need to be imported from
unicows.dll in windows 98:

GetOutlineTextMetricsW

GetTextMetricsW

GetGlyphOutlineW

These seem to be the functions signatures ( by consulting MSDN ):

typedef UINT ( * GetOutlineTextMetricsW_Proc)(
   HDC hdc,
   UINT cbData,
   LPOUTLINETEXTMETRICW lpotmw
);
typedef BOOL ( * GetTextMetricsW_Proc)(
   HDC hdc,
   LPTEXTMETRICW lptmw
);
typedef DWORD ( * GetGlyphOutlineW_Proc)(
   HDC hdc,
   UINT uChar,
   UINT uFormat,
   LPGLYPHMETRICS lpgm,
   DWORD cbBuffer,
   LPVOID lpvBuffer,
   const MAT2 *lpmat2
);

I have changed two parameter types to avoid these compiler warnings:

warning: passing argument 3 of 'Get_Outline_Text_Metrics_W' from
incompatible pointer type
note: expected 'LPOUTLINETEXTMETRIC' but argument is of type 'struct
OUTLINETEXTMETRICW *'

warning: passing argument 2 of 'Get_Text_Metrics_W' from incompatible
pointer type
note: expected 'LPTEXTMETRIC' but argument is of type 'struct TEXTMETRICW *'

Greetings,
                 Osl

Message #131 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Wed, 08 Jun 2011 23:36:35 +0300

> Date: Wed, 8 Jun 2011 20:11:37 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> In any version of windows, if the window apparently does not have at
> least a certain height and I type c-h c-a, I get the *about GNU Emacs*
> buffer version of text terminal Emacs (i.e. emacs -nw) which does not
> show a logotype:
> 
> http://www.speedyshare.com/files/28873451/EmacsNotHighEnough.png
> 
> On the contrary, if the window has at least a certain height and I
> type c-h c-a, I get the expected *about GNU Emacs* buffer version of
> graphical Emacs which, in this case, shows the black and white,
> coarser logotype:
> 
> http://www.speedyshare.com/files/28873452/EmacsHighEnough.png

Yes, this works as intended, see again the function
use-fancy-splash-screens-p, which tests the frame size against the
size of the image displayed in the fancy splash screen.

> However, I still have one more question left:
> In any version of Emacs for windows, if you start Emacs without the -Q
> option and then type c-h c-a you end up with two differently named and
> sized buffers (*GNU Emacs*, *About GNU Emacs*) which have the same
> contents and so, presumably, the same functionality. Is there a reason
> for this?

The contents are very similar, but not identical.  Feel free to ask
this question on emacs-devel <at> gnu.org, though: perhaps there's a place
for improvement there.

> > Btw, could you please enumerate those functions you replaced?  I'm not
> > sure my notes about that are accurate.
> 
> In the end, only 3 functions seem to need to be imported from
> unicows.dll in windows 98:
> 
> GetOutlineTextMetricsW
> 
> GetTextMetricsW
> 
> GetGlyphOutlineW
> 
> These seem to be the functions signatures ( by consulting MSDN ):
> 
> typedef UINT ( * GetOutlineTextMetricsW_Proc)(
>    HDC hdc,
>    UINT cbData,
>    LPOUTLINETEXTMETRICW lpotmw
> );
> typedef BOOL ( * GetTextMetricsW_Proc)(
>    HDC hdc,
>    LPTEXTMETRICW lptmw
> );
> typedef DWORD ( * GetGlyphOutlineW_Proc)(
>    HDC hdc,
>    UINT uChar,
>    UINT uFormat,
>    LPGLYPHMETRICS lpgm,
>    DWORD cbBuffer,
>    LPVOID lpvBuffer,
>    const MAT2 *lpmat2
> );
> 
> I have changed two parameter types to avoid these compiler warnings:
> 
> warning: passing argument 3 of 'Get_Outline_Text_Metrics_W' from
> incompatible pointer type
> note: expected 'LPOUTLINETEXTMETRIC' but argument is of type 'struct
> OUTLINETEXTMETRICW *'
> 
> warning: passing argument 2 of 'Get_Text_Metrics_W' from incompatible
> pointer type
> note: expected 'LPTEXTMETRIC' but argument is of type 'struct TEXTMETRICW *'

Thanks.

Message #134 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sun, 12 Jun 2011 23:47:33 +0200

>> In a second build, I have tried using the unicows implementation of
>> AppendMenuW and I have noticed that the menu items tooltips no longer
>> show.
>
> So it looks like we are better off without libunicows, with using
> function pointers to call the crucial several functions needed for
> normal display.

I didn't remember the libunicows build of emacs not showing the menu
items tooltips so I checked it, and it actually showed them.

So, reviewing globals_of_w32menu:

globals_of_w32menu ()
{
  /* See if Get/SetMenuItemInfo functions are available.  */
  HMODULE user32 = GetModuleHandle ("user32.dll");
  get_menu_item_info = (GetMenuItemInfoA_Proc) GetProcAddress (user32,
"GetMenuItemInfoA");
  set_menu_item_info = (SetMenuItemInfoA_Proc) GetProcAddress (user32,
"SetMenuItemInfoA");
  unicode_append_menu = (AppendMenuW_Proc) GetProcAddress (user32,
"AppendMenuW");
}

I realized that I had carelessly replaced all the occurrences of
'user32' with 'unicows' expecting that:
- At this point in the execution, the unicows library would be already
loaded, which seems to be true.
- Unicows would provide the most up-to-date implementations of the
ansi versions of these functions, which is false.  In general, unicows
only provides the ansi implementations for a few of the functions.  In
particular, unicows doesn't provide the ansi implementations for these
specific functions.

So the change correctly done (supposing the is_windows_9x() function
was available for this file) could be something like :

void
globals_of_w32menu ()
{
  /* See if Get/SetMenuItemInfo functions are available.  */
  HMODULE user32 = GetModuleHandle ("user32.dll");
  get_menu_item_info = (GetMenuItemInfoA_Proc) GetProcAddress (user32,
"GetMenuItemInfoA");
  set_menu_item_info = (SetMenuItemInfoA_Proc) GetProcAddress (user32,
"SetMenuItemInfoA");
  if (is_windows_9x())
    {
      HMODULE unicows = GetModuleHandle ("unicows.dll");
      unicode_append_menu = (AppendMenuW_Proc) GetProcAddress
(unicows, "AppendMenuW");
    }
  else unicode_append_menu = (AppendMenuW_Proc) GetProcAddress
(user32, "AppendMenuW");
}

I think it would be interesting to make this change given that this
unicode function is already called through function pointers and that
this would keep the execution branches of windows 9x and windows NT as
close as possible.

Greetings,
                 Osl

Message #137 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <at> gmail.com
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sat, 01 Oct 2011 14:03:11 +0300

> Date: Tue, 07 Jun 2011 23:32:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > The binary works without any noticeable problem.
> 
> Thank you.  I will prepare an official patch for that, which should
> work both on Windows 9X and on the NT family of Windows, and will ask
> you to test it.

Sorry for such a long delay, I got distracted by issues that needed to
be resolved before Emacs 24 enters the pretest.

Please find below a patch that should let Emacs work correctly on
Windows 9X systems that have UNICOWS.DLL installed.  If UNICOWS.DLL is
not installed, Emacs should pop up an error dialog to that effect, and
refuse to start up.  "emacs -nw" should be possible even if that DLL
is not available.

Please give this a try, both with and without UNICOWS.DLL available,
and see if the results are good.  I will then install this in the
development trunk, and this will be available as part of Emacs 24.1.

It is best to try this in the current development code, or with the
emacs-24.0.90 pretest (which you can find on alpha.gnu.org).

Thanks again for your great help in resolving this issue.

Here's the patch to apply:

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-09-30 20:22:01 +0000
+++ src/ChangeLog	2011-10-01 10:55:28 +0000
@@ -1,3 +1,24 @@
+2011-10-01  Eli Zaretskii  <eliz <at> gnu.org>
+
+	Fix Emacs on Windows 9X (bug#8562).
+	Thanks to oslsachem <oslsachem <at> gmail.com> for debugging this.
+
+	* w32font.c (g_b_init_is_w9x, g_b_init_get_outline_metrics_w)
+	(g_b_init_get_text_metrics_w, g_b_init_get_glyph_outline_w)
+	(g_b_init_get_glyph_outline_w): New static variables.
+	(GetOutlineTextMetricsW_Proc, GetTextMetricsW_Proc)
+	(GetGlyphOutlineW_Proc): New typedefs.
+	(w32_load_unicows_or_gdi32, get_outline_metrics_w)
+	(get_text_metrics_w, get_glyph_outline_w, globals_of_w32font): New
+	functions.
+	(w32font_open_internal, compute_metrics): Call
+	get_outline_metrics_w, get_text_metrics_w, and get_glyph_outline_w
+	instead of calling the "wide" APIs directly.
+
+	* emacs.c (main) [HAVE_NTGUI]: Call globals_of_w32font.
+
+	* w32.h (syms_of_w32font): Add prototype.
+
 2011-09-30  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	* buffer.h (struct buffer): Use time_t, not int, for a time stamp.

=== modified file 'src/emacs.c'
--- src/emacs.c	2011-09-24 09:22:06 +0000
+++ src/emacs.c	2011-10-01 10:06:12 +0000
@@ -1591,6 +1591,7 @@ Using an Emacs configured with --with-x-
       /* Initialization that must be done even if the global variable
 	 initialized is non zero.  */
 #ifdef HAVE_NTGUI
+      globals_of_w32font ();
       globals_of_w32fns ();
       globals_of_w32menu ();
       globals_of_w32select ();

=== modified file 'src/w32.h'
--- src/w32.h	2011-05-04 14:03:16 +0000
+++ src/w32.h	2011-10-01 10:11:20 +0000
@@ -139,6 +139,7 @@ extern void term_w32select (void);
 extern void syms_of_w32menu (void);
 extern void globals_of_w32menu (void);
 extern void syms_of_fontset (void);
+extern void syms_of_w32font (void);
 
 extern int _sys_read_ahead (int fd);
 extern int _sys_wait_accept (int fd);

=== modified file 'src/w32font.c'
--- src/w32font.c	2011-05-12 07:07:06 +0000
+++ src/w32font.c	2011-10-01 10:43:40 +0000
@@ -145,6 +145,137 @@ struct font_callback_data
    style variations if the font name is not specified.  */
 static void list_all_matching_fonts (struct font_callback_data *);
 
+static BOOL g_b_init_is_w9x;
+static BOOL g_b_init_get_outline_metrics_w;
+static BOOL g_b_init_get_text_metrics_w;
+static BOOL g_b_init_get_glyph_outline_w;
+static BOOL g_b_init_get_glyph_outline_w;
+
+typedef UINT (WINAPI * GetOutlineTextMetricsW_Proc) (
+   HDC hdc,
+   UINT cbData,
+   LPOUTLINETEXTMETRICW lpotmw);
+typedef BOOL (WINAPI * GetTextMetricsW_Proc) (
+   HDC hdc,
+   LPTEXTMETRICW lptmw);
+typedef DWORD (WINAPI * GetGlyphOutlineW_Proc) (
+   HDC hdc,
+   UINT uChar,
+   UINT uFormat,
+   LPGLYPHMETRICS lpgm,
+   DWORD cbBuffer,
+   LPVOID lpvBuffer,
+   const MAT2 *lpmat2);
+
+/* Several "wide" functions we use to support the font backends are
+   unavailable on Windows 9X, unless UNICOWS.DLL is installed (their
+   versions in the default libraries are non-functional stubs).  On NT
+   and later systems, these functions are in GDI32.DLL.  The following
+   helper function attempts to load UNICOWS.DLL on Windows 9X, and
+   refuses to let Emacs start up if that library is not found.  On NT
+   and later versions, it simply loads GDI32.DLL, which should always
+   be available.  */
+static HMODULE
+w32_load_unicows_or_gdi32 (void)
+{
+  static BOOL is_9x = 0;
+  OSVERSIONINFO os_ver;
+  HMODULE ret;
+  if (g_b_init_is_w9x == 0)
+    {
+      g_b_init_is_w9x = 1;
+      ZeroMemory (&os_ver, sizeof (OSVERSIONINFO));
+      os_ver.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
+      if (GetVersionEx (&os_ver))
+	is_9x = (os_ver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS);
+    }
+  if (is_9x)
+    {
+      ret = LoadLibrary ("Unicows.dll");
+      if (!ret)
+	{
+	  int button;
+
+	  button = MessageBox (NULL,
+			       "Emacs cannot load the UNICOWS.DLL library.\n"
+			       "This library is essential for using Emacs\n"
+			       "on this system.  You need to install it.\n\n"
+			       "However, you can still use Emacs by invoking\n"
+			       "it with the '-nw' command-line option.\n\n"
+			       "Emacs will exit when you click OK.",
+			       "Emacs cannot load UNICOWS.DLL",
+			       MB_ICONERROR | MB_TASKMODAL
+			       | MB_SETFOREGROUND | MB_OK);
+	  switch (button)
+	    {
+	    case IDOK:
+	    default:
+	      exit (1);
+	    }
+	}
+    }
+  else
+    ret = LoadLibrary ("Gdi32.dll");
+}
+
+/* The following 3 functions call the problematic "wide" APIs via
+   function pointers, to avoid linking against the non-standard
+   libunicows on W9X.  */
+static UINT WINAPI
+get_outline_metrics_w(HDC hdc, UINT cbData, LPOUTLINETEXTMETRICW lpotmw)
+{
+  static GetOutlineTextMetricsW_Proc s_pfn_Get_Outline_Text_MetricsW = NULL;
+  HMODULE hm_unicows = NULL;
+  if (g_b_init_get_outline_metrics_w == 0)
+    {
+      g_b_init_get_outline_metrics_w = 1;
+      hm_unicows = w32_load_unicows_or_gdi32 ();
+      if (hm_unicows)
+	s_pfn_Get_Outline_Text_MetricsW = (GetOutlineTextMetricsW_Proc)
+	  GetProcAddress (hm_unicows, "GetOutlineTextMetricsW");
+    }
+  if (s_pfn_Get_Outline_Text_MetricsW == NULL)
+    abort ();	/* cannot happen */
+  return s_pfn_Get_Outline_Text_MetricsW (hdc, cbData, lpotmw);
+}
+
+static BOOL WINAPI
+get_text_metrics_w(HDC hdc, LPTEXTMETRICW lptmw)
+{
+  static GetTextMetricsW_Proc s_pfn_Get_Text_MetricsW = NULL;
+  HMODULE hm_unicows = NULL;
+  if (g_b_init_get_text_metrics_w == 0)
+    {
+      g_b_init_get_text_metrics_w = 1;
+      hm_unicows = w32_load_unicows_or_gdi32 ();
+      if (hm_unicows)
+	s_pfn_Get_Text_MetricsW = (GetTextMetricsW_Proc)
+	  GetProcAddress (hm_unicows, "GetTextMetricsW");
+    }
+  if (s_pfn_Get_Text_MetricsW == NULL)
+    abort ();	/* cannot happen */
+  return s_pfn_Get_Text_MetricsW (hdc, lptmw);
+}
+
+static DWORD WINAPI
+get_glyph_outline_w (HDC hdc, UINT uChar, UINT uFormat, LPGLYPHMETRICS lpgm,
+		     DWORD cbBuffer, LPVOID lpvBuffer, const MAT2 *lpmat2)
+{
+  static GetGlyphOutlineW_Proc s_pfn_Get_Glyph_OutlineW = NULL;
+  HMODULE hm_unicows = NULL;
+  if (g_b_init_get_glyph_outline_w == 0)
+    {
+      g_b_init_get_glyph_outline_w = 1;
+      hm_unicows = w32_load_unicows_or_gdi32 ();
+      if (hm_unicows)
+	s_pfn_Get_Glyph_OutlineW = (GetGlyphOutlineW_Proc)
+	  GetProcAddress (hm_unicows, "GetGlyphOutlineW");
+    }
+  if (s_pfn_Get_Glyph_OutlineW == NULL)
+    abort ();	/* cannot happen */
+  return s_pfn_Get_Glyph_OutlineW (hdc, uChar, uFormat, lpgm, cbBuffer,
+				   lpvBuffer, lpmat2);
+}
 
 static int
 memq_no_quit (Lisp_Object elt, Lisp_Object list)
@@ -816,11 +947,11 @@ w32font_open_internal (FRAME_PTR f, Lisp
   old_font = SelectObject (dc, hfont);
 
   /* Try getting the outline metrics (only works for truetype fonts).  */
-  len = GetOutlineTextMetricsW (dc, 0, NULL);
+  len = get_outline_metrics_w (dc, 0, NULL);
   if (len)
     {
       metrics = (OUTLINETEXTMETRICW *) alloca (len);
-      if (GetOutlineTextMetricsW (dc, len, metrics))
+      if (get_outline_metrics_w (dc, len, metrics))
         memcpy (&w32_font->metrics, &metrics->otmTextMetrics,
 		sizeof (TEXTMETRICW));
       else
@@ -828,7 +959,7 @@ w32font_open_internal (FRAME_PTR f, Lisp
     }
 
   if (!metrics)
-    GetTextMetricsW (dc, &w32_font->metrics);
+    get_text_metrics_w (dc, &w32_font->metrics);
 
   w32_font->cached_metrics = NULL;
   w32_font->n_cache_blocks = 0;
@@ -2306,7 +2437,7 @@ compute_metrics (HDC dc, struct w32font_
   transform.eM11.value = 1;
   transform.eM22.value = 1;
 
-  if (GetGlyphOutlineW (dc, code, options, &gm, 0, NULL, &transform)
+  if (get_glyph_outline_w (dc, code, options, &gm, 0, NULL, &transform)
       != GDI_ERROR)
     {
       metrics->lbearing = gm.gmptGlyphOrigin.x;
@@ -2581,3 +2712,13 @@ versions of Windows) characters.  */);
   w32font_driver.type = Qgdi;
   register_font_driver (&w32font_driver, NULL);
 }
+
+void
+globals_of_w32font (void)
+{
+  g_b_init_is_w9x = 0;
+  g_b_init_get_outline_metrics_w = 0;
+  g_b_init_get_text_metrics_w = 0;
+  g_b_init_get_glyph_outline_w = 0;
+}
+

Message #140 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sat, 01 Oct 2011 14:06:25 +0300

> Date: Sun, 12 Jun 2011 23:47:33 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> So the change correctly done (supposing the is_windows_9x() function
> was available for this file) could be something like :
> 
> void
> globals_of_w32menu ()
> {
>   /* See if Get/SetMenuItemInfo functions are available.  */
>   HMODULE user32 = GetModuleHandle ("user32.dll");
>   get_menu_item_info = (GetMenuItemInfoA_Proc) GetProcAddress (user32,
> "GetMenuItemInfoA");
>   set_menu_item_info = (SetMenuItemInfoA_Proc) GetProcAddress (user32,
> "SetMenuItemInfoA");
>   if (is_windows_9x())
>     {
>       HMODULE unicows = GetModuleHandle ("unicows.dll");
>       unicode_append_menu = (AppendMenuW_Proc) GetProcAddress
> (unicows, "AppendMenuW");
>     }
>   else unicode_append_menu = (AppendMenuW_Proc) GetProcAddress
> (user32, "AppendMenuW");
> }
> 
> I think it would be interesting to make this change given that this
> unicode function is already called through function pointers and that
> this would keep the execution branches of windows 9x and windows NT as
> close as possible.

I would like to avoid making changes for which we don't have a good
reason and a clear test case.  So if you can spot any significant
differences in menus depending on whether AppendMenuW comes from
unicows.dll or elsewhere, please show them, and let's take it from
there.  If there are no significant differences, I'd prefer not to
rock the boat more than necessary.

Thanks.

Message #143 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Thu, 27 Oct 2011 00:46:01 +0200

Sorry for the late reply, I haven't checked this email address for weeks.

> Please find below a patch that should let Emacs work correctly on
> Windows 9X systems that have UNICOWS.DLL installed.

http://www.speedyshare.com/files/30942248/EmacsWithUnicowsWindow.png

http://www.speedyshare.com/files/30942249/EmacsWithUnicowsGDB.txt

> If UNICOWS.DLL is
> not installed, Emacs should pop up an error dialog to that effect, and
> refuse to start up.

http://www.speedyshare.com/files/30942250/EmacsWithoutUnicowsErrorWindow.png

http://www.speedyshare.com/files/30942251/EmacsWithoutUnicowsGDB.txt

>  "emacs -nw" should be possible even if that DLL
> is not available.

http://www.speedyshare.com/files/30942252/EmacsNWWithoutUnicowsWindow.png

http://www.speedyshare.com/files/30942253/EmacsNWWithoutUnicowsGDB.txt

> Please give this a try, both with and without UNICOWS.DLL available,
> and see if the results are good.

As far as I can tell, the patched Emacs works perfectly when using
emacs.exe (and runemacs.exe with unicows.dll).

However, when using runemacs.exe without unicows.dll, the program
doesn't show the error dialog window or the application window and the
process stays hidden in the background instead of exiting gracefully.

> It is best to try this in the current development code, or with the
> emacs-24.0.90 pretest (which you can find on alpha.gnu.org).

"This is GNU Emacs 24.0.90.1 (i386-mingw-windows98.2222) [...]"

Greetings,
    Osl

Message #146 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Thu, 27 Oct 2011 01:05:53 +0200

> I would like to avoid making changes for which we don't have a good
> reason and a clear test case.  So if you can spot any significant
> differences in menus depending on whether AppendMenuW comes from
> unicows.dll or elsewhere, please show them, and let's take it from
> there.  If there are no significant differences, I'd prefer not to
> rock the boat more than necessary.

Indeed, I couldn't tell any difference between them.
Come to think of it, I can't but agree with you. It seems a good
example of "if it ain't broke, don't fix it" or "never change a
running system" :)

Greetings,
    Osl

Message #149 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Thu, 27 Oct 2011 10:53:46 -0400

> Date: Thu, 27 Oct 2011 00:46:01 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> Sorry for the late reply, I haven't checked this email address for weeks.

No worries.

> As far as I can tell, the patched Emacs works perfectly when using
> emacs.exe (and runemacs.exe with unicows.dll).

Thanks.

> However, when using runemacs.exe without unicows.dll, the program
> doesn't show the error dialog window or the application window and the
> process stays hidden in the background instead of exiting gracefully.

Which process stays hidden -- the original runemacs.exe or emacs.exe
that is run by runemacs.exe?

Message #152 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 28 Oct 2011 12:10:58 +0200

> Date: Thu, 27 Oct 2011 00:46:01 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > Please give this a try, both with and without UNICOWS.DLL available,
> > and see if the results are good.
> 
> As far as I can tell, the patched Emacs works perfectly when using
> emacs.exe (and runemacs.exe with unicows.dll).

Thanks, I installed the changes in the bzr repository.  The next
pretest, due in a day or two, should work on Windows 9X.

> However, when using runemacs.exe without unicows.dll, the program
> doesn't show the error dialog window or the application window and the
> process stays hidden in the background instead of exiting gracefully.

See my other mail about this.

Message #155 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: Jason Rumney <jasonr <at> gnu.org>, 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 28 Oct 2011 12:21:12 +0200

> Date: Thu, 27 Oct 2011 21:38:55 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> 
> > 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.

Does it matter in your case whether Emacs is invoked from the command
prompt or from a shortcut?

Jason, could you perhaps help me out here, by looking at the patch I
posted in this bug report?  Did I do something wrong with how I invoke
the error dialog that might not work on Windows 9X, when Emacs is
invoked via runemacs?

If nothing else gives a clue, I think I can make a similar test in
runemacs.exe and pop up the error dialog from there.

Thanks.

Message #158 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <at> gmail.com
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: 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 <eliz <at> gnu.org>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > Date: Thu, 27 Oct 2011 21:38:55 +0200
> > From: oslsachem <oslsachem <at> gmail.com>
> > 
> > > 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

Message #161 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: 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

Message #164 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 04 Nov 2011 13:42:11 +0200

> Date: Sun, 30 Oct 2011 00:24:31 +0200
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> - 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)

Maybe.  But since we are in a pretest, I opted for a safer solution:
add a similar test to runemacs.  The patch is below; please try
applying it to the current trunk of Emacs 24.  If it works, I will
commit it.

Thanks.

=== modified file 'nt/ChangeLog'
--- a/nt/ChangeLog	2011-11-04 11:36:25 +0000
+++ b/nt/ChangeLog	2011-11-04 11:41:29 +0000
@@ -1,3 +1,11 @@
+2011-11-04  Eli Zaretskii  <eliz <at> gnu.org>
+
+	* runemacs.c (ensure_unicows_dll): New function, tries to load
+	UNICOWS.DLL on Windows 9X.
+	(WinMain): If ensure_unicows_dll fails to find UNICOWS.DLL,
+	display a dialog to the effect that Emacs cannot be started.
+	(Bug#8562)
+
 2011-10-28  Eli Zaretskii  <eliz <at> gnu.org>
 
 	* README.W32: Mention UNICOWS.DLL as prerequisite for running

=== modified file 'nt/runemacs.c'
--- a/nt/runemacs.c	2011-11-04 11:36:25 +0000
+++ b/nt/runemacs.c	2011-11-04 11:41:29 +0000
@@ -45,6 +45,7 @@
 #include <malloc.h>
 
 static void set_user_model_id (void);
+static int ensure_unicows_dll (void);
 
 int WINAPI
 WinMain (HINSTANCE hSelf, HINSTANCE hPrev, LPSTR cmdline, int nShow)
@@ -59,6 +60,9 @@
   char *p;
   char modname[MAX_PATH];
 
+  if (!ensure_unicows_dll ())
+    goto error;
+
   set_user_model_id ();
 
   if (!GetModuleFileName (NULL, modname, MAX_PATH))
@@ -203,3 +207,43 @@
     }
 }
 
+static int
+ensure_unicows_dll (void)
+{
+  OSVERSIONINFO os_ver;
+  HMODULE h;
+
+  ZeroMemory (&os_ver, sizeof (OSVERSIONINFO));
+  os_ver.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
+  if (!GetVersionEx (&os_ver))
+    return 0;
+
+  if (os_ver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS)
+    {
+      h = LoadLibrary ("Unicows.dll");
+      if (!h)
+	{
+	  int button;
+
+	  button = MessageBox (NULL,
+			       "Emacs cannot load the UNICOWS.DLL library.\n"
+			       "This library is essential for using Emacs\n"
+			       "on this system.  You need to install it.\n\n"
+			       "However, you can still use Emacs by invoking\n"
+			       "it with the '-nw' command-line option.\n\n"
+			       "Emacs will exit when you click OK.",
+			       "Emacs cannot load UNICOWS.DLL",
+			       MB_ICONERROR | MB_TASKMODAL
+			       | MB_SETFOREGROUND | MB_OK);
+	  switch (button)
+	    {
+	      case IDOK:
+	      default:
+	        return 0;
+	    }
+	}
+      FreeLibrary (h);
+      return 1;
+    }
+  return 1;
+}

Message #167 received at 8562 <at> debbugs.gnu.org (full text, mbox):

From: oslsachem <oslsachem <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8562 <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Fri, 4 Nov 2011 21:59:57 +0100

> Maybe.  But since we are in a pretest, I opted for a safer solution:
> add a similar test to runemacs.  The patch is below; please try
> applying it to the current trunk of Emacs 24.  If it works, I will
> commit it.

"This is GNU Emacs 24.0.91.1 (i386-mingw-windows98.2222) [...]"

As far as I can tell, the patched Emacs works flawlessly:

http://speedy.sh/6cENk/RunemacsWithoutUnicowsErrorWindow1.png

http://speedy.sh/m8Mkt/RunemacsWithoutUnicowsErrorWindow2.png

http://speedy.sh/fqHtP/RunemacsWithoutUnicowsGDB.txt

http://speedy.sh/7FUP6/RunemacsWithUnicows.png

http://speedy.sh/hpg6m/RunemacsWithUnicowsGDB.txt

Greetings,
    Osl

Message #172 received at 8562-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: oslsachem <oslsachem <at> gmail.com>
Cc: 8562-done <at> debbugs.gnu.org
Subject: Re: bug#8562: Emacs 23.1 and later don't work in windows 98
Date: Sat, 05 Nov 2011 00:01:13 +0200

> Date: Fri, 4 Nov 2011 21:59:57 +0100
> From: oslsachem <oslsachem <at> gmail.com>
> Cc: 8562 <at> debbugs.gnu.org
> 
> > Maybe.  But since we are in a pretest, I opted for a safer solution:
> > add a similar test to runemacs.  The patch is below; please try
> > applying it to the current trunk of Emacs 24.  If it works, I will
> > commit it.
> 
> "This is GNU Emacs 24.0.91.1 (i386-mingw-windows98.2222) [...]"
> 
> As far as I can tell, the patched Emacs works flawlessly:

Thanks.  I committed those changes, which completes the solution for
this problem.

This bug is now officially closed.  Thanks so much for all your help
during the work on the solution.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.