kentd@FtCollins.NCR.com (Kent.Dalton) (10/12/90)
I've moved discussion of this topic to ...st.tech since it's getting more technical than general interest. The following is a reply to my query about Laser C's incompatibility with MiNT. Sam Streeper writes: From: Sam_Streeper@NeXT.COM To: Kent.Dalton@FtCollins.NCR.com Subject: Re: Laser C V2.1 vs MiNT?? Newsgroups: comp.sys.atari.st In-Reply-To: <KENTD.90Oct9111745@zappa.FtCollins.NCR.com> References: <KENTD.90Oct7182718@zappa.FtCollins.NCR.com> <1990Oct8.144159.12610@doe.utoronto.ca> Organization: NeXT, Inc. >When in debug mode, MiNT shows Laser Programs malloc'ing 8K (presumably >stack), it then tries to grab some more mem and gets a message to the >effect of: get_region, no region is big enough or some such. From this description, I know exactly what the problem is. The laser init code can start both programs and desk accessories. It tests something undocumented to determine which it is starting. If it is starting a program, it gives back all the memory except what it needs for a stack (using Mfree()). If it is starting a desk accessory, it mallocs a stack, but has no need to free any memory, since accessories are already "shrunk to fit" The init thinks the program is an accessory, so it is a big memory pig and all subsequent mallocs will fail. I don't consider this a Laser bug, because all versions of TOS set this up correctly, and lots of people use this trick to get their gem applications to work as both programs and DA's. With this being the case, MiNT should really start apps with the same setup as TOS. I had to patch the original MichTron juggler to get it to correctly start Laser (and other dual purpose) programs. If you write back, I'll check what it is that Laser init checks when I get home. Feel free to post this information; I don't really know how to do News posting... -sam -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* Fort Collins, Colorado * "This mind intentionally left blank" */ /* (303)223-5100 X-319 * All standard disclaimers apply */ /**************************************************************************/
kentd@FtCollins.NCR.com (Kent.Dalton) (10/15/90)
Well, I figured out exactly what's happening to cause the Laser C init code to hang up MiNT. The Laser C startup module is set up to start both desk accessories as well as normal applications. The way it determines which type of program it is, is by looking at it's parent's basepage address (offset 36(decimal) into it's own)... If it's zero it starts itself up as an accessory and if it's non-zero it starts as a "normal" program. When MiNT launches a program this location is zero and the startup code, convinced that it's a desk accessory, hangs the system. I hacked up a prg only version of the startup code and my Laser programs now work with MiNT. The obvious long-term solution is to have MiNT put it's own basepage address in that location when it launches a program (or at least something that's nonzero). That way MiNT'll be more compatible with the programs out there that can function as both regular programs and desk accessories. Hopefully, this change can be incorporated in the next "official" release of MiNT. -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* Fort Collins, Colorado * "This mind intentionally left blank" */ /* (303)223-5100 X-319 * All standard disclaimers apply */ /**************************************************************************/
apratt@atari.UUCP (Allan Pratt) (10/16/90)
>From: Sam_Streeper@NeXT.COM >It tests >something undocumented to determine which it is starting. [...] >I don't consider this a Laser bug, I do, at least in part. >because all versions of TOS set this up correctly, All EXISTING versions might, but it's not documented or guaranteed. >and lots of people use this trick to get their gem applications to work >as both programs and DA's. If lots of people jumped off a bridge, would that make it the bridge's fault? I'm being facetious, of course, but just because "lots of people" do something doesn't make it documented. This is called a "settled expectation," and we *do* consider them whe we make TOS changes, but it doesn't mean they're guaranteed: it's still the program's fault (in this case, Laser's startup code). Of course, it wouldn't be hard to make MiNT start up programs with whatever key difference Laser C expects, but the fact remains that the programs are relying on something which is not guaranteed. That means they are "version dependent," and if they work under a different "version" of TOS, fine, but if they don't, blame the program, not the OS. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt