bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[macross84]

Anyone knows why the majority of windowed applications launched from an
emacs shell doesn't show until the shell buffer is killed? [MSWindows]

Try M-x shell <RET> notepad

Doesn't show anything on the computers I've tried until C-x k



--------------------------------------------------------------------------------------------
Busca, compara... pero busca con OZÚ
Descúbrelo en http://buscar.ozu.es
--------------------------------------------------------------------------------------------
Correo enviado desde http://www.ozu.es

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Jason Rumney]

macross84@ozu.es wrote:
> Anyone knows why the majority of windowed applications launched from an
> emacs shell doesn't show until the shell buffer is killed? [MSWindows]
>
> Try M-x shell <RET> notepad
>
> Doesn't show anything on the computers I've tried until C-x k
>   

Can you reproduce this starting from "emacs -Q" at the command line?

What version of Emacs is it? Please paste the text from M-x 
report-emacs-bug.

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Lennart Borgman]

On Thu, Jan 8, 2009 at 1:35 PM, Jason Rumney <jasonr@gnu.org> wrote:
> macross84@ozu.es wrote:
>>
>> Anyone knows why the majority of windowed applications launched from an
>> emacs shell doesn't show until the shell buffer is killed? [MSWindows]
>>
>> Try M-x shell <RET> notepad
>>
>> Doesn't show anything on the computers I've tried until C-x k
>>
>
> Can you reproduce this starting from "emacs -Q" at the command line?
>
> What version of Emacs is it? Please paste the text from M-x
> report-emacs-bug.

I have no problem reproducing this with an unpatched Emacs from 2009-01-04.

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Jason Rumney]

macross84@ozu.es wrote:
> Anyone knows why the majority of windowed applications launched from an
> emacs shell doesn't show until the shell buffer is killed? [MSWindows]
>
> Try M-x shell <RET> notepad
>
> Doesn't show anything on the computers I've tried until C-x k
>   

Strange, I couldn't reproduce this when I first tried, but now I can 
reproduce it every time on Emacs 21.3, 22.3 and CVS trunk.

Perhaps it was a recent OS patch that caused this behaviour. It does not 
even seem to be linked to the fact that the shell window is hidden, as 
changing w32-start-process-show-window does not improve the problem.

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Juanma Barranquero]

On Sun, Jan 18, 2009 at 14:07, Jason Rumney <jasonr@gnu.org> wrote:

> Strange, I couldn't reproduce this when I first tried, but now I can
> reproduce it every time on Emacs 21.3, 22.3 and CVS trunk.

Is the problem still reproducible?

  M-x shell <RET>
  notepad <RET>

works as expected for me.

    Juanma

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Jan 18, 2009 at 14:07, Jason Rumney <jasonr@gnu.org> wrote:
>
>> Strange, I couldn't reproduce this when I first tried, but now I can
>> reproduce it every time on Emacs 21.3, 22.3 and CVS trunk.
>
> Is the problem still reproducible?
>
>   M-x shell <RET>
>   notepad <RET>
>
> works as expected for me.

It works as expected for me now on Vista with CVS trunk. But I don't think
this was the configuration I reproduced it on originally.

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Juanma Barranquero]

On Fri, Jul 8, 2011 at 17:29, Jason Rumney <jasonr@gnu.org> wrote:

> It works as expected for me now on Vista with CVS trunk. But I don't think
> this was the configuration I reproduced it on originally.

Well, IMHO it does not make much sense to keep the bug open if we
cannot reproduce it. We can reopen it if it happens again.

    Juanma

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jul 8, 2011 at 17:29, Jason Rumney <jasonr@gnu.org> wrote:
>
>> It works as expected for me now on Vista with CVS trunk. But I don't think
>> this was the configuration I reproduced it on originally.
>
> Well, IMHO it does not make much sense to keep the bug open if we
> cannot reproduce it. We can reopen it if it happens again.

Please leave it open until we've had a chance to try on systems where it
was known to fail.

bug#1819: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed? [MSWindows]

[Juanma Barranquero]

On Fri, Jul 8, 2011 at 17:57, Jason Rumney <jasonr@gnu.org> wrote:

> Please leave it open until we've had a chance to try on systems where it
> was known to fail.

OK, though I don't see in the thread any specific system where it was
known to fail. Not a lot of detail in the reports.

    Juanma

