rosenkra@hall.cray.com (Bill Rosenkranz) (12/13/88)
---- after disassembling a code i found on some bbs which doubles the effective on-screen travel of the mouse form, i found it ixecutes bios function 0x7F (which is not documented, at least in anything i have, including original developer's docs). i thought it might be the disasm but after compiling (with madmac) everything works fine. what is this puppy and what other undocumented treasures are worth knowing about? by the way, concerning monitor weirdness, my mono monitor sqeezes the far right side of the screen such that the last column of text looks about half as wide as is should. can this be easily adjusted or is a sign of (bad) things to come? -bill ...!rutgers!umn-cs!hall!boston!rosenkra ----
dlm@druhi.ATT.COM (Dan Moore) (12/15/88)
in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) says: > after disassembling a code i found on some bbs which doubles the effective > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F There isn't a bios function 0x7f. But it is a useful bios call if you intended to patch the bios handler on the ST. When the ST bios or xbios handler receives an illegal function number it returns an error code and a pointer to the bios/xbios function pointer table. I believe it returns the pointer in A0. You need this pointer if you are going to have your own code handle the bios/xbios traps. This is a trick Dave Small and I used in the MOUSE program in STart #2 or #3. MOUSE kept the mouse out of the menu bar unless you pressed the right button. Dan Moore AT&T Bell Labs Denver dlm@druhi.ATT.COM or dlm@druwy.ATT.COM
apratt@atari.UUCP (Allan Pratt) (12/15/88)
In article <12076@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: > [...] it executes bios function 0x7F [...] There is no such function. The only way it could usefully do anything with that BIOS call is if it installed a handler itself, or if it is probing for another installed handler which it knows about. (That is, if some other product installs a handler for BIOS call 0x7f, and this program knows how to use that other product.) It is a documented guarantee that if you make a BIOS or XBIOS call and there is no handler for that function number, the function number itself will be returned in D0.W. If there *is* a handler there, it is free to return whatever it wants, of course, but every attempt should be made *not* to return the function number in D0.W so you can tell that it's a handler, not an invalid function number. (If you never know what you'll be returning, there should be a special sub-function of your handler which is the "probe" call -- it should return a known value which is not the function number, just to prove it exists.) This guarantee holds true for all versions of ROM TOS: things turned out this way, as it's so useful we decided to document the fact. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ignac@electro.UUCP (Ignac Kolenko) (12/15/88)
In article <12076@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: > >by the way, concerning monitor weirdness, my mono monitor sqeezes the far >right side of the screen such that the last column of text looks about half as >wide as is should. can this be easily adjusted or is a sign of (bad) things >to come? > the exact same thing happened to my monochrome monitor and the mono monitor of a friend. all we did was open the monitor up, and adjust the trimpots which control the horizontal dimension of the screen (i can't remember the names of the pots offhand - i'd have to open up the monitor again to get the names - i think one is the horizontal width, and another is the centering control - it should be fairly obvious which pots control which aspects of the screen once the monitor is open) good luck -- Ignac A. Kolenko "Squeeze my lemon, let the juice run watmath!watcgl!electro!ignac down my leg!" - Led Zep (Lemon Song) "Ask me no further questions, I WILL NOT answer!!" - Spock (ST:TOS Amok Time)
apratt@atari.UUCP (Allan Pratt) (12/16/88)
In article <3767@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes: > in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) says: > > after disassembling a code i found on some bbs which doubles the effective > > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F > > There isn't a bios function 0x7f. But it is a useful bios call > if you intended to patch the bios handler on the ST. When the ST bios > or xbios handler receives an illegal function number it returns an error > code and a pointer to the bios/xbios function pointer table. Great! This is exactly the kind of "It works, so use it" philosophy which makes it so hard to improve TOS in a backward-compatible way. Please do not rely on crap like this in your programs. If you do, don't expect them to work in the future. Maybe I should make sure the hack described above stops working, but I'm not vindictive or petty, so I won't. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
rosenkra@hall.cray.com (Bill Rosenkranz) (12/17/88)
--- In article <1263@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: =In article <3767@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes: => in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) says: => > after disassembling a code i found on some bbs which doubles the effective => > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F => => There isn't a bios function 0x7f. But it is a useful bios call => if you intended to patch the bios handler on the ST. When the ST bios => or xbios handler receives an illegal function number it returns an error => code and a pointer to the bios/xbios function pointer table. = =Great! This is exactly the kind of "It works, so use it" philosophy =which makes it so hard to improve TOS in a backward-compatible way. =Please do not rely on crap like this in your programs. If you do, don't =expect them to work in the future. Maybe I should make sure the hack =described above stops working, but I'm not vindictive or petty, so I =won't. = lighten up, allan... i was not advocating its use nor do i even plan to use it in my own stuff i just wanted to know what was going on... i do, however, appreciate your frustration. i have just found out how relying on undocumented stuff is bad. on my 1040 i used to use GEMBOOT (i know, a BIG no-no). well, now with my mega4, gemboot does not work. only trouble is now i have to reboot the system every 1-2 hours of use because the unpatched os is so bad and tos 1.4 is not ready for release (i assumed all the memory mgmt/OSPool issues have _FINALLY_ been resolved?) with atari selling mostly all 1 MB or larger machines these days, i would expect THIS CRAP TO FINALLY GO AWAY. and what about stupid cp/m-era (64k or less) restriction on command line length? how about a Pexec2() fcn so we can get into the 90's already? allan, you've been one of the few good/positive things in the whole scheme of ST things please DONT get vindictive. just keep striving (as you have in the past) to improve things. i agree that undocumented thiings used are at the risk of the user. the free market should weed them out if end users have a problem. the REAL problem is there are very few end users who upgrade their ROMS (even if they could :^) that using weirdnes will more than likely never be a problem anyway. i know you are in the middle of the "they used an undocemented/illegal practice so screw them" and the "atari doesn't support its developers" dilema. don't bother flaming me, i have calmed down. you should, too. it's not worth an ulcer or heart attack... -bill ...!rutgers!umn-cs!hall!boston!rosenkra ---
dlm@druhi.ATT.COM (Dan Moore) (12/20/88)
in article <1263@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: > Great! This is exactly the kind of "It works, so use it" philosophy > which makes it so hard to improve TOS in a backward-compatible way. > Please do not rely on crap like this in your programs. If you do, don't > expect them to work in the future. Maybe I should make sure the hack > described above stops working, but I'm not vindictive or petty, so I > won't. It just thrills me to see Atari programmers saying they will break things just for fun. But they are never petty or vindictive. Of course the fact that this was done about 4 years ago, when no one at Atari would admit that people might need to patch bios/xbios code, doesn't matter. Or the fact that 2 years ago an Atari programmer said this was a useful feature and would be left in. Oh no, such ancient history is unimportant. What matters is that the current programmers don't like it. Try checking the background on things before you start complaining. There are a lot of things that happened before you started at Atari which you don't know about. Dan Moore AT&T Bell Labs Denver dlm@druhi.ATT.COM or dlm@druwy.ATT.COM
to_stdnet@stag.UUCP (12/20/88)
From: dynasoft!john@stag.UUCP (John Stanley) [apratt@atari.UUCP (Allan Pratt) writes...] > In article <12076@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: >> [...] it executes bios function 0x7F [...] > > There is no such function. The only way it could usefully do anything > with that BIOS call is if it installed a handler itself, or if it > is probing for another installed handler which it knows about. > (That is, if some other product installs a handler for BIOS call 0x7f, > and this program knows how to use that other product.) I'm suprised at you Allan... It has nothing to do with seperate installable handlers. Hint: It pays attention to shift keys.... --- [rosenkra@hall.cray.com (Bill Rosenkranz) writes...] > after disassembling a code i found on some bbs which doubles the effective > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F > (which is not documented, at least in anything i have, including original > developer's docs). i thought it might be the disasm but after compiling > (with madmac) everything works fine. what is this puppy and what other > undocumented treasures are worth knowing about? This is how one obtains a pointer to the bios (or xbios) jump tables. This is actualy a -totaly- unintended fallout case that just happens to occur because of the way the bios jump code is written... Pass it instructions to call any bios function that's not in the table, and it will, as part of its error checking, realise this and return. That the pointer to the bios table just happens to be in one of the registers on return is just a fortuitous side effect... The author probably adds $44 to the pointer and then saves the long it points to. This is a portable method for obtaining a pointer to the bios function that returns the keyboard shift status... The reason for doing this is to allow a program to test the kb status while inside an interrupt. (Something that can't be done by just calling the bios...) --- PS: Please(!) note that my Reply-To address gets munged by the gateway I'm currently using for news access so you can't just <r>eply to this article and have your message get to me. Please use the address below. --- John Stanley (dynasoft!john@stag.UUCP) Software Consultant / Dynasoft Systems
to_stdnet@stag.UUCP (12/20/88)
From: dynasoft!john@stag.UUCP (John Stanley) [dlm@druhi.ATT.COM (Dan Moore) writes...] > in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) says: >> after disassembling a code i found on some bbs which doubles the effective >> on-screen travel of the mouse form, i found it ixecutes bios function 0x7F > > There isn't a bios function 0x7f. But it is a useful bios call > if you intended to patch the bios handler on the ST. When the ST bios > or xbios handler receives an illegal function number it returns an error > code and a pointer to the bios/xbios function pointer table. I believe > it returns the pointer in A0. All correct up to this point... > You need this pointer if you are going to > have your own code handle the bios/xbios traps. Wrong! There are better methods for doing this... Using this method the way many people have been using it makes it impossible to use many other useful resident programs. Bypassing the bios vector chain just to install your own program is not necessary at-all(!) and definately isn't friendly to other programs that use the bios vector... > This is a trick Dave Small and I used in the MOUSE program in STart > #2 or #3. MOUSE kept the mouse out of the menu bar unless you pressed > the right button. I've seen the code for this program. While interesting, it isn't useable with Flash or any other program that uses the right mouse button for it's own purposes. Someone else took it and modified it to allow using the right button for other purposes, but it was still incompatable with many resident programs because it used a very bad installation method (bypasses the bios vector chain which means that -any- bios vector-using programs loaded before it was are no longer called after this program gets its hooks into the system). If anyone wants a copy of my own version of this program which works with everything including the mouse modifier prorams, feel free to drop me a note (PLEASE read the mail warning at the end of this msg first.). If there's enough interest my program, I'll post it to the comp.binaries atari.st newsgroup. Please don't get me wrong Dan... I have the highest regards for 99% of the software that you and Dave Small have written. I just don't want these TSR hostile methods to get out any further. There's already too much incompatable software out there... And from what I've seen, none of the incompatabilities are necessary. > Dan Moore -- PS: Please(!) note that my Reply-To address gets munged by the gateway I'm currently using for news access so you can't just <r>eply to this article and have your message get to me. Please use the address below. --- John Stanley (dynasoft!john@stag.UUCP) Software Consultant / Dynasoft Systems
rogers@ncrcce.StPaul.NCR.COM (Bob Rogers) (12/21/88)
In article <3774@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes: >in article <1263@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: >> Great! This is exactly the kind of "It works, so use it" philosophy >> which makes it so hard to improve TOS in a backward-compatible way. >> Please do not rely on crap like this in your programs. If you do, don't >> expect them to work in the future. Maybe I should make sure the hack >> described above stops working, but I'm not vindictive or petty, so I >> won't. Mr. Pratt seems to be complaining about programmers using TOS in an illegal way. Perhaps if Atari had ever bothered to publish good, widely available documentation his complaint would be valid. Given Atari's disinterest in documenting their machine I don't think Atari should complain too loudly when folks make mistakes. -- Bob Rogers rogers@stpaul.ncr.com or rogers@pnet51.cts.com NCR Comten, St. Paul, MN GEnie: R.C.ROGERS
apratt@atari.UUCP (Allan Pratt) (12/22/88)
In article <3774@druhi.ATT.COM> dlm writes: > in article <1263@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: > > Great! This is exactly the kind of "It works, so use it" philosophy... > It just thrills me to see Atari programmers saying they will > break things just for fun. But they are never petty or vindictive. > ... Or the fact that 2 years ago an Atari programmer > said this was a useful feature and would be left in. No, we're not petty or vindictive. What makes you think we are? I *didn't* say I would break things just for fun. It is more than possible that a future, seemingly-harmless change to the code in the trap handler will make the described hack stop working. This issue illustrates the thing which has hamstrung improvements to the OS from Day 1: whenever we talk of making something better, people complain that they were relying on the old, undocumented, bogus behavior. Want to know why I can't speed up Pexec? Because people rely on the entire heap, not just their declared BSS, being clear. Want to know why I can't get rid of Malloc limitations? Because people use memory they don't own, and also rely on multiple Malloc's returning contiguous memory. Who promised that this "feature" would be left in? I have been here more than 2 years, and I never heard about it. Worse, it was not commented in the code, which is the final arbiter of what has been promised. Blame whoever made that promise, not me. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
david@bdt.UUCP (David Beckemeyer) (12/22/88)
In article <1263@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >In article <3767@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes: >> There isn't a bios function 0x7f. But it is a useful bios call >> if you intended to patch the bios handler on the ST. When the ST bios >> or xbios handler receives an illegal function number it returns an error >> code and a pointer to the bios/xbios function pointer table. > >Great! This is exactly the kind of "It works, so use it" philosophy >which makes it so hard to improve TOS in a backward-compatible way. >Please do not rely on crap like this in your programs... I know Dan pretty well and I like him, but in this case I have to agree with Allan Pratt. The reason I'm posting a followup though is becuase this sort of "philosophy", as Allan calls it, also is part of the reason why "clean" BIOS trap handlers are dificult to implement too. In order to be compatible with these types of programs, the trap handler must implement all the documented functions as well as the undocumented "features" too. There are safe and legal ways to intercept BIOS traps that are TOS/ROM independent. So why do some people cheat? Sometimes the "legal" ways aren't as fast or as compact as the "cheating" ways, so programmers can be lured into these practices. Often the pressure comes from the Users who want it FAST FAST FAST and TINY TINY TINY. Then when the next TOS ROMS come out, everybody's bitching becuase their nifty programs don't work anymore. But in the long run breaking the rules is bad for everyone, and limits the potential for future success of the very machine we all love so much. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
saj@chinet.chi.il.us (Stephen Jacobs) (12/23/88)
In article <1268@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: [as part of the illegal BIOS call discussion] > Want to know why I can't speed up Pexec? Because people rely > on the entire heap, not just their declared BSS, being clear. Want to > know why I can't get rid of Malloc limitations? Because people use > memory they don't own, and also rely on multiple Malloc's returning > contiguous memory. > > Who promised that this "feature" would be left in? I have been here more > than 2 years, and I never heard about it. Worse, it was not commented > in the code, which is the final arbiter of what has been promised. > Blame whoever made that promise, not me. > > ============================================ > Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. > reflect those of Atari Corp. or anyone else. ...ames!atari!apratt I'll admit to being of the camp that tends to say that if an OS repair breaks the application, redo the application. However, it would seem fair to everyone to announce publicly and officially that un-documented features X, Y and Z have been found to interfere with desirable changes to TOS, and that any new OS releases after some given future date will defeat those hacks. Developers who are still in business will have decent notice to remove dependence on such features (as a courtesy, Atari might privately inform developers whose products are known to be at risk, without promising that they'll do so). Some orphan products will become useless to owners of new or upgraded machines, but that will just make more business for the remaining developers. Anyone dependent on an orphan product will probably have to forego the OS upgrade, but I personally think that anyone who stays dependant on an orphan product needs his head examined (and I don't mean disk drive).
david@bdt.UUCP (David Beckemeyer) (12/24/88)
In response to something Dan Moore said about illegal bios traps returning a pointer to the bios jump table, Alan Pratt said: >> Please do not rely on crap like this in your programs. If you do, don't >> expect them to work in the future. Maybe I should make sure the hack >> described above stops working, but I'm not vindictive or petty, so I >> won't. Then Bob Rogers said: >Mr. Pratt seems to be complaining about programmers using TOS in an illegal >way. Perhaps if Atari had ever bothered to publish good, widely available >documentation his complaint would be valid. Given Atari's disinterest in >documenting their machine I don't think Atari should complain too loudly >when folks make mistakes. You're both right. Allan is correct that un-documented features shouldn't be used, but Bob is also correct when he mentions that many "official" features are (or at least were) effectively un-documented. Dan Moore also makes a good point about how many times in the past someone at Atari has given mis-information, and now nobody there wants to take any responsibility for it. And then someone else discussed ways of informing developers before TOS updates are released about changes that may break certain un-documented features, saying: >Developers who are still in business will have decent notice to >remove dependence on such features (as a courtesy, Atari might privately >inform developers whose products are known to be at risk, without promising >that they'll do so). Some orphan products will become useless to owners of >new or upgraded machines, but that will just make more business for the >remaining developers. This brings us to the bigger problem that is really behind all this. First, Atari has yet to attract the big developer bucks. This means very few big-budget development efforts. Especially the early ST software, but it still applies today. When you are working on a budget, you can't always attract top-quality people and the end-result may have more "hacks" than desired. In addition, you can't devote a lot of time tracking down information from Atari, especially in those early days when it was almost impossible to get *any* information out of Atari (I really don't think anyone there knew much about the DRI stuff yet). The above applies to at least 90% of the Atari ST software projects. There just aren't that many experienced software professionals getting paid to develop Atari ST software. Atari doesn't want to take the blame for it and neither do the software developers. So we end up with the Atari ST vernacular made up of comments like "Developers who are still in business" and "orphan products". Without major investments by Atari, I don't see anything more than a TRS-80 type market in the future either (i.e. lot's of people that like the machine, but far outside the main-stream). -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
rosenkra@hall.cray.com (Bill Rosenkranz) (12/29/88)
--- since i'm the horrible fiend who started this mess by asking a very simple question (which dan politely answered), let me just ask allan this: ok, fine. there are programs that rely on the way things work, both documented and undocumented, probably more of the latter, eh? but why not just fix what is there (like Pexec/xmain forcing lower case args, tiny command line buffer of 255 char, etc) by offering a parallel development of "corrected" utilities? is rom real estate THAT tight? heck, i'd even load the sucker from disk every time i booted (if gem was fixed i would not have to reboot every 2 hours anyway). in my own programs, i never rely on undocumented features, though many are tempting. you should either sh*t or get off the pot. make your beloved changes that break half the software (which sells your machines) of live with it and adapt to the often pioneering efforts of us wcky developers. just don't throw a public tantrum, it makes both you and atari corp look bad (neither of which, incidently, i want to see). if corporate policies at atari are so bad, the machine does not deserve to survive. if, on the other hand, atari is REALLY interested in being the number 2 or 3 pc in the world, grow up and start acting like ibm rather than some undisciplined wimpering child. kick some ass. just make sure it's not some important developer's ass yer kicking :^). you may find yourself out in the cold... i just think this whole argument is a bunch of crap. since when has standards stood in the way of any (perceived) top-notch computer hardware/software company? besides, if atari fails, all this banter is just a lot of hot air anyway. who really cares? just EVOLVE. if that means ruffling some feathers, so be it... now lets get on with it. (BTW your own developers newsletter published several undocumented tidbits like houw to reset the desktop after a wind_set (...,WF_NEWDESK,...)...shall i tell them how, allan?). -bill rosenkra@hall.cray.com ---
walkerb@tramp.Colorado.EDU (Brian Walker) (12/30/88)
In article <12401@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: > >since i'm the horrible fiend who started this mess by asking a very simple >question (which dan politely answered), let me just ask allan this: ok, >fine. [...] >in my own programs, i never rely on undocumented >features, though many are tempting. you should either sh*t or get off the >pot. make your beloved changes that break half the software (which sells >your machines) of live with it and adapt to the often pioneering efforts >of us wcky developers. just don't throw a public tantrum, [...] > >if, on the other hand, atari is REALLY interested in being the >number 2 or 3 pc in the world, grow up and start acting like ibm rather >than some undisciplined wimpering child. kick some ass. [...] > >i just think this whole argument is a bunch of crap. since when has standards >stood in the way of any (perceived) top-notch computer hardware/software >company? besides, if atari fails, all this banter is just a lot of hot air >anyway. who really cares? just EVOLVE. if that means ruffling some feathers, >so be it... > It's nice to hear that some people follow the rules. This discussion of the ongoing confrontation between OS designers and devlopers is not new. It is also not restricted to Atari. Just ask Apple about this problem. I read in a recent issue of Byte Magazine (September, perhaps) about the Apples Multi Finder system. The article presented some of the enhancements added to the system to support their multitasking environment and it presented some of the fixes required to support all of the existing programs. In short, the folks at Apple were amazed at the number of programs that did not follow the rules. As a result, the curent version of Multi Finder includes many patches. A few of those patches were included for the benefit of a single program. This should not have been necessary. The abuses of Apple developers forced Multi Finder designers to make unnecessary compromises. Each compromise means that at least one efficient way of performing a given operation becomes blocked and the designer must choose a less efficient method. Now put yourself in Allan's place. You're in the middle of an ongoing process to develope an efficient operating system. Your team is playing with 196K of low level coding which must be tweaked for maximum efficiency. Then some bozo comes along and decides to use a short-cut. He's already told all of his friends about his latest trick so you must grudgingly accept even though you now have to accomodate that new feature. That bozo just created more work for you that was not necessary. Futhermore, your freedom has been restricted so now instead of that elegant solution you came up with, you have to gludge something together and make it work. Wouldn't you be a little upset? Brian Walker, University of Colorado at Boulder walkerb@tramp.colorado.edu or {ncar,nbires}!boulder!tramp!walkerb "If we imagine no worse of them than they of themselves, they may pass for excellent men."
peter@sugar.uu.net (Peter da Silva) (12/31/88)
[ discussion of the problems involved in upgrading system software and a comment that "even apple" has problems with badly-behaved programs ] Apple is a poor example. You might want to use AT&T and the various flavors of UNIX if you want to talk about big boys having compatibility problems. But even that's misleading, because now you're dealing with nearly 20 years of software changes, instead of 4 or 5. The Amiga system software is now into the fourth released revision with no major problems so far. A completely new file system with different-sized blocks has just been put in place, and there are still no problems. Two points to bear in mind. First, much of the enhancements that are causing the problems in other systems (multitasking, virtual environments, and so on) were built into the Amiga software to begin with. Second, there are areas documented (even to having include files) but marked "here there be tygers". Commodore has said, over and over again, that the WILL change the system and they WILL break things. They have also worked with developers who needed to do stuff they didn't support so their software would continue to work after it became supported. They have changed the system, and things have broken. But never very much, and the blame has always been on the developers. There are still plenty of old programs that do quite sophisticated things that run under the latest version of AmigaOS. Moral: Atari should say "the following programs are going to break in rev such-and-such of TOS. Other programs that make this, thato, or the other assumption will also break. We're giving you X months warning. These changes are necessary to fix the a, b, and c bugs and to add these enhancements...". Then DO it. Fix it. It's like going cold turkey, but at some point you just have to stop throwing good money after bad. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
to_stdnet@stag.UUCP (01/01/89)
From: ardvar!krs@stag.UUCP (Kent Schumacher) [walkerb@tramp.Colorado.EDU (Brian Walker) writes...] > [... lots o' stuff I agree with deleted ] > That bozo just created more work for > you that was not necessary. Futhermore, your freedom has been restricted so > now instead of that elegant solution you came up with, you have to gludge > something together and make it work. Wouldn't you be a little upset? Sure would. Here's my proposal - let Allan write the perfect OS and release it. Then let all of us that like to hack on the OS write patches to put it back into it's original broken state so that we can run the poorly written software. Everybody will be happy... I get to write fatslow - who wants to write foldr000 and zerofill? :^) - Kent Schumacher /* "A member of STdNET- */ krs@ardvar.UUCP /* The ST developers network */
david@bdt.UUCP (David Beckemeyer) (01/04/89)
In article <3186@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Moral: Atari should say "the following programs are going to break in rev >such-and-such of TOS. Other programs that make this, thato, or the other >assumption will also break. We're giving you X months warning. These changes >are necessary to fix the a, b, and c bugs and to add these enhancements...". Maybe in a perfect world they *should* do this, but in the real world there's no way in heck they *can* do it. It's a no win situation for Atari, so they have to take the "lose the least" option. Who's going to fix the broken programs? Not the developers who aren't in the ST business anymore. Maybe Atari? HA! Some of the programs that would break come in Atari Corp. boxes, yet I doubt if Atari would spend a single dime to fix any of them. Like someone else said, I always try to follow the rules. Even so, ROM changes can break stuff you didn't know was "TOS dependent". I solve this problem by letting registered users download free updates from our BBS. Many of the programs that would break however don't have anybody to fix them anymore and there isn't enough new developmewnt going on to replace all the programs with new software. And Atari can't afford to lose any of the ST applications since there is less and less new stuff coming out. It would cost Atari money to solve this problem, so you can bet that they will take the most inexpensive route which is to hack up TOS enough to get improvements without sacrificing too much compatibility. Not a bad choice really. This leaves the option of hoping a third party (somebody elses money) develops a better OS, or if there's enough growth in the future Atari could develop a real OS and make it an option, letting users know that it might break old software. It's business, you know. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
peter@sugar.uu.net (Peter da Silva) (01/05/89)
In article <470@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: > In article <3186@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >Moral: Atari should be [firm but fair about breaking stuff] > Maybe in a perfect world they *should* do this, but in the real world there's > no way in heck they *can* do it. It's a no win situation for Atari, so > they have to take the "lose the least" option. May I direct you to the following two articles (you can look them up yourself, or if enough people care I'll post). Why can Commodore do this but Atari can't? < From carolyn@cbmvax.UUCP Tue Jan 3 09:53:10 1989 < From: carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) < Path: sugar!texbell!killer!ames!mailrus!ulowell!cbmvax!carolyn < Newsgroups: comp.sys.amiga.tech < Subject: Unsupported Programming Practices < Keywords: warning unsupported < Message-ID: <5605@cbmvax.UUCP> < Date: 3 Jan 89 15:53:10 GMT < Reply-To: carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) < Organization: Commodore Technology, West Chester, PA < Lines: 70 < IMPORTANT ! < Official Warning to Rom-Jumpers, Structure-Hackers, and Others < ============================================================== < From Commodore Engineering, Commodore-Amiga, and C.A.T.S. < We who bring you the Amiga want to make it perfectly clear that < if you don't follow the rules, you WILL break. [rest of article deleted] < From daveh@cbmvax.UUCP Tue Jan 3 10:46:49 1989 < Path: sugar!texbell!killer!ames!mailrus!ulowell!cbmvax!daveh < From: daveh@cbmvax.UUCP (Dave Haynie) < Newsgroups: comp.sys.amiga.tech < Subject: Re: Unsupported Programming Practices < Message-ID: <5608@cbmvax.UUCP> < Date: 3 Jan 89 16:46:49 GMT < References: <5605@cbmvax.UUCP> < Organization: Commodore Technology, West Chester, PA < Lines: 35 [body of article deleted] Yes, Atari has to take the choice that loses the least. I agree 100%. I just don't agree with you what that choice is. To quote my buddy Karl, "system software must evolve, and if it does not evolve, it hastens the eventual demise of the system". At some point you have to make a clean break with the past, or you lose everything. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
david@bdt.UUCP (David Beckemeyer) (01/07/89)
In article <3212@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >May I direct you to the following two articles (you can look them up >yourself, or if enough people care I'll post). Why can Commodore do this >but Atari can't? [Rest deleted. By "this" he means upgrade the ROMS and break old programs] Exactly my point. Commodore can do it for the Amiga because they have enough support from enough developers who can upgrade their software. My point was that Atari won't do it because they can't afford to break applications that nobody will fix. I agree that they *should* do it so that those of us that *are* willing to fix anything that breaks don't have to live with the bugs/limitations. But I bet they won't do it until they can be sure of getting the broken stuff (that they care about) fixed. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
poole@forty2.UUCP (Simon Poole) (01/09/89)
[I know this is late, but the Swiss backbone always closes down over Christmas/New Year] In article <12210@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: >lighten up, allan... > >i was not advocating its use nor do i even plan to use it in my own stuff >i just wanted to know what was going on... > >i do, however, appreciate your frustration. i have just found out how >relying on undocumented stuff is bad. on my 1040 i used to use GEMBOOT >(i know, a BIG no-no). well, now with my mega4, gemboot does not work. You must have a really old version of GEMBOOT, newer versions (mine is surely nearly a year old) have a variable that you can set to the address of the internal free list, we've got various machines here with Mega Roms including a Mega ST 4 and they all have GEMBOOT installed. -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
ralph@cc.brunel.ac.uk (Ralph Mitchell) (01/10/89)
In article <470@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >In article <3186@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >>Moral: Atari should say "the following programs are going to break in rev >>such-and-such of TOS. Other programs that make this, thato, or the other >>assumption will also break. We're giving you X months warning. These changes >>are necessary to fix the a, b, and c bugs and to add these enhancements...". > >Maybe in a perfect world they *should* do this, but in the real world there's >no way in heck they *can* do it. It's a no win situation for Atari, so >they have to take the "lose the least" option. Just how do you suppose Atari are going to find out who has been making use of the bugs in TOS ?? How many suppliers can you name that have declared "Note: This program makes use of TOS bug such-and-so." ?? I think it unreasonable to expect ATARI to keep track of ALL 3rd party software and to find out which suppliers are using which bugs. If a supplier uses an un-documented "feature" of an operating system, he should issue a warning saying "this program is only known to work with OS version NNN dated dd/mm/yy", and/or offer updates when the program breaks. This already happens with IBM-PC software, where programs are marked as "DOS3.1-compatible" or "compatible with DOS3.0,3.1,3.2,3.3", etc. Of course, if the supplier has "ceased trading" there's not much you can do about it... Possible solution: Could Atari produce a ROM cartridge that would accept the current "buggy" ROMs when a user upgrades to the new TOS ?? That way you'd be able to switch back to the old TOS just by plugging in the cartridge. This presumes that a cartridge can over-ride the builtin ROM's, and also that it could be made bigger than 128K... Or perhaps the cartridge could just intercept certain system calls that contain the most popular "illegal" entries ?? Then the new ROMs could have a pair of vector tables, selectable by an option on the menu-bar. Ralph Mitchell -- From: Ralph Mitchell at Brunel University, Uxbridge, UB8, 3PH, UK JANET: ralph@uk.ac.brunel.cc ARPA: ralph%cc.brunel.ac.uk@cwi.nl UUCP: ...ukc!cc.brunel!ralph PHONE: +44 895 74000 x2561 "There's so many different worlds, so many different Suns" -- Dire Straits
ralph@laas.laas.fr (Ralph P. Sobek) (01/11/89)
In article <3186@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: | Moral: Atari should say "the following programs are going to break in rev | such-and-such of TOS. Other programs that make this, thato, or the other | assumption will also break. We're giving you X months warning. These changes | are necessary to fix the a, b, and c bugs and to add these enhancements...". | | Then DO it. Fix it. It's like going cold turkey, but at some point you just | have to stop throwing good money after bad. | -- I agree emphatically!! Yes, even if some of my nice PD programs that I've collected would crash. --ralph -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU
saj@chinet.chi.il.us (Stephen Jacobs) (01/12/89)
In article <527@Terra.cc.brunel.ac.uk>, ralph@cc.brunel.ac.uk (Ralph Mitchell) writes: > In article <470@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > >In article <3186@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >>Moral: Atari should say "the following programs are going to break in rev > >>such-and-such of TOS. Other programs that make this, thato, or the other > >>assumption will also break. We're giving you X months warning. These changes > >>are necessary to fix the a, b, and c bugs and to add these enhancements...". > > > >Maybe in a perfect world they *should* do this, but in the real world there's > >no way in heck they *can* do it. It's a no win situation for Atari, so > >they have to take the "lose the least" option. > > > Just how do you suppose Atari are going to find out who has been making use > of the bugs in TOS ?? How many suppliers can you name that have declared > "Note: This program makes use of TOS bug such-and-so." ?? > > I think it unreasonable to expect ATARI to keep track of ALL 3rd party > software and to find out which suppliers are using which bugs. If a [ some good stuff omitted] As one of the people who has suggested such a thing in public, I'd like to answer. Atari is pretty conscienscious about trying to keep a copy of any commercial program around (I hear this from developers). From the discussion of what was done BEFORE BETA TEST on the new ROMS, it appears that they are also rather conscienscious about testing. It's pretty clear that when a change breaks lots of software or at least one strategically important program, an effort is made to understand why. Therefore, Atari gets enough information to give warnings of the form 'We wanted to fix this problem, but too much software needs it the old way, so We're telling you now that it will change in the future'. In general, they even have enough information to tell the affected developers 'THIS means YOU'. The key problem is with important programs which are either totally unsupported (yes, often because Atari didn't help at the right time) or are from tiny shops which can't do fixes on an externally-imposed schedule. And I'd suggest that the cure for the problem is to improve Atari (How many official or semi-official vapor announcements have you heard in the last 6 months? Care to compare that with the prior year? Attaboy!) and to improve the ST. A better machine from a better company will attract developers.
peter@sugar.uu.net (Peter da Silva) (01/12/89)
In article <527@Terra.cc.brunel.ac.uk>, ralph@cc.brunel.ac.uk (Ralph Mitchell) writes: > In article <470@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > >In article <3186@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >>Moral: Atari should say "the following programs are going to break in rev > >>such-and-such of TOS. Other programs that make this, thato, or the other > >>assumption will also break. We're giving you X months warning. These changes > >>are necessary to fix the a, b, and c bugs and to add these enhancements...". > >Maybe in a perfect world they *should* do this, but in the real world there's > >no way in heck they *can* do it. It's a no win situation for Atari, so > >they have to take the "lose the least" option. > Just how do you suppose Atari are going to find out who has been making use > of the bugs in TOS ?? How many suppliers can you name that have declared > "Note: This program makes use of TOS bug such-and-so." ?? They can (1) test the programs under a kindler, gentler TOS; (2) ask the developers (using the reply card when they send out the developers kit with the new TOS in it); (3) ask developers who have been trying to fix the bugs on their own (David Beckmeyer, for example); (4) etc... Also, they do not need to catch all programs. They must know of some, at least, that they discovered while working on TOS 1.whatever. Nobody expects them to be perfect. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
rona@hpdml93.HP.COM (ron abramson) (01/13/89)
Stephen Jacobs writes: >As one of the people who has suggested such a thing in public, I'd like to >answer. Atari is pretty conscienscious about trying to keep a copy of any >commercial program around (I hear this from developers). From the discussion >of what was done BEFORE BETA TEST on the new ROMS, it appears that they are >also rather conscienscious about testing. It's pretty clear that when a >change breaks lots of software or at least one strategically important >program, an effort is made to understand why. Therefore, Atari gets enough I didn't know that Atari did that, but I'm glad to hear it. I for one, am more concerned about whether or not my favorite programs will run over whether I have the most well conceived OS ever designed. Oh sure, I'd like to see the bugs fixed and see a few things run faster. However, making >30% of applications break might not be worth it. I happen to think that one of the things that Atari has done well has been to come out with new products that were mostly compatible with the old stuff. Basically, we've only seen 2 basic designs (8-bit/16-bit) in the 10 years (more or less) that Atari has been selling computers. Many companies change their OS faster than (#include appropriate simile). Ron Abramson P.S. My opinions are my own! (I think)