From: dwade@svcdudes.com
Subject: Re: Smartcom II offer ?
Organization: Software Ventures, Inc.
Date: Wed, 23 Dec 92 19:44:59 GMT

In article <6568.2b344b48@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <lux.724649824@sol.UVic.CA>, lux@sol.UVic.CA (Michael O'Henly) writes:
>>     Well, caveat emptor. I _assumed_ (stupidly, as it turned out) that
>> because the terminal functions in Smartcom II weren't based on the
>> Communications Toolbox, I could increase the number of rows displayed
>> under VT100 emulation to more than 24. 
>> 
>>     So I bought Smartcom II, found it a slick little program, and
>> promptly discovered that it's 24 rows and we don't care how big your
>> screen is...
>
>I've heard of people asking for this, but I admit I really don't understand
>it.

	That's because you're a programmer :-)

>A VT100 (actually we emulate a 102) has 24 lines of 80 or 132 characters. You
>can't have any more.
>
>Certainly, by a change in programming, you could increase the number of lines
>to anything you want (even larger than the screen), same for the number of
>characters (to any reasonable limit).

	MicroPhone II allows this.  But it's also important to note that most
hosts don't know about these kinds of changes, and just draw to the bottom
of the screen anyway.

>The moral dilemma is this -- how is this VT102 emulation? You'd now be 
>emulating a different terminal, not a VT102.

	True.  I know a lot of people who take a program like MicroPhone
and with a little scripting and a little of extra features do a decent job
of emulating WYSE terminals and so on.

>More specifically, how many hosts are set up to deal with a VT102 with
>more lines (and characters) than a real VT102?

	See above.

>If someone could adequately explain this to me, perhaps we can justify putting
>this feature on the ol' enhancements list.

	I think our NeXT version only does 24.  I'm not sure about the
Windows version, I think it will let you pick but I haven't double checked.
We would rather work on other issues in the early versions, like making sure 
that our file transfer methods are rock solid. But while it's certaintly not 
something I'd make a huge priority, but it is something that some people find 
useful (fewer than you might think, because of the host issue) and it's one of 
the many small things that distinguishes a mature, top of the line program to 
one that certaintly works, but doesn't do everything.

	It's an important issue -- how much do you stubbornly stick to an
emulation when your hosts are playing with it?  Do you somehow try to
emulate all 6 ways hosts have added to the 4 pfkeys that a VT100 physically
has, or do you ignore the issue, or do you give them a scripting language so
they can roll their own....

>-- 
>Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
>Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
>Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
>POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
>Disclaimer: "My employer doesn't pay me to have opinions."
>Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
>


-- 
Doug Wade  /  dwade@svcdudes.com  /   Disclaimer:  It's not official, folks.