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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1819 in the body.
You can then email your comments to 1819 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: macross84 <at> ozu.es
To: bug-gnu-emacs <at> gnu.org
Subject: Anyone knows why the majority of windowed proggies launched from 
     an emacs shell doesn't show until the shell buffer is killed? 
     [MSWindows]
Date: Wed, 7 Jan 2009 20:56:03 +0100 (CET)

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

Message #12 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 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]
Date: Thu, 08 Jan 2009 20:35:57 +0800

macross84 <at> 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.

Message #22 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Lennart Borgman" <lennart.borgman <at> gmail.com>
To: "Jason Rumney" <jasonr <at> gnu.org>, 1819 <at> debbugs.gnu.org
Cc: macross84 <at> ozu.es, bug-gnu-emacs <at> gnu.org
Subject: Re: 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]
Date: Thu, 8 Jan 2009 15:01:14 +0100

On Thu, Jan 8, 2009 at 1:35 PM, Jason Rumney <jasonr <at> gnu.org> wrote:
> macross84 <at> 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.

Message #32 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 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]
Date: Sun, 18 Jan 2009 21:07:51 +0800

macross84 <at> 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.

Message #42 received at 1819 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: dhruva <dhruva <at> ymail.com>
To: 1819 <at> debbugs.gnu.org
Subject: Re: Anyone knows why the majority of windowed proggies launched from an emacs shell doesn't show until the shell buffer is killed?       [MSWindows]
Date: Sun, 18 Oct 2009 20:03:38 -0700 (PDT)

Hello,
 I did some further testing. Not conclusive though but enough to give good leads.

shell>notepad
You do not see the notepad window showing up (as reported)

shell>[return]
shell>[return]
shell>[return]
shell>[return]

And you see the notepad window coming up after exactly 4 CR presses! Somewhere, it is expecting CRLF combinations I guess.. some comint?

For records, this works as expected:
(comint-exec (current-buffer) "notepad" "notepad.exe" nil nil)

-dhruva


      Yahoo! India has a new look. Take a sneak peek http://in.yahoo.com/trynew

Message #45 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Subject: Re: 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]
Date: Fri, 8 Jul 2011 00:22:58 +0200

On Sun, Jan 18, 2009 at 14:07, Jason Rumney <jasonr <at> 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

Message #48 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Subject: Re: 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]
Date: Fri, 08 Jul 2011 23:29:56 +0800

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sun, Jan 18, 2009 at 14:07, Jason Rumney <jasonr <at> 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.

Message #51 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Subject: Re: 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]
Date: Fri, 8 Jul 2011 17:49:59 +0200

On Fri, Jul 8, 2011 at 17:29, Jason Rumney <jasonr <at> 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

Message #54 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Subject: Re: 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]
Date: Fri, 08 Jul 2011 23:57:51 +0800

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Fri, Jul 8, 2011 at 17:29, Jason Rumney <jasonr <at> 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.

Message #57 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: macross84 <at> ozu.es, 1819 <at> debbugs.gnu.org
Subject: Re: 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]
Date: Fri, 8 Jul 2011 18:44:50 +0200

On Fri, Jul 8, 2011 at 17:57, Jason Rumney <jasonr <at> 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

Message #60 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: darkdescendant <at> gmail.com
To: 1819 <at> debbugs.gnu.org
Subject: I can reproduce this on that pre-release Emacs 24 build on WIndows
	Server 2003 100%
Date: Sun, 09 Oct 2011 03:35:54 +0000

[Message part 1 (text/plain, inline)]

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/

[Message part 2 (text/html, inline)]

Message #63 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: darkdescendant <at> gmail.com
Cc: 1819 <at> debbugs.gnu.org
Subject: Re: bug#1819: I can reproduce this on that pre-release Emacs 24 build
	on WIndows Server 2003 100%
Date: Sun, 09 Oct 2011 09:01:21 -0400

> Date: Sun, 09 Oct 2011 03:35:54 +0000
> From: darkdescendant <at> 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

Message #66 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Jones <darkdescendant <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1819 <at> debbugs.gnu.org
Subject: Re: bug#1819: I can reproduce this on that pre-release Emacs 24 build
	on WIndows Server 2003 100%
Date: Sun, 9 Oct 2011 08:40:40 -0700

[Message part 1 (text/plain, inline)]

*** inline

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

> > Date: Sun, 09 Oct 2011 03:35:54 +0000
> > From: darkdescendant <at> 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!

[Message part 2 (text/html, inline)]

Message #69 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Jones <darkdescendant <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1819 <at> debbugs.gnu.org
Subject: Re: bug#1819: I can reproduce this on that pre-release Emacs 24 build
	on WIndows Server 2003 100%
Date: Mon, 10 Oct 2011 09:05:19 -0700

[Message part 1 (text/plain, inline)]

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 <at> gmail.com>wrote:

> *** inline
>
> On Sun, Oct 9, 2011 at 6:01 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > Date: Sun, 09 Oct 2011 03:35:54 +0000
>> > From: darkdescendant <at> 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!
>

[Message part 2 (text/html, inline)]

Message #72 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: 1819 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: control message for bug #1819
Date: Wed, 13 Jan 2016 16:03:41 +0000

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.

Message #77 received at 1819 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 1819-done <at> debbugs.gnu.org, 1819 <at> debbugs.gnu.org
Subject: Re: bug#1819: control message for bug #1819
Date: Thu, 28 Jul 2016 11:09:04 +0200

[Message part 1 (text/plain, inline)]

Richard Copley <rcopley <at> 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

[signature.asc (application/pgp-signature, inline)]

Previous Next

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