Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ub!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: What's Wrong with ARP!!!! Message-ID: <15901@cbmvax.commodore.com> Date: 16 Nov 90 01:54:53 GMT References: <114.273F7E66@myamiga.UUCP> <1990Nov14.034507.19784@hoss.unl.edu> <7039@sugar.hackercorp.com> <90318.162021DXB132@psuvm.psu.edu> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 29 In article cedman@golem.ps.uci.edu (Carl Edman) writes: {talking about the ARP shell} > It is to >this day the only shell which made all the right design choices, >starting from being small and fast to being largly compatible and >implemented in as a system library. Well, there are as many definitions of what a shell "should be" as there are users, I'm afraid. And ASH made one MAJOR boo-boo: it creates it's own process structures, and this will NOT work under 2.0. Crash, burn, up in flames. :-( (Note: this is what Charlie told me, I never bothered trying it myself.) Arp had some nice ideas, but parts of it suffered from a lack of overall design and had some flaws related to the way in which it was coded (tight, tricky assembler is small, but it can lead to some nasty boo- boos, especially when you don't have a tight design first). The basic premise of Arp was good, which was why we incorporated a fair amount of Arp (or it's equivalents, designed with hindsight) into 2.0 when I rewrote it in C/asm. And of course, with all those new calls and with the new commands written in C, they got smaller (or went into the shell, or got a number of useful new features). Plus they're a lot easier to maintain and debug in C. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"