Running expext with WIN2000
Van
Thanks.
David Gravereaux
>Has anyone tried to install and run the NT version of Expect on WIN2000?
>Thanks.
It works last time I checked. It's stuck with a custom core v8.0.5, doesn't
load into a newer core, doesn't support Stubs, not unicode aware, and some
people have reported strange bugs in the I/O handling. It hasn't seen an update
since 1999. Even the one on the sourceforge site that I did is missing a full
featured [spawn] command.
Personally, I wouldn't use either in a product. Good for a proof-of-concept,
though.
It's sad that group effort development isn't a valid business model in our
capitalist society. Those lucky Linux folks have a consortium.
--
David Gravereaux <davy...@pobox.com>
$ make war
make: *** No rule to make target `war'. Stop. Try `love' instead.
BlueFox
"David Gravereaux" <davy...@pobox.com> wrote in message
news:r63vlvghdqe39dve3...@4ax.com...
> vdu...@snowshore.com (Van) wrote:
>
> >Has anyone tried to install and run the NT version of Expect on WIN2000?
> >Thanks.
>
> It works last time I checked. It's stuck with a custom core v8.0.5,
doesn't
> load into a newer core, doesn't support Stubs, not unicode aware, and some
> people have reported strange bugs in the I/O handling. It hasn't seen an
update
> since 1999. Even the one on the sourceforge site that I did is missing a
full
> featured [spawn] command.
>
> Personally, I wouldn't use either in a product. Good for a
proof-of-concept,
> though.
>
> It's sad that group effort development isn't a valid business model in our
> capitalist society. Those lucky Linux folks have a consortium.
> --
Not lucky, just smart. :)
David Gravereaux
>> It's sad that group effort development isn't a valid business model in our
>> capitalist society. Those lucky Linux folks have a consortium.
>> --
>
>Not lucky, just smart. :)
Ouch, I'm jealous. We had one once. It fizzled.
Van
>
> >Has anyone tried to install and run the NT version of Expect on WIN2000?
> >Thanks.
>
> It works last time I checked. It's stuck with a custom core v8.0.5, doesn't
> load into a newer core, doesn't support Stubs, not unicode aware, and some
> people have reported strange bugs in the I/O handling. It hasn't seen an update
> since 1999. Even the one on the sourceforge site that I did is missing a full
> featured [spawn] command.
>
> Personally, I wouldn't use either in a product. Good for a proof-of-concept,
> though.
>
> It's sad that group effort development isn't a valid business model in our
> capitalist society. Those lucky Linux folks have a consortium.
Thanks for the feedback. 'spawn' is actually the one command I DO need.
Do you know of any limitations that expect has running on NT?
David Gravereaux
Sure... Even though Gordon distributes his source, it's barely readable.
That's the biggest bug of all. So when you bump into those strange I/O bugs,
you're lost in overly complicated source that expresses little in design
patterns.
And when you do jump into his source and have the big epiphany, you'll see
slavedrv.exe isn't even needed. Debug events cross process boundaries. And
crossing that is also crossing console boundaries. So therefore the whole
debugger mechanism should get moved into the expect extension with the results
of the debugger becoming the end point for a channel driver in place of the
binary protocol over a namedpipe (which doesn't work on Win9x, btw). By having
the debugger in the extension, would allow for [interact] and would look like
this in one of the breakpoints:
void
ConsoleDebugger::OnSetConsoleCursorPosition(Process *proc,
ThreadInfo *threadInfo, Breakpoint *brkpt, PDWORD returnValue,
DWORD direction)
{
static CHAR buf[50];
DWORD count;
if (*returnValue == FALSE) {
return;
}
CursorPosition = *((PCOORD) &threadInfo->args[1]);
/* convert to VT100 */
count = wsprintf(buf, "\033[%d;%dH", CursorPosition.Y+1,
CursorPosition.X+1);
WriteMaster(buf, count);
-> if (interacting) {
SetConsoleCursorPosition(interactingConsole, CursorPosition);
} ----^
}
That was an easy copy.. no binary protocol from the debugger in slavedrv.exe
over namedpipes into expect to get to that decision.
If you're aim is to put Gordon's Expect-NT into a product, set aside about a one
man/year for fixing it, IMO. Or get on Jeff Hobbs <je...@activestate.com> 's
radar list. He may be able to assist you in making that effort a whole lot
less.
David Gravereaux
>Do you know of any limitations that expect has running on NT?
If the question was general one, as in what are the limits of the operating
system and how would that impact the features set of a port to Win32?
To my knowledge, only the ability to catch output from a DOS-16 application is
hampered by the OS. Something to do with how the VDM (virtual dos machine)
switches to kernel mode and the debugger technique of turning Console API into a
VT100 stream is unavailable from the VDM.
David Gravereaux
>only the ability to catch output from a DOS-16 application is
>hampered by the OS.
Not like DOS is an important part of today's computing environments ;)
Would be nice, though, if the VDM is friendlier. There's access into part of
the VDM, but the place where the translation to Win32 console calls are made...
at least, not from user mode.
Helmut Giese
<davy...@pobox.com> wrote:
>vdu...@snowshore.com (Van) wrote:
>
>>Do you know of any limitations that expect has running on NT?
>
>If the question was general one, as in what are the limits of the operating
>system and how would that impact the features set of a port to Win32?
>
>To my knowledge, only the ability to catch output from a DOS-16 application is
>hampered by the OS.
Hm, how does the scenario for Expect look if one were to completely
drop support for 16-bit-DOS apps?
Taking this thought a bit further: Considering only the latest version
of Windows (XP) - what is the current status of Expect?
- Could be used to control 32-bit (console) apps ?
- Could be made to work with Win 2k ?
- Could be made to work with Win ... ?
Best regards
Helmut Giese
David Gravereaux
>On Thu, 11 Sep 2003 15:11:27 -0700, David Gravereaux
><davy...@pobox.com> wrote:
>
>>vdu...@snowshore.com (Van) wrote:
>>
>>>Do you know of any limitations that expect has running on NT?
>>
>>If the question was general one, as in what are the limits of the operating
>>system and how would that impact the features set of a port to Win32?
>>
>>To my knowledge, only the ability to catch output from a DOS-16 application is
>>hampered by the OS.
>Hm, how does the scenario for Expect look if one were to completely
>drop support for 16-bit-DOS apps?
all good.
>Taking this thought a bit further: Considering only the latest version
>of Windows (XP) - what is the current status of Expect?
XP has a couple new console API functions that should get added to the
breakpoint list. But only newest programs would be using them.
>- Could be used to control 32-bit (console) apps ?
Yup. That's its purpose.
>- Could be made to work with Win 2k ?
>- Could be made to work with Win ... ?
After dropping the namedpipes IPC that Gordon used, it works on Win9x now.
Helmut Giese
<davy...@pobox.com> wrote:
>hgi...@ratiosoft.com (Helmut Giese) wrote:
>
>>On Thu, 11 Sep 2003 15:11:27 -0700, David Gravereaux
>><davy...@pobox.com> wrote:
>>
>>>vdu...@snowshore.com (Van) wrote:
>>>
>>>>Do you know of any limitations that expect has running on NT?
>>>
>>>If the question was general one, as in what are the limits of the operating
>>>system and how would that impact the features set of a port to Win32?
>>>
>>>To my knowledge, only the ability to catch output from a DOS-16 application is
>>>hampered by the OS.
>>Hm, how does the scenario for Expect look if one were to completely
>>drop support for 16-bit-DOS apps?
>
>all good.
>
>>Taking this thought a bit further: Considering only the latest version
>>of Windows (XP) - what is the current status of Expect?
>
>XP has a couple new console API functions that should get added to the
>breakpoint list. But only newest programs would be using them.
>
>>- Could be used to control 32-bit (console) apps ?
>
>Yup. That's its purpose.
>
>>- Could be made to work with Win 2k ?
>>- Could be made to work with Win ... ?
>
>After dropping the namedpipes IPC that Gordon used, it works on Win9x now.
Hi David,
to me this sounds good, or is there something I don't see?
As a rough estimate, how much work would you consider necessary to get
an XP-only-no-16-bit-app-support Expect running?
Have a nice weekend
Helmut Giese
David Gravereaux
>Hi David,
>to me this sounds good, or is there something I don't see?
>As a rough estimate, how much work would you consider necessary to get
>an XP-only-no-16-bit-app-support Expect running?
I really do want to answer this question, but due to certain circumstances, I
shouldn't. Xp only? No.... 95,98,ME,NT,2K,XP. The whole lot.
Helmut Giese
<davy...@pobox.com> wrote:
>hgi...@ratiosoft.com (Helmut Giese) wrote:
>
>>Hi David,
>>to me this sounds good, or is there something I don't see?
>>As a rough estimate, how much work would you consider necessary to get
>>an XP-only-no-16-bit-app-support Expect running?
>
>I really do want to answer this question, but due to certain circumstances, I
>shouldn't. Xp only? No.... 95,98,ME,NT,2K,XP. The whole lot.
Ok, if the circumstances are such ...
Jeff Hobbs
>>>Taking this thought a bit further: Considering only the latest version
>>>of Windows (XP) - what is the current status of Expect?
> As a rough estimate, how much work would you consider necessary to get
> an XP-only-no-16-bit-app-support Expect running?
ActiveState is currently working on a modern, up-to-date port of Expect
for Windows. We are employing Dave in this effort as well. I can't say
when it will be available, but the target is the latest Expect (5.29)
working with Tcl 8.4+ on Windows NT-based systems (NOT 9x). I should
note that it won't be available as open source initially.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
David Gravereaux
>Helmut Giese wrote:
>>>>Taking this thought a bit further: Considering only the latest version
>>>>of Windows (XP) - what is the current status of Expect?
> ...
>> As a rough estimate, how much work would you consider necessary to get
>> an XP-only-no-16-bit-app-support Expect running?
>
>ActiveState is currently working on a modern, up-to-date port of Expect
>for Windows. We are employing Dave in this effort as well. I can't say
>when it will be available, but the target is the latest Expect (5.29)
>working with Tcl 8.4+ on Windows NT-based systems (NOT 9x). I should
>note that it won't be available as open source initially.
I can say I solved the read/write sub process memory issue on Win9x. But I
won't be testing it there, though. But should work.. If it is broken on Win9x,
it should be minor work to resolve.
marsd
> Helmut Giese wrote:
> >>>Taking this thought a bit further: Considering only the latest version
> >>>of Windows (XP) - what is the current status of Expect?
> ...
> > As a rough estimate, how much work would you consider necessary to get
> > an XP-only-no-16-bit-app-support Expect running?
>
> ActiveState is currently working on a modern, up-to-date port of Expect
> for Windows. We are employing Dave in this effort as well. I can't say
> when it will be available, but the target is the latest Expect (5.29)
> working with Tcl 8.4+ on Windows NT-based systems (NOT 9x). I should
> note that it won't be available as open source initially.
That's very cool news.
Now the burning question:
Will there be a full featured interact?
Jeff Hobbs
> Jeff Hobbs <je...@activestate.com> wrote in message news:<3F63EE72...@activestate.com>...
>
>>Helmut Giese wrote:
>>
>>>>>Taking this thought a bit further: Considering only the latest version
>>>>>of Windows (XP) - what is the current status of Expect?
>>
>> ...
>>
>>>As a rough estimate, how much work would you consider necessary to get
>>>an XP-only-no-16-bit-app-support Expect running?
>>
>>ActiveState is currently working on a modern, up-to-date port of Expect
>>for Windows. We are employing Dave in this effort as well. I can't say
>>when it will be available, but the target is the latest Expect (5.29)
>>working with Tcl 8.4+ on Windows NT-based systems (NOT 9x). I should
>>note that it won't be available as open source initially.
> Will there be a full featured interact?
Not at this time. It is technically possible, but it would take
someone interested enough to contract the work. Right now we are
looking at creating something equivalent to Gordon Chaffee's old
port, but rewritten with modern Tcl constructs (channels, objs,
etc).