Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!laidbak!zog From: zog@laidbak.UUCP (Christian G. Herzog) Newsgroups: comp.sys.tandy Subject: Re: Ldos vs. NeWDOS Message-ID: <1139@laidbak.UUCP> Date: Thu, 10-Sep-87 12:53:37 EDT Article-I.D.: laidbak.1139 Posted: Thu Sep 10 12:53:37 1987 Date-Received: Sat, 12-Sep-87 09:49:53 EDT References: <52@nancy.UUCP> <18@umn-d-ub.D.UMN.EDU> Reply-To: zog@laidbak.UUCP (Christian G. Herzog) Organization: LAI Chicago Lines: 84 In article <1123@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >I used TRSDOS and later LDOS back when I used a TRS-80. Both have a >serious design flaw. They both want programs to load at a specific >address. Worse, the original TRSDOS had all the system calls at >absolute addresses that had to be hard-coded into every program. This >is bad software design at its worst. > Spare us ! These OS's were written for a 8-bit microprocessor which provided no hardware support for program relocations. Hardcoded system calls weren't a problem since they were documented and the OS always loaded in the same place. (Interrupts were a more treasured resource on earlier 8-bit micros) What's the problem if you always set your programs to load at the lowest user area of memory and used the HIGHMEM pointer to find out how much memory was left ? Have you ever written any position- independant code for the Z80 ? (LDOS filters come to mind along with the TRSDOS print spooler I wrote) Do you remember the special ROM sequence to allow you to do this: POP HL ; get the PC into HL JMP (HL) ; get back to where we were Called by: CALL ---- XYZ ABC ; at this time the address of the ; current instruction is in HL ; where we can use an offset to ; reference a buffer in our pos-ind ; code (If anyone is interested, I can find the address of this routine and forward it) Guess what, doing this was a pain in the ass unless you had a program that absolutely required it. The OS would be massive if it needed to constantly adjust pointers dynamically or even call through a table set at boot time. It also wouldn't really serve any point to "float" the OS since who knows how your program would need to be split if the OS might appear in your intended program space. >Constrast this with MSDOS. At load time, the MSDOS loader performs >relocation of EXE format files, so the code can be loaded anywhere. >This is how operating systems should be designed. Obviously taking advantage of 5 years experience in micro OS's and also the relocation capabilities of the hardware it is running on. Contrasts like this don't mean anything. What about when only COM files were available ? OH NO ! No relocations ! > This >is bad software design at its worst. >It's been nearly 10 years since TRSDOS was first marketed. It's a >shame they still haven't managed to fix its problems. It's time to >upgrade to a different oeprating system. What do you mean haven't managed to fix it's problems ? Is anyone at Tandy still working on TRSDOS 1.3 enhancements ? As a Tandy stock holder I'll drop John Roach a line and ask him to place that person on something a little more productive. Why beat a dead horse ? The future isn't TRSDOS, but many applications developed for it are still going strong ! >-- >Rahul Dhesi UUCP: !{iuvax,pur-ee,uunet}!bsu-cs!dhesi You post the most bizzarre things ! __ __________ __ | ||_______ ||__| Christian G. Herzog | | _______| | __ | || ____ || | {ihnp4,sun}!laidbak!zog | || |____| || | | ||__________|| | Lachman Associates, Inc. | |___________ | | |______________||__|