From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows] Date: Wed, 23 Oct 2002 03:10:35 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1035357048 1298 80.91.224.249 (23 Oct 2002 07:10:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 07:10:48 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 184FfD-0000Kl-00 for ; Wed, 23 Oct 2002 09:10:47 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184Fgn-0007d4-00 for ; Wed, 23 Oct 2002 09:12:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 184Ffp-0007Yt-00; Wed, 23 Oct 2002 03:11:25 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184Ff6-0006ma-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 03:10:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184Ff2-0006fT-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 03:10:39 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 184Ff2-0006fN-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 03:10:36 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 184Ff1-0007WC-00; Wed, 23 Oct 2002 03:10:35 -0400 Original-To: andrewi@gnu.org, eliz@is.elta.co.il Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8671 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8671 Any ideas for what to do here? ------- Start of forwarded message ------- Envelope-to: emacs-pretest-bug@gnu.org Delivery-date: Mon, 21 Oct 2002 13:43:36 -0400 X-Originating-IP: [207.46.137.206] From: "Jay Finger" To: emacs-pretest-bug@gnu.org 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 -------