Re: Issues resolved in 1.1.5, time for 1.1.6?

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

Christopher Faylor wrote:
> 
> Problems solved:
> 
> - fixed the make -j and zsh hanging problems.
> 
> - fixed 'clear screen' only clearing part of the screen when horizontal
>   buffer is larger than visible buffer.
> 
> - fixed problem with rewinddir.
> 
> - fixed problem with ./.foo when cwd is root.
> 
> If there are no other serious issues, I am going to release 1.1.6 on
> Tuesday.

I'm copying this to the xemacs-nt list.  Those of you familiar with the
XEmacs code, please be gentle when correcting my misconceptions (I'm
sure there are some) -- as they say, "a little knowledge is a dangerous
thing"...

What about the "*main_environ = NULL" patch in dcrt0.cc ? Is that a
"fix" or just a "hack" -- it seems to fix the XEmacs problem I
previously reported, but I am still unsure *why* it fixes it.  Even
using the just-in-time gdb-debugger I can't unravel the problem enough
to figure it out.  It sure looks like xemacs is spawning *itself* as a
new process ("dumping itself" in XEmacs parlance) and the dumped version
fails to get its environment properly.

AFAIRC, when you run XEmacs.exe it creates a copy of itself in memory,
populates various areas of its codespace with pre-compiled lisp code
(which is *stored* as an additional section in the pe-i386 executable). 
Then, it exec's this new, 'dumped' xemacs.  Somewhere along this path,
something goes haywire with environment passing.  However, because of
the weirdness, it's beyond my limited familiarity with the XEmacs code
to debug -- but the "*main_environ = NULL" patch seems to fix it.

So, two questions:
  1) is "*main_environ = NULL" a hack or a fix?  If it's a fix, then it
should go in 1.1.6
  2) If it's a "hack", should it go in 1.1.6 anyway?

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com