address@hidden: Two problems in Emacs-21.2.91 on Windows]

[Richard Stallman]

Any ideas for what to do here?

------- Start of forwarded message -------
Envelope-to: address@hidden
Delivery-date: Mon, 21 Oct 2002 13:43:36 -0400
X-Originating-IP: [207.46.137.206]
From: "Jay Finger" <address@hidden>
To: address@hidden
Bcc: 
Subject: Two problems in Emacs-21.2.91 on Windows
Date: Mon, 21 Oct 2002 17:43:14 +0000
X-OriginalArrivalTime: 21 Oct 2002 17:43:14.0779 (UTC) 
FILETIME=[551402B0:01C27929]
X-Spam-Status: No, hits=0.6 required=5.0
        tests=SPAM_PHRASE_00_01
        version=2.41
X-Spam-Level: 

[Forgive me if this is the wrong alias for posting pretest bugs; I’ve been 
idling on this alias for a long time and my archive it doesn’t contain the 
procedure any more.  I’d be happy for pointers about where to rtfm about 
that.]

I’ve found two unrelated problems:  one when building with MSVC 7, the other 
in the w32 code.

1)  When building with MSVC 7:

A linker error comes up complaining about multiply defined symbols for 
_heap_init and _heap_term.  These are both defined in w32heap.c, apparently 
to prevent the functions with that name in the CRT from initializing the 
heap.  In the MSVC 7 libc.lib there are a couple of additional symbols 
defined in the object with these functions that cause that object to get 
sucked in, whereas it didn't used to get included.  Simply removing
libc.lib(heapinit.obj) from the library creates it's own problems as it 
removes other symbols needed by the CRT.

I found two hacks that seem to work, but I don't really like either because 
there are sure to be issues I don't understand:

Linking with the libc.lib from MSVC 6 works: it links, Emacs seems to work 
fine (I haven't played with any features added since 21.1.1, what I've been 
running).  I don't like this, though, since it requires hacking the build 
environment, and there may be dependencies between the compiler and libc.lib 
that I'm unaware of.  (You definitely need the V7 libc.lib if you want to 
compile with the /GS option, which was invaluable for finding the stack 
corruption described below).

The other hack that seems to work OK (it links and runs with caveats as 
above), is to just remove the definitions of _heap_init and _heap_term from 
w32heap.c.  The comment above those says "They are normally defined by the 
runtime, but we override them here so that the unnecessary HeapCreate call 
is not performed."  If it's just an extra heap that we're worried about, 
this should be slightly wasteful but harmless.  But maybe there is some 
problem caused by having that heap initialized that the comment doesn't 
record?

2) Bug in w32_term_init in w32term.c.

This function calls w32_defined_color to do lookups of colors "white" and 
"black".  It passes a pointer to a COLORDEF, but w32_term_init expects a 
pointer to an XColor.  Debug builds run fine, but on optimized builds you 
get a stack corruption and Emacs fails before painting the first window.  I 
hacked this by pasting in the definition for XColor into w32term.c and 
passing in one of those, but I figure somebody would want to actually move 
that structure to a header.  A function prototype wouldn't hurt either :-)

jay


_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access. 
http://resourcecenter.msn.com/access/plans/default.asp
------- End of forwarded message -------