GNU bug report logs - #12993
Wrong icon for Cygw32-Emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 12993 <at> debbugs.gnu.org, angelo.graziosi <at> alice.it
Subject: bug#12993: Wrong icon for Cygw32-Emacs
Date: Mon, 10 Dec 2012 21:57:23 +0200

> Date: Mon, 10 Dec 2012 08:24:30 -0800
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: 12993 <at> debbugs.gnu.org, angelo.graziosi <at> alice.it
> 
> >        SetErrorMode (SEM_FAILCRITICALERRORS);
> >     -
> >     -  /* Invoke the NT CRT startup routine now that our housecleaning
> >     -     is finished.  */
> >     -#ifdef HAVE_NTGUI
> >     -  /* determine WinMain args like crt0.c does */
> >     -  hinst = GetModuleHandle (NULL);
> >     -  lpCmdLine = GetCommandLine ();
> >     -  nCmdShow = SW_SHOWDEFAULT;
> >     -#endif
> >        mainCRTStartup ();
> >      }
> > 
> > What do you know about lpCmdLine and nCmdShow, and "what crt0.c does"
> > with them, to be sure they can be removed?
> 
> I removed dead code. Those variables are never used; the C runtime (to
> which we dynamically link anyway) handles this initialization
> internally.

I'm not sure.  To me, it looks like we are _replacing_ the _start
function from the C runtime, and therefore whoever wrote this code
wanted to do things like the C runtime does.  I see similar code in
crt0.c from the Windows Platform SDK.  If you know why this is dead
code, please tell the details.

> (We appear to have a separate bug with respect to
> nCmdShow: create a shortcut to runemacs.exe and set it to start
> minimized or start maximized. Emacs starts with a normal window.)

The equivalent code in crt0.c indeed looks at dwFlags member of
STARTUPINFO.  So I guess this is evidence that this code does matter,
right?
 
> > And this hunk breaks the MS-DOS build:
> 
> *sigh* The MS-DOS build breaks when the wind blows the wrong way.

That's an exaggeration.  There's no evidence for that.

> Does the build work inside DOSBox? I'll have to start testing the
> build in that environment before pushing.

There's no need.  The DOS build can remain broken on the trunk for
prolonged periods, because no one tracks that.  I usually test the
build at strategic moments, and fix whatever needs fixing.  For this
pretest, I already did that on the branch, and I'd like to keep it
functional if possible.

In general, any introduction of a new variable in src/Makefile.in that
gets replaced by the configure script should be edited by
msdos/sed1v2.inp, usually to an empty value.  But if the configury
stuff doesn't change during a pretest, no changes are needed in
msdos/* files.  Anyway, when in doubt, just ask me, I can test if
needed.

Previous Next

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