Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!ccu!bright From: bright@ccu.umanitoba.ca (Bob Bright) Newsgroups: comp.sys.atari.st Subject: Re: Tick-tick-tick-CRASH! is not dead in TOS 1.4 Message-ID: <1990Feb6.174024.13984@ccu.umanitoba.ca> Date: 6 Feb 90 17:40:24 GMT References: <8040@shlump.nac.dec.com> Reply-To: bright@ccu.UManitoba.CA (Bob Bright) Organization: University of Manitoba, Winnipeg, Manitoba, Canada Lines: 66 In article <8040@shlump.nac.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes: > >In article <2015@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes... >>grahamt@syma.sussex.ac.uk (Graham Thomas) writes: >> >>| GST say it's something inside TOS (or GEMDOS or whatever layer >>| it might be), so I was rather hoping the problem might go away with TOS >>| 1.4. >> >>Now why doesn't that surprise me? Not to bash GST, but I have found >>that a lot of problems similar to this are a result of bad programming >>practices. Not intentional, but just because the developer wasn't >>aware of some restriction or another. It's all too easy to blame TOS. > ... >no fair, Ken, it's not GST's problem. > >About a year ago I posted this same problem with Word Perfect Atari. >It too drops into "slow mode" now and then, when it eats up the keyboard >buffer about one key every few seconds, treats the screen as if the >mouse button were stuck down, and if you're lucky lets you (slowly!) >request a save before you have to reboot. Just so; this is _definitely_ not a problem restricted to GST products. As Fred goes on to note, WP Corp. has been aware of The Problem for a long time; they claim that Atari Corp. has been uncooperative in helping them track down its source. Whatever; fact is, there's a real problem here, it's a royal pain in the *ss, and whether or not it's a bug in TOS is not entirely relevant. If it is a bug in TOS, then you as well as us should be interested in getting it fixed as soon as possible (another patch?; at any rate a fix for TOS 1.8). If on the other hand it really is a matter of developers breaking rules, you should be interested in identifying the rule or rules in question and warning developers of the consequences of breaking them as soon as possible. Apparently WP Corp. and GST are under the mistaken impression that they're not doing anything wrong, which is making my life miserable, not to mention harming their sales and ultimately Atari's. Fortunately, The Problem hasn't hit me in WP for a couple of weeks (even without the chicken blood and incantations :-). Prior to that it seemed like I was getting bitten every other day or so. I don't have any more of a clue than anyone else about how to replicate it, but for what it's worth, I've noticed that The Problem is not unconnected with mouse movement. I.e.: If I catch it before it gets out of hand (after the machine has started to crawl, but before it locks up completely), I can save my file and exit WP by moving the mouse slightly after each key press. Here's the scenario: 1. Machine slows to a crawl; keystrokes and mouseclicks have an effect only seconds after a key is pushed or button clicked. 2. I hit F7 ("Exit"). Nothing happens. 3. I move mouse slightly. "Save file?" dialogue pops us instantly. 4. I respond with "y". Nothing happens. 5. I move mouse slightly. File is saved, and "Exit?" dialogue pops up. 6. I respond with "y". Nothing happens... etc. Does this behaviour suggest anything to anyone? BBB -- Bob Bright Dept. of Philosophy University of Manitoba Winnipeg, Man R3T 2N2 (204) 474-9680