bug#1819: I can reproduce this on that pre-release Emacs 24 build on WIndows Server 2003 100%

[darkdescendant]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

I haven't tried the 4 CR trick outlined in the original posting but this is  
an issue that I have to deal with all the time. It stops me from doing all  
my work in Emacs.

This also reproduces on the latest released patched EmacsW32 distribution  
running Emacs 23.2/

[-- Attachment #2: Type: text/html, Size: 277 bytes --]

bug#1819: I can reproduce this on that pre-release Emacs 24 build on WIndows Server 2003 100%

[Eli Zaretskii]

> Date: Sun, 09 Oct 2011 03:35:54 +0000
> From: darkdescendant@gmail.com
> 
> I haven't tried the 4 CR trick outlined in the original posting but this is  
> an issue that I have to deal with all the time. It stops me from doing all  
> my work in Emacs.

Does it help to invoke GUI programs via "start", like this:

  d:\foo> start notepad

> This also reproduces on the latest released patched EmacsW32 distribution  
> running Emacs 23.2/

I can see it in the current development version as well.

I played with this, and here are my observations.  Hopefully, someone
who knows more than I do about the startup process of a GUI
application could make some sense out of it.

 . The behavior is not entirely repeatable.  Sometimes I need 3 RETs,
   sometimes 4, and sometimes just 1.

 . It looks like the program that is invoked is in some limbo state
   inside early stages of its startup code, until you hit enough RETs.
   Process Explorer shows no threads for such a program.  PsList does
   show one thread, but it is waiting for something.  Here's an
   example with notepad:

    Tid Pri    Cswtch            State     User Time  Kernel Time  Elapsed Time
   2872   8        14   Wait:Executive   0:00:00.000  0:00:00.000  0:00:05.354

 . Each time I hit RET, notepad seems to do a few more things in its
   startup.  Process Explorer shows more and more handles being open.
   I show below the list of handles after each RET.  Note that the
   desktop (WinSta0) is only opened after one RET.  Another noteworthy
   fact is that when started from shell-mode, GUI applications have 3
   pipes open -- those are the 3 standard handles they inherited from
   Emacs via cmd.exe.

 . I also tried with runemacs.exe, and I see the same pattern: it
   takes several RETs for it to make through its works, at which point
   it spawns emacs.exe and exits.

 . Invoking GUI programs through the "start" command works as
   expected: the program opens its window immediately.

   Here's the list of handles open by notepad just after the invocation:

    Type	Name
    Directory	\Windows
    Directory	\KnownDlls
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000002
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	D:\usr\eli\bzr
    File	C:\WINDOWS\AppPatch\sysmain.sdb
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    KeyedEvent	\KernelObjects\CritSecOutOfMemoryEvent
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Thread	emacs.exe(740): 2096

  This is after one RET:

    Type	Name
    Directory	\BaseNamedObjects
    Directory	\Windows
    Directory	\KnownDlls
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000002
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	D:\usr\eli\bzr
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    Key		HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
    Key		HKLM
    KeyedEvent	\KernelObjects\CritSecOutOfMemoryEvent
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Thread	emacs.exe(740): 2096
    WindowStation	\Windows\WindowStations\WinSta0
    WindowStation	\Windows\WindowStations\WinSta0

  After 2 RETs:

    Type	Name
    Directory	\BaseNamedObjects
    Directory	\Windows
    Directory	\KnownDlls
    Event	\BaseNamedObjects\userenv:  User Profile setup event
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000002
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\KsecDD
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    File	D:\usr\eli\bzr
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    Key		HKCU
    Key		HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
    Key		HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
    Key		HKLM
    KeyedEvent	\KernelObjects\CritSecOutOfMemoryEvent
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Semaphore	\BaseNamedObjects\shell.{A48F1A32-A340-11D1-BC6B-00A0C90312E1}
    Thread	emacs.exe(740): 2096
    WindowStation	\Windows\WindowStations\WinSta0
    WindowStation	\Windows\WindowStations\WinSta0

  After 3 RETs:

    Type	Name
    Directory	\BaseNamedObjects
    Directory	\Windows
    Directory	\KnownDlls
    Event		\BaseNamedObjects\userenv:  User Profile setup event
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000002
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\NamedPipe\Win32Pipes.000002e4.00000001
    File	\Device\KsecDD
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    File	D:\usr\eli\bzr
    File	C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
    Key		HKLM\SYSTEM\ControlSet001\Control\Nls\Language Groups
    Key		HKLM\SYSTEM\ControlSet001\Control\Nls\Locale\Alternate Sorts
    Key		HKLM\SYSTEM\ControlSet001\Control\Nls\Locale
    Key		HKCU
    Key		HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
    Key		HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
    Key		HKLM
    KeyedEvent	\KernelObjects\CritSecOutOfMemoryEvent
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\ShimCacheMutex
    Mutant	\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-135337107-1212574998-751859383-11823MUTEX.DefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\CTF.TMD.MutexDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\CTF.Layouts.MutexDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\CTF.Asm.MutexDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\CTF.Compart.MutexDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\CTF.LBES.MutexDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Mutant	\BaseNamedObjects\DBWinMutex
    Section	\BaseNamedObjects\ShimSharedMemory
    Section	\BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-135337107-1212574998-751859383-11823SFM.DefaultS-1-5-21-135337107-1212574998-751859383-11823
    Section	\BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-135337107-1212574998-751859383-11823
    Semaphore	\BaseNamedObjects\shell.{A48F1A32-A340-11D1-BC6B-00A0C90312E1}
    Thread	emacs.exe(740): 2096
    WindowStation	\Windows\WindowStations\WinSta0
    WindowStation	\Windows\WindowStations\WinSta0

bug#1819: I can reproduce this on that pre-release Emacs 24 build on WIndows Server 2003 100%

[Joseph Jones]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

*** inline

On Sun, Oct 9, 2011 at 6:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 09 Oct 2011 03:35:54 +0000
> > From: darkdescendant@gmail.com
> >
> > I haven't tried the 4 CR trick outlined in the original posting but this
> is
> > an issue that I have to deal with all the time. It stops me from doing
> all
> > my work in Emacs.
>
> Does it help to invoke GUI programs via "start", like this:
>
>  d:\foo> start notepad
>
>

*** I didn't even think of that. I use that for a service that I am testing
but didn't think to use it for non-service exes. I'll give that a shot when
I am back in office tomorrow.  Thanks for the idea!

[-- Attachment #2: Type: text/html, Size: 1016 bytes --]

bug#1819: I can reproduce this on that pre-release Emacs 24 build on WIndows Server 2003 100%

[Joseph Jones]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

I can confirm that both the start command as well as hitting RET 3-4 times
both work for me. Interesting side note: If the app brings up a dialog that
requires input then displays a main window, both require the 3-4 RETs. In my
case, I am using P4V.

1) In Emacs cmd shell type: p4v
2) Hit RET 3 times to display the connection dialog.
3) Enter connection information and hit OK

