Mailer@C.CS.CMU.EDU (The Mailer Daemon) (06/02/86)
Message failed for the following: post-info-applebbus@UCBVAX.BERKELEY.EDU: 550 <post-info-applebbus@UCBVAX.BERKELEY.EDU>... User unknown ------------ Received: ID <RALPHW@C.CS.CMU.EDU>; Mon 2 Jun 86 12:53:54-EDT Return-Path: <wrs@k.cs.cmu.edu> Received: from K.CS.CMU.EDU by C.CS.CMU.EDU with TCP; Sun 1 Jun 86 18:28:18-EDT Date: Sun, 1 Jun 86 18:17:04 EDT From: Walter.Smith@K.CS.CMU.EDU To: info-applebus@c Subject: BIG AppleTalk bug...Talk V2 delayed ReSent-Date: Mon 2 Jun 86 12:40:55-EDT ReSent-From: AppleTalk Interest Group Moderator <Applebus.Directory@C.CS.CMU.EDU> ReSent-Sender: RALPHW@C.CS.CMU.EDU ReSent-To: info-applebus-dist@C.CS.CMU.EDU ReSent-Message-ID: <12211636162.32.RALPHW@C.CS.CMU.EDU> Talk version 2 (the first non-toy version) almost works. There's a really bizarre bug that had me completely puzzled for a while. Apparently, the Appletalk library is wiping out one of my TE records at random because it thinks the master pointer block where that pointer lives is a parameter block for an Appletalk call. This trashes the heap as well as my TE handle. It turns out that the Appletalk library has a great big stupidity in it. See Apple Technical Note #8 (it just came out) for an explanation. The problem is that the library does a RecoverHandle at interrupt time without bothering to check whether it's in the correct heap zone. There is no workaround. The high-level Appletalk calls are useless. To quote the TN: "The only complete cure for this problem is to make all calls to AppleTalk using Device Manager _Control calls." I don't know if I really want to fix Talk to use Control calls... It may be easier just to wait for the revised Pascal library. In the meantime, be very careful of ABPasIntf (and atpl). - Walt -------