bug#8268: Windows Emacs Console persists while running running emacs.exe.

This seems to be related to bug #1849, but perhaps never properly fixed.

Anyways, when opening emacs from Emacs.exe, which is difficult to not do in
Windows 7 with pinning to the task bar, Emacs will open with an unneeded
console window that cannot be destroyed.

This seems likely due to the fact that Emacs is spawned as a console
application when run in this manner.  However, I think there is a simple fix
that doesn't cause problems when the program is run as a console app.

By calling the FreeConsole win32 function when Emacs initializes it's GUI
this should kill any os spawned console windows, had they not been opened
separately.

See:
http://msdn.microsoft.com/en-us/library/ms683...

I've used this function to great effect in other applications, and am
confident it'd work. I'd have fixed it and created a patch myself, but I've
spent the last few hours trying to get Emacs to build on this weird setup I
have here.

Indy

> Anyways, when opening emacs from Emacs.exe

Why do you run emacs.exe, and not runemacs.exe?> which is difficult to not do in
> Windows 7 with pinning to the task barWhat do you mean? Do you have any trouble pinning runemacs.exe to the
Start menu or taskbar?

    Juanma

> Why do you run emacs.exe, and not runemacs.exe?

> What do you mean? Do you have any trouble pinning runemacs.exe to the
> Start menu or taskbar?When I pin runemacs.exe to the taskbar and run it, it loads emacs
which creates another icon on my taskbar, It seems impossible to
currently have the same pin'd icon load up and run emacs under the
same icon without creating the console window.

Ideally, I should be able to have one pinned icon on the taskbar, and
when clicking it it should load emacs without the console window. This
seems impossible.

Indy

On 17/03/2011 13:19, Nicholas "Indy" Ray wrote:

> When I pin runemacs.exe to the taskbar and run it, it loads emacs
> which creates another icon on my taskbar, It seems impossible to
> currently have the same pin'd icon load up and run emacs under the
> same icon without creating the console window.
>
> Ideally, I should be able to have one pinned icon on the taskbar, and
> when clicking it it should load emacs without the console window. This
> seems impossible.
>What version of Emacs are you using?  runemacs, emacs and emacsclient 
should all be treated as the same program by Windows 7 taskbar since 
23.2 if the MSDN documentation is correct.  Perhaps you can help us to 
debug this if you are already using a more recent version.

Jason Rumney skrev 2011-03-17 07:31:
> On 17/03/2011 13:19, Nicholas "Indy" Ray wrote:
>
>> When I pin runemacs.exe to the taskbar and run it, it loads emacs
>> which creates another icon on my taskbar, It seems impossible to
>> currently have the same pin'd icon load up and run emacs under the
>> same icon without creating the console window.
>>
>> Ideally, I should be able to have one pinned icon on the taskbar, and
>> when clicking it it should load emacs without the console window. This
>> seems impossible.
>
> What version of Emacs are you using? runemacs, emacs and emacsclient
> should all be treated as the same program by Windows 7 taskbar since
> 23.2 if the MSDN documentation is correct. Perhaps you can help us to
> debug this if you are already using a more recent version.
>
>Maybe this is what the original poster meant, it is what happens for me 
in Windows 7:

1. Start runemacs.exe.
2. Pin the emacs icon to the taskbar.
3. Exit emacs.
4. Start emacs by clicking on the newly pinned icon in the taskbar.

Result: You get a new emacs window but also a console window.
This is on 23.2 BTW.  Is there reason to think 23.3 or trunk behaves 
differently?

	Jan D.

On Thu, Mar 17, 2011 at 08:19, Jan D.  wrote:

> 1. Start runemacs.exe.
> 2. Pin the emacs icon to the taskbar.IIUC, you're not pinning runemacs.exe, but emacs.exe (which runemacs started).> 3. Exit emacs.
> 4. Start emacs by clicking on the newly pinned icon in the taskbar.
>
> Result: You get a new emacs window but also a console window.
> This is on 23.2 BTW.  Is there reason to think 23.3 or trunk behaves
> differently?Once you've pinned emacs.exe, edit the properties (you can use
shift-right-click) and change the executable path to point to
C:/this/is/your/path/to/runemacs.exe instead of
C:/this/is/your/path/to/emacs.exe

Hope this helps,

    Juanma

On Thu, Mar 17, 2011 at 07:31, Jason Rumney  wrote:

> What version of Emacs are you using?  runemacs, emacs and emacsclient should
> all be treated as the same program by Windows 7 taskbar since 23.2 if the
> MSDN documentation is correct.By the way, for

  CompanyName.ProductName.SubProduct.VersionInformation

we're just using CompanyName.ProductName ("GNU.Emacs").

Do we want Windows 7 to group executables from different versions, or
not? I can imagine having shortcuts to 23.3 and trunk and wanting to
keep them separate.

    Juanma

> Date: Wed, 16 Mar 2011 20:42:56 -0700
> From: "Nicholas \"Indy\" Ray" 
> Cc: 
> 
> This seems to be related to bug #1849, but perhaps never properly fixed.
> 
> Anyways, when opening emacs from Emacs.exe, which is difficult to not do in
> Windows 7 with pinning to the task bar, Emacs will open with an unneeded
> console window that cannot be destroyed.We have runemacs.exe for this very purpose.  Why don't you use it?
Doesn't it work on Windows 7?

Again, runemacs.exe doesn't interact properly with the task bar.
runemacs.exe and emacs.exe act as separate icons on the task bar. If
runemacs.exe is pinned, then while emacs.exe is running it's you get
two taskbar icons dedicated to emacs.

Thanks,
IndyOn Wed, Mar 16, 2011 at 10:39 PM, Eli Zaretskii  wrote:
>> Date: Wed, 16 Mar 2011 20:42:56 -0700
>> From: "Nicholas \"Indy\" Ray" 
>> Cc:
>>
>> This seems to be related to bug #1849, but perhaps never properly fixed.
>>
>> Anyways, when opening emacs from Emacs.exe, which is difficult to not do in
>> Windows 7 with pinning to the task bar, Emacs will open with an unneeded
>> console window that cannot be destroyed.
>
> We have runemacs.exe for this very purpose.  Why don't you use it?
> Doesn't it work on Windows 7?
>

> Again, runemacs.exe doesn't interact properly with the task bar.
> runemacs.exe and emacs.exe act as separate icons on the task bar. If
> runemacs.exe is pinned, then while emacs.exe is running it's you get
> two taskbar icons dedicated to emacs.Have you seen my later message? Are you sure you're pinning
runemacs.exe, and not emacs.exe? It's impossible to pin runemacs.exe
by running it, because it almost immediately starts emacs.exe and
exits.

    Juanma

Unless your fix isn't in Emacs 23.3 then yes. I drag runemacs.exe from
finder into the task bar.

IndyOn Thu, Mar 17, 2011 at 5:48 AM, Juanma Barranquero  wrote:
>> Again, runemacs.exe doesn't interact properly with the task bar.
>> runemacs.exe and emacs.exe act as separate icons on the task bar. If
>> runemacs.exe is pinned, then while emacs.exe is running it's you get
>> two taskbar icons dedicated to emacs.
>
> Have you seen my later message? Are you sure you're pinning
> runemacs.exe, and not emacs.exe? It's impossible to pin runemacs.exe
> by running it, because it almost immediately starts emacs.exe and
> exits.
>
>     Juanma
>

On Thu, Mar 17, 2011 at 17:29, Nicholas "Indy" Ray  wrote:

> Unless your fix isn't in Emacs 23.3 then yes. I drag runemacs.exe from
> finder into the task bar.I've tried dragging runemacs.exe to the taskbar (both my own compiled
23.3 and the one in emacs-23.3-bin-i386.zip) and both behave as
expected: running Emacs from them does not show additional icons, nor
console windows.

    Juanma

Hmm, thanks for that info. It seems then I've run into some form of
bug rather then what I originally thought.

Any thoughts on the matter? the runemacs.exe if from my emacs 32.3
folder recentlly extracted from emacs-23.3-bin-i386.zip and running
M-x version on the resultant emacs window gives me:

GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600) of 2011-03-10 on 3249CTO

Thanks,
IndyOn Thu, Mar 17, 2011 at 11:19 AM, Juanma Barranquero  wrote:
> On Thu, Mar 17, 2011 at 17:29, Nicholas "Indy" Ray  wrote:
>
>> Unless your fix isn't in Emacs 23.3 then yes. I drag runemacs.exe from
>> finder into the task bar.
>
> I've tried dragging runemacs.exe to the taskbar (both my own compiled
> 23.3 and the one in emacs-23.3-bin-i386.zip) and both behave as
> expected: running Emacs from them does not show additional icons, nor
> console windows.
>
>     Juanma
>

> Any thoughts on the matter? the runemacs.exe if from my emacs 32.3
> folder recentlly extracted from emacs-23.3-bin-i386.zip and running
> M-x version on the resultant emacs window gives me:
>
> GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600) of 2011-03-10 on 3249CTOI've tested that very same version.

Hmm. Perhaps some of the calls to
SetCurrentProcessExplicitAppUserModelID are failing? Could you try to
debug that?

    Juanma

I could. I'm probally going to have to actually build a version of
emacs locally to do that. Is it possible to build it in MSVC 2008, or
should I probally get MinGW working? the version installed with git
seems unsuitable to do the job.

IndyOn Thu, Mar 17, 2011 at 12:27 PM, Juanma Barranquero  wrote:
>> Any thoughts on the matter? the runemacs.exe if from my emacs 32.3
>> folder recentlly extracted from emacs-23.3-bin-i386.zip and running
>> M-x version on the resultant emacs window gives me:
>>
>> GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600) of 2011-03-10 on 3249CTO
>
> I've tested that very same version.
>
> Hmm. Perhaps some of the calls to
> SetCurrentProcessExplicitAppUserModelID are failing? Could you try to
> debug that?
>
>     Juanma
>

On Fri, Mar 18, 2011 at 04:53, Nicholas "Indy" Ray  wrote:

> I could. I'm probally going to have to actually build a version of
> emacs locally to do that.Thanks.> Is it possible to build it in MSVC 2008, or
> should I probally get MinGW working?I think there was some work done to make it compile with MSVC 2008,
but certainly you won't have trouble with MinGW, which I recommend.

    Juanma

> Date: Thu, 17 Mar 2011 20:53:19 -0700
> From: "Nicholas \"Indy\" Ray" 
> Cc: Eli Zaretskii , 
> 
> I could. I'm probally going to have to actually build a version of
> emacs locally to do that. Is it possible to build it in MSVC 2008, or
> should I probally get MinGW working?You could even try debugging the pre-compiled binaries if you install
the sources as well.  Assuming the binary you are using is not
stripped, that is.

Failing that, installing MinGW is the recommended way.

> the version installed with git seems unsuitable to do the job.

What "version installed with git"?

Is there a specific way to build in debug mode? I presume GDB is the
proper debugger to be using? I'm uncertain how to load the proper
source to set breakpoints.

IndyOn Fri, Mar 18, 2011 at 1:08 AM, Eli Zaretskii  wrote:
>> Date: Thu, 17 Mar 2011 20:53:19 -0700
>> From: "Nicholas \"Indy\" Ray" 
>> Cc: Eli Zaretskii , 
>>
>> I could. I'm probally going to have to actually build a version of
>> emacs locally to do that. Is it possible to build it in MSVC 2008, or
>> should I probally get MinGW working?
>
> You could even try debugging the pre-compiled binaries if you install
> the sources as well.  Assuming the binary you are using is not
> stripped, that is.
>
> Failing that, installing MinGW is the recommended way.
>
>> the version installed with git seems unsuitable to do the job.
>
> What "version installed with git"?
>

> Date: Wed, 23 Mar 2011 14:50:55 -0700
> From: "Nicholas \"Indy\" Ray" 
> Cc: , 
> 
> Is there a specific way to build in debug mode?Yes, "configure --no-opt --enable-checking".

> I presume GDB is the proper debugger to be using?

Yes, if you compile with MinGW.

> I'm uncertain how to load the proper source to set breakpoints.

Sorry, I don't understand.  Are you asking what are the GDB commands
to set a breakpoint?

On Mar 18, 3:27 am, Juanma Barranquero  wrote:
> > Any thoughts on the matter? the runemacs.exe if from my emacs 32.3
> > folder recentlly extracted from emacs-23.3-bin-i386.zip and running
> > M-x version on the resultant emacs window gives me:
>
> > GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600) of 2011-03-10 on 3249CTO
>
> I've tested that very same version.
>
> Hmm. Perhaps some of the calls to
> SetCurrentProcessExplicitAppUserModelID are failing? Could you try to
> debug that?
>
>     JuanmaI think I've found out the problem.

Double click runemacs.exe in the explorer, pin it to the taskbar, then
right click on the icon, change the target from emacs.exe to
runemacs.exe, click the icon, everything work fine.

Drag runemacs.exe from the explorer to the taskbar, click on it,
another icon will apply to the taskbar.

The shortcut file (location in C:\Users\[User NAME]\AppData\Roaming
\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar) created
by the 2nd way didn't have a System.AppUserModel.ID property.


oCameLo

On Sun, Apr 3, 2011 at 12:46, oCameLo  wrote:

> Double click runemacs.exe in the explorer, pin it to the taskbar, then
> right click on the icon, change the target from emacs.exe to
> runemacs.exe, click the icon, everything work fine.So the shortcut is created from a running instance of emacs.exe.> Drag runemacs.exe from the explorer to the taskbar, click on it,
> another icon will apply to the taskbar.And this one is created from the executable.> The shortcut file (location in C:\Users\[User NAME]\AppData\Roaming
> \Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar) created
> by the 2nd way didn't have a System.AppUserModel.ID property.Sound quite logical, because the executable isn't associated with the
"GNU.Emacs" ID until it runs and sets it itself.

So this should be documented in nt/README.W32, and perhaps addpm.c
should set the System.AppUserModel.ID property in the shortcuts it
creates.

    Juanma