Path: utzoo!utgpu!attcan!uunet!oddjob!ncar!mailrus!um-math!hyc From: hyc@math.lsa.umich.edu (Howard Chu) Newsgroups: comp.sys.atari.st Subject: Malloc (was Re: Another great quote from Mr. Good) Message-ID: <402@clio.math.lsa.umich.edu> Date: 18 Aug 88 19:49:20 GMT References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> <6339@chinet.UUCP> Sender: usenet@math.lsa.umich.edu Reply-To: hyc@math.lsa.umich.edu (Howard Chu) Distribution: comp Organization: University of Michigan Math Dept., Ann Arbor Lines: 31 UUCP-Path: {mailrus,umix}!um-math!hyc I get the feeling that there really is no solution at this point. How can you have two different versions of Malloc/Free in the same system? Consider how this would work. Assume a new ROM with TOS and GEMDOS that use the new, fixed Malloc. Consider starting an old application from this new GEM desktop. Both memory allocators will have to be rewritten to know exactly what each other is doing, or you get programs tromping all over each other. And since you really can't change the old version of Malloc, what you're really going to have to do is write the new Malloc such that it allocates memory in such a way that the old Malloc will honor its allocations. Anything using the old Malloc will still eat up memory, will still need to be freed in the correct order or else you lose. It'd be pretty gross. Having two incompatible memory allocators active in the same system just can't be a good idea... It's not just a question of a single program only sticking to one version - it's a question of many programs being able to be loaded up arbitrarily, bearing in mind that the OS itself is probably using the new allocator. The only real solution would have been to put in the fixed allocator and tell anyone with misbehaving code to rewrite it. Unfortunately, as Roy Good has mentioned, a lot of programs' original writers are no longer in business, so there's no way to catch everything with an appropriate update. About the only route then, if Atari put out a fixed Malloc, is for some Good Samaritan to pull out a debugger and come up with some binary patches. Not exactly a nice situation. -- / /_ , ,_. Howard Chu / /(_/(__ University of Michigan / Computing Center College of LS&A ' Unix Project Information Systems