V067MAJP@UBVMSC.CC.BUFFALO.EDU (Arion) (01/15/90)
(This has to do with the thread about about documented source for TOS etc.
where Allan Pratt makes an argument involving developers taking advantage of
"features" (my word, definitely not his). Sorry for not quoting)
What I don't understand is why don't the excellent development team at Atari
just go ahead and make the changes and break all the programs that don't follow
the rules. I'm not a developer, but I doubt that there was any documentation
that said 2 successive mallocs would yield neighboring blocks. (same for other
examples)
It seems to me (IMHO) that if developers keep taking advantage of
"side-effects" and Atari tries it's best to keep programs from breaking,
eventually, you won't be able to revise TOS at all.
I mean, if a program breaks because a programmer takes advantage of an
undocumented or illegal "feature" which isn't there at the next os revision,
isn't that the programmer's fault?
Also, about working around bugs in TOS, there is a legal way of checking TOS
version, right? So, can't you write your program so it uses a "workaround" for
TOS 1.0 but does things the right way for TOS 1.4 (sort of like how Ian
Lepore's GEMFAST bindings simulates the TOS 1.4 file_selector if your TOS is
<1.4) or whatever the case may be?
(I think they're right. Maybe Atarians ARE militant :-) )
John
v067majp@ubvmsc.cc.buffalo.edupwp@iuvax.cs.indiana.edu (Paul Purdom) (01/16/90)
The question of whether or not to up grade a ROM operating system so that old programs work is delicate. Many users would like to beable to up grade to remove bugs in their operating system without losing the ability to run their old comerical programs. Their needs should be balanced aagainst the difficulty (or impossibility) of fixing the bugs while still being able to run old programs. The benefit of each change needs to be compared with the trouble it causes users of old programs. For the most part, people who write their own programs like improvement, but people who buy programs like stability. I do both myself, so I feel for the people that have to decide what to do in each particular case.
ajy2208%ritcv@cs.rit.edu (01/16/90)
In article <F39D2F69C99FC014B9@UBVMS.BITNET> V067MAJP@UBVMSC.CC.BUFFALO.EDU (Arion) writes: >It seems to me (IMHO) that if developers keep taking advantage of >"side-effects" and Atari tries it's best to keep programs from breaking, >eventually, you won't be able to revise TOS at all. > >I mean, if a program breaks because a programmer takes advantage of an >undocumented or illegal "feature" which isn't there at the next os revision, >isn't that the programmer's fault? Hmm, this reminds me of what happened when Atari brought out the XL operating system for the 8-bit computer.. A LOT of programs broke because programmers did not follow the rules... > John I have Mark Williams C, and am curious: What is the difference between malloc() and Malloc() ???? I am writing a slideshow/picture viewing program, and when I used malloc() to get a 32k block of memory for a picture, the picture always had some stray data at the top (looked suspiciously like the other variables I was using).. However, when I used Malloc() this disappeared. Boy, I almost pulled my hair out trying to figure out what was wrong!!! _____________________________________________________________________________ Albert Yarusso, Rochester ajy2208@ritvax.bitnet,ajy2208@ultb.isc.rit.edu Institute of Tech. _________________________________________________________ Computer Science /___ / {rutgers, ames}!rochester!ritcv!ajy2208 ______________________/ / ajy2208@ritcv.cs.rit.edu GEnie: A.Yarusso
kbad@atari.UUCP (Ken Badertscher) (01/16/90)
V067MAJP@UBVMSC.CC.BUFFALO.EDU (Arion) writes: | What I don't understand is why don't the excellent development team at Atari | just go ahead and make the changes and break all the programs that don't follow | the rules. Believe me, Arion, it's very very tempting at times. Especially when you see some of the really silly things that some developers do to break the rules. You want to punish them. But in fact, the end users are punished worse if Atari breaks programs which break the rules. All a user knows is that his favorite program doesn't work any more. If the company that made it is no longer in business, that user is really up the creek. Fortunately, we are not constrained to strict compatibility with the TTOS, so we may be able to fix some of the things we were previously unable to fix. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
alex@athertn.Atherton.COM (Alex Leavens) (01/17/90)
The difference between malloc() and Malloc() in Mark Williams C is this: Malloc() is the standard GEMDos memory allocation. malloc() is Mark William's own version of malloc, which basically tries to buffer you from some of Malloc()'s oddities. The first time you call the MWC malloc(), it does a GEMDos Malloc() of a bigger chunk than you asked for, then parcels it out to you as requested. For example, if you ask it for 10K, MWC will go out and get (say) 32K, and give you a pointer to 10K. Then if you ask for another 10K, it'll just give you a pointer to another chunk of it's remaining 22K. In doing this, you cut down on the number of calls made to Malloc(), which is good, since Malloc() will fail after some fixed (albeit large) number of calls. (The Malloc() call limit can be raised by using the FoldrXXX.prg program from Atari.) I ran into this problem myself in a program I'm writing; I was doing _lots_ of little malloc()'s (roughly 1K each), and I was supposedly "running out of memory" _much_ sooner than I should have. (I had 800K+ free, but couldn't get anymore). I put in Foldr100.prg, and the problem went away. Another alternative would be to use someone else's malloc() package; Dave Beckemeyer has one on his BBS which you can tweak to the values you want. -- |-------------------------------------------------------------------------| |--alex | alex@atherton.com | Caution! Falling Opinions, next 6 miles | | Now who are you gonna believe--me, or your own lyin' eyes? | |-------------------------------------------------------------------------|
hyc@math.lsa.umich.edu (Howard Chu) (01/17/90)
In article <1534@cs.rit.edu> ajy2208%ritcv@cs.rit.edu (Albert Yarusso) writes: >>I mean, if a program breaks because a programmer takes advantage of an >>undocumented or illegal "feature" which isn't there at the next os revision, >>isn't that the programmer's fault? > >Hmm, this reminds me of what happened when Atari brought out the XL >operating system for the 8-bit computer.. A LOT of programs broke >because programmers did not follow the rules... So, make TOS 1.4 available on a boot disk. A LOT of XL Translators were available to address the problem, and they usually sufficed, except for the rare case where actual hardware differences got in the way. (Like the XL/XE's bank switching in place of 3rd & 4th joystick ports...) Why compromise when you don't need to - get the best possible system into production, and release it. But make sure moving up to the new system isn't a one-way trip - allow for using the old system when it's needed. >I have Mark Williams C, and am curious: What is the difference between >malloc() and Malloc() ???? I am writing a slideshow/picture viewing >program, and when I used malloc() to get a 32k block of memory for a >picture, the picture always had some stray data at the top (looked >suspiciously like the other variables I was using).. However, when I >used Malloc() this disappeared. Boy, I almost pulled my hair out >trying to figure out what was wrong!!! The MWC malloc() library routine uses MWC's own memory management setup. Since GEMDOS's Malloc call is potentially dangerous, and the danger increases as you approach 20 calls per program, the idea is to call the system memory allocator as few times as possible, and to handle the memory you *do* have to allocate by yourself. So the MWC library will typically start up with a "heap" of, say, 64K, that is parceled out to you whenever you use their malloc routine. If the heap is too small to satisfy your request, the library will call Malloc to add more memory to the heap. As for the stray data at the top, perhaps you're not aligning the screen memory correctly? And just as a side note... (Since I've spent the past couple of weeks getting my favorite programs, e.g. Uniterm, working with Overscan...) If you're writing code that you eventually hope for other people to use, don't hard-code magic numbers like 32K into your screen manipulation routines. [In fact, don't even use 32K. You only need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?] Also don't assume that when you're looking at the default screen, Physbase and Logbase will be identical. Retrieve and store them both, when you want to do page-flipping. While I'm up here on my soapbox... Here's some code to properly align your screen memory. It seems simple enough, but I've seen it done wrong too many times... [And hey, if you see that *I'm* doing it wrong, let me know, quick, 'cause this is how I've been doing it!!] In C: char *ptr, *malloc(); ptr=malloc(32256); /* for argument's sake */ (long)ptr+=255; (long)ptr&=0xffffff00; In asm I'd do something like (Malloc returns to d0...) clr.l d1 st.b d1 add.l d1,d0 sf.b d0 -- -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1] and You Too can have a Personal Electronic Relationship with God!
gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (01/17/90)
In article <16687@laurel.athertn.Atherton.COM> alex@Atherton.COM (Alex Leavens) writes: > [...] Another alternative >would be to use someone else's malloc() package; Dave Beckemeyer >has one on his BBS which you can tweak to the values you want. Probably the most widely distributed malloc() implementation would be the one in dLibs, which is a complete C library implementation distributed with source code. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
ajy2208%ritcv@cs.rit.edu (01/17/90)
In article <10665@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: [...informative stuff deleted...] > >As for the stray data at the top, perhaps you're not aligning the >screen memory correctly? This was a problem at first, as I am a beginning ST programmer and am not a registered developer (yet.. :-). Of course, the people who wrote the MWC documentation didn't bother mentioning the fact that the memory has to be ALIGNED.. But they provided a nice example, in which they aligned the memory, so that's how I learned.. >If you're writing code that you eventually hope for >other people to use, don't hard-code magic numbers like 32K into your >screen manipulation routines. [In fact, don't even use 32K. You only >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?] Kind of interesting, that the example in the MWC manual does have 32K hard wired in. Of course, it's only an example, but for someone learning how to do something for a first time, it's not setting a GOOD example.. sigh.. (at least it does have LOTS of examples).. Thanks! _____________________________________________________________________________ Albert Yarusso, Rochester ajy2208@ritvax.bitnet,ajy2208@ultb.isc.rit.edu Institute of Tech. _________________________________________________________ Computer Science /___ / {rutgers, ames}!rochester!ritcv!ajy2208 ______________________/ / ajy2208@ritcv.cs.rit.edu GEnie: A.Yarusso