Note that nothing happens...

4) Hit RET 3 more times in the cmd shell
5) P4V main UI shows up.



On Sun, Oct 9, 2011 at 8:40 AM, Joseph Jones <darkdescendant@gmail.com>wrote:

> *** inline
>
> On Sun, Oct 9, 2011 at 6:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Date: Sun, 09 Oct 2011 03:35:54 +0000
>> > From: darkdescendant@gmail.com
>> >
>> > I haven't tried the 4 CR trick outlined in the original posting but this
>> is
>> > an issue that I have to deal with all the time. It stops me from doing
>> all
>> > my work in Emacs.
>>
>> Does it help to invoke GUI programs via "start", like this:
>>
>>  d:\foo> start notepad
>>
>>
>
> *** I didn't even think of that. I use that for a service that I am testing
> but didn't think to use it for non-service exes. I'll give that a shot when
> I am back in office tomorrow.  Thanks for the idea!
>

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

bug#1819: control message for bug #1819

[Richard Copley]

tags 1819 unreproducible

Tested not observable on Windows 7. There have been enough years since
the original report for someone to have tested on the (unspecified,
presumably now obsolete) system(s) where the bug was reported.

bug#1819: control message for bug #1819

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

Richard Copley <rcopley@gmail.com> writes:

>> Should we close this bug report then?

> In my opinion, yes it should be closed. I'm not sure how bold I should be
> with control messages, as I have no particular standing in the community. I
> sometimes close and merge bugs that I reported. This one's not mine so I
> just tagged it.

I'm closing it then.  If needed, someone can reopen.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]