all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
@ 2002-10-23  7:10 Richard Stallman
  2002-10-23 12:06 ` Juanma Barranquero
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Richard Stallman @ 2002-10-23  7:10 UTC (permalink / raw)
  Cc: emacs-devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]

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" <jay_finger@hotmail.com>
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 -------

^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
@ 2002-10-23 13:37 jasonr
  2002-10-23 13:43 ` Juanma Barranquero
  2002-10-23 16:41 ` Eli Zaretskii
  0 siblings, 2 replies; 21+ messages in thread
From: jasonr @ 2002-10-23 13:37 UTC (permalink / raw)
  Cc: andrewi, eliz, akochoi, jay_finger, emacs-devel

> Basically it makes sense to extract the definition of XColor from the
> three or four places it happens now and define it specifically in the
> *gui.h files of the platforms that need it (w32gui.h and macgui.h at
> this moment).

I think the use of XColor in xfaces.c will affect
DOS as well. I'm not sure if there is a convenient
header to put the definition in for the DOS build.

^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
@ 2002-10-23 13:44 jasonr
  0 siblings, 0 replies; 21+ messages in thread
From: jasonr @ 2002-10-23 13:44 UTC (permalink / raw)
  Cc: emacs-devel

> Other than that, do you approve of the patch?

Yes.

^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows]
@ 2002-10-24  8:25 jasonr
  0 siblings, 0 replies; 21+ messages in thread
From: jasonr @ 2002-10-24  8:25 UTC (permalink / raw)
  Cc: emacs-devel


> XColor is needed in some platforms (like Mac OS 9, Windows and DOS) and
> not in others (like X or Mac OS X), so either you put it in a include
> used by every build and guard it through #ifdef's, or put it in
> platform-specific includes. That's what I chose because it seems
> cleaner/simpler.

Having just one definition seems cleaner to me. Multiple
identical definitions lead to maintainence problems.
It has long been a goal to merge as much of the platform
specific display code as possible. So far only xfaces.c
has benefited due to lack of time. But we should at
least try to avoid introducing new duplicated code.

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2002-10-28 17:52 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-23  7:10 [jay_finger@hotmail.com: Two problems in Emacs-21.2.91 on Windows] Richard Stallman
2002-10-23 12:06 ` Juanma Barranquero
2002-10-23 16:19   ` Andrew Choi
2002-10-23 16:47     ` Juanma Barranquero
2002-10-23 16:43       ` Eli Zaretskii
2002-10-24  6:47         ` Juanma Barranquero
2002-10-25  7:51           ` Juanma Barranquero
2002-10-23 12:13 ` Juanma Barranquero
2002-10-28  5:57 ` Harald.Maier.BW
2002-10-28 17:52   ` Juanma Barranquero
  -- strict thread matches above, loose matches on Subject: below --
2002-10-23 13:37 jasonr
2002-10-23 13:43 ` Juanma Barranquero
2002-10-23 16:41 ` Eli Zaretskii
2002-10-24  6:42   ` Juanma Barranquero
2002-10-24  7:13     ` Eli Zaretskii
2002-10-24  8:06       ` Juanma Barranquero
2002-10-24  9:35         ` Kim F. Storm
2002-10-24  8:40           ` Juanma Barranquero
2002-10-24 17:28           ` Eli Zaretskii
2002-10-23 13:44 jasonr
2002-10-24  8:25 jasonr

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.