mrimages@beach.gal.utexas.edu (05/15/91)
From: R.Luebbert, University of Texas Medical Branch at Galveston 1) Never heard a reply to the earlier question about a kill command for AmigaDOS. Is this ever going to be developed? It sure would save my ctrl-A-A keys from wear and tear after dead programs start piling up. 2) Is there a way to safely (or reasonably safely) change the contents of screens/windows opened by other processes? Using public screens would be lovely, unfortunately the screens I want to write to are created by programs that do not use public screens, like my term program. I have been able to locate and write data to the screens, but after I do so, I cannot open new screens, change the resolution of screens already open (like CED), or run my compiler. I usually get the guru 8100000C after moving on to other tasks, always at the same address. I am always careful about using LockIBase before poking around in intuitionbase, but it doesn't seem to help. I am using AmigaDOS 2.0. Any questions or comments would be greatly appreciated.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/16/91)
In article <378.2830d367@beach.gal.utexas.edu> mrimages@beach.gal.utexas.edu writes: >From: R.Luebbert, University of Texas Medical Branch at Galveston > >1) Never heard a reply to the earlier question about a kill command for >AmigaDOS. Is this ever going to be developed? It sure would save my ctrl-A-A >keys from wear and tear after dead programs start piling up. Oh huh, this one again. (You know, we have such discussions at least every four weeks.) Now, there is no kill command *possible* in AmigaDOS, because we have no resource tracking, mainly for performance and compatibility reasons. So the OS doesn't know what memory or file locks are occupied by this task and thus can't free them (e.g. screens/windows, etc.). To say it clearly: Yes you can stop a program (there are PD tools like Xoper available), but you can't free all resources. So this is of not much use. (Please *not again* this resource tracking discussion, noooo!!) >2) Is there a way to safely (or reasonably safely) change the contents of >screens/windows opened by other processes? Using public screens would be >lovely, unfortunately the screens I want to write to are created by programs >that do not use public screens, like my term program. Why on earth do you want to stomp someone other's screen? This is normally considered a no-no. But you mentioned public screens: Yes, these are part of the news in OS 2.0 and are intended exactly to allow this. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
mrimages@beach.gal.utexas.edu (05/17/91)
>>2) Is there a way to safely (or reasonably safely) change the contents of >>screens/windows opened by other processes? Using public screens would be >>lovely, unfortunately the screens I want to write to are created by programs >>that do not use public screens, like my term program. > > Why on earth do you want to stomp someone other's screen? This is > normally considered a no-no. But you mentioned public screens: Yes, > these are part of the news in OS 2.0 and are intended exactly to > allow this. Public screens are a marvelous idea and I am glad that Commodore decided to implement them. Still, have you ever wanted to print a small message or perhaps a clock in the most remote of places of another application's screen? OK, maybe you haven't, but I have. Anyway, here's what I do, and it works on my screen, but then the machine has problems running new tasks or opening new screens or windows. In my new program I have a screen structure assigned the address to the screen opened by the other application. (basically by locking the IntuitionBase and making my_screen=IntuitionBase->FirstScreen->NextScreen, then unlocking the base again.) Then I write on the screen like I would any other screen. Why would this present a problem? Seems pretty harmless to me, especially because I am not changing any Base values. R. Luebbert = mrimages@beach.gal.utexas.edu (U.T. Medical Branch Galveston)
mrimages@beach.gal.utexas.edu (05/18/91)
In article <1991May17.193919.24599@wehi.dn.mu.oz>, baxter_a@wehi.dn.mu.oz writes: > In article <385.2833079e@beach.gal.utexas.edu>, mrimages@beach.gal.utexas.edu > writes: >> Still, have you ever wanted to print a small message or perhaps a >> clock in the most remote of places of another application's screen? OK, maybe >> you haven't, but I have. Anyway, here's what I do, and it works on my screen, >> but then the machine has problems running new tasks or opening new screens or >> windows. In my new program I have a screen structure assigned the address to >> the screen opened by the other application. (basically by locking the >> IntuitionBase and making my_screen=IntuitionBase->FirstScreen->NextScreen, >> then unlocking the base again.) Then I write on the screen like I would any >> other screen. Why would this present a problem? Seems pretty harmless to me, >> especially because I am not changing any Base values. > > And then the screen closes. > > And then you write to it. Well, actually, this is not possible, because if IntuitionBase->FirstScreen->NextScreen==NULL the program exits without writing anything anywhere. Each time I am about to write I make SURE the screen is still there and still has the same address, using basically the same technique as above every time I want to update my message. R. Luebbert = mrimages@beach.gal.utexas.edu (U.T. Medical Branch Galveston)
baxter_a@wehi.dn.mu.oz (05/18/91)
In article <1228@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: ... > Oh huh, this one again. (You know, we have such discussions at least > every four weeks.) > Now, there is no kill command *possible* in AmigaDOS, because we have > no resource tracking, mainly for performance and compatibility reasons. > So the OS doesn't know what memory or file locks are occupied by this > task and thus can't free them (e.g. screens/windows, etc.). To say it > clearly: Yes you can stop a program (there are PD tools like Xoper > available), but you can't free all resources. So this is of not much use. > (Please *not again* this resource tracking discussion, noooo!!) Okay, fine. But why can't a symbolic debugger handle allocation/return type issues. I've been hunting an 800 byte memory loss with SDB (Lattice) for 2 weeks. If the debugger maintained a list of resources allocated and returned, it would be able to give me the location of the lost memory and what line allocated it. Regards Alan
baxter_a@wehi.dn.mu.oz (05/18/91)
In article <385.2833079e@beach.gal.utexas.edu>, mrimages@beach.gal.utexas.edu writes: > Still, have you ever wanted to print a small message or perhaps a > clock in the most remote of places of another application's screen? OK, maybe > you haven't, but I have. Anyway, here's what I do, and it works on my screen, > but then the machine has problems running new tasks or opening new screens or > windows. In my new program I have a screen structure assigned the address to > the screen opened by the other application. (basically by locking the > IntuitionBase and making my_screen=IntuitionBase->FirstScreen->NextScreen, > then unlocking the base again.) Then I write on the screen like I would any > other screen. Why would this present a problem? Seems pretty harmless to me, > especially because I am not changing any Base values. And then the screen closes. And then you write to it. Regards Alan
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/22/91)
In article <1991May17.193234.24598@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >In article <1228@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >... >> (Please *not again* this resource tracking discussion, noooo!!) > >Okay, fine. But why can't a symbolic debugger handle allocation/return >type issues. I've been hunting an 800 byte memory loss with SDB (Lattice) >for 2 weeks. If the debugger maintained a list of resources allocated and >returned, it would be able to give me the location of the lost memory >and what line allocated it. Well, as the OS doesn't do it, every program is responsible to maintain and track its resources. If you see such a loss when using SDB, it's certainly a fault of SDB. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
lindwall@beowulf.ucsd.edu (John Lindwall) (05/25/91)
In article <1991May24.203418.24601@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >Something must have got lost in the translation! _I_ know it is not the >fault of SDB. I know that _MY_ code is loosing the memory. But why? Where? >Since SDB actually steps line by line, it could maintain a list of >memory allocated and let me know what I didn't return, which would be a lovely >programming tool and one I need just at the moment (and judging by the "I'm >loosing my memory posts", others need fairly regularly). Take a look at Amiga World Tech Journal Vol 1, No 2. There is an article by Doug Walker called "Debugging Memory Errors". It describes the most common memory allocation errors and techniques for avoiding them. It also includes a library of routines which replace AllocMem/malloc/Free/free/etc.. with routines that perform sanity checks on your calls. The library is on the disk (I hate paying for the disk! Whay not a BBS?). This library sounds perfect for you -- it is supposed to report line numbers in YOUR SOURCE CODE for an offending memory allocation/deallocation call! Note: I haven't used the library yet, but since its written by Doug Walker I'm sure its excellent. John -- John Lindwall lindwall@cs.ucsd.edu "Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot
billk@hawk.cs.ukans.edu (Bill Kinnersley) (05/25/91)
In article <1991May24.203418.24601@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes:
:
: Something must have got lost in the translation! _I_ know it is not the
: fault of SDB. I know that _MY_ code is loosing the memory. But why? Where?
: Since SDB actually steps line by line, it could maintain a list of
: memory allocated and let me know what I didn't return, which would be a lovely
: programming tool and one I need just at the moment (and judging by the "I'm
: loosing my memory posts", others need fairly regularly). It is one thing
: to say the system does not support resource tracking, but it is another to
: say the tools to ensure a program frees all its resources need not exist
: because it's the programmer's job.
:
Have you tried using the MemTrace routines on Fish Disk 163? That's what
they're designed to do.
--
--Bill Kinnersley
billk@hawk.cs.ukans.edu
226 Transfer complete.baxter_a@wehi.dn.mu.oz (05/25/91)
In article <1237@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > In article <1991May17.193234.24598@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >>In article <1228@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>... >>> (Please *not again* this resource tracking discussion, noooo!!) >> >>Okay, fine. But why can't a symbolic debugger handle allocation/return >>type issues. I've been hunting an 800 byte memory loss with SDB (Lattice) >>for 2 weeks. If the debugger maintained a list of resources allocated and >>returned, it would be able to give me the location of the lost memory >>and what line allocated it. > > Well, as the OS doesn't do it, every program is responsible to maintain > and track its resources. If you see such a loss when using SDB, it's > certainly a fault of SDB. Something must have got lost in the translation! _I_ know it is not the fault of SDB. I know that _MY_ code is loosing the memory. But why? Where? Since SDB actually steps line by line, it could maintain a list of memory allocated and let me know what I didn't return, which would be a lovely programming tool and one I need just at the moment (and judging by the "I'm loosing my memory posts", others need fairly regularly). It is one thing to say the system does not support resource tracking, but it is another to say the tools to ensure a program frees all its resources need not exist because it's the programmer's job. Regards Alan