rcs91900@zach.fit.edu ( Charles Stockman /ADVISOR-Clutterham) (01/04/91)
Last night, I was working on a small program and the guru visited me about six times in thirty minutes. In other words, I had to reboot my machine 6 times in 30 minutes !!!!! Could someone please : 1) give me advice on how to stop the guru 2) programs that stop the machine from guruing I have an Amiga 3000 and 1.3 includes and 2.0 Os I hope with the new Os: and the new machine that this can be changed because it makes programming on the amiga a hassle THANKS A LOT
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/04/91)
In <1776@winnie.fit.edu>, rcs91900@zach.fit.edu ( Charles Stockman /ADVISOR-Clutterham) writes: >Last night, I was working on a small program and the guru visited me >about six times in thirty minutes. In other words, I had to reboot >my machine 6 times in 30 minutes !!!!! > >Could someone please : > > 1) give me advice on how to stop the guru Write programs that don't cause GURUs. > 2) programs that stop the machine from guruing You want it to not GURU when it has scrambled its brain? Either something has caused drastic problems or it hasn't. If it has, you don't want to keep running, lest you be smitten by worse things that cessation of activity. If it has not, you of course do not want to chat with the GURU, but then he won't be there when all is well. >I have an Amiga 3000 and 1.3 includes and 2.0 Os If your machine is crashing a lot, and it is not your own code that is doing it, you should find out what _IS_ causing it. Find the conditions that cause problems. If it is a particular program, dump it, or replace it. If it is hardware, get it fixed. >I hope with the new Os: and the new machine that this can be changed because it >makes programming on the amiga a hassle A new OS will not protect you from errors in your code, or ill-behaved programs, or hardware failures. Investigate; do some digging. -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
ben@epmooch.UUCP (Rev. Ben A. Mesander) (01/04/91)
>In article <7463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >> Does anyone know how to FORCE a guru through C? > > char *p; > > for(p = 0; p != (char *)-1; p++) > *p = 0; > >This will certainly clobber the machine. Play with variations until you get >the results you want. (sigh) >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Gee, Peter, that's a lot cleaner than using the exec Alert() function... -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
dave@cs.arizona.edu (Dave P. Schaumann) (01/05/91)
References: <2468@lpami.wimsey.bc.ca> Organization: U of Arizona CS Dept, Tucson In article <2468@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: !In <1776@winnie.fit.edu>, rcs91900@zach.fit.edu ( Charles Stockman /ADVISOR-Clutterham) writes: !![ He's a new user knocking his head against the guru ] ! !Write programs that don't cause GURUs. ! !! [...] ! !You want it to not GURU when it has scrambled its brain? Either something has !caused drastic problems or it hasn't. If it has, you don't want to keep running, !lest you be smitten by worse things that cessation of activity. If it has not, !you of course do not want to chat with the GURU, but then he won't be there !when all is well. ! !hardware, get it fixed. ! !!I hope with the new Os: and the new machine that this can be changed because it !!makes programming on the amiga a hassle ! !A new OS will not protect you from errors in your code, or ill-behaved !programs, or hardware failures. Investigate; do some digging. ! Those are some rather flip answers to what, IMHO, is the Amiga's greatest shortcoming: any program can crash the whole system quite easily. To my mind, this is unacceptable in a multitasking machine. I believe that CBM has got away with it up til now because no-one else even had multitasking. This is now changing. When IBM, Apple, NeXT, and Atari all have multitasking machines out there, it's going to be a different market place. Who wants a computer when one unstable program makes the whole platform unstable? There is a solution to this. It's called virtual memory. It takes an MMU, which is not available to the 68000. However, the 68030 has one. I think this is something CBM should be seriously considering putting into their next major release of Workbench. Please tell me that at least Amiga Unix has virtual memory... !The best way to accelerate an MsDos machine is at 32 ft/sec/sec. !+-----------------------------------------------------------------------+ !| // Larry Phillips | !| \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | !| COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | !+-----------------------------------------------------------------------+ Dave Schaumann | My folks went to uunet.uu.net, but all dave@cs.arizona.edu | they got me was this lousy .sig...
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (01/05/91)
>>>>> In article <611@caslon.cs.arizona.edu>, >>>>> dave@cs.arizona.edu (Dave P. Schaumann) writes: Dave> [...] Dave> There is a solution to this. It's called virtual memory. It takes an MMU, Dave> which is not available to the 68000. However, the 68030 has one. I think this Dave> is something CBM should be seriously considering putting into their next major Dave> release of Workbench. Virtual memory does not provide protection between processes. Virtual memory provides a transparent way to address more memory than a machine really has. Memory mapping and memory protection mechanisms (which are also provided by an MMU) provide the protection you are referring to. In addition, putting memory protection into AmigaDos is not as easy as you imply. It will break the vast majority of existing Amiga programs. All interprocess communication in the Amiga is done using shared memory techniques. Guidelines for writing programs in a manner upwardly compatible with future memory protection mechanisms have not existed for a long time, and have not been religiously followed in any case. Almost every "hot" game written for the Amiga would fail to work, since they almost all go right to the hardware, which would be disallowed in a protected AmigaDos. In summary, I agree that it is true that memory protection is something which the Amiga needs, but it is not that easy to achieve (due to the initial design decisions made in creating AmigaDos (or Exec, if you prefer)) and in most cases, judicious selection of the programs you run in your system should keep you out of trouble most of the time. If a program GURUs your machine, throw it away! Hamish. -- -------------------------------------------------------------------- himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/05/91)
Larry Phillips says about preventing GURU visits: >> A new OS will not protect you from errors in your code, or ill-behaved >> programs, or hardware failures. Investigate; do some digging. Dave Schaumann replies: > Those are some rather flip answers to what, IMHO, is the Amiga's greatest > shortcoming: any program can crash the whole system quite easily. Umm. But they were correct answers for the _real world_ case: the current Amiga OS/hardware configuration. Blue-skying begs the question. > To my mind, this is unacceptable in a multitasking machine. > I believe that CBM has got away with it up til now because no-one > else even had multitasking. [...] Who wants a computer when > one unstable program makes the whole platform unstable? There are three main scenarios for multitasking machines: 1. Used by developer only 2. Used by end user only 3. Used by both developer and enduser In (1), crashing is a pain, but not "unacceptable". In (3), crashing would be unacceptable...on a multiuser system... but since almost all Amigas are **single-user** systems, the offending programmer is also the enduser and should surely recognize when he's about to try something dangerous ;-). That leaves (2), and the culling out of unstable programs renders a totally stable enduser system... it's as simple as that. So in return, here's _my_ own beefs <g>: First, the unspeakable horror of today's CS majors who rely on hardware to catch their mistakes. Second, the unrealistic expectation that inexpensive personal computers should have all the bells and whistles of the expensive "machines I use at school". Now I'll backtrack -- Yes, hardware protection is A Good Thing (so go buy a $99 Tandy CoCo-3... it's got an MMU :). And I'd be terribly surprised if Amiga Unix doesn't use it. Further, I think you're right that _eventually_ all personals will have and use an MMU. But I also think it's gonna take some radical changes to most current personal OS's to add that capability. Or rather, it would break most current programs. best - Kevin <kdarling@catt.ncsu.edu> <76703.4227@compuserve.com>
rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (01/05/91)
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >In addition, putting memory protection into AmigaDos is not as easy as >you imply. It will break the vast majority of existing Amiga >programs. All interprocess communication in the Amiga is done using >shared memory techniques. Guidelines for writing programs in a manner >upwardly compatible with future memory protection mechanisms have not >existed for a long time, and have not been religiously followed in any >case. One Think that I have alaways wondered: is is practical implement memory protection from one task? Ie can the MMU be used to insure that task X doesn't stomp on any memory that it has not allocated? This ability would be extreemly useful for developement (even if it required linking in special code to do resource tacking so that the task could be shut down). After all it's VERY annonying to have to reboot all the time while testing a program as apposed to getting a segmentation fault message. While this is certainly NOT an answer to stopping guru visits under normal amigaDOS operation, it would be very helpful for debugging. Anyone care to comment on the practicality of this idea? // Rick Golembiewski rg20+@andrew.cmu.edu \\ \\ #include stddisclaimer.h // \\ "I never respected a man who could spell" // \\ -M. Twain //
jph@ais.org (Joseph Hillenburg) (01/05/91)
Does anyone know how to FORCE a guru through C? What includes, etc, and
maybe a ForceGuru() call? I have a program where if you enter an incorrect
response, it is supposed to guru. Does anyone have a sure-fire routine?
--
Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
iuvax!news!valnet!joseph jph@ais.org anlhille@iubacs.BITNET
"Only Apple could slow down a 68030 chip" --Computer Shopperjesup@cbmvax.commodore.com (Randell Jesup) (01/05/91)
In article <1991Jan4.224833.24914@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > Larry Phillips says about preventing GURU visits: >>> A new OS will not protect you from errors in your code, or ill-behaved >>> programs, or hardware failures. Investigate; do some digging. > > Dave Schaumann replies: >> Those are some rather flip answers to what, IMHO, is the Amiga's greatest >> shortcoming: any program can crash the whole system quite easily. > >Umm. But they were correct answers for the _real world_ case: the current >Amiga OS/hardware configuration. Blue-skying begs the question. Correct. First of all, 80-90% of all Amigas do not have an MMU, and aren't likely too (though maybe eventually - nowhere near soon - low-end machines may have MMUs). Also, using protected-process-techniques for inter-process communication would slow down the OS a lot (unacceptably so on a 68000 machine). They add a lot of overhead, and add it even when there's no MMU in the system. Witness the Bill Gates comments that multitasking will require 4Meg, a 386, and your first-born son. >There are three main scenarios for multitasking machines: > 1. Used by developer only > 2. Used by end user only > 3. Used by both developer and enduser > >In (1), crashing is a pain, but not "unacceptable". In (3), crashing >would be unacceptable...on a multiuser system... but since almost all Amigas >are **single-user** systems, the offending programmer is also the enduser >and should surely recognize when he's about to try something dangerous ;-). Amigas also boot about 10-100 times faster than most Unix boxes. If you care and are a developer, test programs on a second machine - they're cheap, and it helps to have a base configuration around to test on. (Since most developers are running '030's with lots of mem and HD nowadays). Personally, I usually test stuff on my development machine. We have enough debugging utilities (such as enforcer) that I rarely have to reboot (though installing a dead Dos will force it... ;-) >That leaves (2), and the culling out of unstable programs renders a totally >stable enduser system... it's as simple as that. And Commodore has been working HARD to provide developers with utilities to make code bug-free when shipped. Enforcer, Mungwall (aka MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration (those last two from Bill Hawes), angel (traps free mem references with the MMU), etc, etc. If something passes all of these, it's damn safe. How many Unix programmers do you know who ever tested their memory allocation failure paths (or other uncommon failure paths)? With memoration, it's easy (and we're using it to check all the failure paths in the ROMs for 2.0x). The combination of Mungwall and Angel (or enforcer) should cover almost all problems related to the fact that it's shared-memory OS. >So in return, here's _my_ own beefs <g>: First, the unspeakable horror >of today's CS majors who rely on hardware to catch their mistakes. Second, >the unrealistic expectation that inexpensive personal computers should have >all the bells and whistles of the expensive "machines I use at school". In an A500, true. An A3000 does have them, which is why it also makes a good Unix platform, or a _really_ fast AmigaDos platform. >a $99 Tandy CoCo-3... it's got an MMU :). And I'd be terribly surprised if >Amiga Unix doesn't use it. Further, I think you're right that _eventually_ >all personals will have and use an MMU. But I also think it's gonna take >some radical changes to most current personal OS's to add that capability. >Or rather, it would break most current programs. MMU's (at least for modern processors) aren't cheap, and '030's aren't cheap enough to put in A500's. They will be, one day, but not soon. Oh, and of course Amiga Unix uses the MMU (Unix effectively requires it, along with massive amounts of memory and HD and CPU power - at least compared to AmigaDos). AmigaDos isn't likely to support protection any time soon - it's not designed for it, and attempting to add it would break almost any program that uses anything more complex than Dos functions (tty-style). This may be a (very slight) exaggeration, but it's mostly true. VM is far easier. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <2468@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > A new OS will not protect you from errors in your code, or ill-behaved > programs[.] Well, *a* new O/S may... for example, Amiga UNIX will protect you very nicely from ill-behaved programs. What you mean to say is that AmigaOS 2.0 won't. This protection isn't free, by the way. Compare real-time performance of UNIX with AmigaOS. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <611@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: > Those are some rather flip answers to what, IMHO, is the Amiga's greatest > shortcoming: any program can crash the whole system quite easily. To my mind, > this is unacceptable in a multitasking machine. But the same is true for the multitasking offerings from Apple, IBM, and other PC manufacturers. Rather than CBM having "got away with it up til now", it's gotten an undeserved bad reputation. Now that other PC manufacturers are starting to offer multitasking without protected memory perhaps that will change. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: > Does anyone know how to FORCE a guru through C? char *p; for(p = 0; p != (char *)-1; p++) *p = 0; This will certainly clobber the machine. Play with variations until you get the results you want. (sigh) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > And Commodore has been working HARD to provide developers with > utilities to make code bug-free when shipped. Enforcer, Mungwall (aka > MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration > (those last two from Bill Hawes), angel (traps free mem references with the > MMU), etc, etc. Um, where do you *get* these. I'm a developer, I have the Autodocs, and I have Enforcer (it came unannounced on an update disk), but I've never heard of the majority of these programs. What should I be ordering? Please answer in the newsfroup... I suspect I'm not the only one. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
Sylvain@Speedy.CAM.ORG (Sylvain Tremblay) (01/06/91)
>In article <1776@winnie.fit.edu> rcs91900@zach.fit.edu ( Charles Stockman /ADVISOR-Clutterham) writes: >Last night, I was working on a small program and the guru visited me >about six times in thirty minutes. In other words, I had to reboot >my machine 6 times in 30 minutes !!!!! > >Could someone please : > > 1) give me advice on how to stop the guru > > 2) programs that stop the machine from guruing > >I have an Amiga 3000 and 1.3 includes and 2.0 Os > >I hope with the new Os: and the new machine that this can be changed because it >makes programming on the amiga a hassle > >THANKS A LOT Buy GOMF 3.0 (GOMF stands for Go Out Of My Face! :-) It doesn't stop every crash (when the Amiga HAS to freeze, it freezes) but most of them, particularely "software error - task held". -- Sylvain __ +-----------------------------------------------------------------///------+ | Sylvain Tremblay INTERNET: Sylvain@Speedy.CAM.ORG __ /// /| | | Montreal, Qc, Canada CIS: 71640,666 \\\/// # | | | (514) 256-2311 or: 71640.666@compuserve.com \XX/ _|_ | +--------------------------------------------------------------------------+
BAXTER_A@wehi.dn.mu.oz (01/06/91)
In article <V2H++Q_@irie.ais.org>, jph@ais.org (Joseph Hillenburg) writes: > Does anyone know how to FORCE a guru through C? What includes, etc, and > maybe a ForceGuru() call? I have a program where if you enter an incorrect > response, it is supposed to guru. Does anyone have a sure-fire routine? > BLOODY HELL!!!!!!! What's wrong with a nice little requester saying: "Oh, you naughty boy! You entered the incorrect response!" ----------------- ---------------- | Oh I am silly | | I'm so dumb | ----------------- ---------------- Why the hell do you have to crash the machine?? Regards Alan
jprad@faatcrl.UUCP (Jack Radigan) (01/06/91)
jph@ais.org (Joseph Hillenburg) writes: >Does anyone know how to FORCE a guru through C? What includes, etc, and >maybe a ForceGuru() call? I have a program where if you enter an incorrect >response, it is supposed to guru. Does anyone have a sure-fire routine? Depends *which* guru you want. Divide a number by zero and you'll generate a #5 guru. Reference an odd address with a 68000 Amiga and you'll also do it. -jack-
dailey@frith.uucp (Chris Dailey) (01/06/91)
In article <1991Jan4.203339.8800@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >>>>>> In article <611@caslon.cs.arizona.edu>, >>>>>> dave@cs.arizona.edu (Dave P. Schaumann) writes: > >Dave> [...] >Dave> There is a solution to this. It's called virtual memory. It takes an MMU, >Dave> which is not available to the 68000. However, the 68030 has one. I think this >Dave> is something CBM should be seriously considering putting into their next major >Dave> release of Workbench. I think there is a bright young PhD student trying to get his degree by putting VM into the AmigaOS. This does not, however, imply memory protection. See below. >Virtual memory does not provide protection between processes. Virtual >memory provides a transparent way to address more memory than a >machine really has. Memory mapping and memory protection mechanisms >(which are also provided by an MMU) provide the protection you are >referring to. > >In addition, putting memory protection into AmigaDos is not as easy as >you imply. It will break the vast majority of existing Amiga ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >programs. All interprocess communication in the Amiga is done using ^^^^^^^^ >shared memory techniques. [...] >Almost every "hot" game written for the Amiga would fail to work, >since they almost all go right to the hardware, which would be >disallowed in a protected AmigaDos. I don't care much about existing programs. If the Amiga could provide a more stable development environment, so we know that, when the equivalent of Unix's reference through NULL pointer or the many other things that cause a reboot on the Amiga as is, does not mean that the machine needs to be rebooted. This would speed up development and allow programmers to write more correct programs that will make everybody's lives easier. I know if the SunOS machines that our schools had to be rebooted every time one of these problems happened (instead of the usual core dump or whatever) noone would finish programs in time! >In summary, I agree that it is true that memory protection is >something which the Amiga needs, but it is not that easy to achieve Even fake memory protection would due for many of us. How about a command like "run such and such a program so it doesn't touch anything other than the OS". It gets its own space, tucked away from the rest of the system? >(due to the initial design decisions made in creating AmigaDos (or >Exec, if you prefer)) and in most cases, judicious selection of the >programs you run in your system should keep you out of trouble most of >the time. If a program GURUs your machine, throw it away! It's not just running programs, it's developing! Native development is where it's at right now, and if that is made more difficult on the Amiga then people will be more likely to develop for some other machine, and maybe port it over to the Amiga some other time. I don't mean to sound like a downer. I'm sure Commodore would love to see this sort of thing implemented, too. It's a definite minus, but it won't keep me from buying an A3000 later this year. (A war in the Persian Gulf might, but this wouldn't.) >Hamish. >-- >-------------------------------------------------------------------- >himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; __ __ ___ DDR = NULL; \\__/ \/ \/ __:>- num_countries --; \__/\__/\__/ Snake in the Grass
mt87692@tut.fi (Mikko Tsokkinen) (01/06/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: > Does anyone know how to FORCE a guru through C? What includes, etc, and > maybe a ForceGuru() call? I have a program where if you enter an incorrect > response, it is supposed to guru. Does anyone have a sure-fire routine? Yes! Make a short assembler program: Crash: illegal end And call Crash when you want to crash your Amiga. Only use for this I can imagine is if you are making a guru-killer program (like GOMF or GURU). MIT -- Bubble Bobble
chanson@isis.cs.du.edu (Chris Hanson) (01/06/91)
In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Correct. First of all, 80-90% of all Amigas do not have an MMU, and >aren't likely too (though maybe eventually - nowhere near soon - low-end >machines may have MMUs). Also, using protected-process-techniques for >inter-process communication would slow down the OS a lot (unacceptably so >on a 68000 machine). They add a lot of overhead, and add it even when there's >no MMU in the system. Witness the Bill Gates comments that multitasking will >require 4Meg, a 386, and your first-born son. Couldn't you just make all inter-process communication be done using MEMF_PUBLIC memory? As it was supposed to be? Since most people didn't do this, Maybe make all the Message functions automagically force the exchanged memory to be MEMF_PUBLIC temporarily. It'd be a pain, and a megakludge, but it might work. As for Bill Gates: Did anyone else notice the InfoWorld Christmas-list column, wherein they suggested that he wants a Video Toaster for Christmas, to produce his next "IBM/Microsoft invented/is-leading-the-market-in multimedia" video? > AmigaDos isn't likely to support protection any time soon - it's not >designed for it, and attempting to add it would break almost any program that >uses anything more complex than Dos functions (tty-style). This may be a >(very slight) exaggeration, but it's mostly true. VM is far easier. Agreed, adding protection might break large quantities of stuff. How about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS, which tells you intimate info about the program that LoadSeg is bringing in. You could have a flag to signify "I'm a nice program and I work well under memory protection, so protect me if you can". This would also be an excellent place to finally settle the PURE code problem. Make a hunk flag that signifies, regardless of what the FS bit says, "This code is pure, damnit." ;) >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Chris - Xenon -- #define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane I work, but you don't know who I work for. And they don't know I'm here. "We apologize for the inconveniences." -GOD. (According to D. Adams)
jesup@cbmvax.commodore.com (Randell Jesup) (01/06/91)
In article <7465@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> And Commodore has been working HARD to provide developers with >> utilities to make code bug-free when shipped. Enforcer, Mungwall (aka >> MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration >> (those last two from Bill Hawes), angel (traps free mem references with the >> MMU), etc, etc. > >Um, where do you *get* these. I'm a developer, I have the Autodocs, and I have >Enforcer (it came unannounced on an update disk), but I've never heard of the >majority of these programs. What should I be ordering? Enforcer is available both on the kickfile disks, and on BIX and perhaps other networks for downloading. Scratchr and memoration are definitely on BIX, and io_torture almost certainly is (and/or some devcon disk), as is MungWall (a combination of MemMung and a "wall" test around allocations to catch things like strcpy(AllocMem(strlen(str)),str)). Most of the rest are things from the software toolkit, either old or revised (though I don't know when the revised Toolkit will be available - check with CATS). I don't know what the story with angel is - it did have a few problems, and _really_ eats the CPU alive. Remember, we do official developer support on BIX, not anywhere else - our messages here are unofficial and on a personal basis. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (01/06/91)
In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes: >I think there is a bright young PhD student trying to get his degree by >putting VM into the AmigaOS. This does not, however, imply memory >protection. See below. Hmmm. BTW, it's been done once already by a student in Canada (not that something having been done before is a disqualification, especially if exactly what is done or attempted is different). >I don't care much about existing programs. If the Amiga could provide >a more stable development environment, so we know that, when the >equivalent of Unix's reference through NULL pointer or the many other >things that cause a reboot on the Amiga as is, does not mean that the >machine needs to be rebooted. This would speed up development and allow >programmers to write more correct programs that will make everybody's >lives easier. I know if the SunOS machines that our schools had to be >rebooted every time one of these problems happened (instead of the usual >core dump or whatever) noone would finish programs in time! A one word answer: enforcer. It traps out all reads to the lowest 1K of memory (except location 4, of course) and all writes to that area. Things that use NULL (or funny) pointers don't trash the system (at least in that way - if they're confused enough, they may trash something like the free memory list). BTW, since my amiga boots in about 15 seconds, it bothers me much less than rebooting a sun would (5-10 minutes, a few more to get set up). >Even fake memory protection would due for many of us. How about a >command like "run such and such a program so it doesn't touch anything >other than the OS". It gets its own space, tucked away from the rest of >the system? The problem is defining "it's own space". What is part of the OS, and what is part of an App? What if an "application" (let's say Mount) allocates a data structure and adds it to a system list? >It's not just running programs, it's developing! Native development is >where it's at right now, and if that is made more difficult on the Amiga >then people will be more likely to develop for some other machine, and >maybe port it over to the Amiga some other time. Ever notice what happens on a Mac or pcclone when you run a program you're developing? If it's bad, you almost always have to reboot. Actually, AmigaDos does a better job of trapping errors (the infamous "software error" requester) - PC's usually just lock up, and Macs either lock up or put up the "bombs" - almost as bad. With the amiga, if the program didn't trash the system, your other processes continue to work, and you can muck around in a debugger to figure out what went wrong. If I know why something died (i.e. that it wouldn't have trashed anything it didn't own), or am fairly certain, I may continue to use the system for a short while before rebooting (part of the purpose for the "suspend" option under 2.0). For example, if something I wrote dies with divide by zero because of a missing check, I'll add the check and recompile without rebooting. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (01/06/91)
In article <1991Jan5.213642.16547@isis.cs.du.edu> chanson@isis.UUCP (Chris Hanson) writes: > Couldn't you just make all inter-process communication be done using >MEMF_PUBLIC memory? As it was supposed to be? Since most people didn't do >this, Maybe make all the Message functions automagically force the >exchanged memory to be MEMF_PUBLIC temporarily. It'd be a pain, and a >megakludge, but it might work. Won't work. A message usually has pointers to other areas of arbitrary memory, or has an extended structure (ala StandardPacket), etc, etc. As has been discussed before, MEMF_PUBLIC can't be used since each person has had a different idea as to what should be public and what shouldn't. > As for Bill Gates: Did anyone else notice the InfoWorld Christmas-list >column, wherein they suggested that he wants a Video Toaster for Christmas, >to produce his next "IBM/Microsoft invented/is-leading-the-market-in >multimedia" video? :-) > Agreed, adding protection might break large quantities of stuff. How >about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS, >which tells you intimate info about the program that LoadSeg is bringing in. >You could have a flag to signify "I'm a nice program and I work well under >memory protection, so protect me if you can". This would also be an >excellent place to finally settle the PURE code problem. Make a hunk flag >that signifies, regardless of what the FS bit says, "This code is pure, >damnit." ;) A better idea. You _could_ allow segments of code from a loadfile to be protected (at least without many problems), and you could allow applications to request protected memory. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
hill@evax.arl.utexas.edu (Adam Hill) (01/06/91)
In article <7465@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> And Commodore has been working HARD to provide developers with >> utilities to make code bug-free when shipped. Enforcer, Mungwall (aka >> MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration >> (those last two from Bill Hawes), angel (traps free mem references with the >> MMU), etc, etc. > >Um, where do you *get* these. I'm a developer, I have the Autodocs, and I have >Enforcer (it came unannounced on an update disk), but I've never heard of the >Please answer in the newsfroup... I suspect I'm not the only one. >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. I have uploaded Enforcer, MemWall, and Memoration to ab20.larc.nasa.gov in a archive called DebugUtils.lzh. It is in incoming/amiga/UTILS. Those were the only utilities available on BIX in the amiga.dev section. It would be nice if CBM would release the rest of them as well (esp. IO_Torture.. It does nasty things to the serial.device B-) ). Perhaps a Fish disk.... Or even better, since CBM now has UNIX boxes galore.. Give is a read only FTP site. CBM could release debug utils and WB upgrades via that mechanism. This might even be an alternative to BIX support. Well... What does everybody think?? -- adam hill hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA! Amiga... Multimedia NOW Most Common Phrase at DevCon '90 - "Shhhhhhh.."
x194@cs.utexas.edu (Jonathan Abbey) (01/06/91)
The best thing to do to guard yourself from GURU's during software development is to use a debugger to run your code. There is one available on a relatively recent fred fish disk which will suffice to debug software that doesn't take over the display in some fashion. Even then you could patch it to open aux: instead of a con: window, and hook it up to a terminal. In either case, you can have the debugger run the code in 68000 trace mode so that any guru inspiring phenomena will just return to the debugger rather than bring the system down. This won't catch all possible errors, though.. you can still feed a system function bad information, as well as overwrite system structures. Has anyone written a debugger that will try to watch out for your code a bit? That is, that will monitor the PC during a trace and let you specify various behaviors if your task goes outside of a certain set of memory regions? ------------------------------------------------------------------------------- Jonathan Abbey The University of Texas at Austin x194@cs.utexas.edu Computer Science-Math?-Psychology? --
rjc@wookumz.ai.mit.edu (Ray Cromwell) (01/06/91)
On a side note Randell, how difficult would it be to add Resource
Tracking to the Amiga? Couldn't each library's close routine make
sure all resources are freed when a Task exits? I get really tired when
poor programs forget to free a Lock() or Memory. (XOper to the rescue)
It would also be nice to 'kill' a process and have it automaticly free itself.
Consider this:
'KILL HandShake'
Dos.Library's KillProcess() call does a sanity check, then proceeds
to close all the libraries said process had open. (I assume OpenLibrary
maintains a list and attacks it to the task) Each of the libraries/devices
free the resources from their close() routines. Poof! HandShake is
UnLoadSeg'd and all its resources have been cleaned up by the libraries
themselves.
Virtual Memory shouldn't be a problem either. The OS merely checks for
the presence of an MMU and enables virtual mem (for FAST mem. Its impossible
to protect Chip mem from the blitter. And I can't imagine a machine
with an MMU that doesn't have fast ram)
MMU Protection. I'm fairly certain AmyDOS will never get Unix style
protection because of the shared-memory paradigm. But how about this
. AllocMem(blah,MEMF_PRIVATE) Programs could request private
memory for their data structures and use Allocate/DeAllocate to
manage it. This would cut down on programs stomping on valuable data, so
a GURU could atleast exit with a warning 'Please save all data, then reboot'
I have no problems with Software Error requesters. I like them. I can save
my data/finish a download, then reboot. Or if developing, suspend the
task, recompile, and try again. GURUs aren't so forgiving. They
offer only 1 choice. Reboot immediately.
Also. Alot of errors aren't fatal (Like FreeMem twice, etc) its the
0003/4 errors you have to watch out for (meaning a task when wild
stomping thru memory) I think FreeMemtwice type of errors should put
up a warning ('Task A went nutso, data may be corrupt, Wanna Reboot?')
Three more questions.
1) Has layers library been speeded up/reworked? It gets really slow
when there are lots of open windows on the screen.
2) What happens when you pull down a screen (on 2.0) and a productivety
mode screen is behind it? Can monitors actually handle scan rate changes
mid screen? (15khz <-> 31khz)
3) Was file notification/record locking ever added to the 2.0 FS?
Thanks in Advance. (I don't have 2.0)dave@cs.arizona.edu (Dave P. Schaumann) (01/06/91)
In article <133@atacama.cs.utexas.edu> x194@cs.utexas.edu (Jonathan Abbey) writes: >[...] >Even then you could patch it to open aux: >instead of a con: window, and hook it up to a terminal. How would you do this? I have heard about being able to hook up a terminal to help debug gurus, but I've never seen any documentation on How To Do It. What kind of a terminal do you need? Any & all pointers would be appreciated! >Jonathan Abbey The University of Texas at Austin >x194@cs.utexas.edu Computer Science-Math?-Psychology? Dave Schaumann | My folks went to uunet.uu.net, but all dave@cs.arizona.edu | they got me was this lousy .sig...
U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (01/06/91)
G'day, RJ> Randell Jesup (jesup@cbmvax.commodore.com ) writes: First of all, thanks Randell for your private time and efforts you put into helping out in things Amiga in this group. CH> Chris Hanson (chanson@isis.UUCP) writes: [...] CH> Agreed, adding protection might break large quantities of stuff. How CH> about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS, CH> which tells you intimate info about the program that LoadSeg is bringing in. CH> [...] RJ> A better idea. You _could_ allow segments of code from a loadfile RJ> to be protected (at least without many problems), and you could allow RJ> applications to request protected memory. Randell, can the parts of the Amiga OS themselves request protected memory? {That is in some scenario where it is available.} This is a simple question really and I presume the answer is simple also. I am asking because I have forgotten the details regarding the attributes RAM required by the OS must have. {I wish I had the RTMs.} Btw would someone run by me again the problems with making an Amiga virtual machine for _development_ purposes. RJ> Randell Jesup, Keeper of AmigaDos, Commodore Engineering. RJ> {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup RJ> The compiler runs RJ> Like a swift-flowing river RJ> I wait in silence. (From "The Zen of Programming") ;-) An appropriate quote for this discussion of the GURU. :-) yours truly, Lou Cavallo.
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (01/06/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: > Does anyone know how to FORCE a guru through C? Try that for a 00000003: or that for a 00000005: int *ptr = 1; int x = whatyouwant; *ptr = whatyouwant; int y = x / 0; (I didn't test them since I don't like when my Amiga crashs :-) -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?
peter@sugar.hackercorp.com (Peter da Silva) (01/07/91)
In article <ben.4184@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: > Gee, Peter, that's a lot cleaner than using the exec Alert() function... Hey man, anyone who thinks they need to force a GURU would certainly have trouble setting up the AlertMessage string. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/07/91)
In article <1991Jan6.012949.9295@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: > Well... What does everybody think?? I think a comp.binaries.amiga posting is in order for those of us without FTP access. In fact I'm getting tired of reading about all this neat stuff that's only available for FTP, while comp.{sources,binaries}.amiga sits empty... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
a218@mindlink.UUCP (Charlie Gibbs) (01/07/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >Does anyone know how to FORCE a guru through C? What includes, etc, and >maybe a ForceGuru() call? I have a program where if you enter an incorrect >response, it is supposed to guru. Does anyone have a sure-fire routine? If I really want to crash a program on any machine, I just do a division by zero. Of course, the question remains: why do you want a guru? We multitasking enthusiasts would get rather upset if you took out not only your own program but everything else on the system. A nasty message followed by termination would be much nicer. If you really want to get someone's attention, a requester would do the job quite nicely. Consider this a philosophical question. Forcing a guru for an incorrect response sounds like an awfully severe punishment. Charlie_Gibbs@mindlink.UUCP "I'm cursed with hair from HELL!" -- Night Court
x194@cs.utexas.edu (Jonathan Abbey) (01/07/91)
In article <615@caslon.cs.arizona.edu> Dave P. Schaumann writes: > >How would you do this? I have heard about being able to hook up a terminal >to help debug gurus, but I've never seen any documentation on How To Do It. > >What kind of a terminal do you need? Any & all pointers would be appreciated! Any kind of a terminal will work, although a vt100 or compatible terminal might do more than a simple dumb tty. I was speaking of using a debugger over the serial port, but I think what you've heard of is ROM-WACK, which is a simple rom-based monitor which operates over the serial port at 9600 baud to anything that will listen. You can invoke rom-wack by issuing the debug() command, or by pressing the delete key on your terminal when your amiga starts to blink its power light before rebooting. Try to find the debugger I mentioned if you can.. it's quite a good one. It's somewhere between ff350 and ff400, I _think_. You can use newzap to replace the reference to con: with one to aux: if you want a serial based debugger, or if you leave it as is it will open its own window (which should be sufficient for programs which don't take over the machine). Be forewarned, it does keep your system from guruing (I used it for Modula-2 development for a class I had, helped save me a lot of time), but you might get a little lost if you haven't been exposed to assembly. A source level debugger would be optimal, of course. If you can't find the debugger on ux1.cso.uiuc.edu by anonymous ftp, send me mail and I'll try to send you the debugger. >Dave Schaumann | My folks went to uunet.uu.net, but all >dave@cs.arizona.edu | they got me was this lousy .sig... ------------------------------------------------------------------------------- Jonathan Abbey The University of Texas at Austin x194@cs.utexas.edu Major:Unknown. Life's goals:Ditto --
limonce@pilot.njin.net (Tom Limoncelli) (01/07/91)
Every couple of months these same questions appear. Could some take all these posts and summarize them and build a new entry for the monthly posting? Randell? It could cover which Amigas have MMUs, define memory protection vs. virtual memory vs. resource tracking, why memory protection and resource tracking can't reasonable be added to AmigaDOS, what utilities (from SetCPU to Angle) do use the MMU, etc. I think those are all the related questions. Any time one is asked, all the others issues are eventually brought up too. Other things to include advice on how to not have your Amiga guru and notes about the fact that Mac and MS-DOS doesn't have any of this protection and people have to reboot then all the time but they don't complain. :-) Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter, et. al. will let me re-use their posts. Tom -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
pcooper@eecs.wsu.edu (Phil Cooper - CS495) (01/07/91)
In article <7463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >> Does anyone know how to FORCE a guru through C? > > char *p; > > for(p = 0; p != (char *)-1; p++) > *p = 0; > >This will certainly clobber the machine. Play with variations until you get >the results you want. (sigh) >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. OR, how 'bout a nice little divide by zero exception? int result, divisor = 0 ; result = 10/divisor ; That should really throw it for a loop. PC
rjc@wookumz.ai.mit.edu (Ray Cromwell) (01/07/91)
In article <Jan.6.17.58.23.1991.29680@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >Every couple of months these same questions appear. Could some take >all these posts and summarize them and build a new entry for the >monthly posting? Randell? > >It could cover which Amigas have MMUs, define memory protection vs. >virtual memory vs. resource tracking, why memory protection and >resource tracking can't reasonable be added to AmigaDOS, what ^^^^^^^^^^^^^^^^^^^^^^^^^ I've been around awhile and I know these questions come up every once in awhile. The MMU issue is hard. But there is no convincing evidence to me why resource tracking and virtual memory cannot be added to the Amiga. Just look at AllocRemember(), or better yet, ArpLibrary, these are fine examples of elementary resource tracking. In fact, resource tracking is ALWAYS done, by the programmer in his own code. If a programmer didn't check for things he had aquired in his program before closing resources would be eaten up quick. All that needs to be done is move resource tracking out of the programmers hands into the system level. Granted, the programmer is still responsible for freeing things himself. Atleast(if resource tracking is implemented at the system level) buggy programs can't force a reboot, or tasks that have been suspended/killed can be unloaded from memory. Virtual memory is easier than resource tracking. Resource tracking has a memory/speed hit, but on a 68030 its well worth it.
jesup@cbmvax.commodore.com (Randell Jesup) (01/07/91)
In article <1991Jan6.032929.1813@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > > On a side note Randell, how difficult would it be to add Resource >Tracking to the Amiga? Couldn't each library's close routine make ancient idea, can't be done without a bunch of new routines (dups of all those that don't track), since you existing things can't handle it. You also have to be careful about things that _shouldn't_ be released on exit. > Virtual Memory shouldn't be a problem either. The OS merely checks for >the presence of an MMU and enables virtual mem (for FAST mem. Its impossible >to protect Chip mem from the blitter. And I can't imagine a machine >with an MMU that doesn't have fast ram) Not so simple, at least in implementation. Some things (for various reasons) should NOT be paged out (remember this is a semi-realtime OS, it will suffer badly if certain things are paged out). However, not real read. >MMU Protection. I'm fairly certain AmyDOS will never get Unix style >protection because of the shared-memory paradigm. But how about this >. AllocMem(blah,MEMF_PRIVATE) A few things could be protected. Not much without breaking things, and would require a lot of code and MMU tables per-process. >1) Has layers library been speeded up/reworked? It gets really slow >when there are lots of open windows on the screen. Yes. Still slow in bad cases (not much one can do about it). >2) What happens when you pull down a screen (on 2.0) and a productivety >mode screen is behind it? Can monitors actually handle scan rate changes >mid screen? (15khz <-> 31khz) Magic. :-) >3) Was file notification/record locking ever added to the 2.0 FS? Both are active in recent releases. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
chanson@isis.cs.du.edu (Chris Hanson) (01/07/91)
In article <17135@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Won't work. A message usually has pointers to other areas of >arbitrary memory, or has an extended structure (ala StandardPacket), etc, etc. >As has been discussed before, MEMF_PUBLIC can't be used since each person >has had a different idea as to what should be public and what shouldn't. Ahhh, true. I spoke before thinking there. > A better idea. You _could_ allow segments of code from a loadfile >to be protected (at least without many problems), and you could allow >applications to request protected memory. Could you then please consider myself begging for such a feature? Such programs as Enforcer are great for develop-time, but if we can add some cover-the-user's-butt type of capability to all NEW programs it is a big plus in my mind. I mean, Why should my perfectly innocent program get spammed by DeluxePaint3? If I can protect the OS from my mistakes, and have my program be protected from the mistakes of others, I can sleep a little better, eh? >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. What exactly does 'Keeping' AmigaDos entail anyway? ;) Chris - Xenon -- #define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane I work, but you don't know who I work for. And they don't know I'm here. "Someone thinks of us, therefore we are."
glmwc@marlin.jcu.edu.au (Matt Crowd) (01/07/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >Does anyone know how to FORCE a guru through C? What includes, etc, and >maybe a ForceGuru() call? I have a program where if you enter an incorrect >response, it is supposed to guru. Does anyone have a sure-fire routine? void Crash() { void *zero = 0; while(1) *zero++ = 0; } I used this, or something similar once to crash the Amiga when a password protection failed. Takes ages though. Suggestions for a better crash would be appreciated. Maybe copying the screen bitmap into the Exec structure.... :-) :-) :-) >-- > Joseph Hillenburg, Secretary, Bloomington Amiga Users Group >iuvax!news!valnet!joseph jph@ais.org anlhille@iubacs.BITNET > "Only Apple could slow down a 68030 chip" --Computer Shopper Colin.
glmwc@marlin.jcu.edu.au (Matt Crowd) (01/07/91)
In article <17157@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Jan6.032929.1813@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >>2) What happens when you pull down a screen (on 2.0) and a productivety >>mode screen is behind it? Can monitors actually handle scan rate changes >>mid screen? (15khz <-> 31khz) > > Magic. :-) > Yep the hires screen behind amazed me. I just want to know how Lattice Editor knows about the screen change! Magic? >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Colin.
dailey@frith.uucp (Chris Dailey) (01/07/91)
In article <17135@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> Agreed, adding protection might break large quantities of stuff. How >>about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS, >>which tells you intimate info about the program that LoadSeg is bringing in. >>You could have a flag to signify "I'm a nice program and I work well under >>memory protection, so protect me if you can". This would also be an >>excellent place to finally settle the PURE code problem. Make a hunk flag >>that signifies, regardless of what the FS bit says, "This code is pure, >>damnit." ;) > > A better idea. You _could_ allow segments of code from a loadfile >to be protected (at least without many problems), and you could allow >applications to request protected memory. I think that would make people very happy. Would it be possible to keep that program from writing to unprotected areas of memory except when dealing with the system structures? Perhaps give system calls universal access to all memory but not the user's code? I consider myself a good programmer (maybe foolishly so :), and I'm not hit by the SEG_FAULT that often when I program for school; when I do get them, I'm thankful my errors are handled as they are. When I start programming seriously for the Amiga (ie when I get a 3000) I might not think this a major problem. (ie a 15 second boot time might not be so bad after a GURU-- now I have about 1.5 minutes, plus getting things back to the state I had them in...) >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >The compiler runs >Like a swift-flowing river >I wait in silence. (From "The Zen of Programming") ;-) -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; __ __ ___ DDR = NULL; \\__/ \/ \/ __:>- num_countries --; \__/\__/\__/ Snake in the Grass
dailey@frith.uucp (Chris Dailey) (01/07/91)
In article <Jan.6.17.58.23.1991.29680@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >Every couple of months these same questions appear. Could some take >all these posts and summarize them and build a new entry for the >monthly posting? Randell? But every time it appears there are a couple of new points brought up, even though a lot of the old stuff is re-hashed. But it still is a good idea, me thinks. >Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter, >et. al. will let me re-use their posts. >Tom >-- >tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! >tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen >tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!" P.S. Tom, I'm sure Laura would want me to say, "Hi" to you. -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; __ __ ___ DDR = NULL; \\__/ \/ \/ __:>- num_countries --; \__/\__/\__/ Snake in the Grass
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (01/07/91)
>>>>> In article <1991Jan7.110218.9448@marlin.jcu.edu.au>, >>>>> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: Matt> I used this, or something similar once to crash the Amiga when a Matt> password protection failed. Takes ages though. Suggestions for Matt> a better crash would be appreciated. Maybe copying the screen Matt> bitmap into the Exec structure.... I hope that this is a stand-alone program. If any program I ran ever crashed the machine just because I typed the wrong password, that program would be sent back for a refund _fast_. Lord save us from idiot programmers. Hamish. -- -------------------------------------------------------------------- himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (01/08/91)
In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >Does anyone know how to FORCE a guru through C? What includes, etc, and >maybe a ForceGuru() call? I have a program where if you enter an incorrect >response, it is supposed to guru. Does anyone have a sure-fire routine? > > >-- > Joseph Hillenburg, Secretary, Bloomington Amiga Users Group >iuvax!news!valnet!joseph jph@ais.org anlhille@iubacs.BITNET > "Only Apple could slow down a 68030 chip" --Computer Shopper Newsgroups: comp.sys.amiga.tech Subject: Re: Help --> How to prevent the visit from the dreaded guru Summary: Expires: References: <611@caslon.cs.arizona.edu> <1991Jan4.203339.8800@maytag.waterloo.edu> <V2H++Q_@irie.ais.org> Sender: Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) Followup-To: Distribution: Organization: Jet Propulsion Laboratory, Pasadena, CA Keywords: In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >Does anyone know how to FORCE a guru through C? What includes, etc, and >maybe a ForceGuru() call? I have a program where if you enter an incorrect >response, it is supposed to guru. Does anyone have a sure-fire routine? > > Yeah! Devide by zero. >-- > Joseph Hillenburg, Secretary, Bloomington Amiga Users Group >iuvax!news!valnet!joseph jph@ais.org anlhille@iubacs.BITNET > "Only Apple could slow down a 68030 chip" --Computer Shopper Jeff
dave@cs.arizona.edu (Dave P. Schaumann) (01/08/91)
In article <Jan.6.17.58.23.1991.29680@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: |Every couple of months these same questions appear. Could some take |all these posts and summarize them and build a new entry for the |monthly posting? Randell? | |[...] | |Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter, |et. al. will let me re-use their posts. You have my permission. Maybe I should ask that certain names be changed to protect the quick-to-post. :-/ I gotta practice sitting on my hands. |Tom |-- |tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! |tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen |tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!" Dave Schaumann | You are in a twisty maze of little dave@cs.arizona.edu | C statements, all different.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/08/91)
In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes: > >I don't care much about existing programs. I hope you wear fireproof clothes. The Amiga is *not* a machine for only exercising in programming, it is used in the real world with existing programs. You actually can buy some! >Even fake memory protection would due for many of us. How about a >command like "run such and such a program so it doesn't touch anything >other than the OS". It gets its own space, tucked away from the rest of >the system? I fear I can't explain this too well (perhaps someone other could cut in): In AmigaOS (and in most other current OS's) you can't draw a sharp line between program-owned and system-owned memory, because of all that message passing to and fro. The Amiga implementation of the message system is very fast, because it works with shared memory so that the contents needs not to be copied. And these messages are bidirectional, containing perhaps different data on reply. And all this may happen asynchroneously. - In addition there are many data structures that are created and owned by the system on demand of a program, but this program also must be able to access these data. You see, it's simply not possible to define the "own space" of a normal Amiga program, so it also can't be easily protected by a MMU. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
stoller@cbmcel.UUCP (Martin S. Stoller) (01/08/91)
In article <1991Jan7.110218.9448@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >>Does anyone know how to FORCE a guru through C? What includes, etc, and >>maybe a ForceGuru() call? I have a program where if you enter an incorrect >>response, it is supposed to guru. Does anyone have a sure-fire routine? [CODE DELETED] >I used this, or something similar once to crash the Amiga when a >password protection failed. Takes ages though. Suggestions >for a better crash would be appreciated. Maybe copying the >screen bitmap into the Exec structure.... >:-) :-) :-) >> Joseph Hillenburg, Secretary, Bloomington Amiga Users Group >>iuvax!news!valnet!joseph jph@ais.org anlhille@iubacs.BITNET >> "Only Apple could slow down a 68030 chip" --Computer Shopper >Colin. Hmmm... As long as no GURU catchers are watching, then x=5/0; works fine. Try it. (If your compiler is SO SMART that it catches that mistake, then use variables instead...) This fires off the DIVIDE THRU NULL interuppt. It works, most of the time. Now WHY would anyone want to GURU the AMIGA? You testing a new GURU TRAP or somethin'? -- Regards, UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller
chanson@isis.cs.du.edu (Chris Hanson) (01/09/91)
In article <1991Jan7.181114.19016@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes: >>Does anyone know how to FORCE a guru through C? What includes, etc, and >>maybe a ForceGuru() call? I have a program where if you enter an incorrect > Yeah! Devide by zero. Another, perhaps more random way would be to set the blitter into it's 'NASTY' mode, and instruct it to fill all of CHIP memory with zeros. This may be quick, or it may take a few seconds. I have (ostensibly) never done this to my poor machine. I do however, guarentee that this WILL crash the machine. It may not even get to GURUing, it may just Crash & Burn. Or, perhaps you could merely simulate the GURU with an appropriately set up Alert(). I believe, if it is a DEADEND_ALERT, the machine will happily reset for you after it is done displaying the ALert. Do I want to know what kind of program this is for, Joseph? >> Joseph Hillenburg, Secretary, Bloomington Amiga Users Group > Jeff Chris - Xenon -- #define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane I work, but you don't know who I work for. And they don't know I'm here. "My stack runneth over." -Brian Walder
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/09/91)
In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >VM is NOT a solution. This is the second post that says VM doesn't do task protection. I was taught that VM gives every task its own unique address space, and when a memory fetch was made, a combination of hardware/firmware mapped this into an actual address in memory (after a possible disk fetch). I realize that any machine that needs a RAM: disk has no business running VM. When I said VM, I was only thinking of the 'unique address space' aspect of it. I also realize that, as explained elsewhere, because of message passing, memory protection would break the current OS. *sigh*. There are two accepted meanings for the term "virtual memory". The most common one (at least, the one I see most often) is "demand paged virtual memory", which is a solution to the budget-constrained memory problem. This does _not_ imply that every task has it's own private address space. You can do demand paging on a large virtual address space, and have all tasks live in that same address space. The other meaning is the one you allude to, "mapped virtual memory", where each task has it's own memory map in the MMU. No paging - or even swapping - needed. OS/9 used to do this on the 6809, and Unix does it on the PDP-11. Unix practically requires support for this feature. The two concepts are orthogonal, though most people who do demand paging also provide mapping. BTW, if you look around in the Unix groups, you'll find people arguing that RAM: disks are wonderful things (even on ther demand paged virtual memory systems), and trying to find drivers for them. And no, I can't explain that either. <mike --
hclausen@adspdk.UUCP (Henrik Clausen) (01/09/91)
In article <17157@cbmvax.commodore.com>, Randell Jesup writes: > In article <1991Jan6.032929.1813@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > > > > Virtual Memory shouldn't be a problem either. The OS merely checks for > >the presence of an MMU and enables virtual mem (for FAST mem. Its impossible > >to protect Chip mem from the blitter. And I can't imagine a machine > >with an MMU that doesn't have fast ram) > > Not so simple, at least in implementation. Some things (for various > reasons) should NOT be paged out. Certainly things like message ports and other time-critical stuff would need to stay in physical memory. There's an interesting point in that the critical items are usually of rather small size, while the real fillers (DTP documents, graphics, text etc) are usually non-critical. The point is, the OS could (on MMU machines) set up an area for virtual memory, and applications could ask explicitly for memory that can swapped (MEMF_VIRT?). Thus, the real fillers could have the advantage, and the programs that don't use much ram could get along without VM. I suppose code hunks could be marked non-critical as well? This would bring us most of the advantages of VM without breaking anyone, if I'm not mistaken. > A few things could be protected. Not much without breaking things, > and would require a lot of code and MMU tables per-process. Obviously a more complex thing to do. I wouldn't expect this to happen. Have a nice day -Henrik ______________________________________________________________________________ | Henrik Clausen, Graffiti Data | If the Doors of Perception where cleansed, | | ...{pyramid|rutgers}!cbmvax! | Man would see Reality as it is - Infinite. | \______cbmehq!adspdk!hclausen___|_________________________________W. Blake___/
glmwc@marlin.jcu.edu.au (Matt Crowd) (01/09/91)
In article <1991Jan7.150214.24971@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >>>>>> In article <1991Jan7.110218.9448@marlin.jcu.edu.au>, >>>>>> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >Matt> I used this, or something similar once to crash the Amiga when a >Matt> password protection failed. Takes ages though. Suggestions for >Matt> a better crash would be appreciated. Maybe copying the screen >Matt> bitmap into the Exec structure.... > >I hope that this is a stand-alone program. If any program I ran ever >crashed the machine just because I typed the wrong password, that >program would be sent back for a refund _fast_. > >Lord save us from idiot programmers. > You are hardly likely to get the word wrong THREE times if you bought the program!! Pirates deserve all they get. What do you want me to do? Print "So you pirated this game. Have a nice day"? Anyway, as most games don't even multitask, if the program quit from a state of no OS it may as well crash. >himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon Colin Adams
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/09/91)
In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: > > But to suggest that anyone >just "write programs that don't guru" (under *any circumstances*) is silly. I >doubt there is a single programmer who would be willing to attempt to live up >to such a standard. Perhaps I miss your point a little, but YES: Anyone should ALWAYS at least *attempt* to write non-guruing code! -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
kevin@cbmvax.commodore.com (Kevin Klop) (01/10/91)
In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <1991Jan8.213049.7683@motaus.sps.mot.com> skipper@motaus.sps.mot.com (Skipper Smith) writes: >certainly agree, especially on the Amiga, that it is the programmer's >responsibility to thoroughly test all code. But to suggest that anyone >just "write programs that don't guru" (under *any circumstances*) is silly. I >doubt there is a single programmer who would be willing to attempt to live up >to such a standard. Ummm, it is ALWAYS my GOAL to have a bug free program. As such, as soon as someone reports a GURU or bug to me, I fix it and give the fix to everyone with a copy of the program. I do NOT blame the OS for my bug, nor believe that the OS should be modified in order to "put up" with errors in _my_ code. -- Kevin -- Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin Commodore-Amiga, Inc. ``Be excellent to each other.'' - Bill and Ted's most excellent adventure Disclaimer: _I_ don't know what I said, much less my employer.
kevin@cbmvax.commodore.com (Kevin Klop) (01/10/91)
In article <1991Jan9.092435.10710@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >>>>>>> In article <1991Jan7.110218.9448@marlin.jcu.edu.au>, >>>>>>> glmwc@marlin.jcu.edu.au ( >> > >You are hardly likely to get the word wrong THREE times if >you bought the program!! Pirates deserve all they get. > While I agree that Pirates deserve to be squashed, I can hardly agree with you that I or some other user won't get a password wrong three times in a row - I've managed it several times, like when I'm tired and my fingers are a little fumbly, etc. As to the assertion: >What do you want me to do? Print "So you pirated this game. Have >a nice day"? Anyway, as most games don't even multitask, if the >program quit from a state of no OS it may as well crash. I disagree. There are several games that push the OS aside, run to their heart's content, and then exit cleanly to the workbench. A game that requires a reboot in order to exit it irks me to no end. -- Kevin -- Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin Commodore-Amiga, Inc. ``Be excellent to each other.'' - Bill and Ted's most excellent adventure Disclaimer: _I_ don't know what I said, much less my employer.
hill@evax.arl.utexas.edu (Adam Hill) (01/10/91)
Tad is still experiencing disk crunch where csa.b is stored. So until
some magic disk space appears (or unless we pitch in and buy some Hd's )
we will not get any more postings to csa.[b|s]. :-(
--
adam hill
hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA!
Amiga... Multimedia NOW
Most Common Phrase at DevCon '90 - "Shhhhhhh.." dave@cs.arizona.edu (Dave P. Schaumann) (01/10/91)
In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes: >Ummm, it is ALWAYS my GOAL to have a bug free program. As such, as soon as >someone reports a GURU or bug to me, I fix it and give the fix to everyone >with a copy of the program. I do NOT blame the OS for my bug, nor believe that >the OS should be modified in order to "put up" with errors in _my_ code. > > -- Kevin -- My point is an issue of robustness. Give someone a computer, and the next thing you know, they want to write a program on it ;). Every time you go through the program development process, you have to deal with bugs in your code. Often, these bugs are of a catastrophic nature. I think that expecting the OS to deal with programs that experience such bugs in a graceful manner is not unreasonable. I have been taught that program robustness (in dealing with user input and environment conditions) is nearly as important as program correctness. Should an OS be held up to any less of a standard? I don't blame any OS for bugs introduced by *my* code. But I do believe that an OS should be as robust as possible in dealing with what a user program might do. >Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin >Commodore-Amiga, Inc. > > ``Be excellent to each other.'' > - Bill and Ted's most excellent adventure > >Disclaimer: _I_ don't know what I said, much less my employer. Dave Schaumann | You are in a twisty maze of little dave@cs.arizona.edu | C statements, all different.
kevin@cbmvax.commodore.com (Kevin Klop) (01/11/91)
In article <630@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes: >>Ummm, it is ALWAYS my GOAL to have a bug free program. As such, as soon as >>someone reports a GURU or bug to me, I fix it and give the fix to everyone >>with a copy of the program. I do NOT blame the OS for my bug, nor believe that >>the OS should be modified in order to "put up" with errors in _my_ code. >> >> -- Kevin -- > >My point is an issue of robustness. Give someone a computer, and the next >thing you know, they want to write a program on it ;). Every time you go >through the program development process, you have to deal with bugs in your >code. Often, these bugs are of a catastrophic nature. I think that expecting >the OS to deal with programs that experience such bugs in a graceful manner >is not unreasonable. I have been taught that program robustness (in dealing >with user input and environment conditions) is nearly as important as program >correctness. Should an OS be held up to any less of a standard? > >I don't blame any OS for bugs introduced by *my* code. But I do believe that >an OS should be as robust as possible in dealing with what a user program >might do. > > >>Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin >>Commodore-Amiga, Inc. >> >> ``Be excellent to each other.'' >> - Bill and Ted's most excellent adventure >> >>Disclaimer: _I_ don't know what I said, much less my employer. > > >Dave Schaumann | You are in a twisty maze of little >dave@cs.arizona.edu | C statements, all different. The problem with this is the difficulty in a non memory protected model. There is nothing to stop the user program from trashing system structures, passing pointers that ostensibly point to buffers and actually point to program code, etc. to the operating system, nor is there any way to stop a program from trashing some OTHER program's code and data. "So put memory protection in" sounds like a possible answer, but has been hashed over and over again, this is no easy task. The ramifications are pretty far reaching and too detailed for me to get into now. Ditto for resource tracking so that memory, devices, etc. are freed when a program exits. I have more than one program that opens something and then passes the IO request to some OTHER task. The original task then exits. I certainly do NOT want the OS closing that device or deallocating the IO request memory on me. The question you raise, while a valid concern, is a tough one. How much are we willing to trade off? Do we need to put an MMU in the A500s and thereby raise the price of them significantly? If not, then we need two (or more) operating systems. One to deal with MMU systems and one that doesn't. The two OSs would be VERY dissimilar, and would thereby at least double the R&D load here at Commodore. -- Kevin --
glmwc@marlin.jcu.edu.au (Matt Crowd) (01/12/91)
In article <22567@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >>Anyway, as most games don't even multitask, if the >>program quit from a state of no OS it may as well crash. > >Please be sure and tell us all when you finish your game. I'd like to warn >all of my friends in advance about it. I sure wouldn't want any of them >to support such idiocy as you're putting into it. >-- Did I say my game killed the OS? Did I say my game didn't multitask perfectly? Did I say my game isn't hard drive installable and doesn't come with a HD install program to help? Did I say my game doesn't work on the Amiga 3000? Did I say my game doesn't work with 2.0 and doesn't use the standard file requester if running on 2.0? NO! Because all of the above is not true. >Mike Farren farren@well.sf.ca.us As for crashing the machine after the password fails.... well I'm still thinking about it. Colin Adams.
davids@ucscf.UCSC.EDU (Dave Schreiber) (01/13/91)
In article <1991Jan12.034631.18571@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >In article <22567@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >>glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >> >>>Anyway, as most games don't even multitask, if the >>>program quit from a state of no OS it may as well crash. >> >>Please be sure and tell us all when you finish your game. I'd like to warn >>all of my friends in advance about it. I sure wouldn't want any of them >>to support such idiocy as you're putting into it. I agree totally. I've usually got too much going on my 3000 to risk losing it all because some programmer is out for blood. >Did I say my game killed the OS? You used the "as most games don't even multitask" statement as justification for crashing the machine if the user messed up the copy-protection. If your game doesn't throw out the OS, and in fact multitasks perfectly, then you're arguing that, because OTHER games that throw out the OS effectively crash when the copy protection scheme says "TROUBLE!", it's all right for YOUR game to do so even though it doesn't throw out the OS. >Did I say my game didn't multitask perfectly? >Did I say my game isn't hard drive installable and doesn't > come with a HD install program to help? >Did I say my game doesn't work on the Amiga 3000? >Did I say my game doesn't work with 2.0 and doesn't use > the standard file requester if running on 2.0? > >NO! Because all of the above is not true. I don't remember anybody claiming that your game didn't multitask, couldn't be installed on a hard drive, wouldn't work on a 3000, or wouldn't work under 2.0. _You_ implied that the game threw out the OS. >>Mike Farren farren@well.sf.ca.us >As for crashing the machine after the password fails.... >well I'm still thinking about it. Think about this: if you crash the machine, you will drive away legitimate users (me for one). You will not stop pirates, however; an unprotected version of your software will be floating around "out there" within days of it's release. The net result will be a lower number of sales. If that's the way you want it, fine; nobody's forcing you to make money :-). >Colin Adams. Followups to comp.sys.amiga.misc -- Dave Schreiber davids@slugmail.ucsc.edu or (but not both) davids@ucscb.ucsc.edu "It was fun learning about logic, but I don't see where or when I will ever use it again."
aduncan@rhea.trl.oz (Allan Duncan) (01/14/91)
From article <17133@cbmvax.commodore.com>, by jesup@cbmvax.commodore.com (Randell Jesup): > > Remember, we do official developer support on BIX, not anywhere else - our > messages here are unofficial and on a personal basis. > Yes, but those who do not reside in continental USA have this strange aversion to link costs to BIX, but still would like access to these useful tools. Some appear on disks accompanying the DEVCON notes that we can buy months after the event and at quite high cost, some on the restricted beta releases. What would be nice would be the appearance of those utilities that can be made public on CBA and or Fred's collection, which make it the the far corners of this planet. Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
jesup@cbmvax.commodore.com (Randell Jesup) (01/15/91)
In article <2587@trlluna.trl.oz> aduncan@rhea.trl.oz (Allan Duncan) writes: >From article <17133@cbmvax.commodore.com>, by jesup@cbmvax.commodore.com (Randell Jesup): >> >> Remember, we do official developer support on BIX, not anywhere else - our >> messages here are unofficial and on a personal basis. > >Yes, but those who do not reside in continental USA have this strange >aversion to link costs to BIX, but still would like access to these >useful tools. We have other arrangements (adsp) for non-american developers. I do not know if these arrangements cover australia - certainly they cover europe. Contact your local support manager or CATS for more info. > What would be nice would be the appearance of >those utilities that can be made public on CBA and or Fred's collection, >which make it the the far corners of this planet. I suspect these will be on a Fish disk soon, though I don't know for sure. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
david@twg.com (David S. Herron) (01/15/91)
In article <MWM.91Jan8180131@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >BTW, if you look around in the Unix groups, you'll find people arguing >that RAM: disks are wonderful things (even on ther demand paged >virtual memory systems), and trying to find drivers for them. And no, >I can't explain that either. Well, see, I've always had this evil desire to have the swap device be a RAM disk ... ;-) Something that seems vaguely useful is in SunOS v4.1+ .. TMPFS .. which lets /tmp be allocated out of virtual memory. I dunno .... Now.. if swap space were to come from any free space, like it does on Mach, *THAT* would be useful ... David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- MS-DOS ... The ultimate computer virus.