Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: OBSERVE.MAR Part 1 of 1 Message-ID: <8612181618.AA05718@ucbvax.Berkeley.EDU> Date: Thu, 18-Dec-86 11:19:02 EST Article-I.D.: ucbvax.8612181618.AA05718 Posted: Thu Dec 18 11:19:02 1986 Date-Received: Thu, 18-Dec-86 22:18:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To:Organization: The ARPA Internet Lines: 61 Approved: info-vax@sri-kl.arpa WARNING!!! This program can crash your system! OBSERVE is a clever little piece of code that interposes itself between the port and class drivers of a target terminal and copies all outgoing characters directly to the terminal it was run on. For OBSERVE to work, it must under- stand the kind of port driver being used, and further the same port driver must be used on both the target and observing terminals. In practice, the program understands the DZ11 and DMF32 port drivers. Unfortunately, it makes a rather simple test to determine which of the two it is dealing with: It looks at the second byte of the terminal's device name. If that byte is "X", the DMF32 code is used; otherwise, the DZ11 code is used. For example, if you try it out using a VAXStation emulated window - device name WTAn: - you'll get a quick crash. (At least I did.) I'm willing to bet that the same thing will happen with LAT terminals (LTAn) or a DECnet remote terminal (RTAn). I don't know what will happen with other terminal hardware, such as the DZ32, though I think the port drivers for the DZ32 and DZ11 are the same, so that particular one should work. It's also not obvious that the code will work if virtual terminals are enabled. Since it WON'T run on my VAXStation - which has no "real" terminals - I can't test any of this out; I'm not willing to crash our 8600 just for the heck of it. So, I can only guess based on a quick reading of sparsely-commented code. Other things to know about OBSERVE: - I suspect that typing CTRL/S while observing a terminal that's producing a lot of output can cause a crash as various buffers overflow. - It is hard-wired to assume VT100-compatible terminals, only, though nothing really terrible will happen on others. - It has hard-coded in a variety of assumptions about the inards of the terminal driver. Hence, it stands a good chance of dying as new versions of VMS come out. Further, given its nature, any time OBSERVE dies, it is almost certain to take the system with it. - Some of the coding isn't quite as defensive as it might be; there are some timing windows during initialization that could leave the system in a strange state. Don't type CTRL/Y while the program is starting up! - The program never bothers to lock down the kernel-mode, elevated-IPL code it runs during initialization; a page fault in this code will cause a crash. This is quite unlikely, but possible. - If you start it via a foreign command, it will take a single argu- ment, the name of the target terminal. Otherwise, it will prompt you. - Don't bother thinking about using OBSERVE to RECORD what a terminal is doing, rather than just displaying it - that would involve a whole new approach. Take all this as a warning to be careful. Given its simplicity, it's probably the case that if OBSERVE works on a particular configuration at all, it will continue to work - i.e., if you can run it for a couple of minutes without crashing the system you should be safe. But don't make your test run during production! BTW, OBSERVE needs CMKRNL - which it will NOT enable - and must be linked against the system symbol table. (I'm being brief deliberately: If you don't know what this means, you have no business playing with this program.) -- Jerry -------