TIP: Click on subject to list as thread! ANSI
echo: cis.hot_topics
to: Kevin Darling (UG Pres) 76703,4227 (X)
from: Bob van der Poel 76510,2203
date: 1990-10-31 20:42:16
subject: #7907-OSK Software

#: 7926 S15/Hot Topics
    31-Oct-90  20:42:16
Sb: #7907-OSK Software
Fm: Bob van der Poel 76510,2203
To: Kevin Darling (UG Pres) 76703,4227 (X)

Kevin,

Good points in your messages. Yes, GetStts can be a problem. But if my idea of
device driver/descriptors would work, they too can be handled.

Hey, I even have a name from my crazy scheme--"remote windows". I've been doing
some more thinking about this, and it really should work. Again, the idea is to
have a driver which would translate between the computers native screen i/o
codes and that of a remote. The descriptor would have translation tables for
both keyboard and screen codes. Not thinking here...but I suppose it could also
fudge get/sutstt calls too.

For now, I see no problem with simply ignoring incompatible codes. If you are
running a gfx program and the terminal doesn't have gfx, then that is YOU
problem. Even though it might be expensive, the remote window driver could even
support windows, etc. Just a matter of keeping virtual screens in memory and
doing updates at the proper time.

I sort of see this as an evolving thing. Hopefully, it could be set up in an
expandable format. Another thought--quite a few people might want to use old
CoCos as terminals with the new computers. Be nice to have some compatiblity
there.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.