Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!bellcore!faline!scherzo!allegra!mit-eddie!ll-xn!cit-vax!usc-oberon!sdcrdcf!trwrb!sansom
From: sansom@trwrb.UUCP
Newsgroups: comp.sys.atari.st
Subject: Repost of link68 fix (thanks Konrad)
Message-ID: <1640@trwrb.UUCP>
Date: Wed, 4-Mar-87 11:33:09 EST
Article-I.D.: trwrb.1640
Posted: Wed Mar  4 11:33:09 1987
Date-Received: Sat, 7-Mar-87 00:31:40 EST
Reply-To: sansom@trwrb.UUCP (Richard Sansom)
Organization: TRW EDS, Redondo Beach, CA
Lines: 34

I finally got a chance to dig this thing out of my archives.  It was posted
quite some time ago (a year?) and contains a fix to the pathname problem with
link68, the Alcyon/DRI overlay linker which comes with the developer's kit.

-Rich

p.s. - this thing _does_ work, however there still seems to be a problem
with long pathnames.  I don't remember the exact length which works, but I
think it's somewhere around 13-14 characters.

-- cut here, extract file linkfix.doc --
Trying to overcome the problem with LINK68 not accepting pathnames I found
a scanner control table starting at file-offset 0x8144.
The command scanner of LINK68 uses a byte entry of this table indexed by an
input character as a control pattern specifying the character class.

The backslash entry at file-offset 0x81A0 has the value 0x02 which is a
separator pattern.
Patching it to value 0x04 puts the backslash into the number class.
After this fix LINK68 treats the backslash as a normal identifier character
but GEMDOS still sees a pathname.

  Konrad Hahn
  Techn. University Darmstadt
  Dept. of Computer Science (Datentechnik)
  Merckstr. 25, D-6100 Darmstadt, W.-Germany
-- cut here --


-- 
  //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
 /// Richard E. Sansom                    TRW Electronics & Defense Sector \\\
 \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom   Redondo Beach, CA                ///
  \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////