Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP Newsgroups: comp.sys.tandy Subject: Re: DOS WARS (Re: Ldos vs. NeWDOS) Message-ID: <1138@bsu-cs.UUCP> Date: Sat, 12-Sep-87 14:39:19 EDT Article-I.D.: bsu-cs.1138 Posted: Sat Sep 12 14:39:19 1987 Date-Received: Sun, 13-Sep-87 08:31:31 EDT References: <52@nancy.UUCP> <18@umn-d-ub.D.UMN.EDU> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Distribution: world Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 29 From trost@reed.UUCP (Bill Trost): I think that your understanding of TRSDOS is less than you suspect. Not only will it allow you to load a program into memory anywhere above the overlay area, but it will allow you to load different pieces into different chunks of memory, a process known as scatter loading. My understanding of TRSDOS is just fine. Suppose I compile a program that normally loads at address x. But then I decide I really want it to load at address x+1000, because I have loaded a debugger at address x. TRS-DOS can't handle this. Even if you could arrange to load it at x+1000, the program will crash when you transfer control to it, because all its absolute memory references still assume that it's loaded at x. Sure you can write a self-relocating program, that calls the ROM to find out where it is, then relocates all absolute addresses in itself. This is a ridiculous situation. Your program is now forced to do something that a well-designed operating system should have already done for it. (By the way, the @WHERE entry point was undocumented in all the versions of TRS-DOS that I used, and this was some years ago. I found out about it only by disassembling the ROM, and I think LDOS later documented it. So from the TRSDOS user's point it might as well not have existed.) -- Rahul Dhesi UUCP: !{iuvax,pur-ee,uunet}!bsu-cs!dhesi