minow@thundr.dec.com.UUCP (03/27/87)
/*
* This program illustrates what appears to be a bug deep in the
* bowels of the Atari operating system. The program initializes
* the desktop, then starts one of two terminal emulators, which
* have identical logic, but use different operating system functions.
* To elicit the problem, execute the program, connect to a host,
* and cause the host to send text (at 2400 Baud). Then, type something
* (I use <CTRL/C>) while output is being transmitted. The program
* will crash in various ways. You will probably have to reset the
* computer.
*
* Compile using "cc -VGEM tinytty.c" in Mark Williams C
* Execute (from the Mark Williams desktop) by "gem tinytty"
* Set the terminal service as follows:
* 2400 Baud, XON mode, other parameters seem irrelevant.
* Connect to a VMS system and login.
* $ type *.* ! type a bunch of files
* ... type <CTRL/C> to cancel a file and start another.
* there appears to be a 10% probability of crashing.
*
* Submitted by
* Martin Minow
* decvax!minow
* minow%thundr.dec@decwrl.dec.com
*/
#include <gemdefs.h>
#include <aesbind.h>
#include <osbind.h>
#include <vdibind.h>
#include <obdefs.h>
#define FALSE 0 /* Falsehood. */
#define TRUE 1 /* Truth. */
#define EOS 0 /* End of string */
#define NULL ((char *)0)
#define ESC 0x1B /* Escape */
#define CON 2 /* Console */
#define AUX 1 /* RS232 port */
/*
* Window definition structure
*/
typedef struct window {
int id;
int x, y, w, h;
} WINDOW;
long _stksize = 4096;
#define V_OVW_IN_SIZE 11 /* work in size for v_openvwrk() */
#define V_OVW_OUT_SIZE 57 /* work out size for v_openvwrk() */
int contrl[12];
int intin[128];
int ptsin[128];
int intout[128];
int ptsout[128];
extern int gl_apid; /* Real application id */
int gem_handle;
int vdi_handle;
WINDOW desk; /* The screen itself */
int char_height; /* Box (cell) height */
int debug = FALSE;
main()
{
int junk;
register int i;
int work_in[V_OVW_IN_SIZE];
int work_out[V_OVW_OUT_SIZE];
appl_init();
gem_handle = graf_handle(&junk, &char_height, &junk, &junk);
wind_update(BEG_UPDATE);
for (i = 0; i < 10; i++)
work_in[i] = 1;
work_in[10] = 2; /* Raster coordinates */
vdi_handle = gem_handle;
v_opnvwk(work_in, &vdi_handle, work_out);
if (vdi_handle == 0) {
form_alert(1,"[1][Too many windows|Close one and try again][OK]");
return;
}
wind_get(0, WF_WORKXYWH, &desk.x, &desk.y, &desk.w, &desk.h);
desk.id = wind_create(0, desk.x, desk.y, desk.w, desk.h);
if (desk.id == 0) {
form_alert(1, "[1][Can't create window][OK]");
return;
}
wind_open(desk.id, desk.x, desk.y, desk.w, desk.h);
graf_growbox(0, 0, 36, 36, desk.x, desk.y, desk.w, desk.h);
graf_mouse(M_OFF, 0xL);
if (form_alert(1, "[1][ Which version ][ Good | Crashes ]") == 1)
good_version();
else {
bad_version();
}
form_alert(1,"[1][ Exiting ][OK]");
graf_mouse(M_ON, 0xL);
wind_close(desk.id);
wind_delete(desk.id);
graf_shrinkbox(0, 0, 36, 36, desk.x, desk.y, desk.w, desk.h);
wind_update(END_UPDATE);
v_clsvwk(vdi_handle);
appl_exit();
Cconout('\r');
Cconout('\n');
}
bad_version()
{
register long c;
start_screen();
for (;;) { /* The emulator itself */
if ((c = Crawio(0xFF)) != 0) {
c &= 0x7F;
if (c == '@' || c == ('Z' & 0x1F))
break;
Cauxout((int) c);
}
if (Cauxis() != 0)
Cconout(((int) Cauxin()) & 0x7F);
}
stop_screen();
}
good_version()
{
register long c;
start_screen();
for (;;) { /* The emulator itself */
if (Bconstat(CON) != 0) {
c = Bconin(CON) & 0x7F;
if (c == '@' || c == ('Z' & 0x1F))
break;
Bconout(AUX, (int) c);
}
if (Bconstat(AUX) != 0)
Bconout(CON, ((int) Bconin(AUX)) & 0x7F);
}
stop_screen();
}
start_screen()
{
Cconout(ESC); Cconout('e'); /* Text cursor on */
Cconout(ESC); Cconout('E'); /* Clear screen */
}
stop_screen()
{
Cconout(ESC); Cconout('f'); /* Text cursor off */
}bjorn@alberta.UUCP (03/29/87)
In article <8830@decwrl.DEC.COM>, minow@thundr.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) writes: > /* > * This program illustrates what appears to be a bug deep in the > * bowels of the Atari operating system. The program initializes > * the desktop, then starts one of two terminal emulators, which > * have identical logic, but use different operating system functions. > * To elicit the problem, execute the program, connect to a host, > * and cause the host to send text (at 2400 Baud). Then, type something > * (I use <CTRL/C>) while output is being transmitted. The program > * will crash in various ways. You will probably have to reset the > * computer. I can verify that this is indeed the case. I use a stripped down emulator for logging into a 4.2BSD system. Sometimes I check my mail before switching to the Atari vt52+ emulator. And my emulator sometimes crashes if I hit ^C when the list of messages is being output. Contrary to Martin's experience, I never have to reset the machine, and again contrary to what Martin says in the rest of message flow control does not matter as I have it turned off ALWAYS. I use Bios (as opposed to GEM) calls. Some other comments: 1) I like the Atari emulator, but it lacks break capability. I and probably other people with 2400 baud modems, need that feature to kick `getty's ass (No I don't mean Don Getty nor John Paul Getty) so it will switch the line speed on the multiplexer. 2) I like Uniterm even better (as a terminal emulator that is), but never use it anymore who needs 100k-200k cluttering up their ramdisk all the time, and all because of: a) Graphics terminal (Tektronix emulation), who uses it anyway. Besides it's a bloody nuisance if something goes wrong with the line, you invariably get kicked into graphics mode and need multi-mouse-clicking...nausea. b) Built-in kermit and/or ?modem. Come on, this is not a feature, it's a bug unless you happen to have a hard disk. GEM-Kermit is quite adequate. How often do you log into a remote system versus the number of times you do file transfers? Judge Subtlety's Lemma: Bjorn R. Bjornsson "A continuum awaits the dedekinded" alberta!bjorn
pes@bath63.UUCP (03/30/87)
In article <276@pembina.alberta.UUCP> bjorn@alberta.UUCP (Bjorn R. Bjornsson) writes: >1) I like the Atari emulator, but it lacks break capability. Of course, Uniterm has that... And, he writes about Uniterm --- > a) Graphics terminal (Tektronix emulation), who uses it > anyway. Besides it's a bloody nuisance if something > goes wrong with the line... I haven't noticed this problem with newer Uniterms, though it was common with old ones. Still, I like the graphics myself. > b) Built-in kermit and/or ?modem. Come on, this is not a > feature, it's a bug unless you happen to have a hard disk. > GEM-Kermit is quite adequate. How often do you log into > a remote system versus the number of times you do file > transfers? Well, another matter of taste. The Atari is just one of the things I use as a terminal, and I'd guess that about 90% of the time that I use it to log in with, it's to shuffle files around. I *like* having kermit right at hand... (On the other hand, I *could* live without (X Y)modem, because I've never found it available on any of the mainframes I talk to...)
silvert@dalcs.UUCP (04/03/87)
In article <276@pembina.alberta.UUCP> bjorn@alberta.UUCP writes: >2) I like Uniterm even better (as a terminal emulator that is), > but never use it anymore who needs 100k-200k cluttering up > their ramdisk all the time, and all because of: > > a) Graphics terminal (Tektronix emulation), who uses it > anyway. Besides it's a bloody nuisance if something > goes wrong with the line, you invariably get kicked > into graphics mode and need multi-mouse-clicking...nausea. > > b) Built-in kermit and/or ?modem. Come on, this is not a > feature, it's a bug unless you happen to have a hard disk. > GEM-Kermit is quite adequate. How often do you log into > a remote system versus the number of times you do file > transfers? Granted, uniterm is pretty big, but it is the ONLY package with decent graphics. I use it as an alternative to a $3000 graphics terminal (HDS200's, which I think is the mode that Simon Poole intended to emulate). It might be nice to be able to suppress it, but I can survive the trouble. Actually, those of us who use graphics terminals get used to the occasional flip into graphics mode. It is a pain even with hard-wired terminals, but c'est-la-vie. As for the modem'ing features, sure those are useful. If you don't do file transfers that is your business, great, but many of us use these features. And not every system supports kermit (assuming that you have enough time to use it -- it is slow). Again, I thank Simon Poole for a great program which has been a big hit locally. I don't keep track of how often files get downloaded from my BBS, but I think that Uniterm is either the favorite, or close to it. By the way, what is the latest version? I heard about 1.7b, but haven't seen it yet. -- Bill Silvert Marine Ecology Laboratory, Dartmouth, NS, Canada CDN or BITNET: silvert@cs.dal.cdn -- UUCP: ..!{seismo|utai}!dalcs!silvert ARPA: silvert%dalcs.uucp@seismo.CSS.GOV -- CSNET: silvert%cs.dal.cdn@ubc.csnet