windows on normal terminals
Nigel Holder Marconi
I have a program that provides a windowing system on normal
terminals such as a vt100. Not as good as the real thing on
bitmap screens, but useful all the same. Written for 4.[2,3]
at the moment, although it should work on System V when version 8
is incorporated into it. If enough people are interested, I'll
place it in net.sources, although at the moment I'll reframe from
doing so as its > 2000 lines and I haven't written a proper
manual page yet !
Nigel Holder UK JANET: yf...@uk.co.gec-mrc.u
Marconi Research, ARPA: yf21%u.gec-mrc.co.uk@ucl-cs
Chelmsford,
Essex. CM2 8HN.
+44 245 73331 ext. 3219 / 3214
PS Please note that my mail address is different. You can use either,
although I'd prefer the one at the foot of this mailshot (yf21).
da...@ztivax.uucp
really do not require much I/O bandwidth. A student instrumented a
Macintosh and found that the effective baud rate was very low, like
6000 baud or something.
Therefore, it sounds like nice windowing systems for multi-user
machines are possible. Anyone wanna make a $ million and start building
some?
David Keppel
>Therefore, it sounds like nice windowing systems for multi-user
>machines are possible. Anyone wanna make a $ million and start building
>some?
I have enough problems with this @$%$^* 1200-baud, 24-line
terminal after using a couple side-by-side 60+ line Sun windows,
never mind trying to split 24 lines into subwindows!
In a few years most new terminals will probably be high-
performance, micros w/ high-resolution bitmap graphics and built-in
windowing OS software. Why fool with this obsolete 24-line stuff?
----
:-D avid K eppel ..!ucbvax!pavepaws!keppel
"Learning by Osmosis: Gospel in, Gospel out"
Nigel Holder Marconi
> performance, micros w/ high-resolution bitmap graphics and built-in
> windowing OS software. Why fool with this obsolete 24-line stuff?
>
>----
> :-D avid K eppel ..!ucbvax!pavepaws!keppel
So - do we all sit around for a few years twiddling out thumbs or
wait in queues to get at those lovely bitmapped screens that are slowly
appearing in large enough numbers around us. I can't wait until
these grotty 24 line things dissappear - its really a case of what
can I do with what I've got TODAY ! Anyway, writing a windowing
system has taught me quiet a bit about 4.2 that I wouldn't
normally be exposed to - so I'm happy all the same.
David Keppel
>> [ terminals will be much better/bigger/faster/higer-resolution soon ]
>
> So - do we all sit around for a few years twiddling out thumbs or
>wait in queues to get at those lovely bitmapped screens that are slowly
>appearing in large enough numbers around us. I can't wait until
>these grotty 24 line things dissappear - its really a case of what
>can I do with what I've got TODAY !
I also said that I thought it was difficult to use a number of
the windowing systems on a 24 line terminal, because your windows
got *so* small. There actually are a number of windowning systems
around for normal terminals under *NIX.
>Anyway, writing a windowing
>system has taught me quiet a bit about 4.2 that I wouldn't
>normally be exposed to - so I'm happy all the same.
Yes I'd thought about writing one, but this education doesn't address
the original poster who was asking for somebody else to go to work so
that we could all benefit. OK, so can anybody give a reference to
one of the windowing systems that's available public-domain
somewhere? If nobody can find one, perhaps Nigel would be so kind
as to post his to net.sources...
>Nigel Holder UK JANET: yf...@uk.co.gec-mrc.u
>Marconi Research, ARPA: yf21%u.gec-mrc.co.uk@ucl-cs
>Chelmsford,
>Essex. CM2 8HN.
:-D avid K eppel ..!ucbvax!pavepaws!keppel
Wayne A. Christopher
> OK, so can anybody give a reference to
> one of the windowing systems that's available public-domain
> somewhere? If nobody can find one, perhaps Nigel would be so kind
> as to post his to net.sources...
4.3 has a windowing system for ascii terminals, written by Ed Wang... It's
pretty fast and flexible...
Wayne
Wayne Throop
>> da...@ztivax.UUCP
>>Therefore, it sounds like nice windowing systems for multi-user
>>machines are possible.
It not only sounds like it, they are indeed possible, and are in use.
> [...]
> In a few years most new terminals will probably be high-
> performance, micros w/ high-resolution bitmap graphics and built-in
> windowing OS software. Why fool with this obsolete 24-line stuff?
Two reasons. First, I am developing software now, not "a few years"
from now. Second, the terminal that my employer sees fit to provide for
me is an "obsolete 24-line" terminal, despite my preference for a $100K
workstation. I can't understand why an $n-hundred terminal and 1/mth of
a $100K machine should strike my employer as any more economical than a
$100K machine for each employee(*), but this provides me with quite a
motivation to find a liveable software development environment which
will work on "obsolete 24-line stuff", and it is not beyond the realm
of possibility that there just might be one or two other developers in
the same boat.
"A few years" from now, I will gladly wash my hands of the tools I use
now, but in the meantime, windows (and job control for very-low-bps) on
my "obsolete" terminal work quite nicely, thank you.
Granted, the "short" time-to-obsolete for dumb terminal windowing
("a few years" is *short* in this buisness?) calls into question this
notion:
> Anyone wanna make a $ million and start building some?
The money-making opperknockity on dumb-terminal-windows may already be
past. And then again, it may not.
--
(*) This crack is literally true. I think that this "economy" is penny
wise and kilogram foolish. Nevertheless, it is the status quo, and
I don't have convincing figures to substantiate my position, in
terms of return-on-investment. And I don't know of anyone who
*does* have these figures.
--
"Personal workstations are the technology of the future,
and always will be."
--
Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
Derrell Lipman @ Lipman Enterprises, Los Angeles, CA
> >Therefore, it sounds like nice windowing systems for multi-user
> >machines are possible. Anyone wanna make a $ million and start building
> >some?
I have developed a windowing system, called Multi-Shell, for normal ascii
terminals. It has been ported to various 4.2 systems and System V systems.
Multi-Shell allows the terminal screen to be divided into as many as four
windows, with divisions being horizontal or vertical. Programs running in
windows think that they are running on a terminal of the window size.
(The environment variables TERM, TERMCAP, LINES, and COLUMNS all get set
appropriately for the window.)
Multi-Shell will run on any terminal which has at least the following
capabilities:
clear-screen
clear-to-end-of-line
clear-to-end-of-screen
cursor up, down, left, right
absolute cursor motion
If the terminal has more capability then these, then Multi-Shell takes
advantage of any extra capabilities (e.g. VT100 scrolling regions, insert
and delete line and character, video attributes, etc.).
Multi-Shell is not being distributed as public domain software, which is
why it has not been sent to mod.sources. It is however, reasonably priced,
and distributed in source-code form only. The reason why it is distributed
in source code form, is that a driver is added to the kernel for Multi-Shell
to operate. Since some kernels are different than others, even of the
same version of Unix, the source code is distributed as some minor porting
may be necessary to any new system on which it is installed.
Contact me for more information, at: ..!ucbvax!trwrb!ttidca!lipman!derrell
NOTE: I hope that this article is not too commercial for this network.
I did not post anything about this until now, but it seemed relevent
to the current topic of conversation. If I was wrong to post this,
I'm sorry.
--
=====================================================================
"The pioneers of a warless world are those young men, and women,
who refuse military service."
-- Albert Einstein
"Someday, the people are going to get fed up with this nonsense
and they are going to DEMAND peace from their leaders."
-- Dwight Eisenhower
(President, General, Warrior)
Derrell Lipman
Lipman Enterprises -- Windowing for Unix on standard ASCII terminals
{ucbvax,ihnp4}!trwrb!ttidca!lipman!derrell
seismo!vortex!ttidca!lipman!derrell
David Keppel
>> kep...@pavepaws.UUCP (:-D avid K eppel)
>>> da...@ztivax.UUCP
>>>Therefore, it sounds like nice windowing systems for multi-user
>>>machines are possible.
>> In a few years most new terminals will probably be high-
>> performance, micros w/ high-resolution bitmap graphics and built-in
>> windowing OS software. Why fool with this obsolete 24-line stuff?
I based my comments on a couple of things:
>First, I am developing software now, not "a few years" from now.
So am I. However, I have found 4.3 window(1) on 24-line terminals awkward
to use, and I don't think this is a bad implementation.
>Second, the terminal that my employer sees fit to provide for
>me is an "obsolete 24-line" terminal, despite my preference for a $100K
>workstation. I can't understand why an $n-hundred terminal and 1/mth of
>a $100K machine [...]
The cheapest "reasonable" terminals that I have seen are about $500.
A Mac running uw (unix windows) costs about $1200 (I think), and
even workstations don't cost that much more; I think that the posting
a few months back about cheap *nix boxes concluded that you could by a
Sun 3/75 with a small hard disk and ethernet connection for about $9K.
That's about 20X more expensive than the dumb terminal, but includes
local computing power.
>"Personal workstations are the technology of the future,
> and always will be."
"Intelligent terminals are a thing of the future whose time has passed"
;-D avid K eppel ..!ucbvax!pavepaws!keppel
Mikel Manitius
> the windowing systems on a 24 line terminal, because your windows
> got *so* small. There actually are a number of windowning systems
> around for normal terminals under *NIX.
>
Well, there are ascii 24/80 terminals which have windowing capability,
take the AT&T 4415, 4425, and 5420 terminals for example. They appear
to be regular terminals at a glance, but you can define windows in the
terminal memory, and use them. There exists software to utilize these
features, however the version's I've seen just use regular pipes, not
the "sxt000" interface, so vi and other programs think you're not on
a real terminal.
--
Mikel Manitius @ AT&T-IS Altamonte Springs, FL
...{seismo!akgua|ihnp4|cbosgd}!codas!mikel.ATT.UUCP
Jim Kempf
> >> performance, micros w/ high-resolution bitmap graphics and built-in
> >> windowing OS software. Why fool with this obsolete 24-line stuff?
> ^^^^^^^^ ;-) ;-)
>
> >me is an "obsolete 24-line" terminal, despite my preference for a $100K
> >workstation. I can't understand why an $n-hundred terminal and 1/mth of
> >a $100K machine [...]
>
> The cheapest "reasonable" terminals that I have seen are about $500.
> A Mac running uw (unix windows) costs about $1200 (I think), and
> even workstations don't cost that much more; I think that the posting
> a few months back about cheap *nix boxes concluded that you could by a
> Sun 3/75 with a small hard disk and ethernet connection for about $9K.
> That's about 20X more expensive than the dumb terminal, but includes
> local computing power.
>
Since the whole point of commercial software is to make money for
the company, one way to optimize the return on investment is to
reduce your per engineer cost. A 20x cost factor for a workstation
v.s. a terminal, spread over a 30 engineer project could very
well be the difference between a commercially viable product and
one in which the development costs kill any chance of profitability.
In addition, no engineer spends 100% of his/her time hacking. In
fact, most studies show that only about 5-10% of a typical product
engineer's time is spent doing coding. The rest is meetings, reports,
etc. etc. During the time no hacking is occuring, that $9K capital
investment is basically idle and losing money for the company.
There are two solutions to this problem. Either you multiplex
workstations among engineers or you get dumb terminals. Since
multiplexing leads to scheduling conflicts and constraints on
the engineer as to when she/he can hack, the latter is more
attractive.
As an interesting side note which might reflect on the future
of the personal workstation, several years ago when personal
computers came out, market research firms were predicting
enormous sales on the basis of one computer per desk top.
The actual sales were only one third of the predicted number,
because most employers were only buying one computer per
three employees. I think that something similar will probably
happen with personal workstations.
Of course, if you're in academia, you don't have to justify
your capital equipment costs, except to the NSF, and they'll
generally come up with the cash if your project looks good
enough.
Jim Kempf hplabs!kempf
michael maxwell
>> In a few years most new terminals will probably be high-
>> performance, micros w/ high-resolution bitmap graphics and built-in
>> windowing OS software. Why fool with this obsolete 24-line stuff?
>
>Two reasons. First, I am developing software now, not "a few years"
>from now. Second, the terminal that my employer sees fit to provide for
>me is an "obsolete 24-line" terminal, despite my preference for a $100K
>workstation. I can't understand why an $n-hundred terminal and 1/mth of
>a $100K machine should strike my employer as any more economical than a
If I understand correctly, part of the reason that large bit-mapped screens
(like the Sun I'm priveleged to be typing on now) are so expensive is the cost
of producing a CRT w/ the requisite resolution; the memory for each pixel is
presumably less of a problem these days (?). It's always seemed to me that
there must be a way of setting up a number of 80x24 CRTs to have at least
some of the advantages of the multiple (8 1/2) screens I have on my Sun right
now. Sure, you couldn't have a single large screen w/ 200 columns x 100 lines,
but you could at least have multiple editor windows (each larger than 1/8th of
a 80x24 screen), a screen dedicated to a running program that you're debugging,
etc., and file transfer between them. Just giving one user multiple terminals
is not sufficient, because he would probably rather not have 8 keyboards; so
there would have to be some easy way of shifting the keyboard from one screen
to another (maybe by numbered function keys, which I stubbornly refuse to use
for editors etc.!)
Surely someone else has thought of this. Any experience?
--
Mike Maxwell
Boeing Artificial Intelligence Center
...uw-beaver!uw-june!bcsaic!michaelm
j...@isis.uucp
>Of course, if you're in academia, you don't have to justify
>your capital equipment costs, except to the NSF, and they'll
>generally come up with the cash if your project looks good
>enough.
Don't you love America...
--------
"OK, so now, after it gets dark Lancelot and I will jump out of the rabbit, and
take the castle by supr........ oh."
Jay Batson
{seismo,hplabs}!hao!isis!jay
Doug Gwyn
displays are exclusively associated with $100K workstations;
this is definitely not so. My DMD cost something like $4K plus
1/Nth the cost of the supporting host software, which I think
is a pretty good deal. Even Sun workstations are nowhere near
the $100K price range.
ch...@umcp-cs.uucp
terminals. Someone else wrote a window shell on top of that.
(Actually, two people wrote two different window shells.) We also
have the 4.3BSD `window' program (which, incidentally, is clearly
a distant relative of my library code). So we have a number of
windowing programs available locally. However, I rarely use any
of them. Why? I am not entirely certain, but I think the main
problem is that 24x80 (or 30x80 or even 33x80) is already too small,
or perhaps just barely adequate. I do not intend to put down
anyone's efforts; but before you invest in a windowing system, make
sure you are really going to use it. . . .
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: ch...@mimsy.umd.edu
David Keppel
>there must be a way of setting up a number of 80x24 CRTs to have at least
>some of the advantages of the multiple (8 1/2) screens I have on my Sun right
>now.
There is a paper, "Cognitive Representations of Windows and Multiple
Screen Layouts of Computer Interfaces" by KL Norman, LJ Weldon, and
B Shneiderman of the University of Maryland Hman-Computer Interaction
Laboratory, which is exactly about multiple-scren systems built of
80X25 screens.
> [CRTs are most expensive part of terminal ]
I would think that once you had, say, 4 "windows" built out of terminals,
that you would have exceeded the cost of a Mac running Unix Windows.
;-D avid K eppel ..!ucbvax!pavepaws!keppel
Brandon Allbery
Quoted from <5...@bcsaic.UUCP> ["Re: windows on normal terminals"], by mich...@bcsaic.UUCP (michael maxwell)...
+---------------
+---------------
Indeed someone has. It's called ``shell layers.''
Unfortunately, the only terminal on which it's worth sh*t is -- YOU GOT IT!
A large, expensive bitmapped-screen terminal, yclept DMD5620.
It's enough to make a Unix person throw up.
--Brandon
--
ihnp4!sun!cwruecmp!ncoast!allbery ncoast!all...@Case.CSNET ncoast!tdi2!brandon
(ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101
Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time)
Henry Spencer
> fact, most studies show that only about 5-10% of a typical product
> engineer's time is spent doing coding. The rest is meetings, reports,
> etc. etc. During the time no hacking is occuring, that $9K capital
> investment is basically idle and losing money for the company.
One can also argue that during the time no hacking is occurring, the
$xxxxx/year investment inside the engineer's head is basically idle and
losing money for the company. I.e., that 5-10% factor is a bug, not
a feature. To quote Peter Drucker:
"Meetings are by definition a concession to deficient
organization. For one either meets or one works. One
cannot do both at the same time... There will always be
more than enough meetings. Organizations will always
require [lots of] working together... But if [people]
in an organization spend more than a fairly small part
of their time in meeting, it is a sure sign of
malorganization... meetings should never be allowed to
become the main demand on [a professional's] time."
[The Effective Executive, p. 44-45 -- highly recommended.]
--
Usenet(n): AT&T scheme to earn
revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology
late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Tanner Andrews
) might be interested in one kbds and 8 screens with a way to switch
) the kbd between screens. suggests using numbered function keys.
It might be of some interest to the net that SCO xenix has arranged
to use the IBM-AT or IBM-AT-alike screen and ALT-<function key> to
allow up to 10 logical terminals on the console screen. You switch
between displays easily. True, you can't see them all at once, but
it's a lot better than nothing if you need that sort of thing; it
works fine on a 24x80 screen. The display for all of the screens is
kept in main memory (but where else can you put it on an IBM-AT?).
On a system with 3.5 meg of core, 10*2K is not a whole lot of loss.
A simple priority scheme assures that if anything is output to the
console, the system immediately switches to that screen. Disk errors
and such panics are therefore immediately visible.
--
<std dsclm, copies upon request> Tanner Andrews
Jim Kempf
>Of course, if you're in academia, you don't have to justify
>your capital equipment costs, except to the NSF, and they'll
>generally come up with the cash if your project looks good
>enough.
This rather cavalier comment did, in fact, come from my fingers,
for which I'd like to apologize. What I meant to say was that
people in academia SHOULDN'T have to justify their capital
equipment costs, except to an appropriate funding agency which
should come up with the cash if the project looks good. I am
fully well sensitive to the problems universities are having
with funding these days (what with SDI eating up a bigger and
bigger portion of the research budget). The point of my posting
was that current data on productivity do not justify personal
workstations on cost grounds alone, since they are not cost
competitive with terminals. Therefore, a windowing system may
make sense.
Again, apologies to any of my academic collegues who may have
taken offense at this admittedly cavalier remark.
Jim Kempf hplabs!kempf
(usual disclaimer)
Ihnat
normal tty with X by Y character and lines?? Anyone remember the Tektronix
scope that stood about 5' high, and had a screen big enough to show the
Chicago Bears game on? It windowed just fine, thanx. A little bulky,
a little kludgy, but whaddya want for 1978???
--
Dave Ihnat
Analysts International Corporation
(312) 882-4673
ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz
Robert Bradbury
> If I understand correctly, part of the reason that large bit-mapped screens
> (like the Sun I'm priveleged to be typing on now) are so expensive is the cost
> of producing a CRT w/ the requisite resolution; the memory for each pixel is
> presumably less of a problem these days (?). It's always seemed to me that
> there must be a way of setting up a number of 80x24 CRTs to have at least
> some of the advantages of the multiple (8 1/2) screens I have on my Sun right
> now.
I myself routinely use 2-3 terminals. Up here in Seattle I've got a CIT-500
and 2 VT100's connected to a RIXON 815 stat mux telecommuting over a leased line
to CA. Several fellows in CA have 2 or more terminals on their desks. It
is cumbersone (due to the keyboard size), but when you sometimes need to
work on an IBM mainframes, DEC VMS and UNIX systems all at the same time
it works. We have ethernet running between all of the machines but getting
"rlogin" and various system editors to know about non-standard window sizes
doesn't seem to be a solution now (How do you get EDT on VMS to take advantage
of a 66 line CIT?). We recently got a number of people VAX workstations
with the fancy color screens but this was justified mainly on the basis
of guaranteeing some developers local computing power. I generally don't
prefer a spaceheater (:-)) where several terminals suffice.
My biggest productivity booster seems to be the larger screen on the CIT.
I could use the window packages described in recent msgs to get "real"
windows and it isn't much more expensive than a VT100.
The solutions seem to vary depending on what you really do:
- Some people need local computing power (ala Sun's and Vaxstations)
- Some people need access to multiple machines (ala multiple terminals)
- Some people (managers?) only spend 5-10% of their time a day on a
terminal and can get by with a 24x80 sized screen.
--
Robert Bradbury
Oracle Corporation
(206) 364-1442 {ihnp4!muuxl,hplabs}!oracle!bradbury
Mikel Manitius
> Some people find "shl" useful; it doesn't require any special terminal.
> Its main problem is that it merely multiplexes the terminal for several
> concurrent processes, which have no way to tell what may be visible on
> the current display. A full window manager solves this problem.
You can very easily tell what is on your screen, if you do "stty loblk".
This blocks processes which try to output to the terminal, if they are
not in the current layer. When the layer becomes current, then they job
is unblocked, and you may get flooded with output.
In my opinion, this is still not as nice as berkeley's job control, but
to get that, you must give up other things....
John Owens
> to another (maybe by numbered function keys, which I stubbornly refuse to use
> for editors etc.!)
> Surely someone else has thought of this. Any experience?
My first exposure to this was Venix/86 for the PC. If you had a
video card with sufficient memory, you could hit Alt-1 through Alt-4
to go to screens one through four, each of which was a separate device,
"login:" prompt and all. I used one screen for normal work, one with
an editor, and one logged in as root.
One of the nicest ones I've seen is the windowing system in IC-DOS, a
UNIX-like system sold by Action Instruments to the industrial market.
You can have up to 10 windows, which can be sized from a few lines by
a few characters, to the full 24x80 lines. The can have a border or
not, can have default colors assigned to them, etc. You can have
several full-screen windows, similar to the Venix/86 scheme, plus
several smaller windows at various points on the screen, which will
pop up as needed. It's a very complete system; I enjoy using it.
Window 0 is the full console screen, with no sub-windowing; this is
for programs that want to access screen memory directly (for PC-DOS
emulation, especially). [Disclaimer: I am not unbiased, as I am
connected with the IC-DOS work. Nonetheless, these are my personal
opinions.]
John Owens @ General Electric Company (+1 804 978 5726)
edison!jso%virg...@CSNet-Relay.ARPA [old arpa]
edison!j...@virginia.EDU [w/ nameservers]
j...@edison.UUCP [w/ uucp domains]
{cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
Stanley Friesen
>this is definitely not so. My DMD cost something like $4K plus
>1/Nth the cost of the supporting host software, which I think
>is a pretty good deal. Even Sun workstations are nowhere near
>the $100K price range.
All fine and good, but this is *still* well above $1K, which
is about all many employers(including mine) will spend for a
terminal/workstation. So, until the price for a DMD equivalent is <
$1K it will be necessary to put up with supporting 24X80 terminals! I
would certainly like to *try* a windowing system on my ADM-11!
--
Sarima (Stanley Friesen)
UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ??
Brandon Allbery
Quoted from <5...@codas.ATT.UUCP> ["Re: multiplexing terminals..."], by mi...@codas.ATT.UUCP (Mikel Manitius)...
+---------------
| > "Shell layers" refers to "shl", which is NOT the same as DMD "layers".
| > Some people find "shl" useful; it doesn't require any special terminal.
| > Its main problem is that it merely multiplexes the terminal for several
| > concurrent processes, which have no way to tell what may be visible on
| > the current display. A full window manager solves this problem.
|
| You can very easily tell what is on your screen, if you do "stty loblk".
| This blocks processes which try to output to the terminal, if they are
| not in the current layer. When the layer becomes current, then they job
| is unblocked, and you may get flooded with output.
+---------------
Certainly. Unless you do the following (which is also a problem with job
control, I've discovered:
% sh
[Or, for shl:
>>> sh
]
$ <CTRL-Z>
Stopped
% %
[Or, for shl:
>>> sh
]
[and where are you?]
I've also thought of a solution: write a terminal program for a computer
(even a cheap CP/M system can handle it) to interface to job control/shl.
^Z causes the program to save the current screen and restore the previous one
(the csh or shl). A command is then given to the terminal program to switch
jobs. (This seems easier for a shl-based system to me; ``shl'' is then
interacted with locally, and the terminal program sends the command to the
real shl and switches screens again.) Of course, you have to deal with emacs
and other programs which disable ^Z for their own purposes...
Any takers? (My hands are full: after releasing the bugfixed UA 0.4.4 to the
net, I'm getting cracking on 1.0.0. Besides, we have neither shl nor job
control: we run System III.)
#Bill_Stewart
>In article <13...@brl-smoke.ARPA> gw...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>this is definitely not so. My DMD cost something like $4K plus
>
>is about all many employers(including mine) will spend for a
>terminal/workstation. So, until the price for a DMD equivalent is <
>$1K it will be necessary to put up with supporting 24X80 terminals! I
<How can I pass up this one?>
I know of two Blit-like applications in the $1000-$1500 range.
One is the Atari-520ST software cartridge done at Univ.Toronto
(they turned it into a Blit, which can run real Blit binaries).
The other is PC-Layers, which runs on the AT&T 6300 (not on clones; it
depends on the high-resloution screen).
As far as I know, neither of these is a product, but the job is
definitely doable. Both are limited by their 640x400 screens,
but worthwhile.
If you're not concerned about window size or bitmap graphics, it ought
to be possible to do layers communications on any cheap PC; a Commodore
64 is probably too slow, but an Atari 130 ought to be ok.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Stanley Friesen
>
> <How can I pass up this one?>
>I know of two Blit-like applications in the $1000-$1500 range.
>The other is PC-Layers, which runs on the AT&T 6300 (not on clones; it
>depends on the high-resloution screen).
>As far as I know, neither of these is a product, but the job is
>definitely doable. Both are limited by their 640x400 screens,
>but worthwhile.
>
>If you're not concerned about window size or bitmap graphics, it ought
>to be possible to do layers communications on any cheap PC; a Commodore
>64 is probably too slow, but an Atari 130 ought to be ok.
Fine, now if someone can convince the management here to
transfer a programmer from developing product that goes out the door
to writing or porting the software to support Blit on one of these
machines we will be able to do something :-) Really, when something
like this is a *product*, with full support from BSD Unix, then we
*might* get it. Until then it would require too much human resources
here to support.
Henry Spencer
> like this is a *product*, with full support from BSD Unix, then we
Surely you jest, there is no such thing as a "product" with "full support"
from Berkeley.